From 22083287912ebd552e33b79f7c567bc966376d43 Mon Sep 17 00:00:00 2001 From: Richard Purdie Date: Fri, 15 Oct 2010 11:55:59 +0100 Subject: handbook: Move into documentation directory Signed-off-by: Richard Purdie --- handbook/ChangeLog | 38 - handbook/Makefile | 38 - handbook/TODO | 11 - handbook/bsp-guide.xml | 61 - handbook/bsp.xml | 451 -------- handbook/development.xml | 825 -------------- handbook/examples/hello-autotools/hello_2.3.bb | 7 - handbook/examples/hello-single/files/helloworld.c | 8 - handbook/examples/hello-single/hello.bb | 16 - handbook/examples/libxpm/libxpm_3.5.6.bb | 13 - handbook/examples/mtd-makefile/mtd-utils_1.0.0.bb | 13 - handbook/extendpoky.xml | 1040 ----------------- handbook/faq.xml | 314 ------ handbook/introduction.xml | 352 ------ handbook/poky-beaver.png | Bin 26252 -> 0 bytes handbook/poky-handbook.png | Bin 17829 -> 0 bytes handbook/poky-handbook.xml | 102 -- handbook/poky-logo.svg | 117 -- handbook/ref-bitbake.xml | 348 ------ handbook/ref-classes.xml | 455 -------- handbook/ref-features.xml | 302 ----- handbook/ref-images.xml | 72 -- handbook/ref-structure.xml | 514 --------- handbook/ref-variables.xml | 879 --------------- handbook/ref-varlocality.xml | 211 ---- handbook/resources.xml | 142 --- handbook/screenshots/ss-anjuta-poky-1.png | Bin 96531 -> 0 bytes handbook/screenshots/ss-anjuta-poky-2.png | Bin 76419 -> 0 bytes handbook/screenshots/ss-oprofile-viewer.png | Bin 51240 -> 0 bytes handbook/screenshots/ss-sato.png | Bin 38689 -> 0 bytes handbook/style.css | 953 ---------------- handbook/template/Vera.ttf | Bin 65932 -> 0 bytes handbook/template/Vera.xml | 1 - handbook/template/VeraMoBd.ttf | Bin 49052 -> 0 bytes handbook/template/VeraMoBd.xml | 1 - handbook/template/VeraMono.ttf | Bin 49224 -> 0 bytes handbook/template/VeraMono.xml | 1 - handbook/template/draft.png | Bin 24847 -> 0 bytes handbook/template/fop-config.xml | 58 - handbook/template/ohand-color.svg | 150 --- handbook/template/poky-db-pdf.xsl | 64 -- handbook/template/poky-handbook.png | Bin 32145 -> 0 bytes handbook/template/poky.svg | 163 --- handbook/template/titlepage.templates.xml | 1240 --------------------- handbook/tools/poky-docbook-to-pdf | 45 - handbook/usingpoky.xml | 316 ------ 46 files changed, 9321 deletions(-) delete mode 100644 handbook/ChangeLog delete mode 100644 handbook/Makefile delete mode 100644 handbook/TODO delete mode 100644 handbook/bsp-guide.xml delete mode 100644 handbook/bsp.xml delete mode 100644 handbook/development.xml delete mode 100644 handbook/examples/hello-autotools/hello_2.3.bb delete mode 100644 handbook/examples/hello-single/files/helloworld.c delete mode 100644 handbook/examples/hello-single/hello.bb delete mode 100644 handbook/examples/libxpm/libxpm_3.5.6.bb delete mode 100644 handbook/examples/mtd-makefile/mtd-utils_1.0.0.bb delete mode 100644 handbook/extendpoky.xml delete mode 100644 handbook/faq.xml delete mode 100644 handbook/introduction.xml delete mode 100644 handbook/poky-beaver.png delete mode 100644 handbook/poky-handbook.png delete mode 100644 handbook/poky-handbook.xml delete mode 100644 handbook/poky-logo.svg delete mode 100644 handbook/ref-bitbake.xml delete mode 100644 handbook/ref-classes.xml delete mode 100644 handbook/ref-features.xml delete mode 100644 handbook/ref-images.xml delete mode 100644 handbook/ref-structure.xml delete mode 100644 handbook/ref-variables.xml delete mode 100644 handbook/ref-varlocality.xml delete mode 100644 handbook/resources.xml delete mode 100644 handbook/screenshots/ss-anjuta-poky-1.png delete mode 100644 handbook/screenshots/ss-anjuta-poky-2.png delete mode 100644 handbook/screenshots/ss-oprofile-viewer.png delete mode 100644 handbook/screenshots/ss-sato.png delete mode 100644 handbook/style.css delete mode 100644 handbook/template/Vera.ttf delete mode 100644 handbook/template/Vera.xml delete mode 100644 handbook/template/VeraMoBd.ttf delete mode 100644 handbook/template/VeraMoBd.xml delete mode 100644 handbook/template/VeraMono.ttf delete mode 100644 handbook/template/VeraMono.xml delete mode 100644 handbook/template/draft.png delete mode 100644 handbook/template/fop-config.xml delete mode 100644 handbook/template/ohand-color.svg delete mode 100644 handbook/template/poky-db-pdf.xsl delete mode 100644 handbook/template/poky-handbook.png delete mode 100644 handbook/template/poky.svg delete mode 100644 handbook/template/titlepage.templates.xml delete mode 100755 handbook/tools/poky-docbook-to-pdf delete mode 100644 handbook/usingpoky.xml (limited to 'handbook') diff --git a/handbook/ChangeLog b/handbook/ChangeLog deleted file mode 100644 index e0b51d4a1..000000000 --- a/handbook/ChangeLog +++ /dev/null @@ -1,38 +0,0 @@ -2008-02-29 Matthew Allum - - * development.xml: - Disable images too big / lack context for now. - * introduction.xml: - Remove some OH specific stuff. - * style.css: - Remove limit on image size - -2008-02-15 Matthew Allum - - * introduction.xml: - Minor tweaks to 'What is Poky' - -2008-02-15 Matthew Allum - - * poky-handbook.xml: - * poky-handbook.png - * poky-beaver.png - * poky-logo.svg: - * style.css: - Add some title images. - -2008-02-14 Matthew Allum - - * development.xml: - remove uri's - * style.css: - Fix glossary - -2008-02-06 Matthew Allum - - * Makefile: - Add various xslto options for html. - * introduction.xml: - Remove link in title. - * style.css: - Add initial version diff --git a/handbook/Makefile b/handbook/Makefile deleted file mode 100644 index 4b3035e79..000000000 --- a/handbook/Makefile +++ /dev/null @@ -1,38 +0,0 @@ -all: html pdf tarball - -pdf: - ./tools/poky-docbook-to-pdf poky-handbook.xml ./template - ./tools/poky-docbook-to-pdf bsp-guide.xml ./template - -XSLTOPTS = --stringparam html.stylesheet style.css \ - --stringparam chapter.autolabel 1 \ - --stringparam appendix.autolabel 1 \ - --stringparam section.autolabel 1 \ - --stringparam section.label.includes.component.label 1 \ - --xinclude - -## -# These URI should be rewritten by your distribution's xml catalog to -# match your localy installed XSL stylesheets. -XSL_BASE_URI = http://docbook.sourceforge.net/release/xsl/current -XSL_XHTML_URI = $(XSL_BASE_URI)/xhtml/docbook.xsl - -html: -# See http://www.sagehill.net/docbookxsl/HtmlOutput.html - xsltproc $(XSLTOPTS) -o poky-handbook.html $(XSL_XHTML_URI) poky-handbook.xml - xsltproc $(XSLTOPTS) -o bsp-guide.html $(XSL_XHTML_URI) bsp-guide.xml - -tarball: html - tar -cvzf poky-handbook.tgz poky-handbook.html style.css screenshots/ss-sato.png poky-beaver.png poky-handbook.png - -validate: - xmllint --postvalid --xinclude --noout poky-handbook.xml - -OUTPUTS = poky-handbook.tgz poky-handbook.html poky-handbook.pdf bsp-guide.pdf -SOURCES = *.png *.xml *.css *.svg - -publish: - scp -r $(OUTPUTS) $(SOURCES) o-hand.com:/srv/www/pokylinux.org/doc/ - -clean: - rm $(OUTPUTS) diff --git a/handbook/TODO b/handbook/TODO deleted file mode 100644 index ee0db977c..000000000 --- a/handbook/TODO +++ /dev/null @@ -1,11 +0,0 @@ -Handbook Todo List: - - * Document adding a new IMAGE_FEATURE to the customising images section - * Add instructions about using zaurus/openmoko emulation - * Add component overview/block diagrams - * Software Deevelopment intro should mention its software development for - intended target and could be a different arch etc and thus special case. - * Expand insane.bbclass documentation to cover tests - * Document remaining classes (see list in ref-classes) - * Document formfactor - diff --git a/handbook/bsp-guide.xml b/handbook/bsp-guide.xml deleted file mode 100644 index 2f4906c17..000000000 --- a/handbook/bsp-guide.xml +++ /dev/null @@ -1,61 +0,0 @@ - - - - - - - - - - - - Board Support Package (BSP) Developers Guide - - - - Richard Purdie - - Intel Corporation - - richard@linux.intel.com - - - - - - 0.4 - 26 May 2010 - Alpha Draft - - - - - 2010 - Intel Corporation - - - - - Permission is granted to copy, distribute and/or modify this document under - the terms of the Creative Commons Attribution-Non-Commercial-Share Alike 2.0 UK: England & Wales as published by Creative Commons. - - - - - - - - - Index - - - - diff --git a/handbook/bsp.xml b/handbook/bsp.xml deleted file mode 100644 index e0ca31732..000000000 --- a/handbook/bsp.xml +++ /dev/null @@ -1,451 +0,0 @@ - - - - - Board Support Packages (BSP) - Developers Guide - - - A Board Support Package (BSP) is a collection of information which together - defines how to support a particular hardware device, set of devices, or - hardware platform. It will include information about the hardware features - present on the device and kernel configuration information along with any - additional hardware drivers required. It will also list any additional software - components required in addition to a generic Linux software stack for both - essential and optional platform features. - - - - The intent of this document is to define a structure for these components - so that BSPs follow a commonly understood layout, allowing them to be - provided in a common form that everyone understands. It also allows end-users - to become familiar with one common format and encourages standardisation - of software support of hardware. - - - - The proposed format does have elements that are specific to the Poky and - OpenEmbedded build systems. It is intended that this information can be - used by other systems besides Poky/OpenEmbedded and that it will be simple - to extract information and convert to other formats if required. The format - described can be directly accepted as a layer by Poky using its standard - layers mechanism, but it is important to recognise that the BSP captures all - the hardware specific details in one place in a standard format, which is - useful for any person wishing to use the hardware platform regardless of - the build system in use. - - - - The BSP specification does not include a build system or other tools - - it is concerned with the hardware specific components only. At the end - distribution point the BSP may be shipped combined with a build system - and other tools, but it is important to maintain the distinction that these - are separate components which may just be combined in certain end products. - - -
- Example Filesystem Layout - - - The BSP consists of a file structure inside a base directory, meta-bsp in this example, where "bsp" is a placeholder for the machine or platform name. Examples of some files that it could contain are: - - - - -meta-bsp/ -meta-bsp/binary/zImage -meta-bsp/binary/poky-image-minimal.directdisk -meta-bsp/conf/layer.conf -meta-bsp/conf/machine/*.conf -meta-bsp/conf/machine/include/tune-*.inc -meta-bsp/packages/bootloader/bootloader_0.1.bb -meta-bsp/packages/linux/linux-bsp-2.6.50/*.patch -meta-bsp/packages/linux/linux-bsp-2.6.50/defconfig-bsp -meta-bsp/packages/linux/linux-bsp_2.6.50.bb -meta-bsp/packages/modem/modem-driver_0.1.bb -meta-bsp/packages/modem/modem-daemon_0.1.bb -meta-bsp/packages/image-creator/image-creator-native_0.1.bb -meta-bsp/prebuilds/ - - - - - - The following sections detail what these files and directories could contain. - - -
- -
- Prebuilt User Binaries (meta-bsp/binary/*) - - - This optional area contains useful prebuilt kernels and userspace filesystem - images appropriate to the target system. Users could use these to get a system - running and quickly get started on development tasks. The exact types of binaries - present will be highly hardware-dependent but a README file should be present - explaining how to use them with the target hardware. If prebuilt binaries are - present, source code to meet licensing requirements must also be provided in - some form. - - -
- -
- Layer Configuration (meta-bsp/conf/layer.conf) - - - This file identifies the structure as a Poky layer. This file identifies the - contents of the layer and contains information about how Poky should use - it. In general it will most likely be a standard boilerplate file consisting of: - - - - -# We have a conf directory, add to BBPATH -BBPATH := "${BBPATH}${LAYERDIR}" - -# We have a packages directory, add to BBFILES -BBFILES := "${BBFILES} ${LAYERDIR}/packages/*/*.bb" - -BBFILE_COLLECTIONS += "bsp" -BBFILE_PATTERN_bsp := "^${LAYERDIR}/" -BBFILE_PRIORITY_bsp = "5" - - - - - which simply makes bitbake aware of the packages and conf directories. - - - - This file is required for recognition of the BSP by Poky. - - -
- -
- Hardware Configuration Options (meta-bsp/conf/machine/*.conf) - - - The machine files bind together all the information contained elsewhere - in the BSP into a format that Poky/OpenEmbedded can understand. If - the BSP supports multiple machines, multiple machine configuration files - can be present. These filenames correspond to the values users set the - MACHINE variable to. - - - - These files would define things like which kernel package to use - (PREFERRED_PROVIDER of virtual/kernel), which hardware drivers to - include in different types of images, any special software components - that are needed, any bootloader information, and also any special image - format requirements. - - - - At least one machine file is required for a Poky BSP layer but more than one may be present. - - -
- -
- Hardware Optimisation Options (meta-bsp/conf/machine/include/tune-*.inc) - - - These are shared hardware "tuning" definitions and are commonly used to - pass specific optimisation flags to the compiler. An example is - tune-atom.inc: - - - -BASE_PACKAGE_ARCH = "core2" -TARGET_CC_ARCH = "-m32 -march=core2 -msse3 -mtune=generic -mfpmath=sse" - - - - which defines a new package architecture called "core2" and uses the - optimization flags specified, which are carefully chosen to give best - performance on atom cpus. - - - The tune file would be included by the machine definition and can be - contained in the BSP or reference one from the standard core set of - files included with Poky itself. - - - These files are optional for a Poky BSP layer. - -
-
- Linux Kernel Configuration (meta-bsp/packages/linux/*) - - - These files make up the definition of a kernel to use with this - hardware. In this case it is a complete self-contained kernel with its own - configuration and patches but kernels can be shared between many - machines as well. Taking some specific example files: - - - -meta-bsp/packages/linux/linux-bsp_2.6.50.bb - - - - which is the core kernel recipe which firstly details where to get the kernel - source from. All standard source code locations are supported so this could - be a release tarball, some git repository, or source included in - the directory within the BSP itself. It then contains information about which - patches to apply and how to configure and build it. It can reuse the main - Poky kernel build class, so the definitions here can remain very simple. - - - -linux-bsp-2.6.50/*.patch - - - - which are patches which may be applied against the base kernel, wherever - they may have been obtained from. - - - -meta-bsp/packages/linux/linux-bsp-2.6.50/defconfig-bsp - - - - which is the configuration information to use to configure the kernel. - - - Examples of kernel recipes are available in Poky itself. These files are - optional since a kernel from Poky itself could be selected, although it - would be unusual not to have a kernel configuration. - -
- -
- Other Software (meta-bsp/packages/*) - - - This area includes other pieces of software which the hardware may need for best - operation. These are just examples of the kind of things that may be - encountered. These are standard .bb file recipes in the usual Poky format, - so for examples, see standard Poky recipes. The source can be included directly, - referred to in source control systems or release tarballs of external software projects. - - - -meta-bsp/packages/bootloader/bootloader_0.1.bb - - - - Some kind of bootloader recipe which may be used to generate a new - bootloader binary. Sometimes these are included in the final image - format and needed to reflash hardware. - - - -meta-bsp/packages/modem/modem-driver_0.1.bb -meta-bsp/packages/modem/modem-daemon_0.1.bb - - - - These are examples of a hardware driver and also a hardware daemon which - may need to be included in images to make the hardware useful. "modem" - is one example but there may be other components needed like firmware. - - - -meta-bsp/packages/image-creator/image-creator-native_0.1.bb - - - - Sometimes the device will need an image in a very specific format for - its update mechanism to accept and reflash with it. Recipes to build the - tools needed to do this can be included with the BSP. - - - These files only need be provided if the platform requires them. - -
- -
- Append BSP specific information to existing recipes - - - Say you have a recipe like pointercal which has machine-specific information in it, - and then you have your new BSP code in a layer. Before the .bbappend extension was - introduced, you'd have to copy the whole pointercal recipe and files into your layer, - and then add the single file for your machine, which is ugly. - - .bbappend makes the above work much easier, to allow BSP-specific information to be merged - with the original recipe easily. When bitbake finds any X.bbappend files, they will be - included after bitbake loads X.bb but before finalise or anonymous methods run. - This allows the BSP layer to poke around and do whatever it might want to customise - the original recipe. - - .bbappend is expected to include the below two lines in the head (which may be changed - in the future): - - - -THISDIR := "${@os.path.dirname(bb.data.getVar('FILE', d, True))}" -FILESPATH =. "${@base_set_filespath(["${THISDIR}/${PN}"], d)}:" - - - - Then the BSP could add machine-specific config files in layer directory, which will be - added by bitbake. You can look at meta-emenlow/packages/formfactor as an example. - -
- -
- Prebuild Data (meta-bsp/prebuilds/*) - - - The location can contain a precompiled representation of the source code - contained elsewhere in the BSP layer. It can be processed and used by - Poky to provide much faster build times, assuming a compatible configuration is used. - - - - These files are optional. - - -
- -
- BSP 'Click-through' Licensing Procedure - - This section is here as a description of how - click-through licensing is expected to work, and is - not yet not impemented. - - - - In some cases, a BSP may contain separately licensed IP - (Intellectual Property) for a component, which imposes - upon the user a requirement to accept the terms of a - 'click-through' license. Once the license is accepted - (in whatever form that may be, see details below) the - Poky build system can then build and include the - corresponding component in the final BSP image. Some - affected components may be essential to the normal - functioning of the system and have no 'free' replacement - i.e. the resulting system would be non-functional - without them. Other components may be simply - 'good-to-have' or purely elective, or if essential - nonetheless have a 'free' (possibly less-capable) - version which may substituted for in the BSP recipe. - - - - For the latter cases, where it is possible to do so from - a functionality perspective, the Poky website will make - available a 'de-featured' BSP completely free of - encumbered IP, which can be used directly and without - any further licensing requirements. If present, this - fully 'de-featured' BSP will be named meta-bsp (i.e. the - normal default naming convention). This is the simplest - and therefore preferred option if available, assuming - the resulting functionality meets requirements. - - - - If however, a non-encumbered version is unavailable or - the 'free' version would provide unsuitable - functionality or quality, an encumbered version can be - used. Encumbered versions of a BSP are given names of - the form meta-bsp-nonfree. There are several ways - within the Poky build system to satisfy the licensing - requirements for an encumbered BSP, in roughly the - following order of preference: - - - - - - - Get a license key (or keys) for the encumbered BSP - by - visiting https://pokylinux.org/bsp-keys.html - and give the web form there the name of the BSP - and your e-mail address. - - - - [screenshot of dialog box] - - - - After agreeing to any applicable license terms, the - BSP key(s) will be immediately sent to the address - given and can be used by specifying BSPKEY_<keydomain> - environment variables when building the image: - - - - $ BSPKEY_<keydomain>=<key> bitbake poky-image-sato - - - - This will allow the encumbered image to be built - with no change at all to the normal build process. - - - - Equivalently and probably more conveniently, a line - for each key can instead be put into the user's - local.conf file. - - - - The <keydomain> component of the - BSPKEY_<keydomain> is required because there - may be multiple licenses in effect for a give BSP; a - given <keydomain> in such cases corresponds to - a particular license. In order for an encumbered - BSP encompassing multiple key domains to be built - successfully, a <keydomain> entry for each - applicable license must be present in local.conf or - supplied on the command-line. - - - - - Do nothing - build as you normally would, and follow - any license prompts that originate from the - encumbered BSP (the build will cleanly stop at this - point). These usually take the form of instructions - needed to manually fetch the encumbered package(s) - and md5 sums into e.g. the poky/build/downloads - directory. Once the manual package fetch has been - completed, restarting the build will continue where - it left off, this time without the prompt since the - license requirements will have been satisfied. - - - - - Get a full-featured BSP recipe rather than a key, by - visiting - https://pokylinux.org/bsps.html. - Accepting the license agreement(s) presented will - subsequently allow you to download a tarball - containing a full-featured BSP legally cleared for - your use by the just-given license agreement(s). - This method will also allow the encumbered image to - be built with no change at all to the normal build - process. - - - - - Note that method 3 is also the only option available - when downloading pre-compiled images generated from - non-free BSPs. Those images are likewise available at - https://pokylinux.org/bsps.html. - -
- - diff --git a/handbook/development.xml b/handbook/development.xml deleted file mode 100644 index a383a2f4a..000000000 --- a/handbook/development.xml +++ /dev/null @@ -1,825 +0,0 @@ - - - -Platform Development with Poky - -
- Software development - - Poky supports several methods of software development. These different - forms of development are explained below and can be switched - between as needed. - - -
- Developing externally using the Poky SDK - - - The meta-toolchain and meta-toolchain-sdk targets (see - the images section) build tarballs which contain toolchains and - libraries suitable for application development outside Poky. These unpack into the - /opt/poky directory and contain - a setup script, e.g. - /opt/poky/environment-setup-i586-poky-linux which - can be sourced to initialise a suitable environment. After sourcing this, the - compiler, QEMU scripts, QEMU binary, a special version of pkgconfig and other - useful utilities are added to the PATH. Variables to assist pkgconfig and - autotools are also set so that, for example, configure can find pre-generated test - results for tests which need target hardware to run. - - - - Using the toolchain with autotool enabled packages is straightforward, just pass the - appropriate host option to configure e.g. "./configure --host=arm-poky-linux-gnueabi". - For other projects it is usually a case of ensuring the cross tools are used e.g. - CC=arm-poky-linux-gnueabi-gcc and LD=arm-poky-linux-gnueabi-ld. - -
- -
- Developing externally using the Anjuta plugin - - - An Anjuta IDE plugin exists to make developing software within the Poky framework - easier for the application developer. It presents a graphical IDE from which the - developer can cross compile an application then deploy and execute the output in a QEMU - emulation session. It also supports cross debugging and profiling. - - - - To use the plugin, a toolchain and SDK built by Poky is required along with Anjuta it's development - headers and the Anjuta plugin. The Poky Anjuta plugin is available to download as a tarball at the - OpenedHand labs page or - directly from the Poky Git repository located at git://git.pokylinux.org/anjuta-poky; a web interface - to the repository can be accessed at . - - - See the README file contained in the project for more information on dependencies and building - the plugin. If you want to disable remote gdb debugging, please pass --diable-gdb-integration - switch when doing configure. - - -
- Setting up the Anjuta plugin - - Extract the tarball for the toolchain into / as root. The - toolchain will be installed into - /opt/poky. - - To use the plugin, first open or create an existing - project. If creating a new project the "C GTK+" project type - will allow itself to be cross-compiled. However you should be - aware that this uses glade for the UI. - - To activate the plugin go to - EditPreferences, - then choose General from the left hand side. Choose the - Installed plugins tab, scroll down to Poky - SDK and check the - box. The plugin is now activated but first it must be - configured. -
- -
- Configuring the Anjuta plugin - - The configuration options for the SDK can be found by choosing - the Poky SDK icon from the left hand side. The following options - need to be set: - - - - SDK root: If we use external toolchain, we need to set SDK root. - this is the root directory of the SDK's sysroot. For an i586 SDK this will be /opt/poky/. - This directory will contain directories named like "bin", - "include", "var", etc. under your selected target architecture subdirectory - /opt/poky/sysroot/i586-poky-linux/. Needed cross compile tools are under - /opt/poky/sysroot/i586-pokysdk-linux/ - - - Poky root: If we have local poky build tree, we need to set the Poky root. - this is the root directory of the poky build tree, if you build your i586 target architecture - under the subdirectory of build_x86 within your poky tree, the Poky root directory should be - ${Poky_tree}/build_x86/. - - - Target Architecture: this is the cross compile - triplet, e.g. "i586-poky-linux". This target triplet is the prefix extracted from - the set up script file name. For examle, "i586-poky-linux" is extracted from set up script file - /opt/poky/environment-setup-i586-poky-linux - - - Kernel: use the file chooser to select the kernel - to use with QEMU - - Root filesystem: use the file chooser to select - the root filesystem directory, this is the directory where you use "poky-extract-sdk" command to - extract the poky-image-sdk tarball. - - - -
- -
- Using the Anjuta plugin - - As an example, cross-compiling a project, deploying it into - QEMU and running a debugger against it and then doing a system - wide profile. - - Choose BuildRun - Configure or - BuildRun - Autogenerate to run "configure" - (or to run "autogen") for the project. This passes command line - arguments to instruct it to cross-compile. - - Next do - BuildBuild - Project to build and compile the - project. If you have previously built the project in the same - tree without using the cross-compiler you may find that your - project fails to link. Simply do - BuildClean - Project to remove the old - binaries. You may then try building again. - - Next start QEMU by using - ToolsStart - QEMU, this will start QEMU and - will show any error messages in the message view. Once Poky has - fully booted within QEMU you may now deploy into it. - - Once built and QEMU is running, choose - ToolsDeploy, - this will install the package into a temporary directory and - then copy using rsync over SSH into the target. Progress and - messages will be shown in the message view. - - To debug a program installed into onto the target choose - ToolsDebug - remote. This prompts for the - local binary to debug and also the command line to run on the - target. The command line to run should include the full path to - the to binary installed in the target. This will start a - gdbserver over SSH on the target and also an instance of a - cross-gdb in a local terminal. This will be preloaded to connect - to the server and use the SDK root to find - symbols. This gdb will connect to the target and load in - various libraries and the target program. You should setup any - breakpoints or watchpoints now since you might not be able to - interrupt the execution later. You may stop - the debugger on the target using - ToolsStop - debugger. - - It is also possible to execute a command in the target over - SSH, the appropriate environment will be be set for the - execution. Choose - ToolsRun - remote to do this. This will open - a terminal with the SSH command inside. - - To do a system wide profile against the system running in - QEMU choose - ToolsProfile - remote. This will start up - OProfileUI with the appropriate parameters to connect to the - server running inside QEMU and will also supply the path to the - debug information necessary to get a useful profile. - -
-
- - -
- Developing externally in QEMU - - Running Poky QEMU images is covered in the Running an Image section. - - - Poky's QEMU images contain a complete native toolchain. This means - that applications can be developed within QEMU in the same was as a - normal system. Using qemux86 on an x86 machine is fast since the - guest and host architectures match, qemuarm is slower but gives - faithful emulation of ARM specific issues. To speed things up these - images support using distcc to call a cross-compiler outside the - emulated system too. If runqemu was used to start - QEMU, and distccd is present on the host system, any bitbake cross - compiling toolchain available from the build system will automatically - be used from within qemu simply by calling distcc - (export CC="distcc" can be set in the enviroment). - Alterntatively, if a suitable SDK/toolchain is present in - /opt/poky it will also - automatically be used. - - - - There are several options for connecting into the emulated system. - QEMU provides a framebuffer interface which has standard consoles - available. There is also a serial connection available which has a - console to the system running on it and IP networking as standard. - The images have a dropbear ssh server running with the root password - disabled allowing standard ssh and scp commands to work. The images - also contain an NFS server exporting the guest's root filesystem - allowing that to be made available to the host. - -
- -
- Developing in Poky directly - - Working directly in Poky is a fast and effective development technique. - The idea is that you can directly edit files in - WORKDIR - or the source directory S - and then force specific tasks to rerun in order to test the changes. - An example session working on the matchbox-desktop package might - look like this: - - - - -$ bitbake matchbox-desktop -$ sh -$ cd tmp/work/armv5te-poky-linux-gnueabi/matchbox-desktop-2.0+svnr1708-r0/ -$ cd matchbox-desktop-2 -$ vi src/main.c -$ exit -$ bitbake matchbox-desktop -c compile -f -$ bitbake matchbox-desktop - - - - - Here, we build the package, change into the work directory for the package, - change a file, then recompile the package. Instead of using sh like this, - you can also use two different terminals. The risk with working like this - is that a command like unpack could wipe out the changes you've made to the - work directory so you need to work carefully. - - - - It is useful when making changes directly to the work directory files to do - so using quilt as detailed in the - modifying packages with quilt section. The resulting patches can be copied - into the recipe directory and used directly in the SRC_URI. - - - For a review of the skills used in this section see Sections 2.1.1 and 2.4.2. - - -
- -
- Developing with 'devshell' - - - When debugging certain commands or even to just edit packages, the - 'devshell' can be a useful tool. To start it you run a command like: - - - - -$ bitbake matchbox-desktop -c devshell - - - - - which will open a terminal with a shell prompt within the Poky - environment. This means PATH is setup to include the cross toolchain, - the pkgconfig variables are setup to find the right .pc files, - configure will be able to find the Poky site files etc. Within this - environment, you can run configure or compile command as if they - were being run by Poky itself. You are also changed into the - source (S) - directory automatically. When finished with the shell just exit it - or close the terminal window. - - - - The default shell used by devshell is the gnome-terminal. Other - forms of terminal can also be used by setting the - TERMCMD and - TERMCMDRUN variables - in local.conf. For examples of the other options available, see - meta/conf/bitbake.conf. An external shell is - launched rather than opening directly into the original terminal - window to make interaction with bitbakes multiple threads easier - and also allow a client/server split of bitbake in the future - (devshell will still work over X11 forwarding or similar). - - - - It is worth remembering that inside devshell you need to use the full - compiler name such as arm-poky-linux-gnueabi-gcc - instead of just gcc and the same applies to other - applications from gcc, bintuils, libtool etc. Poky will have setup - environmental variables such as CC to assist applications, such as make, - find the correct tools. - - -
- -
- Developing within Poky with an external SCM based package - - - If you're working on a recipe which pulls from an external SCM it - is possible to have Poky notice new changes added to the - SCM and then build the latest version. This only works for SCMs - where its possible to get a sensible revision number for changes. - Currently it works for svn, git and bzr repositories. - - - - To enable this behaviour it is simply a case of adding - SRCREV_pn- - PN = "${AUTOREV}" to - local.conf where PN - is the name of the package for which you want to enable automatic source - revision updating. - -
- -
- -
- Debugging with GDB Remotely - - - GDB (The GNU Project Debugger) - allows you to examine running programs to understand and fix problems and - also to perform postmortem style analsys of program crashes. It is available - as a package within poky and installed by default in sdk images. It works best - when -dbg packages for the application being debugged are installed as the - extra symbols give more meaningful output from GDB. - - - - Sometimes, due to memory or disk space constraints, it is not possible - to use GDB directly on the remote target to debug applications. This is - due to the fact that - GDB needs to load the debugging information and the binaries of the - process being debugged. GDB then needs to perform many - computations to locate information such as function names, variable - names and values, stack traces, etc. even before starting the debugging - process. This places load on the target system and can alter the - characteristics of the program being debugged. - - - This is where GDBSERVER comes into play as it runs on the remote target - and does not load any debugging information from the debugged process. - Instead, the debugging information processing is done by a GDB instance - running on a distant computer - the host GDB. The host GDB then sends - control commands to GDBSERVER to make it stop or start the debugged - program, as well as read or write some memory regions of that debugged - program. All the debugging information loading and processing as well - as the heavy debugging duty is done by the host GDB, giving the - GDBSERVER running on the target a chance to remain small and fast. - - - As the host GDB is responsible for loading the debugging information and - doing the necessary processing to make actual debugging happen, the - user has to make sure it can access the unstripped binaries complete - with their debugging information and compiled with no optimisations. The - host GDB must also have local access to all the libraries used by the - debugged program. On the remote target the binaries can remain stripped - as GDBSERVER does not need any debugging information there. However they - must also be compiled without optimisation matching the host's binaries. - - - - The binary being debugged on the remote target machine is hence referred - to as the 'inferior' in keeping with GDB documentation and terminology. - Further documentation on GDB, is available on - on their site. - - -
- Launching GDBSERVER on the target - - First, make sure gdbserver is installed on the target. If not, - install the gdbserver package (which needs the libthread-db1 - package). - - - To launch GDBSERVER on the target and make it ready to "debug" a - program located at /path/to/inferior, connect - to the target and launch: - $ gdbserver localhost:2345 /path/to/inferior - After that, gdbserver should be listening on port 2345 for debugging - commands coming from a remote GDB process running on the host computer. - Communication between the GDBSERVER and the host GDB will be done using - TCP. To use other communication protocols please refer to the - GDBSERVER documentation. - -
- -
- Launching GDB on the host computer - - - Running GDB on the host computer takes a number of stages, described in the - following sections. - - -
- Build the cross GDB package - - A suitable gdb cross binary is required which runs on your host computer but - knows about the the ABI of the remote target. This can be obtained from - the the Poky toolchain, e.g. - /opt/poky/sysroots/x86_64-pokysdk-linux/usr/bin/armv5te-poky-linux-gnueabi/arm-poky-linux-gnueabi-gdb - which "x86_64" is the host architecture, "arm" is the target architecture and "linux-gnueabi" the target ABI. - - - - Alternatively this can be built directly by Poky. To do this you would build - the gdb-cross package so for example you would run: - bitbake gdb-cross - Once built, the cross gdb binary can be found at - tmp/sysroots/<host-arch>/usr/bin/\ -<target-arch>-poky-<target-abi>/<target-arch>-poky-<target-abi>-gdb - - -
-
- - Making the inferior binaries available - - - The inferior binary needs to be available to GDB complete with all debugging - symbols in order to get the best possible results along with any libraries - the inferior depends on and their debugging symbols. There are a number of - ways this can be done. - - - - Perhaps the easiest is to have an 'sdk' image corresponding to the plain - image installed on the device. In the case of 'pky-image-sato', - 'poky-image-sdk' would contain suitable symbols. The sdk images already - have the debugging symbols installed so its just a question expanding the - archive to some location and telling GDB where this is. - - - - Alternatively, poky can build a custom directory of files for a specific - debugging purpose by reusing its tmp/rootfs directory, on the host computer - in a slightly different way to normal. This directory contains the contents - of the last built image. This process assumes the image running on the - target was the last image to be built by Poky, the package foo - contains the inferior binary to be debugged has been built without without - optimisation and has debugging information available. - - - Firstly you want to install the foo package to tmp/rootfs - by doing: - - tmp/sysroots/i686-linux/usr/bin/opkg-cl -f \ -tmp/work/<target-abi>/poky-image-sato-1.0-r0/opkg.conf -o \ -tmp/rootfs/ update - - then, - - tmp/sysroots/i686-linux/usr/bin/opkg-cl -f \ -tmp/work/<target-abi>/poky-image-sato-1.0-r0/opkg.conf \ --o tmp/rootfs install foo - -tmp/sysroots/i686-linux/usr/bin/opkg-cl -f \ -tmp/work/<target-abi>/poky-image-sato-1.0-r0/opkg.conf \ --o tmp/rootfs install foo-dbg - - which installs the debugging information too. - - -
-
- - Launch the host GDB - - To launch the host GDB, run the cross gdb binary identified above with - the inferior binary specified on the commandline: - <target-arch>-poky-<target-abi>-gdb rootfs/usr/bin/foo - This loads the binary of program foo - as well as its debugging information. Once the gdb prompt - appears, you must instruct GDB to load all the libraries - of the inferior from tmp/rootfs: - set solib-absolute-prefix /path/to/tmp/rootfs - where /path/to/tmp/rootfs must be - the absolute path to tmp/rootfs or wherever the - binaries with debugging information are located. - - - Now, tell GDB to connect to the GDBSERVER running on the remote target: - target remote remote-target-ip-address:2345 - Where remote-target-ip-address is the IP address of the - remote target where the GDBSERVER is running. 2345 is the - port on which the GDBSERVER is running. - - -
-
- - Using the Debugger - - Debugging can now proceed as normal, as if the debugging were being done on the - local machine, for example to tell GDB to break in the main - function, for instance: - break main - and then to tell GDB to "continue" the inferior execution, - continue - - - For more information about using GDB please see the - project's online documentation at . - -
-
- -
- -
- Profiling with OProfile - - - OProfile is a - statistical profiler well suited to finding performance - bottlenecks in both userspace software and the kernel. It provides - answers to questions like "Which functions does my application spend - the most time in when doing X?". Poky is well integrated with OProfile - to make profiling applications on target hardware straightforward. - - - - To use OProfile you need an image with OProfile installed. The easiest - way to do this is with "tools-profile" in IMAGE_FEATURES. You also - need debugging symbols to be available on the system where the analysis - will take place. This can be achieved with "dbg-pkgs" in IMAGE_FEATURES or by - installing the appropriate -dbg packages. For - successful call graph analysis the binaries must preserve the frame - pointer register and hence should be compiled with the - "-fno-omit-framepointer" flag. In Poky this can be achieved with - SELECTED_OPTIMIZATION - = "-fexpensive-optimizations -fno-omit-framepointer - -frename-registers -O2" or by setting DEBUG_BUILD = "1" in - local.conf (the latter will also add extra debug information making the - debug packages large). - - -
- Profiling on the target - - - All the profiling work can be performed on the target device. A - simple OProfile session might look like: - - - - -# opcontrol --reset -# opcontrol --start --separate=lib --no-vmlinux -c 5 -[do whatever is being profiled] -# opcontrol --stop -$ opreport -cl - - - - - Here, the reset command clears any previously profiled data, - OProfile is then started. The options used to start OProfile mean - dynamic library data is kept separately per application, kernel - profiling is disabled and callgraphing is enabled up to 5 levels - deep. To profile the kernel, you would specify the - --vmlinux=/path/to/vmlinux option (the vmlinux file is usually in - /boot/ in Poky and must match the running kernel). The profile is - then stopped and the results viewed with opreport with options - to see the separate library symbols and callgraph information. - - - Callgraphing means OProfile not only logs infomation about which - functions time is being spent in but also which functions - called those functions (their parents) and which functions that - function calls (its children). The higher the callgraphing depth, - the more accurate the results but this also increased the loging - overhead so it should be used with caution. On ARM, binaries need - to have the frame pointer enabled for callgraphing to work (compile - with the gcc option -fno-omit-framepointer). - - - For more information on using OProfile please see the OProfile - online documentation at . - -
- -
- Using OProfileUI - - - A graphical user interface for OProfile is also available. You can - either use prebuilt Debian packages from the OpenedHand repository or - download and build from svn at - http://svn.o-hand.com/repos/oprofileui/trunk/. If the - "tools-profile" image feature is selected, all necessary binaries - are installed onto the target device for OProfileUI interaction. - - - - - In order to convert the data in the sample format from the target - to the host the opimport program is needed. - This is not included in standard Debian OProfile packages but an - OProfile package with this addition is also available from the OpenedHand repository. - We recommend using OProfile 0.9.3 or greater. Other patches to - OProfile may be needed for recent OProfileUI features, but Poky - usually includes all needed patches on the target device. Please - see the - OProfileUI README for up to date information, and the - OProfileUI website - for more information on the OProfileUI project. - - -
- Online mode - - - This assumes a working network connection with the target - hardware. In this case you just need to run - "oprofile-server" on the device. By default it listens - on port 4224. This can be changed with the --port command line - option. - - - - - The client program is called oprofile-viewer. The - UI is relatively straightforward, the key functionality is accessed - through the buttons on the toolbar (which are duplicated in the - menus.) These buttons are: - - - - - - Connect - connect to the remote host, the IP address or hostname for the - target can be supplied here. - - - - - Disconnect - disconnect from the target. - - - - - Start - start the profiling on the device. - - - - - Stop - stop the profiling on the device and download the data to the local - host. This will generate the profile and show it in the viewer. - - - - - Download - download the data from the target, generate the profile and show it - in the viewer. - - - - - Reset - reset the sample data on the device. This will remove the sample - information that was collected on a previous sampling run. Ensure you do this - if you do not want to include old sample information. - - - - - Save - save the data downloaded from the target to another directory for later - examination. - - - - - Open - load data that was previously saved. - - - - - - The behaviour of the client is to download the complete 'profile archive' from - the target to the host for processing. This archive is a directory containing - the sample data, the object files and the debug information for said object - files. This archive is then converted using a script included in this - distribution ('oparchconv') that uses 'opimport' to convert the archive from - the target to something that can be processed on the host. - - - - Downloaded archives are kept in /tmp and cleared up when they are no longer in - use. - - - - If you wish to profile into the kernel, this is possible, you just need to ensure - a vmlinux file matching the running kernel is available. In Poky this is usually - located in /boot/vmlinux-KERNELVERSION, where KERNEL-version is the version of - the kernel e.g. 2.6.23. Poky generates separate vmlinux packages for each kernel - it builds so it should be a question of just ensuring a matching package is - installed ( opkg install kernel-vmlinux. These are automatically - installed into development and profiling images alongside OProfile. There is a - configuration option within the OProfileUI settings page where the location of - the vmlinux file can be entered. - - - - Waiting for debug symbols to transfer from the device can be slow and it's not - always necessary to actually have them on device for OProfile use. All that is - needed is a copy of the filesystem with the debug symbols present on the viewer - system. The GDB remote debug - section covers how to create such a directory with Poky and the location - of this directory can again be specified in the OProfileUI settings dialog. If - specified, it will be used where the file checksums match those on the system - being profiled. - -
-
- Offline mode - - - If no network access to the target is available an archive for processing in - 'oprofile-viewer' can be generated with the following set of command. - - - - -# opcontrol --reset -# opcontrol --start --separate=lib --no-vmlinux -c 5 -[do whatever is being profiled] -# opcontrol --stop -# oparchive -o my_archive - - - - - Where my_archive is the name of the archive directory where you would like the - profile archive to be kept. The directory will be created for you. This can - then be copied to another host and loaded using 'oprofile-viewer''s open - functionality. The archive will be converted if necessary. - -
-
-
- - - diff --git a/handbook/examples/hello-autotools/hello_2.3.bb b/handbook/examples/hello-autotools/hello_2.3.bb deleted file mode 100644 index 5c5332f73..000000000 --- a/handbook/examples/hello-autotools/hello_2.3.bb +++ /dev/null @@ -1,7 +0,0 @@ -DESCRIPTION = "GNU Helloworld application" -SECTION = "examples" -LICENSE = "GPLv3" - -SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.bz2" - -inherit autotools diff --git a/handbook/examples/hello-single/files/helloworld.c b/handbook/examples/hello-single/files/helloworld.c deleted file mode 100644 index fc7169b7b..000000000 --- a/handbook/examples/hello-single/files/helloworld.c +++ /dev/null @@ -1,8 +0,0 @@ -#include - -int main(void) -{ - printf("Hello world!\n"); - - return 0; -} diff --git a/handbook/examples/hello-single/hello.bb b/handbook/examples/hello-single/hello.bb deleted file mode 100644 index d815b1ed7..000000000 --- a/handbook/examples/hello-single/hello.bb +++ /dev/null @@ -1,16 +0,0 @@ -DESCRIPTION = "Simple helloworld application" -SECTION = "examples" -LICENSE = "MIT" - -SRC_URI = "file://helloworld.c" - -S = "${WORKDIR}" - -do_compile() { - ${CC} helloworld.c -o helloworld -} - -do_install() { - install -d ${D}${bindir} - install -m 0755 helloworld ${D}${bindir} -} diff --git a/handbook/examples/libxpm/libxpm_3.5.6.bb b/handbook/examples/libxpm/libxpm_3.5.6.bb deleted file mode 100644 index 2710189b2..000000000 --- a/handbook/examples/libxpm/libxpm_3.5.6.bb +++ /dev/null @@ -1,13 +0,0 @@ -require xorg-lib-common.inc - -DESCRIPTION = "X11 Pixmap library" -LICENSE = "X-BSD" -DEPENDS += "libxext" -PR = "r2" -PE = "1" - -XORG_PN = "libXpm" - -PACKAGES =+ "sxpm cxpm" -FILES_cxpm = "${bindir}/cxpm" -FILES_sxpm = "${bindir}/sxpm" diff --git a/handbook/examples/mtd-makefile/mtd-utils_1.0.0.bb b/handbook/examples/mtd-makefile/mtd-utils_1.0.0.bb deleted file mode 100644 index b21dc653a..000000000 --- a/handbook/examples/mtd-makefile/mtd-utils_1.0.0.bb +++ /dev/null @@ -1,13 +0,0 @@ -DESCRIPTION = "Tools for managing memory technology devices." -SECTION = "base" -DEPENDS = "zlib" -HOMEPAGE = "http://www.linux-mtd.infradead.org/" -LICENSE = "GPLv2" - -SRC_URI = "ftp://ftp.infradead.org/pub/mtd-utils/mtd-utils-${PV}.tar.gz" - -CFLAGS_prepend = "-I ${S}/include " - -do_install() { - oe_runmake install DESTDIR=${D} -} diff --git a/handbook/extendpoky.xml b/handbook/extendpoky.xml deleted file mode 100644 index 662096844..000000000 --- a/handbook/extendpoky.xml +++ /dev/null @@ -1,1040 +0,0 @@ - - - - -Extending Poky - - - This section gives information about how to extend the functionality - already present in Poky, documenting standard tasks such as adding new - software packages, extending or customising images or porting poky to - new hardware (adding a new machine). It also contains advice about how - to manage the process of making changes to Poky to achieve best results. - - -
- Adding a Package - - - To add package into Poky you need to write a recipe for it. - Writing a recipe means creating a .bb file which sets various - variables. The variables - useful for recipes are detailed in the - recipe reference section along with more detailed information - about issues such as recipe naming. - - - - Before writing a recipe from scratch it is often useful to check - whether someone else has written one already. OpenEmbedded is a good place - to look as it has a wider scope and hence a wider range of packages. - Poky aims to be compatible with OpenEmbedded so most recipes should - just work in Poky. - - - - For new packages, the simplest way to add a recipe is to base it on a similar - pre-existing recipe. There are some examples below of how to add - standard types of packages: - - -
- Single .c File Package (Hello World!) - - - To build an application from a single file stored locally (e.g. under "files/") - requires a recipe which has the file listed in the SRC_URI variable. In addition - the do_compile and do_install - tasks need to be manually written. The - S variable defines the directory containing the source - code which in this case is set equal to - WORKDIR, the directory BitBake uses for the build. - - -DESCRIPTION = "Simple helloworld application" -SECTION = "examples" -LICENSE = "MIT" -PR = "r0" - -SRC_URI = "file://helloworld.c" - -S = "${WORKDIR}" - -do_compile() { - ${CC} helloworld.c -o helloworld -} - -do_install() { - install -d ${D}${bindir} - install -m 0755 helloworld ${D}${bindir} -} - - - - As a result of the build process "helloworld", "helloworld-dbg" and "hellworld-dev" - packages will be built by default. It is possible to - customise the packaging process. - -
- -
- Autotooled Package - - - Applications which use autotools (autoconf, automake) - require a recipe which has a source archive listed in - SRC_URI and - inherit autotools to instruct BitBake to use the - autotools.bbclass which has - definitions of all the steps - needed to build an autotooled application. - The result of the build will be automatically packaged and if - the application uses NLS to localise then packages with - locale information will be generated (one package per - language). Below is one example (hello_2.2.bb) - - - -DESCRIPTION = "GNU Helloworld application" -SECTION = "examples" -LICENSE = "GPLv2+" -LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe" -PR = "r0" - -SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz" - -inherit autotools gettext - - - - LIC_FILES_CHKSUM - is used to - track source license change. Autotool based recipe can be quickly - created this way like above example. - - -
- -
- Makefile-Based Package - - - Applications which use GNU make require a recipe which has - the source archive listed in SRC_URI. - Adding a do_compile step - is not needed as by default BitBake will start the "make" - command to compile the application. If there is a need for - additional options to make then they should be stored in the - EXTRA_OEMAKE variable - BitBake - will pass them into the GNU - make invocation. A do_install task is required - - otherwise BitBake will run an empty do_install - task by default. - - - - Some applications may require extra parameters to be passed to - the compiler, for example an additional header path. This can - be done buy adding to the CFLAGS variable, as in the example below: - - - -CFLAGS_prepend = "-I ${S}/include " - - - - mtd-utils is an example as Makefile-based: - - - -DESCRIPTION = "Tools for managing memory technology devices." -SECTION = "base" -DEPENDS = "zlib lzo e2fsprogs util-linux" -HOMEPAGE = "http://www.linux-mtd.infradead.org/" -LICENSE = "GPLv2" - -SRC_URI = "git://git.infradead.org/mtd-utils.git;protocol=git;tag=v${PV}" - -S = "${WORKDIR}/git/" - -EXTRA_OEMAKE = "'CC=${CC}' 'CFLAGS=${CFLAGS} -I${S}/include -DWITHOUT_XATTR' \ - 'BUILDDIR=${S}'" - -do_install () { - oe_runmake install DESTDIR=${D} SBINDIR=${sbindir} MANDIR=${mandir} \ - INCLUDEDIR=${includedir} - install -d ${D}${includedir}/mtd/ - for f in ${S}/include/mtd/*.h; do - install -m 0644 $f ${D}${includedir}/mtd/ - done -} - - -
- -
- Controlling packages content - - - The variables PACKAGES and - FILES are used to split an - application into multiple packages. - - - - Below the "libXpm" recipe (libxpm_3.5.7.bb) is used as an example. By - default the "libXpm" recipe generates one package - which contains the library - and also a few binaries. The recipe can be adapted to - split the binaries into separate packages. - - - -require xorg-lib-common.inc - -DESCRIPTION = "X11 Pixmap library" -LICENSE = "X-BSD" -DEPENDS += "libxext libsm libxt" -PR = "r3" -PE = "1" - -XORG_PN = "libXpm" - -PACKAGES =+ "sxpm cxpm" -FILES_cxpm = "${bindir}/cxpm" -FILES_sxpm = "${bindir}/sxpm" - - - - In this example we want to ship the "sxpm" and "cxpm" binaries - in separate packages. Since "bindir" would be packaged into the - main PN - package as standard we prepend the PACKAGES variable so - additional package names are added to the start of list. The - extra FILES_* - variables then contain information to specify which files and - directories goes into which package. Files included by earlier - package are skipped by latter packages, and thus main - PN will not include - above listed files - -
- -
- Post Install Scripts - - - To add a post-installation script to a package, add - a pkg_postinst_PACKAGENAME() - function to the .bb file - where PACKAGENAME is the name of the package to attach - the postinst script to. Normally PN can be used which expands - to PACKAGENAME automatically. A post-installation function has the - following structure: - - -pkg_postinst_PACKAGENAME () { -#!/bin/sh -e -# Commands to carry out -} - - - The script defined in the post installation function - gets called when the rootfs is made. If the script succeeds, - the package is marked as installed. If the script fails, - the package is marked as unpacked and the script will be - executed again on the first boot of the image. - - - - Sometimes it is necessary that the execution of a post-installation - script is delayed until the first boot, because the script - needs to be executed on the device itself. To delay script execution - until boot time, the post-installation function should have the - following structure: - - - -pkg_postinst_PACKAGENAME () { -#!/bin/sh -e -if [ x"$D" = "x" ]; then - # Actions to carry out on the device go here -else - exit 1 -fi -} - - - - The structure above delays execution until first boot - because the D variable points - to the 'image' - directory when the rootfs is being made at build time but - is unset when executed on the first boot. - -
- -
- -
- Customising Images - - - Poky images can be customised to satisfy - particular requirements. Several methods are detailed below - along with guidelines of when to use them. - - -
- Customising Images through a custom image .bb files - - - One way to get additional software into an image is by creating a - custom image. The recipe will contain two lines: - - - -IMAGE_INSTALL = "task-poky-x11-base package1 package2" - -inherit poky-image - - - - By creating a custom image, a developer has total control - over the contents of the image. It is important to use - the correct names of packages in the IMAGE_INSTALL variable. - The names must be in - the OpenEmbedded notation instead of Debian notation, for example - "glibc-dev" instead of "libc6-dev" etc. - - - - The other method of creating a new image is by modifying - an existing image. For example if a developer wants to add - "strace" into "poky-image-sato" the following recipe can - be used: - - - -require poky-image-sato.bb - -IMAGE_INSTALL += "strace" - - -
- -
- Customising Images through custom tasks - - - For complex custom images, the best approach is to create a custom - task package which is then used to build the image (or images). A good - example of a tasks package is meta/packages/tasks/task-poky.bb - . The PACKAGES - variable lists the task packages to build (along with the complementary - -dbg and -dev packages). For each package added, - RDEPENDS and - RRECOMMENDS - entries can then be added each containing a list of packages the parent - task package should contain. An example would be: - - - - -DESCRIPTION = "My Custom Tasks" - -PACKAGES = "\ - task-custom-apps \ - task-custom-apps-dbg \ - task-custom-apps-dev \ - task-custom-tools \ - task-custom-tools-dbg \ - task-custom-tools-dev \ - " - -RDEPENDS_task-custom-apps = "\ - dropbear \ - portmap \ - psplash" - -RDEPENDS_task-custom-tools = "\ - oprofile \ - oprofileui-server \ - lttng-control \ - lttng-viewer" - -RRECOMMENDS_task-custom-tools = "\ - kernel-module-oprofile" - - - - - In this example, two task packages are created, task-custom-apps and - task-custom-tools with the dependencies and recommended package dependencies - listed. To build an image using these task packages, you would then add - "task-custom-apps" and/or "task-custom-tools" to IMAGE_INSTALL or other forms - of image dependencies as described in other areas of this section. - -
- -
- Customising Images through custom <glossterm><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></glossterm> - - - Ultimately users may want to add extra image "features" as used by Poky with the - IMAGE_FEATURES - variable. To create these, the best reference is meta/classes/poky-image.bbclass - which illustrates how poky achieves this. In summary, the file looks at the contents of the - IMAGE_FEATURES - variable and then maps this into a set of tasks or packages. Based on this then the - IMAGE_INSTALL - variable is generated automatically. Extra features can be added by - extending the class or creating a custom class for use with specialised image .bb files. - -
- -
- Customising Images through local.conf - - - It is possible to customise image contents by abusing - variables used by distribution maintainers in local.conf. - This method only allows the addition of packages and - is not recommended. - - - - To add an "strace" package into the image the following is - added to local.conf: - - - -DISTRO_EXTRA_RDEPENDS += "strace" - - - - However, since the - DISTRO_EXTRA_RDEPENDS variable is for - distribution maintainers this method does not make - adding packages as simple as a custom .bb file. Using - this method, a few packages will need to be recreated if they have been - created before and then the image is rebuilt. - - -bitbake -c clean task-boot task-base task-poky -bitbake poky-image-sato - - - - Cleaning task-* packages is required because they use the - - DISTRO_EXTRA_RDEPENDS variable. There is no need to - build them by hand as Poky images depend on the packages they contain so - dependencies will be built automatically when building the image. For this reason we don't use the - "rebuild" task in this case since "rebuild" does not care about - dependencies - it only rebuilds the specified package. - - -
- -
- -
- Porting Poky to a new machine - - Adding a new machine to Poky is a straightforward process and - this section gives an idea of the changes that are needed. This guide is - meant to cover adding machines similar to those Poky already supports. - Adding a totally new architecture might require gcc/glibc changes as - well as updates to the site information and, whilst well within Poky's - capabilities, is outside the scope of this section. - - -
- Adding the machine configuration file - - A .conf file needs to be added to conf/machine/ with details of the - device being added. The name of the file determines the name Poky will - use to reference this machine. - - - - The most important variables to set in this file are - TARGET_ARCH - (e.g. "arm"), - PREFERRED_PROVIDER_virtual/kernel (see below) and - MACHINE_FEATURES - (e.g. "kernel26 apm screen wifi"). Other variables - like SERIAL_CONSOLE - (e.g. "115200 ttyS0"), - KERNEL_IMAGETYPE - (e.g. "zImage") and - IMAGE_FSTYPES (e.g. "tar.gz jffs2") might also be - needed. Full details on what these variables do and the meaning of - their contents is available through the links. There're lots of existing - machine .conf files which can be easily leveraged from meta/conf/machine/. - -
- -
- Adding a kernel for the machine - - Poky needs to be able to build a kernel for the machine. You need - to either create a new kernel recipe for this machine or extend an - existing recipe. There are plenty of kernel examples in the - meta/recipes-kernel/linux directory which can be used as references. - - - If creating a new recipe the "normal" recipe writing rules apply - for setting up a SRC_URI - including any patches and setting - S to point at the source - code. You will need to create a configure task which configures the - unpacked kernel with a defconfig be that through a "make defconfig" - command or more usually though copying in a suitable defconfig and - running "make oldconfig". By making use of "inherit kernel" and also - maybe some of the linux-*.inc files, most other functionality is - centralised and the the defaults of the class normally work well. - - - If extending an existing kernel it is usually a case of adding a - suitable defconfig file in a location similar to that used by other - machine's defconfig files in a given kernel, possibly listing it in - the SRC_URI and adding the machine to the expression in - COMPATIBLE_MACHINE - : - - -COMPATIBLE_MACHINE = '(qemux86|qemumips)' - -
- -
- Adding a formfactor configuration file - - A formfactor configuration file provides information about the - target hardware on which Poky is running, and that Poky cannot - obtain from other sources such as the kernel. Some examples of - information contained in a formfactor configuration file include - framebuffer orientation, whether or not the system has a keyboard, - the positioning of the keyboard in relation to the screen, and - screen resolution. - - - Sane defaults should be used in most cases, but if customisation is - necessary you need to create a machconfig file - under meta/packages/formfactor/files/MACHINENAME/ - where MACHINENAME is the name for which this infomation - applies. For information about the settings available and the defaults, please see - meta/packages/formfactor/files/config. Below is one - example for qemuarm: - - -HAVE_TOUCHSCREEN=1 -HAVE_KEYBOARD=1 - -DISPLAY_CAN_ROTATE=0 -DISPLAY_ORIENTATION=0 -#DISPLAY_WIDTH_PIXELS=640 -#DISPLAY_HEIGHT_PIXELS=480 -#DISPLAY_BPP=16 -DISPLAY_DPI=150 -DISPLAY_SUBPIXEL_ORDER=vrgb - -
-
- -
- Making and Maintaining Changes - - - We recognise that people will want to extend/configure/optimise Poky for - their specific uses, especially due to the extreme configurability and - flexibility Poky offers. To ensure ease of keeping pace with future - changes in Poky we recommend making changes to Poky in a controlled way. - - - Poky supports the idea of "layers" which when used - properly can massively ease future upgrades and allow segregation - between the Poky core and a given developer's changes. Some other advice on - managing changes to Poky is also given in the following section. - - -
- Bitbake Layers - - - Often, people want to extend Poky either through adding packages - or overriding files contained within Poky to add their own - functionality. Bitbake has a powerful mechanism called - layers which provides a way to handle this extension in a fully - supported and non-invasive fashion. - - - - The Poky tree includes several additional layers which demonstrate - this functionality, such as meta-emenlow and meta-extras. - The meta-emenlow layer is an example layer enabled by default. The meta-extras - repostory is not enabled by default but enabling any layer is as easy as adding - the layers path to the BBLAYERS variable in your bblayers.conf. this is how - meta-extras are enabled in Poky builds: - - - LCONF_VERSION = "1" - -BBFILES ?= "" -BBLAYERS = " \ - /path/to/poky/meta \ - /path/to/poky/meta-moblin \ - /path/to/poky/meta-emenlow \ - /path/to/poky/meta-extras \ - " - - - - - Bitbake parses the conf/layer.conf of each of the layers in BBLAYERS - to add the layers packages, classes and configuration to Poky. - To create your own layer, independent of the main Poky repository, - you need only create a directory with a conf/layer.conf file and - add the directory to your bblayers.conf. - - - - The meta-emenlow/conf/layer.conf demonstrates the required syntax: - # We have a conf and classes directory, add to BBPATH -BBPATH := "${BBPATH}:${LAYERDIR}" - -# We have a packages directory, add to BBFILES -BBFILES := "${BBFILES} ${LAYERDIR}/packages/*/*.bb \ - ${LAYERDIR}/packages/*/*.bbappend" - -BBFILE_COLLECTIONS += "emenlow" -BBFILE_PATTERN_emenlow := "^${LAYERDIR}/" -BBFILE_PRIORITY_emenlow = "6" - - - - - As can be seen, the layers recipes are added to - BBFILES. The - BBFILE_COLLECTIONS variable is then appended to with the - layer name. The BBFILE_PATTERN variable is immediately expanded - with a regular expression used to match files from BBFILES into - a particular layer, in this case by using the base pathname. - The BBFILE_PRIORITY variable then assigns different - priorities to the files in different layers. This is useful - in situations where the same package might appear in multiple - layers and allows you to choose which layer should 'win'. - Note the use of - LAYERDIR with the immediate expansion operator. - LAYERDIR - expands to the directory of the current layer and - requires use of the immediate expansion operator so that Bitbake - does not lazily expand the variable when it's parsing a - different directory. - - - - Additional bbclass and configuration files can be locationed by - bitbake through the addition to the BBPATH - environment variable. In this case, the first file with the - matching name found in BBPATH is the one that is used, just - like the PATH variable for binaries. It is therefore recommended - that you use unique bbclass and configuration file names in your - custom layer. - - - - The recommended approach for custom layers is to store them in a - git repository of the format meta-prvt-XXXX and have this repository - cloned alongside the other meta directories in the Poky tree. - This way you can keep your Poky tree and it's configuration entirely - inside POKYBASE. - -
- -
- Committing Changes - - - Modifications to Poky are often managed under some kind of source - revision control system. The policy for committing to such systems - is important as some simple policy can significantly improve - usability. The tips below are based on the policy followed for the - Poky core. - - - - It helps to use a consistent style for commit messages when committing - changes. We've found a style where the first line of a commit message - summarises the change and starts with the name of any package affected - work well. Not all changes are to specific packages so the prefix could - also be a machine name or class name instead. If a change needs a longer - description this should follow the summary: - - - - bitbake/data.py: Add emit_func() and generate_dependencies() functions - - These functions allow generation of dependency data between funcitons and - variables allowing moves to be made towards generating checksums and allowing - use of the dependency information in other parts of bitbake. - - Signed-off-by: Richard Purdie rpurdie@linux.intel.com - - - - Any commit should be self contained in that it should leave the - metadata in a consistent state, buildable before and after the - commit. This helps ensure the autobuilder test results are valid - but is good practice regardless. - -
- -
- Package Revision Incrementing - - - If a committed change will result in changing the package output - then the value of the PR - variable needs to be increased (commonly referred to - as 'bumped') as part of that commit. Only integer values are used - and PR = - "r0" should be added into new recipes as, while this is the - default value, not having the variable defined in a recipe makes - it easy to miss incrementing it when updating the recipe. - When upgrading the version of a package (PV), the PR variable should be reset to "r0". - - - - The aim is that the package version will only ever increase. If - for some reason PV - will change and but not increase, the PE (Package Epoch) can - be increased (it defaults to '0'). The version numbers aim to - follow the - Debian Version Field Policy Guidelines which define how - versions are compared and hence what "increasing" means. - - - - There are two reasons for doing this, the first is to ensure that - when a developer updates and rebuilds, they get all the changes to - the repository and don't have to remember to rebuild any sections. - The second is to ensure that target users are able to upgrade their - devices via their package manager such as with the - opkg upgrade commands (or similar for - dpkg/apt or rpm based systems). The aim is to ensure Poky has - upgradable packages in all cases. - -
-
- Using Poky in a Team Environment - - - It may not be immediately clear how Poky can work in a team environment, - or scale to a large team of developers. The specifics of any situation - will determine the best solution and poky offers immense flexibility in - that aspect but there are some practises that experience has shown to work - well. - - - - The core component of any development effort with Poky is often an - automated build testing framework and image generation process. This - can be used to check that the metadata is buildable, highlight when - commits break the builds and provide up to date images allowing people - to test the end result and use them as a base platform for further - development. Experience shows that buildbot is a good fit for this role - and that it works well to configure it to make two types of build - - incremental builds and 'from scratch'/full builds. The incremental builds - can be tied to a commit hook which triggers them each time a commit is - made to the metadata and are a useful acid test of whether a given commit - breaks the build in some serious way. They catch lots of simple errors - and whilst they won't catch 100% of failures, the tests are fast so - developers can get feedback on their changes quickly. The full builds - are builds that build everything from the ground up and test everything. - They usually happen at preset times such as at night when the machine - load isn't high from the incremental builds. - poky autobuilder - is an example implementation with buildbot. - - - - Most teams have pieces of software undergoing active development. It is of - significant benefit to put these under control of a source control system - compatible with Poky such as git or svn. The autobuilder can then be set to - pull the latest revisions of these packages so the latest commits get tested - by the builds allowing any issues to be highlighted quickly. Poky easily - supports configurations where there is both a stable known good revision - and a floating revision to test. Poky can also only take changes from specific - source control branches giving another way it can be used to track/test only - specified changes. - - - Perhaps the hardest part of setting this up is the policy that surrounds - the different source control systems, be them software projects or the Poky - metadata itself. The circumstances will be different in each case but this is - one of Poky's advantages - the system itself doesn't force any particular policy - unlike a lot of build systems, allowing the best policy to be chosen for the - circumstances. - -
- -
- Updating Existing Images - - - Often, rather than reflashing a new image you might wish to install updated - packages into an existing running system. This can be done by sharing the tmp/deploy/ipk/ directory through a web server and then on the device, changing /etc/opkg/base-feeds.conf to point at this server, for example by adding: - - -src/gz all http://www.mysite.com/somedir/deploy/ipk/all -src/gz armv7a http://www.mysite.com/somedir/deploy/ipk/armv7a -src/gz beagleboard http://www.mysite.com/somedir/deploy/ipk/beagleboard -
-
- -
- Modifying Package Source Code - - - Poky is usually used to build software rather than modifying - it. However, there are ways Poky can be used to modify software. - - - - During building, the sources are available in WORKDIR directory. - Where exactly this is depends on the type of package and the - architecture of target device. For a standard recipe not - related to MACHINE it will be - tmp/work/PACKAGE_ARCH-poky-TARGET_OS/PN-PV-PR/. - Target device dependent packages use MACHINE - - instead of PACKAGE_ARCH - - in the directory name. - - - - - Check the package recipe sets the S variable to something - other than standard WORKDIR/PN-PV/ value. - - - - After building a package, a user can modify the package source code - without problem. The easiest way to test changes is by calling the - "compile" task: - - - -bitbake -c compile -f NAME_OF_PACKAGE - - - - "-f" or "--force" is used to force re-execution of the specified task. - Other tasks may also be called this way. But note that all the modifications - in WORKDIR - are gone once you executes "-c clean" for a package. - - -
- Modifying Package Source Code with quilt - - - By default Poky uses quilt - to manage patches in do_patch task. - It is a powerful tool which can be used to track all - modifications done to package sources. - - - - Before modifying source code it is important to - notify quilt so it will track changes into new patch - file: - -quilt new NAME-OF-PATCH.patch - - - Then add all files which will be modified into that - patch: - -quilt add file1 file2 file3 - - - Now start editing. At the end quilt needs to be used - to generate final patch which will contain all - modifications: - -quilt refresh - - - The resulting patch file can be found in the - patches/ subdirectory of the source - (S) directory. For future builds it - should be copied into - Poky metadata and added into SRC_URI of a recipe: - -SRC_URI += "file://NAME-OF-PATCH.patch" - - - This also requires a bump of PR value in the same recipe as we changed resulting packages. - - -
- -
-
- Track license change - - The license of one upstream project may change in the future, and Poky provides - one mechanism to track such license change - - LIC_FILES_CHKSUM variable. - - -
- Specifying the LIC_FILES_CHKSUM variable - - -LIC_FILES_CHKSUM = "file://COPYING; md5=xxxx \ - file://licfile1.txt; beginline=5; endline=29;md5=yyyy \ - file://licfile2.txt; endline=50;md5=zzzz \ - ..." - - - - S is the default directory - for searching files listed in - LIC_FILES_CHKSUM. Relative path could be used too: - - - -LIC_FILES_CHKSUM = "file://src/ls.c;startline=5;endline=16;\ - md5=bb14ed3c4cda583abc85401304b5cd4e" -LIC_FILES_CHKSUM = "file://../license.html;md5=5c94767cedb5d6987c902ac850ded2c6" - - - - The first line locates a file in - S/src/ls.c, and the second line refers to a file in - WORKDIR, which is the parent - of S - - -
- -
- Explanation of syntax - - - This parameter lists all the important files containing the text -of licenses for the -source code. It is also possible to specify on which line the license text -starts and on which line it ends within that file using the "beginline" and -"endline" parameters. If the "beginline" parameter is not specified then license -text begins from the 1st line is assumed. Similarly if "endline" parameter is -not specified then the license text ends at the last line in the file is -assumed. So if a file contains only licensing information, then there is no need -to specify "beginline" and "endline" parameters. - - -The "md5" parameter stores the md5 checksum of the license text. So if -the license text changes in any way from a file, then its md5 sum will differ and will not -match with the previously stored md5 checksum. This mismatch will trigger build -failure, notifying developer about the license text md5 mismatch, and allowing -the developer to review the license text changes. Also note that if md5 checksum -is not matched while building, the correct md5 checksum is printed in the build -log which can be easily copied to .bb file. - - -There is no limit on how many files can be specified on this parameter. But generally every -project would need specifying of just one or two files for license tracking. -Many projects would have a "COPYING" file which will store all the -license information for all the source code files. If the "COPYING" file -is valid then tracking only that file would be enough. - - - -1. If you specify empty or invalid "md5" parameter; then while building -the package, bitbake will give md5 not matched error, and also show the correct -"md5" parameter value both on the screen and in the build log - - -2. If the whole file contains only license text, then there is no need to -specify "beginline" and "endline" parameters. - - -
-
-
- Handle package name alias - -Poky implements a distro_check task which automatically connects to major distributions -and checks whether they contains same package. Sometimes the same package has different -names in different distributions, which results in a mismatch from distro_check task -This can be solved by defining per distro recipe name alias - -DISTRO_PN_ALIAS - - -
- Specifying the DISTRO_PN_ALIAS variable - - -DISTRO_PN_ALIAS_pn-PACKAGENAME = "distro1=package_name_alias1 \ - distro2=package_name_alias2 \ - distro3=package_name_alias3 \ - ..." - - -Use space as the delimiter if there're multiple distro aliases - - - -The current code can check if the src package for a recipe exists in the latest -releases of these distributions automatically. - - -Fedora, OpenSuSE, Debian, Ubuntu, Mandriva - - -For example, this command will generate a report, listing which linux distros include the -sources for each of the poky recipe. - - -bitbake world -f -c distro_check - - -The results will be stored in the build/tmp/log/distro_check-${DATETIME}.results file. - - -
-
- - - diff --git a/handbook/faq.xml b/handbook/faq.xml deleted file mode 100644 index b209fff81..000000000 --- a/handbook/faq.xml +++ /dev/null @@ -1,314 +0,0 @@ - - - -FAQ - - - - - How does Poky differ from OpenEmbedded? - - - - - Poky is a derivative of OpenEmbedded, a stable, - smaller subset focused on the GNOME Mobile environment. Development - in Poky is closely tied to OpenEmbedded with features being merged - regularly between the two for mutual benefit. - - - - - - - How can you claim Poky is stable? - - - - - There are three areas that help with stability; - - - - - We keep Poky small and focused - around 650 packages compared to over 5000 for full OE - - - - - We only support hardware that we have access to for testing - - - - - We have an autobuilder which provides continuous build and integration tests - - - - - - - - - - How do I get support for my board added to Poky? - - - - - There are two main ways to get a board supported in Poky; - - - - Send us the board if we don't have it yet - - - - - Send us bitbake recipes if you have them (see the Poky handbook to find out how to create recipes) - - - - Usually if it's not a completely exotic board then adding support in Poky should be fairly straightforward. - - - - - - - Are there any products running poky ? - - - - - The Vernier Labquest is using Poky (for more about the Labquest see the case study at OpenedHand). There are a number of pre-production devices using Poky and we will announce those as soon as they are released. - - - - - - - What is the Poky output ? - - - - - The output of a Poky build will depend on how it was started, as the same set of recipes can be used to output various formats. Usually the output is a flashable image ready for the target device. - - - - - - - How do I add my package to Poky? - - - - - To add a package you need to create a bitbake recipe - see the Poky handbook to find out how to create a recipe. - - - - - - - Do I have to reflash my entire board with a new poky image when recompiling a package? - - - - - Poky can build packages in various formats, ipk (for ipkg/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 like Ubuntu or Fedora. - - - - - - - What is GNOME Mobile? What's 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. - - - - - - - I see the error 'chmod: XXXXX new permissions are r-xrwxrwx, not r-xr-xr-x'. What's wrong? - - - - - You're probably running the build on an NTFS filesystem. Use a sane one like ext2/3/4 instead! - - - - - - - How do I make Poky work in RHEL/CentOS? - - - - - To get Poky 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 those the following external packages are needed: - - - - python-sqlite2 from DAG - repository - - - - - help2man from Karan - repository - - - - - - - Once these packages are installed Poky will be able to build standard images however there - may be a problem with QEMU segfaulting. You can either disable the generation of binary - locales by setting ENABLE_BINARY_LOCALE_GENERATION - to "0" or remove the linux-2.6-execshield.patch from the kernel and rebuild - it since its that patch which causes the problems with QEMU. - - - - - - - I see lots of 404 responses for files on http://pokylinux.org/sources/*. Is something wrong? - - - - - Nothing is wrong, Poky will check any configured source mirrors before downloading - from the upstream sources. It does this searching for both source archives and - pre-checked out versions of SCM managed software. This is so in large installations, - it can reduce load on the SCM servers themselves. The address above is one of the - default mirrors configured into standard Poky so if an upstream source disappears, - we can place sources there so builds continue to work. - - - - - - - I have a 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 stop it? - - - - - 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 which handles SRC_URI_OVERRIDES_PACKAGE_ARCH - is in base.bbclass. - - - - - - - I'm behind a firewall and need to use a proxy server. How do I do that? - - - - - Most source fetching by Poky 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/' and 'ftp_proxy = http://proxy.yoyodyne.com:18023/'. - Poky also includes a site.conf.sample file which shows how to configure cvs and git proxy servers - if needed. - - - - - - - I'm using Ubuntu Intrepid and am seeing build failures. Whats wrong? - - - - - In Intrepid, Ubuntu turned on by default normally optional compile-time security features - and warnings. There are more details at https://wiki.ubuntu.com/CompilerFlags. - You can work around this problem by disabling those options by adding " -Wno-format-security -U_FORTIFY_SOURCE" - to the BUILD_CPPFLAGS variable in conf/bitbake.conf. - - - - - - - Whats the difference between foo and foo-native? - - - - - The *-native targets are designed to run on the system the build is running on. 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 would run on the target device. - - - - - - - I'm seeing random build failures. Help?! - - - - - If the same build is failing in totally different and random ways the most likely explaination is that either the hardware you're running it on has some problem or if you are running it under virtualisation, the virtualisation probably has bugs. Poky processes a massive amount of data causing lots of network, disk and cpu activity and is senstive to even single bit failure in any of these areas. Totally random failures have always been traced back to hardware or virtualisation issues. - - - - - - - What do we need to ship for licence complience? - - - - - This is a difficult question and you need to consult your lawyer for the answer for your specific case. Its worth bearing in mind that for GPL complience there needs to be enough information shipped to allow someone else to rebuild the same end result as you are shipping. This means sharing the source code, any patches applied to it but also any configuration information about how that package was configured and built. - - - - - - - diff --git a/handbook/introduction.xml b/handbook/introduction.xml deleted file mode 100644 index 0b407a142..000000000 --- a/handbook/introduction.xml +++ /dev/null @@ -1,352 +0,0 @@ - - - -Introduction - -
- What is Poky? - - - - Poky is an open source platform build tool. It is a complete - software development environment for the creation of Linux - devices. It aids the design, development, building, debugging, - simulation and testing of complete modern software stacks - using Linux, the X Window System and GNOME Mobile - based application frameworks. It is based on OpenEmbedded but has - been customised with a particular focus. - - - - Poky was setup to: - - - - Provide an open source Linux, X11, Matchbox, GTK+, Pimlico, Clutter, and other GNOME Mobile technologies based full platform build and development tool. - - - Create a focused, stable, subset of OpenEmbedded that can be easily and reliably built and developed upon. - - - Fully support a wide range of x86, ARM, MIPS, PowerPC hardware and device virtulisation - - - - - Poky is primarily a platform builder which generates filesystem images - based on open source software such as the Kdrive X server, the Matchbox - window manager, the GTK+ toolkit and the D-Bus message bus system. Images - for many kinds of devices can be generated, however the standard example - machines target QEMU full system emulation(x86, ARM, MIPS and PowerPC) and the ARM based - Sharp Zaurus series of devices. Poky's ability to boot inside a QEMU - emulator makes it particularly suitable as a test platform for development - of embedded software. - - - - An important component integrated within Poky is Sato, a GNOME Mobile - based user interface environment. - It is designed to work well with screens at very high DPI and restricted - size, such as those often found on smartphones and PDAs. It is coded with - focus on efficiency and speed so that it works smoothly on hand-held and - other embedded hardware. It will sit neatly on top of any device - using the GNOME Mobile stack, providing a well defined user experience. - - - - - - - - - The Sato Desktop - A screenshot from a machine running a Poky built image - - - - - - - - Poky has a growing open source community and is also backed up by commercial organisations including Intel Corporation. - - -
- -
- Documentation Overview - - - The handbook is split into sections covering different aspects of Poky. - The 'Using Poky' section gives an overview - of the components that make up Poky followed by information about using and - debugging the Poky build system. The 'Extending Poky' section - gives information about how to extend and customise Poky along with advice - on how to manage these changes. - The 'Board Support Packages (BSP) - Developers Guide' section - gives information about how to develop BSP such as the common layout, the - software hardware configuration options etc. - The 'Platform Development with Poky' - section gives information about interaction between Poky and target - hardware for common platform development tasks such as software development, - debugging and profiling. The rest of the manual - consists of several reference sections each giving details on a specific - section of Poky functionality. - - - - This manual applies to Poky Release 3.3 (Green). - - -
- - -
- System Requirements - - - We recommend Debian-based distributions, in particular a recent Ubuntu - release (10.04 or newer), as the host system for Poky. Nothing in Poky is - distribution specific and - other distributions will most likely work as long as the appropriate - prerequisites are installed - we know of Poky being used successfully on Redhat, - SUSE, Gentoo and Slackware host systems. - - - On a Debian-based system, you need the following packages installed: - - - - build-essential - - - python (version 2.6 or later) - - - diffstat - - - texinfo - - - texi2html - - - cvs - - - subversion - - - wget - - - gawk - - - help2man - - - chrpath - - - mercurial - - - Furthermore if you wish to run an emulated Poky image using QEMU (as in the quickstart below) you will need the following packages installed: - - - libgl1-mesa-dev - - - libglu1-mesa-dev - - - libsdl1.2-dev - - - bochsbios (only to run qemux86 images) - - - - - Debian users can add debian.o-hand.com to their APT sources (See - - for instructions on doing this) and then run - "apt-get install qemu poky-depends poky-scripts" which will - automatically install all these dependencies. Virtualisation images with - Poky and all dependencies can also easily be built if required. - - - - Poky can use a system provided QEMU or build its own depending on how it's - configured. See the options in local.conf for more details. - -
- -
- Quick Start - -
- Building and Running an Image - - - If you want to try Poky, you can do so in a few commands. The example below - checks out the Poky source code, sets up a build environment, builds an - image and then runs that image under the QEMU emulator in x86 system emulation mode: - - - - -$ wget http://pokylinux.org/releases/poky-green-3.3.tar.bz2 -$ tar xjvf poky-green-3.3.tar.bz2 -$ cd green-3.3/ -$ source poky-init-build-env -$ bitbake poky-image-sato -$ bitbake qemu-native -$ runqemu qemux86 - - - - - - This process will need Internet access, about 20 GB of disk space - available, and you should expect the build to take about 4 - 5 hours since - it is building an entire Linux system from source including the toolchain! - - - - - To build for other machines see the MACHINE variable in build/conf/local.conf. - This file contains other useful configuration information and the default version - has examples of common setup needs and is worth - reading. To take advantage of multiple processor cores to speed up builds for example, set the - BB_NUMBER_THREADS - and PARALLEL_MAKE variables. - - The images/kernels built by Poky are placed in the tmp/deploy/images - directory. - - - - You could also run "poky-qemu zImage-qemuarm.bin poky-image-sato-qemuarm.ext2" - within the images directory if you have the poky-scripts Debian package - installed from debian.o-hand.com. This allows the QEMU images to be used standalone - outside the Poky build environment. - - - To setup networking within QEMU see the - QEMU/USB networking with IP masquerading section. - - -
-
- Downloading and Using Prebuilt Images - - - Prebuilt images from Poky are also available if you just want to run the system - under QEMU. To use these you need to: - - - - - - Add debian.o-hand.com to your APT sources (See - for instructions on doing this) - - - - Install patched QEMU and poky-scripts: - - -$ apt-get install qemu poky-scripts - - - - - - - Download a Poky QEMU release kernel (*zImage*qemu*.bin) and compressed - filesystem image (poky-image-*-qemu*.ext2.bz2) which - you'll need to decompress with 'bzip2 -d'. These are available from the - last release - or from the autobuilder. - - - - Start the image: - - -$ poky-qemu <kernel> <image> - - - - - - - A patched version of QEMU is required at present. A suitable version is available from - , it can be built - by poky (bitbake qemu-native) or can be downloaded/built as part of the toolchain/SDK tarballs. - - -
-
- -
- Obtaining Poky - -
- Releases - - Periodically, we make releases of Poky and these are available - at . - These are more stable and tested than the nightly development images. -
- -
- Nightly Builds - - - We make nightly builds of Poky for testing purposes and to make the - latest developments available. The output from these builds is available - at - where the numbers increase for each subsequent build and can be used to reference it. - - - - Automated builds are available for "standard" Poky and for Poky SDKs and toolchains as well - as any testing versions we might have such as poky-bleeding. The toolchains can - be used either as external standalone toolchains or can be combined with Poky as a - prebuilt toolchain to reduce build time. Using the external toolchains is simply a - case of untarring the tarball into the root of your system (it only creates files in - /opt/poky) and then enabling the option - in local.conf. - - -
- -
- Development Checkouts - - - Poky is available from our GIT repository located at - git://git.pokylinux.org/poky.git; a web interface to the repository - can be accessed at . - - - - The 'master' is where the deveopment work takes place and you should use this if you're - after to work with the latest cutting edge developments. It is possible trunk - can suffer temporary periods of instability while new features are developed and - if this is undesireable we recommend using one of the release branches. - -
- -
- - - diff --git a/handbook/poky-beaver.png b/handbook/poky-beaver.png deleted file mode 100644 index 9f9e6cf99..000000000 Binary files a/handbook/poky-beaver.png and /dev/null differ diff --git a/handbook/poky-handbook.png b/handbook/poky-handbook.png deleted file mode 100644 index 333442e0d..000000000 Binary files a/handbook/poky-handbook.png and /dev/null differ diff --git a/handbook/poky-handbook.xml b/handbook/poky-handbook.xml deleted file mode 100644 index fb2bc80df..000000000 --- a/handbook/poky-handbook.xml +++ /dev/null @@ -1,102 +0,0 @@ - - - - - - - - - - - - Poky Handbook - Hitchhiker's Guide to Poky - - - - Richard Purdie - - Intel Corporation - - richard@linux.intel.com - - - - Tomas Frydrych - - Intel Corporation - - - - - Marcin Juszkiewicz - - - Dodji Seketeli - - - - - - 3.3+git - 11 June 2010 - Poky Master Documentation - - - - - 2007-2010 - Intel Corporation - - - - - Permission is granted to copy, distribute and/or modify this document under - the terms of the Creative Commons Attribution-Non-Commercial-Share Alike 2.0 UK: England & Wales as published by Creative Commons. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Index - - - - diff --git a/handbook/poky-logo.svg b/handbook/poky-logo.svg deleted file mode 100644 index d0be40287..000000000 --- a/handbook/poky-logo.svg +++ /dev/null @@ -1,117 +0,0 @@ - - - -]> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/handbook/ref-bitbake.xml b/handbook/ref-bitbake.xml deleted file mode 100644 index eaf946795..000000000 --- a/handbook/ref-bitbake.xml +++ /dev/null @@ -1,348 +0,0 @@ - - - - - Reference: Bitbake - - - Bitbake is a program written in Python that interprets the metadata - that makes up Poky. At some point, people wonder what actually happens - when you type bitbake poky-image-sato. This section - aims to give an overview of what happens behind the scenes from a - BitBake perspective. - - - - It is worth noting that bitbake aims to be a generic "task" executor - capable of handling complex dependency relationships. As such it has no - real knowledge of what the tasks it is executing actually do. It just - considers a list of tasks with dependencies and handles metadata - consisting of variables in a certain format which get passed to the - tasks. - - -
- Parsing - - - The first thing BitBake does is that work out its configuration by - looking for a file called bitbake.conf. - Bitbake searches through the BBPATH environment - variable looking for a conf/ - directory containing a bitbake.conf file and - adds the first bitbake.conf file found in - BBPATH (similar to the PATH environment variable). - For Poky, bitbake.conf is found in meta/conf/. - - - - In Poky, bitbake.conf lists other configuration - files to include from a conf/ - directory below the directories listed in BBPATH. - In general the most important configuration file from a user's perspective - is local.conf, which contains a users customized - settings for Poky. Other notable configuration files are the distribution - configuration file (set by the - DISTRO variable) and the machine configuration file - (set by the MACHINE - variable). The - DISTRO and - MACHINE environment variables are both usually set in - the local.conf file. Valid distribution - configuration files are available in the - meta/conf/distro/ directory and valid machine configuration - files in the meta/conf/machine/ - directory. Within the - meta/conf/machine/include/ directory are various - tune-*.inc configuration files which provide common - "tuning" settings specific to and shared between particular - architectures and machines. - - - - After the parsing of the configuration files some standard classes - are included. In particular, base.bbclass is - always included, as will any other classes - specified in the configuration using the INHERIT - variable. Class files are searched for in a classes subdirectory - under the paths in BBPATH in the same way as - configuration files. - - - - After the parsing of the configuration files is complete, the - variable BBFILES - is set, usually in - local.conf, and defines the list of places to search for - .bb files. By - default this specifies the meta/packages/ - directory within Poky, but other directories such as - meta-extras/ can be included - too. Adding extra content to - BBFILES is best - acheived through the use of Bitbake - "layers". - - - - Bitbake parses each .bb file in - BBFILES and - stores the values of various variables. In summary, for each - .bb - file the configuration + base class of variables are set, followed - by the data in the .bb file - itself, followed by any inherit commands that - .bb file might contain. - - - - Parsing .bb files is a time - consuming process, so a cache is kept to speed up subsequent parsing. - This cache is invalid if the timestamp of the .bb - file itself has changed, or if the timestamps of any of the include, - configuration or class files the .bb - file depends on have changed. - -
- -
- Preferences and Providers - - - Once all the .bb files have been - parsed, BitBake will proceed to build "poky-image-sato" (or whatever was - specified on the commandline) and looks for providers of that target. - Once a provider is selected, BitBake resolves all the dependencies for - the target. In the case of "poky-image-sato", it would lead to - task-base.bb - which in turn would lead to packages like Contacts, - Dates, BusyBox - and these in turn depend on glibc and the toolchain. - - - - Sometimes a target might have multiple providers and a common example - is "virtual/kernel" that is provided by each kernel package. Each machine - will often elect the best provider of its kernel with a line like the - following in the machine configuration file: - - PREFERRED_PROVIDER_virtual/kernel = "linux-rp" - - The default - PREFERRED_PROVIDER is the provider with the same name as - the target. - - - - Understanding how providers are chosen is complicated by the fact - multiple versions might be present. Bitbake defaults to the highest - version of a provider by default. Version comparisons are made using - the same method as Debian. The PREFERRED_VERSION - variable can be used to specify a particular version - (usually in the distro configuration) but the order can - also be influenced by the DEFAULT_PREFERENCE - variable. By default files - have a preference of "0". Setting the - DEFAULT_PREFERENCE to "-1" will - make a package unlikely to be used unless it was explicitly referenced and - "1" makes it likely the package will be used. - PREFERRED_VERSION overrides - any DEFAULT_PREFERENCE. DEFAULT_PREFERENCE - is often used to mark more - experimental new versions of packages until they've undergone sufficient - testing to be considered stable. - - - - The end result is that internally, BitBake has now built a list of - providers for each target it needs in order of priority. - -
- -
- Dependencies - - - Each target BitBake builds consists of multiple tasks (e.g. fetch, - unpack, patch, configure, compile etc.). For best performance on - multi-core systems, BitBake considers each task as an independent - entity with a set of dependencies. There are many variables that - are used to signify these dependencies and more information can be found - about these in the - BitBake manual. At a basic level it is sufficient to know - that BitBake uses the DEPENDS and - RDEPENDS variables when - calculating dependencies and descriptions of these variables are - available through the links. - - -
- -
- The Task List - - - Based on the generated list of providers and the dependency information, - BitBake can now calculate exactly which tasks it needs to run and in what - order. The build now starts with BitBake forking off threads up to - the limit set in the BB_NUMBER_THREADS variable - as long as there are tasks ready to run, i.e. tasks with all their - dependencies met. - - - - As each task completes, a timestamp is written to the directory - specified by the STAMPS variable (usually - build/tmp/stamps/*/). On - subsequent runs, BitBake looks at the STAMPS - directory and will not rerun - tasks its already completed unless a timestamp is found to be invalid. - Currently, invalid timestamps are only considered on a per .bb file basis so if for example the configure stamp has a timestamp greater than the - compile timestamp for a given target the compile task would rerun but this - has no effect on other providers depending on that target. This could - change or become configurable in future versions of BitBake. Some tasks - are marked as "nostamp" tasks which means no timestamp file will be written - and the task will always rerun. - - - Once all the tasks have been completed BitBake exits. - -
- -
- Running a Task - - - It's worth noting what BitBake does to run a task. A task can either - be a shell task or a python task. For shell tasks, BitBake writes a - shell script to ${WORKDIR}/temp/run.do_taskname.pid - and then executes the script. The generated - shell script contains all the exported variables, and the shell functions - with all variables expanded. Output from the shell script is - sent to the file ${WORKDIR}/temp/log.do_taskname.pid. - Looking at the - expanded shell functions in the run file and the output in the log files - is a useful debugging technique. - - - - Python functions are executed internally to BitBake itself and - logging goes to the controlling terminal. Future versions of BitBake will - write the functions to files in a similar way to shell functions and - logging will also go to the log files in a similar way. - -
- - -
- Commandline - - - To quote from "bitbake --help": - - - Usage: bitbake [options] [package ...] - -Executes the specified task (default is 'build') for a given set of BitBake files. -It expects that BBFILES is defined, which is a space separated list of files to -be executed. BBFILES does support wildcards. -Default BBFILES are the .bb files in the current directory. - -Options: - --version show program's version number and exit - -h, --help show this help message and exit - -b BUILDFILE, --buildfile=BUILDFILE - execute the task against this .bb file, rather than a - package from BBFILES. - -k, --continue continue as much as possible after an error. While the - target that failed, and those that depend on it, - cannot be remade, the other dependencies of these - targets can be processed all the same. - -a, --tryaltconfigs continue with builds by trying to use alternative - providers where possible. - -f, --force force run of specified cmd, regardless of stamp status - -c CMD, --cmd=CMD Specify task to execute. Note that this only executes - the specified task for the providee and the packages - it depends on, i.e. 'compile' does not implicitly call - stage for the dependencies (IOW: use only if you know - what you are doing). Depending on the base.bbclass a - listtasks tasks is defined and will show available - tasks - -r FILE, --read=FILE read the specified file before bitbake.conf - -v, --verbose output more chit-chat to the terminal - -D, --debug Increase the debug level. You can specify this more - than once. - -n, --dry-run don't execute, just go through the motions - -S, --dump-signatures - don't execute, just dump out the signature - construction information - -p, --parse-only quit after parsing the BB files (developers only) - -d, --disable-psyco disable using the psyco just-in-time compiler (not - recommended) - -s, --show-versions show current and preferred versions of all packages - -e, --environment show the global or per-package environment (this is - what used to be bbread) - -g, --graphviz emit the dependency trees of the specified packages in - the dot syntax - -I EXTRA_ASSUME_PROVIDED, --ignore-deps=EXTRA_ASSUME_PROVIDED - Assume these dependencies don't exist and are already - provided (equivalent to ASSUME_PROVIDED). Useful to - make dependency graphs more appealing - -l DEBUG_DOMAINS, --log-domains=DEBUG_DOMAINS - Show debug logging for the specified logging domains - -P, --profile profile the command and print a report - -u UI, --ui=UI userinterface to use - --revisions-changed Set the exit code depending on whether upstream - floating revisions have changed or not - -
- -
- Fetchers - - - As well as the containing the parsing and task/dependency handling - code, bitbake also contains a set of "fetcher" modules which allow - fetching of source code from various types of sources. Example - sources might be from disk with the metadata, from websites, from - remote shell accounts or from SCM systems like cvs/subversion/git. - - - - The fetchers are usually triggered by entries in - SRC_URI. Information about the - options and formats of entries for specific fetchers can be found in the - BitBake manual. - - - - One useful feature for certain SCM fetchers is the ability to - "auto-update" when the upstream SCM changes version. Since this - requires certain functionality from the SCM only certain systems - support it, currently Subversion, Bazaar and to a limited extent, Git. It - works using the SRCREV - variable. See the - developing with an external SCM based project section for more - information. - - -
- - - diff --git a/handbook/ref-classes.xml b/handbook/ref-classes.xml deleted file mode 100644 index 036044dd2..000000000 --- a/handbook/ref-classes.xml +++ /dev/null @@ -1,455 +0,0 @@ - - - -Reference: Classes - - - Class files are used to abstract common functionality and share it amongst multiple - .bb files. Any metadata usually found in a - .bb file can also be placed in a class - file. Class files are identified by the extension - .bbclass and are usually placed - in a classes/ directory beneath the - meta*/ directory or the directory pointed - by BUILDDIR (e.g. build/)in the same way as - .conf files in the conf directory. Class files are searched for - in BBPATH in the same was as .conf files too. - - - - In most cases inheriting the class is enough to enable its features, although - for some classes you may need to set variables and/or override some of the - default behaviour. - - -
- The base class - <filename>base.bbclass</filename> - - - The base class is special in that every .bb - file inherits it automatically. It contains definitions of standard basic - tasks such as fetching, unpacking, configuring (empty by default), compiling - (runs any Makefile present), installing (empty by default) and packaging - (empty by default). These are often overridden or extended by other classes - such as autotools.bbclass or - package.bbclass. The class also contains some commonly - used functions such as oe_runmake. - -
- -
- Autotooled Packages - <filename>autotools.bbclass</filename> - - - Autotools (autoconf, automake, libtool) brings standardisation and this - class aims to define a set of tasks (configure, compile etc.) that will - work for all autotooled packages. It should usualy be enough to define - a few standard variables as documented in the simple autotools - example section and then simply "inherit autotools". This class - can also work with software that emulates autotools. - - - - It's useful to have some idea on how the tasks defined by this class work - and what they do behind the scenes. - - - - - - 'do_configure' regenearates the configure script (using autoreconf) and - then launches it with a standard set of arguments used during - cross-compilation. Additional parameters can be passed to - configure through the EXTRA_OECONF variable. - - - - - 'do_compile' runs make with arguments specifying - the compiler and linker. Additional arguments can be passed through - the EXTRA_OEMAKE - variable. - - - - - 'do_install' runs make install passing a DESTDIR - option taking its value from the standard DESTDIR variable. - - - - -
- -
- Alternatives - <filename>update-alternatives.bbclass</filename> - - - Several programs can fulfill the same or similar function and - they can be installed with the same name. For example the ar - command is available from the "busybox", "binutils" and "elfutils" packages. - This class handles the renaming of the binaries so multiple packages - can be installed which would otherwise conflict and yet the - ar command still works regardless of which are installed - or subsequently removed. It renames the conflicting binary in each package - and symlinks the highest priority binary during installation or removal - of packages. - - Four variables control this class: - - - - - - ALTERNATIVE_NAME - - - Name of binary which will be replaced (ar in this example) - - - - - ALTERNATIVE_LINK - - - Path to resulting binary ("/bin/ar" in this example) - - - - - ALTERNATIVE_PATH - - - Path to real binary ("/usr/bin/ar.binutils" in this example) - - - - - ALTERNATIVE_PRIORITY - - - Priority of binary, the version with the most features should have the highest priority - - - - - - - Currently, only one binary per package is supported. - -
- -
- Initscripts - <filename>update-rc.d.bbclass</filename> - - - This class uses update-rc.d to safely install an initscript on behalf of - the package. Details such as making sure the initscript is stopped before - a package is removed and started when the package is installed are taken - care of. Three variables control this class, - INITSCRIPT_PACKAGES, - INITSCRIPT_NAME and - INITSCRIPT_PARAMS. See the - links for details. - -
- -
- Binary config scripts - <filename>binconfig.bbclass</filename> - - - Before pkg-config had become widespread, libraries shipped shell - scripts to give information about the libraries and include paths needed - to build software (usually named 'LIBNAME-config'). This class assists - any recipe using such scripts. - - - - During staging Bitbake installs such scripts into the sysroots/ directory. It also changes all - paths to point into the sysroots/ - directory so all builds which use the script will use the correct - directories for the cross compiling layout. - -
- -
- Debian renaming - <filename>debian.bbclass</filename> - - - This class renames packages so that they follow the Debian naming - policy, i.e. 'glibc' becomes 'libc6' and 'glibc-devel' becomes - 'libc6-dev'. - -
- -
- Pkg-config - <filename>pkgconfig.bbclass</filename> - - - Pkg-config brought standardisation and this class aims to make its - integration smooth for all libraries which make use of it. - - - - During staging Bitbake installs pkg-config data into the sysroots/ directory. By making use of - sysroot functionality within pkgconfig this class no longer has to - manipulate the files. - -
- -
- Distribution of sources - <filename>src_distribute_local.bbclass</filename> - - - Many software licenses require providing the sources for compiled - binaries. To simplify this process two classes were created: - src_distribute.bbclass and - src_distribute_local.bbclass. - - - - Result of their work are tmp/deploy/source/ - subdirs with sources sorted by LICENSE - field. If recipe lists few licenses (or has entries like "Bitstream Vera") source archive is put in each - license dir. - - - - Src_distribute_local class has three modes of operating: - - - - copy - copies the files to the distribute dir - symlink - symlinks the files to the distribute dir - move+symlink - moves the files into distribute dir, and symlinks them back - -
- -
- Perl modules - <filename>cpan.bbclass</filename> - - - Recipes for Perl modules are simple - usually needs only - pointing to source archive and inheriting of proper bbclass. - Building is split into two methods dependly on method used by - module authors. - - - - Modules which use old Makefile.PL based build system require - using of cpan.bbclass in their recipes. - - - - Modules which use Build.PL based build system require - using of cpan_build.bbclass in their recipes. - - -
- -
- Python extensions - <filename>distutils.bbclass</filename> - - - Recipes for Python extensions are simple - they usually only - require pointing to the source archive and inheriting the proper - bbclasses. - Building is split into two methods depending on the build method - used by the module authors. - - - - Extensions which use autotools based build system require use - of autotools and distutils-base bbclasses in their recipes. - - - - Extensions which use distutils build system require use - of distutils.bbclass in their recipes. - - -
- -
- Developer Shell - <filename>devshell.bbclass</filename> - - - This class adds the devshell task. Its usually up to distribution policy - to include this class (Poky does). See the developing with 'devshell' section - for more information about using devshell. - - -
- -
- Packaging - <filename>package*.bbclass</filename> - - - The packaging classes add support for generating packages from a builds - output. The core generic functionality is in - package.bbclass, code specific to particular package - types is contained in various sub classes such as - package_deb.bbclass, package_ipk.bbclass - and package_rpm.bbclass. Most users will - want one or more of these classes and this is controlled by the - PACKAGE_CLASSES - variable. The first class listed in this variable will be used for image - generation. Since images are generated from packages a packaging class is - needed to enable image generation. - - -
- -
- Building kernels - <filename>kernel.bbclass</filename> - - - This class handles building of Linux kernels and the class contains code to know how to build both 2.4 and 2.6 kernel trees. All needed headers are - staged into STAGING_KERNEL_DIR - directory to allow building of out-of-tree modules using module.bbclass. - - - This means that each kernel module built is packaged separately and inter-module dependencies are - created by parsing the modinfo output. If all modules are - required then installing the "kernel-modules" package will install all - packages with modules and various other kernel packages such as "kernel-vmlinux". - - - - Various other classes are used by the kernel and module classes internally including - kernel-arch.bbclass, module_strip.bbclass, - module-base.bbclass and linux-kernel-base.bbclass. - -
- -
- Creating images - <filename>image.bbclass</filename> and <filename>rootfs*.bbclass</filename> - - - Those classes add support for creating images in many formats. First the - rootfs is created from packages by one of the rootfs_*.bbclass - files (depending on package format used) and then image is created. - - The IMAGE_FSTYPES - variable controls which types of image to generate. - - The list of packages to install into the image is controlled by the - IMAGE_INSTALL - variable. - -
- -
- Host System sanity checks - <filename>sanity.bbclass</filename> - - - This class checks prerequisite software is present to - notify the users problems that will affect their build. It also - performs basic checks of the user configuration from local.conf to - prevent common mistakes resulting in build failures. It's usually up to - distribution policy whether to include this class (Poky does). - -
- -
- Generated output quality assurance checks - <filename>insane.bbclass</filename> - - - This class adds a step to package generation which sanity checks the - packages generated by Poky. There are an ever increasing range of checks - it performs, checking for common problems which break builds/packages/images, - see the bbclass file for more information. It's usually up to distribution - policy whether to include this class (Poky does). - -
- -
- Autotools configuration data cache - <filename>siteinfo.bbclass</filename> - - - Autotools can require tests which have to execute on the target hardware. - Since this isn't possible in general when cross compiling, siteinfo is - used to provide cached test results so these tests can be skipped over but - the correct values used. The meta/site directory - contains test results sorted into different categories like architecture, endianess and - the libc used. Siteinfo provides a list of files containing data relevant to - the current build in the CONFIG_SITE - variable which autotools will automatically pick up. - - - The class also provides variables like SITEINFO_ENDIANESS - and SITEINFO_BITS - which can be used elsewhere in the metadata. - - - This class is included from base.bbclass and is hence always active. - -
- -
- Other Classes - - - Only the most useful/important classes are covered here but there are - others, see the meta/classes directory for the rest. - -
- - - - - - diff --git a/handbook/ref-features.xml b/handbook/ref-features.xml deleted file mode 100644 index cde958811..000000000 --- a/handbook/ref-features.xml +++ /dev/null @@ -1,302 +0,0 @@ - - - - Reference: Features - - 'Features' provide a mechanism for working out which packages - should be included in the generated images. Distributions can - select which features they want to support through the - DISTRO_FEATURES - variable which is set in the distribution configuration file - (poky.conf for Poky). Machine features are set in the - MACHINE_FEATURES - variable which is set in the machine configuration file and - specifies which hardware features a given machine has. - - - These two variables are combined to work out which kernel modules, - utilities and other packages to include. A given distribution can - support a selected subset of features so some machine features might not - be included if the distribution itself doesn't support them. - - -
- Distro - - The items below are valid options for DISTRO_FEATURES. - - - - - - alsa - ALSA support will be included (OSS compatibility - kernel modules will be installed if available) - - - - - bluetooth - Include bluetooth support (integrated BT only) - - - - - ext2 - Include tools for supporting for devices with internal - HDD/Microdrive for storing files (instead of Flash only devices) - - - - - irda - Include Irda support - - - - - keyboard - Include keyboard support (e.g. keymaps will be - loaded during boot). - - - - - pci - Include PCI bus support - - - - - pcmcia - Include PCMCIA/CompactFlash support - - - - - usbgadget - USB Gadget Device support (for USB - networking/serial/storage) - - - - - usbhost - USB Host support (allows to connect external - keyboard, mouse, storage, network etc) - - - - - wifi - WiFi support (integrated only) - - - - - cramfs - CramFS support - - - - - ipsec - IPSec support - - - - - ipv6 - IPv6 support - - - - - nfs - NFS client support (for mounting NFS exports on - device) - - - - - ppp - PPP dialup support - - - - - smbfs - SMB networks client support (for mounting - Samba/Microsoft Windows shares on device) - - - -
- -
- Machine - - The items below are valid options for MACHINE_FEATURES. - - - - - - acpi - Hardware has ACPI (x86/x86_64 only) - - - - - alsa - Hardware has ALSA audio drivers - - - - - apm - Hardware uses APM (or APM emulation) - - - - - bluetooth - Hardware has integrated BT - - - - - ext2 - Hardware HDD or Microdrive - - - - - irda - Hardware has Irda support - - - - - keyboard - Hardware has a keyboard - - - - - pci - Hardware has a PCI bus - - - - - pcmcia - Hardware has PCMCIA or CompactFlash sockets - - - - - screen - Hardware has a screen - - - - - serial - Hardware has serial support (usually RS232) - - - - - touchscreen - Hardware has a touchscreen - - - - - usbgadget - Hardware is USB gadget device capable - - - - - usbhost - Hardware is USB Host capable - - - - - wifi - Hardware has integrated WiFi - - - -
- -
- Reference: Images - - - The contents of images generated by Poky can be controlled by the IMAGE_FEATURES - variable in local.conf. Through this you can add several different - predefined packages such as development utilities or packages with debug - information needed to investigate application problems or profile applications. - - - - Current list of IMAGE_FEATURES contains: - - - - - - apps-console-core - Core console applications such as ssh daemon, - avahi daemon, portmap (for mounting NFS shares) - - - - - x11-base - X11 server + minimal desktop - - - - - x11-sato - OpenedHand Sato environment - - - - - apps-x11-core - Core X11 applications such as an X Terminal, file manager, file editor - - - - - apps-x11-games - A set of X11 games - - - - - apps-x11-pimlico - OpenedHand Pimlico application suite - - - - - tools-sdk - A full SDK which runs on device - - - - - tools-debug - Debugging tools such as strace and gdb - - - - - tools-profile - Profiling tools such as oprofile, exmap and LTTng - - - - - tools-testapps - Device testing tools (e.g. touchscreen debugging) - - - - - nfs-server - NFS server (exports / over NFS to everybody) - - - - - dev-pkgs - Development packages (headers and extra library links) for all packages - installed in a given image - - - - - dbg-pkgs - Debug packages for all packages installed in a given image - - - -
- - - diff --git a/handbook/ref-images.xml b/handbook/ref-images.xml deleted file mode 100644 index 03583eb39..000000000 --- a/handbook/ref-images.xml +++ /dev/null @@ -1,72 +0,0 @@ - - - - Reference: Images - - - Poky has several standard images covering most people's standard needs. A full - list of image targets can be found by looking in the directories - meta/recipes-core/images/, - meta/packages/images/, - meta/recipes-sato/images/ and - meta/packages/meta/. The standard - images are listed below along with details of what they contain: - - - - - - poky-image-minimal - A small image, just enough - to allow a device to boot - - - - - poky-image-base - console only image with full - support of target device hardware - - - - - poky-image-core - X11 image with simple apps like - terminal, editor and file manager - - - - - poky-image-sato - X11 image with Sato theme and - Pimlico applications. Also contains terminal, editor and file manager. - - - - - poky-image-sdk - X11 image like poky-image-sato but - also include native toolchain and libraries needed to build applications - on the device itself. Also includes testing and profiling tools and debug - symbols. - - - - - meta-toolchain - This generates a tarball containing - a standalone toolchain which can be used externally to Poky. It is self - contained and unpacks to the /opt/poky - directory. It also contains a copy of QEMU and the scripts neccessary to run - poky QEMU images. - - - - - meta-toolchain-sdk - This includes everything in - meta-toolchain but also includes development headers and libraries - forming a complete standalone SDK. See the - Developing using the Poky SDK and - Developing using the Anjuta Plugin sections for more information. - - - - - diff --git a/handbook/ref-structure.xml b/handbook/ref-structure.xml deleted file mode 100644 index ca589de42..000000000 --- a/handbook/ref-structure.xml +++ /dev/null @@ -1,514 +0,0 @@ - - - - -Reference: Directory Structure - - - Poky consists of several components and understanding what these are - and where they're located is one of the keys to use it. This section walks - through the Poky directory structure giving information about the various - files and directories. - - -
- Top level core components - -
- <filename class="directory">bitbake/</filename> - - - A copy of BitBake is included within Poky for ease of use, and should - usually match the current BitBake stable release from the BitBake project. - Bitbake, a metadata interpreter, reads the Poky metadata and runs the tasks - defined in the Poky metadata. Failures are usually from the metadata, not - BitBake itself, so most users don't need to worry about BitBake. The - bitbake/bin/ directory is placed - into the PATH environment variable by the poky-init-build-env script. - - - For more information on BitBake please see the BitBake project site at - - and the BitBake on-line manual at . - -
- -
- <filename class="directory">build/</filename> - - - This directory contains user configuration files and the output - generated by Poky in its standard configuration where the source tree is - combined with the output. It is also possible to place output and configuration - files in a directory separate from the Poky source, see the section seperate output directory. - -
- -
- <filename class="directory">meta/</filename> - - - This directory contains the core metadata, a key part of Poky. Within this - directory there are definitions of the machines, the Poky distribution - and the packages that make up a given system. - -
- -
- <filename class="directory">meta-extras/</filename> - - - This directory is similar to meta/, - and contains some extra metadata not included in standard Poky. These are - disabled by default, and are not supported as part of Poky. - -
- -
- <filename class="directory">meta-***/</filename> - - - These directories are optional layers to be added to core metadata, which - are enabled by adding them to conf/bblayers.conf. - -
- -
- <filename class="directory">scripts/</filename> - - - This directory contains various integration scripts which implement - extra functionality in the Poky environment, such as the QEMU - scripts. This directory is appended to the PATH environment variable by the - poky-init-build-env script. - -
- -
- <filename class="directory">sources/</filename> - - - While not part of a checkout, Poky will create this directory as - part of any build. Any downloads are placed in this directory (as - specified by the DL_DIR - variable). This directory can be shared between Poky - builds to save downloading files multiple times. SCM checkouts are - also stored here as e.g. sources/svn/ - , sources/cvs/ or - sources/git/ and the - sources directory may contain archives of checkouts for various - revisions or dates. - - - - It's worth noting that BitBake creates .md5 - stamp files for downloads. It uses these to mark downloads as - complete as well as for checksum and access accounting purposes. If you add - a file manually to the directory, you need to touch the corresponding - .md5 file too. - - - - This location can be overridden by setting DL_DIR in local.conf - . This directory can be shared between builds and even between - machines via NFS, so downloads are only made once, speeding up builds. - - -
- -
- <filename class="directory">handbook</filename> - - - This is the location where this handbook is generated - -
- -
- <filename>poky-init-build-env</filename> - - - This script is used to setup the Poky build environment. Sourcing this file in - a shell makes changes to PATH and sets other core BitBake variables based on the - current working directory. You need to use this before running Poky commands. - Internally it uses scripts within the scripts/ - directory to do the bulk of the work. This script supports - specifying any directory as the build output: - - - -source POKY_SRC/poky-init-build-env [BUILDDIR] - - - - The above command can be typed from any directory, as long as POKY_SRC points to - the desired Poky source tree. The optional BUILDDIR could be any directory you'd - like Poky to generate the build output into. - -
-
- -
- <filename class="directory">build/</filename> - The Build Directory - -
- <filename>build/conf/local.conf</filename> - - - This file contains all the local user configuration of Poky. If there - is no local.conf present, it is created from - local.conf.sample. The local.conf - file contains documentation on the various configuration options. Any - variable set here overrides any variable set elsewhere within Poky unless - that variable is hardcoded within Poky (e.g. by using '=' instead of '?='). - Some variables are hardcoded for various reasons but these variables are - relatively rare. - - - - Edit this file to set the MACHINE for which you want to build, which package types you - wish to use (PACKAGE_CLASSES) or where downloaded files should go - (DL_DIR). - -
- -
- <filename>build/conf/bblayers.conf</filename> - - - This file defines layers walked by bitbake. If there's no - bblayers.conf present, it is created from bblayers.conf.sample - when the environment setup script is sourced. - -
- -
- <filename class="directory">build/tmp/</filename> - - - This is created by BitBake if it doesn't exist and is where all the Poky output - is placed. To clean Poky and start a build from scratch (other than downloads), - you can wipe this directory. The tmp/ - directory has some important sub-components detailed below. - -
- -
- <filename class="directory">build/tmp/cache/</filename> - - - When BitBake parses the metadata it creates a cache file of the result which can - be used when subsequently running commands. These are stored here on - a per machine basis. - -
- -
- <filename class="directory">build/tmp/deploy/</filename> - - Any 'end result' output from Poky is placed under here. -
- -
- <filename class="directory">build/tmp/deploy/deb/</filename> - - - Any .deb packages emitted by Poky are placed here, sorted into feeds for - different architecture types. - -
- -
- <filename class="directory">build/tmp/deploy/rpm/</filename> - - - Any .rpm packages emitted by Poky are placed here, sorted into feeds for - different architecture types. - -
- -
- <filename class="directory">build/tmp/deploy/images/</filename> - - - Complete filesystem images are placed here. If you want to flash the resulting - image from a build onto a device, look here for them. - -
- -
- <filename class="directory">build/tmp/deploy/ipk/</filename> - - Any resulting .ipk packages emitted by Poky are placed here. -
- -
- <filename class="directory">build/tmp/sysroots/</filename> - - - Any package needing to share output with other packages does so within sysroots. - This means it contains any shared header files and any shared libraries amongst - other data. It is subdivided by architecture so multiple builds can run within - the one build directory. - -
- -
- <filename class="directory">build/tmp/stamps/</filename> - - - This is used by BitBake for accounting purposes to keep track of which tasks - have been run and when. It is also subdivided by architecture. The files are - empty and the important information is the filenames and timestamps. - -
- -
- <filename class="directory">build/tmp/log/</filename> - - - This contains some general logs if not placing in a package's - WORKDIR, such as - the log output from check_pkg or distro_check tasks. - -
- -
- <filename class="directory">build/tmp/pkgdata/</filename> - - - This is an intermediate place for saving packaging data, which will be used - in later packaging process. For detail please refer to - package.bbclass. - -
- -
- <filename class="directory">build/tmp/pstagelogs/</filename> - - - This directory contains manifest for task based prebuilt. Each manifest is basically - a file list for installed files from a given task, which would be useful for later - packaging or cleanup process. - -
- -
- <filename class="directory">build/tmp/work/</filename> - - - This directory contains various subdirectories for each architecture, and each package built by BitBake has its own work directory under the appropriate architecture subdirectory. All tasks are executed from this work directory. As an example, the source for a particular package will be unpacked, patched, configured and compiled all within its own work directory. - - - - It is worth considering the structure of a typical work directory. An - example is the linux-rp kernel, version 2.6.20 r7 on the machine spitz - built within Poky. For this package a work directory of tmp/work/spitz-poky-linux-gnueabi/linux-rp-2.6.20-r7/ - , referred to as WORKDIR - , is created. Within this directory, the source is - unpacked to linux-2.6.20 and then patched by quilt (see Section 3.5.1). - Within the linux-2.6.20 directory, - standard Quilt directories linux-2.6.20/patches - and linux-2.6.20/.pc are created, - and standard quilt commands can be used. - - - - There are other directories generated within WORKDIR. The most important - is WORKDIR/temp/ which has log files for each - task (log.do_*.pid) and the scripts BitBake runs for - each task (run.do_*.pid). The WORKDIR/image/ directory is where make - install places its output which is then split into subpackages - within WORKDIR - /packages-split/. - -
-
- -
- <filename class="directory">meta/</filename> - The Metadata - - - As mentioned previously, this is the core of Poky. It has several - important subdivisions: - - -
- <filename class="directory">meta/classes/</filename> - - - Contains the *.bbclass files. Class - files are used to abstract common code allowing it to be reused by multiple - packages. The base.bbclass file is inherited by every - package. Examples of other important classes are - autotools.bbclass that in theory allows any - Autotool-enabled package to work with Poky with minimal effort, or - kernel.bbclass that contains common code and functions - for working with the linux kernel. Functions like image generation or - packaging also have their specific class files (image.bbclass - , rootfs_*.bbclass and - package*.bbclass). - -
- -
- <filename class="directory">meta/conf/</filename> - - - This is the core set of configuration files which start from - bitbake.conf and from which all other configuration - files are included (see the includes at the end of the file, even - local.conf is loaded from there!). While - bitbake.conf sets up the defaults, these can often be - overridden by user (local.conf), machine or - distribution configuration files. - -
- -
- <filename class="directory">meta/conf/machine/</filename> - - - Contains all the machine configuration files. If you set MACHINE="spitz", the - end result is Poky looking for a spitz.conf file in this directory. The includes - directory contains various data common to multiple machines. If you want to add - support for a new machine to Poky, this is the directory to look in. - -
- -
- <filename class="directory">meta/conf/distro/</filename> - - - Any distribution specific configuration is controlled from here. OpenEmbedded - supports multiple distributions of which Poky is one. Poky only contains the - Poky distribution so poky.conf is the main file here. This includes the - versions and SRCDATES for applications which are configured here. An example of - an alternative configuration is poky-bleeding.conf although this mainly inherits - its configuration from Poky itself. - -
- -
- <filename class="directory">meta/recipes-bsp/</filename> - - - Anything linking to specific hardware or hardware configuration information - are placed here, such as uboot, grub, etc. - -
- -
- <filename class="directory">meta/recipes-connectivity/</filename> - - - Libraries and applications related to communication with other devices - -
- -
- <filename class="directory">meta/recipes-core/</filename> - - - What's needed to build a basic working Linux image including commonly used dependencies - -
- -
- <filename class="directory">meta/recipes-devtools/</filename> - - - Tools primarily used by the build system (but can also be used on targets) - -
- -
- <filename class="directory">meta/recipes-extended/</filename> - - - Applications which whilst not essential add features compared to the alternatives in - core. May be needed for full tool functionality or LSB compliance. - -
- -
- <filename class="directory">meta/recipes-gnome/</filename> - - - All things related to the GTK+ application framework - -
- -
- <filename class="directory">meta/recipes-graphics/</filename> - - - X and other graphically related system libraries - -
- -
- <filename class="directory">meta/recipes-kernel/</filename> - - - The kernel and generic applications/libraries with strong kernel dependencies - -
- -
- <filename class="directory">meta/recipes-multimedia/</filename> - - - Codecs and support utilties for audio, images and video - -
- -
- <filename class="directory">meta/recipes-qt/</filename> - - - All things related to the QT application framework - -
- -
- <filename class="directory">meta/recipes-sato/</filename> - - - The Sato demo/reference UI/UX, its associated apps and configuration - -
- -
- <filename class="directory">meta/packages/</filename> - - - this is a catch-all place for the rest which not fits into above - recipes-***. Images and tasks are also placed here. - -
- -
- <filename class="directory">meta/site/</filename> - - - Certain autoconf test results cannot be determined when cross compiling since it - can't run tests on a live system. This directory therefore contains a list of - cached results for various architectures which is passed to autoconf. - -
-
- - - diff --git a/handbook/ref-variables.xml b/handbook/ref-variables.xml deleted file mode 100644 index 7e1080852..000000000 --- a/handbook/ref-variables.xml +++ /dev/null @@ -1,879 +0,0 @@ - - - - - -Reference: Variables Glossary - - - This section lists common variables used in Poky and gives an overview - of their function and contents. - - - - - - - A - B - C - D - E - F - - H - I - - K - L - M - - - P - - R - S - T - - - W - - - - - - A - - AUTHOR - - E-mail address to contact original author(s) - to - send patches, forward bugs... - - - - AUTOREV - - Use current (newest) source revision - used with - SRCREV - variable. - - - - - - B - - BB_NUMBER_THREADS - - The maximum number of tasks BitBake should run in parallel at any one time - - - - BBFILES - - List of recipes used by BitBake to build software - - - - - - BBINCLUDELOGS - - Variable which controls how BitBake displays logs on build failure. - - - - BPN - - Bare name of package with any suffixes like -cross -native - removed. - - - - - - C - - CFLAGS - - - Flags passed to C compiler for the target system. Evaluates to the same - as TARGET_CFLAGS. - - - - - COMPATIBLE_MACHINE - - A regular expression which evalutates to match the machines the recipe - works with. It stops recipes being run on machines they're incompatible with, - which is partciuarly useful with kernels. It also helps to increase parsing - speed as further parsing of the recipe is skipped as if it found the current - machine is not compatible. - - - - CONFIG_SITE - - - A list of files which contains autoconf test results relevant - to the current build. This variable is used by the autotools utilities - when running configure. - - - - - - - D - - D - - Destination directory - - - - DEBUG_BUILD - - - Build packages with debugging information. This influences the value - SELECTED_OPTIMIZATION - takes. - - - - - DEBUG_OPTIMIZATION - - - The options to pass in TARGET_CFLAGS - and CFLAGS when compiling a system for debugging. - This defaults to "-O -fno-omit-frame-pointer -g". - - - - - DEFAULT_PREFERENCE - - Priority of recipe - - - - DEPENDS - - - A list of build time dependencies for a given recipe. These indicate - recipes that must have staged before this recipe can configure. - - - - - DESCRIPTION - - Package description used by package - managers - - - - DESTDIR - - Destination directory - - - - DISTRO - - Short name of distribution - - - - DISTRO_EXTRA_RDEPENDS - - List of packages required by distribution. - - - - DISTRO_EXTRA_RRECOMMENDS - - List of packages which extend usability of - image. Those packages will be automatically - installed but can be removed by user. - - - - DISTRO_FEATURES - - Features of the distribution. - - - - DISTRO_NAME - - Long name of distribution - - - - DISTRO_PN_ALIAS - - Alias names of the recipe in various Linux distributions. - More information in - - Configuring the DISTRO_PN_ALIAS variable section - - - - - - DISTRO_VERSION - - Version of distribution - - - - DL_DIR - - Directory where all fetched sources will be stored - - - - - - E - - ENABLE_BINARY_LOCALE_GENERATION - - Variable which control which locales for glibc are - to be generated during build (useful if target device - has 64M RAM or less) - - - - EXTRA_OECMAKE - - Additional cmake options - - - - EXTRA_OECONF - - Additional 'configure' script options - - - - EXTRA_OEMAKE - - Additional GNU make options - - - - - - F - - FILES - - list of directories/files which will be placed - in packages - - - - FULL_OPTIMIZATION - - - The options to pass in TARGET_CFLAGS - and CFLAGS when compiling an optimised system. - This defaults to "-fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2". - - - - - - - - - - H - - HOMEPAGE - - Website where more info about package can be found - - - - - - I - - IMAGE_FEATURES - - List of - features present in resulting images - - - - IMAGE_FSTYPES - - Formats of rootfs images which we want to have - created - - - - IMAGE_INSTALL - - List of packages used to build image - - - - INHIBIT_PACKAGE_STRIP - - - This variable causes the build to not strip binaries in - resulting packages. - - - - - - INHERIT - - - This variable causes the named class to be inherited at - this point during parsing. Its only valid in configuration - files. - - - - - - INITSCRIPT_PACKAGES - - - Scope: Used in recipes when using update-rc.d.bbclass. Optional, defaults to PN. - - - A list of the packages which contain initscripts. If multiple - packages are specified you need to append the package name - to the other INITSCRIPT_* as an override. - - - - - INITSCRIPT_NAME - - - Scope: Used in recipes when using update-rc.d.bbclass. Mandatory. - - - The filename of the initscript (as installed to ${etcdir}/init.d). - - - - - INITSCRIPT_PARAMS - - - Scope: Used in recipes when using update-rc.d.bbclass. Mandatory. - - - Specifies the options to pass to update-rc.d. An example is - "start 99 5 2 . stop 20 0 1 6 ." which gives the script a - runlevel of 99, starts the script in initlevels 2 and 5 and - stops it in levels 0, 1 and 6. - - - - - - - - - - - K - - KERNEL_IMAGETYPE - - The type of kernel to build for a device, usually set by the - machine configuration files and defaults to "zImage". This is used - when building the kernel and is passed to "make" as the target to - build. - - - - - - L - - LAYERDIR - - When used inside a layer.conf gives the path of the - current layer. This variable requires immediate expansion - (see the Bitbake manual) as lazy expansion can result in - the expansion happening in the wrong directory and therefore - giving the wrong value. - - - LICENSE - - List of package source licenses. - - - LIC_FILES_CHKSUM - - Checksums of the license text in the recipe source code. - - This variable tracks changes in license text of the source - code files. If the license text is changed, it will trigger the build - failure, which gives developer an opportunity to review any - license change - This is an optional variable now, and the plan is to make - it a required variable in the future - See "meta/package/zlib/zlib_${PV}.bb" file for an example - - More information in - Configuring the LIC_FILES_CHKSUM variable section - - - - - - M - - MACHINE - - Target device - - - - MACHINE_ESSENTIAL_RDEPENDS - - List of packages required to boot device - - - - MACHINE_ESSENTIAL_RRECOMMENDS - - List of packages required to boot device (usually - additional kernel modules) - - - - MACHINE_EXTRA_RDEPENDS - - List of packages required to use device - - - - MACHINE_EXTRA_RRECOMMNEDS - - List of packages useful to use device (for example - additional kernel modules) - - - - MACHINE_FEATURES - - List of device features - defined in machine - features section - - - - MAINTAINER - - E-mail of distribution maintainer - - - - - - - - - - - P - - PACKAGE_ARCH - - Architecture of resulting package - - - - PACKAGE_CLASSES - - List of resulting packages formats - - - - PACKAGE_EXTRA_ARCHS - - List of architectures compatible with device - CPU. Usable when build is done for few different - devices with misc processors (like XScale and - ARM926-EJS) - - - - PACKAGES - - List of packages to be created from recipe. - The default value is "${PN}-dbg ${PN} ${PN}-doc ${PN}-dev" - - - - PARALLEL_MAKE - - Extra options that are passed to the make command during the - compile tasks. This is usually of the form '-j 4' where the number - represents the maximum number of parallel threads make can run. - - - - PN - - Name of package. - - - - - PR - - Revision of package. - - - - - PV - - Version of package. - The default value is "1.0" - - - - PE - - - Epoch of the package. The default value is "0". The field is used - to make upgrades possible when the versioning scheme changes in - some backwards incompatible way. - - - - - PREFERRED_PROVIDER - - If multiple recipes provide an item, this variable - determines which one should be given preference. It - should be set to the "$PN" of the recipe to be preferred. - - - - PREFERRED_VERSION - - - If there are multiple versions of recipe available, this - variable determines which one should be given preference. It - should be set to the "$PV" of the recipe to be preferred. - - - - - POKY_EXTRA_INSTALL - - List of packages to be added to the image. This should - only be set in local.conf. - - - - POKYLIBC - - Libc implementation selector - glibc, eglibc, or uclibc can be selected. - - - - POKYMODE - - Toolchain selector. It can be external toolchain - built from Poky or few supported combinations of - upstream GCC or CodeSourcery Labs toolchain. - - - - - - - - - R - - RCONFLICTS - - List of packages which conflict with this - one. Package will not be installed if they are not - removed first. - - - - RDEPENDS - - - A list of run-time dependencies for a package. These packages - need to be installed alongside the package it applies to so - the package will run correctly, an example is a perl script - which would rdepend on perl. Since this variable applies to - output packages there would usually be an override attached - to this variable like RDEPENDS_${PN}-dev. Names in this field - should be as they are in PACKAGES - namespace before any renaming of the output package - by classes like debian.bbclass. - - - - - ROOT_FLASH_SIZE - - Size of rootfs in megabytes - - - - RRECOMMENDS - - List of packages which extend usability of the - package. Those packages will be automatically - installed but can be removed by user. - - - - RREPLACES - - List of packages which are replaced with this - one. - - - - - - S - - S - - - Path to unpacked sources (by default: - "${WORKDIR}/${PN}-${PV}") - - - - - SECTION - - Section where package should be put - used - by package managers - - - - SELECTED_OPTIMIZATION - - - The variable takes the value of FULL_OPTIMIZATION - unless DEBUG_BUILD = "1" in which case - DEBUG_OPTIMIZATION is used. - - - - - - SERIAL_CONSOLE - - Speed and device for serial port used to attach - serial console. This is given to kernel as "console" - param and after boot getty is started on that port - so remote login is possible. - - - - SHELLCMDS - - - A list of commands to run within the a shell, used by TERMCMDRUN. - - - - - SITEINFO_ENDIANESS - - - Contains "le" for little-endian or "be" for big-endian depending - on the endian byte order of the target system. - - - - - SITEINFO_BITS - - - Contains "32" or "64" depending on the number of bits for the - CPU of the target system. - - - - - SRC_URI - - List of source files (local or remote ones) - - - - SRC_URI_OVERRIDES_PACKAGE_ARCH - - - By default there is code which automatically detects whether - SRC_URI - contains files which are machine specific and if this is the case it - automatically changes - PACKAGE_ARCH. - Setting this variable to "0" disables that behaviour. - - - - - SRCDATE - - - Date of source code used to build package (if it was fetched - from SCM). - - - - - SRCREV - - - Revision of source code used to build package (Subversion, - GIT, Bazaar only). - - - - - STAGING_KERNEL_DIR - - - Directory with kernel headers required to build out-of-tree - modules. - - - - - STAMPS - - - Directory (usually TMPDIR/stamps) with timestamps of - executed tasks. - - - - - SUMMARY - - Short (72 char suggested) Summary of binary package for packaging sytems such as ipkg, rpm or debian, inherits DESCRIPTION by default - - - - - - T - - TARGET_ARCH - - The architecture of the device we're building for. - A number of values are possible but Poky primarily supports - "arm" and "i586". - - - - TARGET_CFLAGS - - - Flags passed to C compiler for the target system. Evaluates to the same - as CFLAGS. - - - - - - TARGET_FPU - - Method of handling FPU code. For FPU-less targets - (most of ARM cpus) it has to be set to "soft" otherwise - kernel emulation will get used which will result in - performance penalty. - - - - TARGET_OS - - Type of target operating system. Can be "linux" - for glibc based system, "linux-uclibc" for uClibc. For - ARM/EABI targets there are also "linux-gnueabi" and - "linux-uclibc-gnueabi" values possible. - - - - TERMCMD - - - This command is used by bitbake to lauch a terminal window with a - shell. The shell is unspecified so the user's default shell is used. - By default it is set to gnome-terminal but it can - be any X11 terminal application or terminal multiplexers like screen. - - - - - TERMCMDRUN - - - This command is similar to TERMCMD however instead of the users shell it runs the command specified by the SHELLCMDS variable. - - - - - - - - - - - - - W - - WORKDIR - - Path to directory in tmp/work/ where package - will be built. - - - - - - - - - - - - - - - - - diff --git a/handbook/ref-varlocality.xml b/handbook/ref-varlocality.xml deleted file mode 100644 index 87ef0833d..000000000 --- a/handbook/ref-varlocality.xml +++ /dev/null @@ -1,211 +0,0 @@ - - - - Reference: Variable Locality (Distro, Machine, Recipe etc.) - - - Whilst most variables can be used in almost any context (.conf, .bbclass, - .inc or .bb file), variables are often associated with a particular - locality/context. This section describes some common associations. - - -
- Distro Configuration - - - - DISTRO - - - DISTRO_NAME - - - DISTRO_VERSION - - - MAINTAINER - - - PACKAGE_CLASSES - - - TARGET_OS - - - TARGET_FPU - - - POKYMODE - - - POKYLIBC - - -
- -
- Machine Configuration - - - - TARGET_ARCH - - - SERIAL_CONSOLE - - - PACKAGE_EXTRA_ARCHS - - - IMAGE_FSTYPES - - - ROOT_FLASH_SIZE - - - MACHINE_FEATURES - - - MACHINE_EXTRA_RDEPENDS - - - MACHINE_EXTRA_RRECOMMENDS - - - MACHINE_ESSENTIAL_RDEPENDS - - - MACHINE_ESSENTIAL_RRECOMMENDS - - -
- -
- Local Configuration (local.conf) - - - DISTRO - - - MACHINE - - - DL_DIR - - - BBFILES - - - IMAGE_FEATURES - - - PACKAGE_CLASSES - - - BB_NUMBER_THREADS - - - BBINCLUDELOGS - - - ENABLE_BINARY_LOCALE_GENERATION - - -
- -
- Recipe Variables - Required - - - - DESCRIPTION - - - LICENSE - - - LIC_FILES_CHKSUM - - - SECTION - - - HOMEPAGE - - - AUTHOR - - - SRC_URI - - -
- -
- Recipe Variables - Dependencies - - - - DEPENDS - - - RDEPENDS - - - RRECOMMENDS - - - RCONFLICTS - - - RREPLACES - - -
- -
- Recipe Variables - Paths - - - - WORKDIR - - - S - - - FILES - - -
- -
- Recipe Variables - Extra Build Information - - - - DISTRO_PN_ALIAS - - - EXTRA_OECMAKE - - - EXTRA_OECONF - - - EXTRA_OEMAKE - - - PACKAGES - - - DEFAULT_PREFERENCE - - -
- - diff --git a/handbook/resources.xml b/handbook/resources.xml deleted file mode 100644 index 7561669fb..000000000 --- a/handbook/resources.xml +++ /dev/null @@ -1,142 +0,0 @@ - - - -Contributing to Poky - -
- Introduction - - We're happy for people to experiment with Poky and there are a number of places to - find help if you run into difficulties or find bugs. To find out how to download - source code see the Obtaining Poky section of - the Introduction. - -
- -
- Bugtracker - - - Problems with Poky should be reported in the - bug tracker. - -
- -
- Mailing list - - - To subscribe to the mailing list send mail to: - - - -poky+subscribe <at> openedhand <dot> com - - - - Then follow the simple instructions in subsequent reply. Archives are - available here. - -
- -
- IRC - - - Join #poky on freenode. - -
- - - -
- Contributions - - - Contributions to Poky are very welcome. Patches should be sent to the Poky mailing list along with a Signed-off-by: line in the same style as the Linux kernel. Adding this line signifies the developer has agreed to the Developer's Certificate of Origin 1.1: - - - - Developer's Certificate of Origin 1.1 - - By making a contribution to this project, I certify that: - - (a) The contribution was created in whole or in part by me and I - have the right to submit it under the open source license - indicated in the file; or - - (b) The contribution is based upon previous work that, to the best - of my knowledge, is covered under an appropriate open source - license and I have the right under that license to submit that - work with modifications, whether created in whole or in part - by me, under the same open source license (unless I am - permitted to submit under a different license), as indicated - in the file; or - - (c) The contribution was provided directly to me by some other - person who certified (a), (b) or (c) and I have not modified - it. - - (d) I understand and agree that this project and the contribution - are public and that a record of the contribution (including all - personal information I submit with it, including my sign-off) is - maintained indefinitely and may be redistributed consistent with - this project or the open source license(s) involved. - - - - A Poky contributions tree (poky-contrib, git://git.pokylinux.org/poky-contrib.git) - exists for people to stage contributions in, for regular contributors. - If people desire such access, please ask on the mailing list. Usually - access will be given to anyone with a proven track record of good patches. - - -
- - - - diff --git a/handbook/screenshots/ss-anjuta-poky-1.png b/handbook/screenshots/ss-anjuta-poky-1.png deleted file mode 100644 index 4e92012af..000000000 Binary files a/handbook/screenshots/ss-anjuta-poky-1.png and /dev/null differ diff --git a/handbook/screenshots/ss-anjuta-poky-2.png b/handbook/screenshots/ss-anjuta-poky-2.png deleted file mode 100644 index 2c9bfb3bb..000000000 Binary files a/handbook/screenshots/ss-anjuta-poky-2.png and /dev/null differ diff --git a/handbook/screenshots/ss-oprofile-viewer.png b/handbook/screenshots/ss-oprofile-viewer.png deleted file mode 100644 index fa7d1dfa4..000000000 Binary files a/handbook/screenshots/ss-oprofile-viewer.png and /dev/null differ diff --git a/handbook/screenshots/ss-sato.png b/handbook/screenshots/ss-sato.png deleted file mode 100644 index 5a0570924..000000000 Binary files a/handbook/screenshots/ss-sato.png and /dev/null differ diff --git a/handbook/style.css b/handbook/style.css deleted file mode 100644 index c4d9df197..000000000 --- a/handbook/style.css +++ /dev/null @@ -1,953 +0,0 @@ -/* - Generic XHTML / DocBook XHTML CSS Stylesheet. - - Browser wrangling and typographic design by - Oyvind Kolas / pippin@gimp.org - - Customised for Poky by - Matthew Allum / mallum@o-hand.com - - Thanks to: - Liam R. E. Quin - William Skaggs - Jakub Steiner - - Structure - --------- - - The stylesheet is divided into the following sections: - - Positioning - Margins, paddings, width, font-size, clearing. - Decorations - Borders, style - Colors - Colors - Graphics - Graphical backgrounds - Nasty IE tweaks - Workarounds needed to make it work in internet explorer, - currently makes the stylesheet non validating, but up until - this point it is validating. - Mozilla extensions - Transparency for footer - Rounded corners on boxes - -*/ - - - /*************** / - / Positioning / -/ ***************/ - -body { - font-family: Verdana, Sans, sans-serif; - - min-width: 640px; - width: 80%; - margin: 0em auto; - padding: 2em 5em 5em 5em; - color: #333; -} - -h1,h2,h3,h4,h5,h6,h7 { - font-family: Arial, Sans; - color:#999999; - clear: both; -} - -h1 { - font-size: 2em; - text-align: left; - padding: 0em 0em 0em 0em; - margin: 2em 0em 0em 0em; -} - -h2.subtitle { - margin: 0.10em 0em 3.0em 0em; - padding: 0em 0em 0em 0em; - font-size: 1.8em; - padding-left: 20%; - font-weight: normal; - font-style: italic; -} - -h2 { - margin: 2em 0em 0.66em 0em; - padding: 0.5em 0em 0em 0em; - font-size: 1.5em; - font-weight: normal; -} - -h3.subtitle { - margin: 0em 0em 1em 0em; - padding: 0em 0em 0em 0em; - font-size: 142.14%; - text-align: right; -} - -h3 { - margin: 1em 0em 0.5em 0em; - padding: 1em 0em 0em 0em; - font-size: 140%; - font-weight: normal; -} - -h4 { - margin: 1em 0em 0.5em 0em; - padding: 1em 0em 0em 0em; - font-size: 120%; - font-weight: normal; -} - -h5 { - margin: 1em 0em 0.5em 0em; - padding: 1em 0em 0em 0em; - font-size: 110.000%; - border-bottom: 1px solid black; -} - -h6 { - margin: 1em 0em 0em 0em; - padding: 1em 0em 0em 0em; - font-size: 80%; - font-weight: normal; -} - -.authorgroup { - background-color: transparent; - background-repeat: no-repeat; - padding-top: 256px; - background-image: url("poky-beaver.png"); - background-position: right top; - float: right; - margin-top: -256px; - padding-right: 50px; - margin-left: 50px; - text-align: right; - width: 200px; -} - -h3.author { - margin: 0em 0me 0em 0em; - padding: 0em 0em 0em 0em; - font-weight: normal; - font-size: 100%; - clear: both; -} - -.author tt.email { - font-size: 66%; -} - -.titlepage hr { - width: 0em; - clear: both; -} - -.revhistory { - padding-top: 2em; - clear: both; -} - -.toc, -.list-of-tables, -.list-of-examples, -.list-of-figures { - padding: 1.33em 0em 2.5em 0em; -} - -.toc p, -.list-of-tables p, -.list-of-figures p, -.list-of-examples p { - padding: 0em 0em 0em 0em; - padding: 0em 0em 0.3em; - margin: 1.5em 0em 0em 0em; -} - -.toc p b, -.list-of-tables p b, -.list-of-figures p b, -.list-of-examples p b{ - font-size: 100.0%; - font-weight: bold; -} - -.toc dl, -.list-of-tables dl, -.list-of-figures dl, -.list-of-examples dl { - margin: 0em 0em 0.5em 0em; - padding: 0em 0em 0em 0em; -} - -.toc dt { - margin: 0em 0em 0em 0em; - padding: 0em 0em 0em 0em; -} - -.toc dd { - margin: 0em 0em 0em 2.6em; - padding: 0em 0em 0em 0em; -} - -div.glossary dl, -div.variablelist dl { -} - -.glossary dl dt, -.variablelist dl dt, -.variablelist dl dt span.term { - font-weight: normal; - width: 20em; - text-align: right; -} - -.variablelist dl dt { - margin-top: 0.5em; -} - -.glossary dl dd, -.variablelist dl dd { - margin-top: -1em; - margin-left: 25.5em; -} - -.glossary dd p, -.variablelist dd p { - margin-top: 0em; - margin-bottom: 1em; -} - - -div.calloutlist table td { - padding: 0em 0em 0em 0em; - margin: 0em 0em 0em 0em; -} - -div.calloutlist table td p { - margin-top: 0em; - margin-bottom: 1em; -} - -div p.copyright { - text-align: left; -} - -div.legalnotice p.legalnotice-title { - margin-bottom: 0em; -} - -p { - line-height: 1.5em; - margin-top: 0em; - -} - -dl { - padding-top: 0em; -} - -hr { - border: solid 1px; -} - - -.mediaobject, -.mediaobjectco { - text-align: center; -} - -img { - border: none; -} - -ul { - padding: 0em 0em 0em 1.5em; -} - -ul li { - padding: 0em 0em 0em 0em; -} - -ul li p { - text-align: left; -} - -table { - width :100%; -} - -th { - padding: 0.25em; - text-align: left; - font-weight: normal; - vertical-align: top; -} - -td { - padding: 0.25em; - vertical-align: top; -} - -p a[id] { - margin: 0px; - padding: 0px; - display: inline; - background-image: none; -} - -a { - text-decoration: underline; - color: #444; -} - -pre { - overflow: auto; -} - -a:hover { - text-decoration: underline; - /*font-weight: bold;*/ -} - - -div.informalfigure, -div.informalexample, -div.informaltable, -div.figure, -div.table, -div.example { - margin: 1em 0em; - padding: 1em; - page-break-inside: avoid; -} - - -div.informalfigure p.title b, -div.informalexample p.title b, -div.informaltable p.title b, -div.figure p.title b, -div.example p.title b, -div.table p.title b{ - padding-top: 0em; - margin-top: 0em; - font-size: 100%; - font-weight: normal; -} - -.mediaobject .caption, -.mediaobject .caption p { - text-align: center; - font-size: 80%; - padding-top: 0.5em; - padding-bottom: 0.5em; -} - -.epigraph { - padding-left: 55%; - margin-bottom: 1em; -} - -.epigraph p { - text-align: left; -} - -.epigraph .quote { - font-style: italic; -} -.epigraph .attribution { - font-style: normal; - text-align: right; -} - -span.application { - font-style: italic; -} - -.programlisting { - font-family: monospace; - font-size: 80%; - white-space: pre; - margin: 1.33em 0em; - padding: 1.33em; -} - -.tip, -.warning, -.caution, -.note { - margin-top: 1em; - margin-bottom: 1em; - -} - -/* force full width of table within div */ -.tip table, -.warning table, -.caution table, -.note table { - border: none; - width: 100%; -} - - -.tip table th, -.warning table th, -.caution table th, -.note table th { - padding: 0.8em 0.0em 0.0em 0.0em; - margin : 0em 0em 0em 0em; -} - -.tip p, -.warning p, -.caution p, -.note p { - margin-top: 0.5em; - margin-bottom: 0.5em; - padding-right: 1em; - text-align: left; -} - -.acronym { - text-transform: uppercase; -} - -b.keycap, -.keycap { - padding: 0.09em 0.3em; - margin: 0em; -} - -.itemizedlist li { - clear: none; -} - -.filename { - font-size: medium; - font-family: Courier, monospace; -} - - -div.navheader, div.heading{ - position: absolute; - left: 0em; - top: 0em; - width: 100%; - background-color: #cdf; - width: 100%; -} - -div.navfooter, div.footing{ - position: fixed; - left: 0em; - bottom: 0em; - background-color: #eee; - width: 100%; -} - - -div.navheader td, -div.navfooter td { - font-size: 66%; -} - -div.navheader table th { - /*font-family: Georgia, Times, serif;*/ - /*font-size: x-large;*/ - font-size: 80%; -} - -div.navheader table { - border-left: 0em; - border-right: 0em; - border-top: 0em; - width: 100%; -} - -div.navfooter table { - border-left: 0em; - border-right: 0em; - border-bottom: 0em; - width: 100%; -} - -div.navheader table td a, -div.navfooter table td a { - color: #777; - text-decoration: none; -} - -/* normal text in the footer */ -div.navfooter table td { - color: black; -} - -div.navheader table td a:visited, -div.navfooter table td a:visited { - color: #444; -} - - -/* links in header and footer */ -div.navheader table td a:hover, -div.navfooter table td a:hover { - text-decoration: underline; - background-color: transparent; - color: #33a; -} - -div.navheader hr, -div.navfooter hr { - display: none; -} - - -.qandaset tr.question td p { - margin: 0em 0em 1em 0em; - padding: 0em 0em 0em 0em; -} - -.qandaset tr.answer td p { - margin: 0em 0em 1em 0em; - padding: 0em 0em 0em 0em; -} -.answer td { - padding-bottom: 1.5em; -} - -.emphasis { - font-weight: bold; -} - - - /************* / - / decorations / -/ *************/ - -.titlepage { -} - -.part .title { -} - -.subtitle { - border: none; -} - -/* -h1 { - border: none; -} - -h2 { - border-top: solid 0.2em; - border-bottom: solid 0.06em; -} - -h3 { - border-top: 0em; - border-bottom: solid 0.06em; -} - -h4 { - border: 0em; - border-bottom: solid 0.06em; -} - -h5 { - border: 0em; -} -*/ - -.programlisting { - border: solid 1px; -} - -div.figure, -div.table, -div.informalfigure, -div.informaltable, -div.informalexample, -div.example { - border: 1px solid; -} - - - -.tip, -.warning, -.caution, -.note { - border: 1px solid; -} - -.tip table th, -.warning table th, -.caution table th, -.note table th { - border-bottom: 1px solid; -} - -.question td { - border-top: 1px solid black; -} - -.answer { -} - - -b.keycap, -.keycap { - border: 1px solid; -} - - -div.navheader, div.heading{ - border-bottom: 1px solid; -} - - -div.navfooter, div.footing{ - border-top: 1px solid; -} - - /********* / - / colors / -/ *********/ - -body { - color: #333; - background: white; -} - -a { - background: transparent; -} - -a:hover { - background-color: #dedede; -} - - -h1, -h2, -h3, -h4, -h5, -h6, -h7, -h8 { - background-color: transparent; -} - -hr { - border-color: #aaa; -} - - -.tip, .warning, .caution, .note { - border-color: #aaa; -} - - -.tip table th, -.warning table th, -.caution table th, -.note table th { - border-bottom-color: #aaa; -} - - -.warning { - background-color: #fea; -} - -.caution { - background-color: #fea; -} - -.tip { - background-color: #eff; -} - -.note { - background-color: #dfc; -} - -.glossary dl dt, -.variablelist dl dt, -.variablelist dl dt span.term { - color: #044; -} - -div.figure, -div.table, -div.example, -div.informalfigure, -div.informaltable, -div.informalexample { - border-color: #aaa; -} - -pre.programlisting { - color: black; - background-color: #fff; - border-color: #aaa; - border-width: 2px; -} - -.guimenu, -.guilabel, -.guimenuitem { - background-color: #eee; -} - - -b.keycap, -.keycap { - background-color: #eee; - border-color: #999; -} - - -div.navheader { - border-color: black; -} - - -div.navfooter { - border-color: black; -} - - - /*********** / - / graphics / -/ ***********/ - -/* -body { - background-image: url("images/body_bg.jpg"); - background-attachment: fixed; -} - -.navheader, -.note, -.tip { - background-image: url("images/note_bg.jpg"); - background-attachment: fixed; -} - -.warning, -.caution { - background-image: url("images/warning_bg.jpg"); - background-attachment: fixed; -} - -.figure, -.informalfigure, -.example, -.informalexample, -.table, -.informaltable { - background-image: url("images/figure_bg.jpg"); - background-attachment: fixed; -} - -*/ -h1, -h2, -h3, -h4, -h5, -h6, -h7{ -} - -div.preface .titlepage .title, -div.colophon .title, -div.chapter .titlepage .title { - background-image: url("images/title-bg.png"); - background-position: bottom; - background-repeat: repeat-x; -} - -div.section div.section .titlepage .title, -div.sect2 .titlepage .title { - background: none; -} - - -h1.title { - background-color: transparent; - background-image: url("poky-handbook.png"); - background-repeat: no-repeat; - height: 256px; - text-indent: -9000px; - overflow:hidden; -} - -h2.subtitle { - background-color: transparent; - text-indent: -9000px; - overflow:hidden; - width: 0px; - display: none; -} - - /*************************************** / - / pippin.gimp.org specific alterations / -/ ***************************************/ - -/* -div.heading, div.navheader { - color: #777; - font-size: 80%; - padding: 0; - margin: 0; - text-align: left; - position: absolute; - top: 0px; - left: 0px; - width: 100%; - height: 50px; - background: url('/gfx/heading_bg.png') transparent; - background-repeat: repeat-x; - background-attachment: fixed; - border: none; -} - -div.heading a { - color: #444; -} - -div.footing, div.navfooter { - border: none; - color: #ddd; - font-size: 80%; - text-align:right; - - width: 100%; - padding-top: 10px; - position: absolute; - bottom: 0px; - left: 0px; - - background: url('/gfx/footing_bg.png') transparent; -} -*/ - - - - /****************** / - / nasty ie tweaks / -/ ******************/ - -/* -div.heading, div.navheader { - width:expression(document.body.clientWidth + "px"); -} - -div.footing, div.navfooter { - width:expression(document.body.clientWidth + "px"); - margin-left:expression("-5em"); -} -body { - padding:expression("4em 5em 0em 5em"); -} -*/ - - /**************************************** / - / mozilla vendor specific css extensions / -/ ****************************************/ -/* -div.navfooter, div.footing{ - -moz-opacity: 0.8em; -} - -div.figure, -div.table, -div.informalfigure, -div.informaltable, -div.informalexample, -div.example, -.tip, -.warning, -.caution, -.note { - -moz-border-radius: 0.5em; -} - -b.keycap, -.keycap { - -moz-border-radius: 0.3em; -} -*/ - -table tr td table tr td { - display: none; -} - - -hr { - display: none; -} - -table { - border: 0em; -} - - .photo { - float: right; - margin-left: 1.5em; - margin-bottom: 1.5em; - margin-top: 0em; - max-width: 17em; - border: 1px solid gray; - padding: 3px; - background: white; -} - .seperator { - padding-top: 2em; - clear: both; - } - - #validators { - margin-top: 5em; - text-align: right; - color: #777; - } - @media print { - body { - font-size: 8pt; - } - .noprint { - display: none; - } - } - - -.tip, -.note { - background: #91ae35; - color: #fff; - padding: 20px; - margin: 20px; -} - -.tip h3, -.note h3 { - padding: 0em; - margin: 0em; - font-size: 2em; - font-weight: bold; - color: #fff; -} - -.tip a, -.note a { - color: #fff; - text-decoration: underline; -} diff --git a/handbook/template/Vera.ttf b/handbook/template/Vera.ttf deleted file mode 100644 index 58cd6b5e6..000000000 Binary files a/handbook/template/Vera.ttf and /dev/null differ diff --git a/handbook/template/Vera.xml b/handbook/template/Vera.xml deleted file mode 100644 index 3c82043e3..000000000 --- a/handbook/template/Vera.xml +++ /dev/null @@ -1 +0,0 @@ -BitstreamVeraSans729546928-235-183-23512879283200TYPE0CIDFontType20 \ No newline at end of file diff --git a/handbook/template/VeraMoBd.ttf b/handbook/template/VeraMoBd.ttf deleted file mode 100644 index 9be6547ed..000000000 Binary files a/handbook/template/VeraMoBd.ttf and /dev/null differ diff --git a/handbook/template/VeraMoBd.xml b/handbook/template/VeraMoBd.xml deleted file mode 100644 index 9b33107a4..000000000 --- a/handbook/template/VeraMoBd.xml +++ /dev/null @@ -1 +0,0 @@ -BitstreamVeraSansMono-BoldBitstream Vera Sans Mono BoldBitstream Vera Sans Mono729546759-240-19-2356059283400TYPE0CIDFontType20 \ No newline at end of file diff --git a/handbook/template/VeraMono.ttf b/handbook/template/VeraMono.ttf deleted file mode 100644 index 139f0b431..000000000 Binary files a/handbook/template/VeraMono.ttf and /dev/null differ diff --git a/handbook/template/VeraMono.xml b/handbook/template/VeraMono.xml deleted file mode 100644 index 3a0a86659..000000000 --- a/handbook/template/VeraMono.xml +++ /dev/null @@ -1 +0,0 @@ -BitstreamVeraSansMono-RomanBitstream Vera Sans MonoBitstream Vera Sans Mono729546759-240-4-2356059283400TYPE0CIDFontType20 \ No newline at end of file diff --git a/handbook/template/draft.png b/handbook/template/draft.png deleted file mode 100644 index 53051a9dd..000000000 Binary files a/handbook/template/draft.png and /dev/null differ diff --git a/handbook/template/fop-config.xml b/handbook/template/fop-config.xml deleted file mode 100644 index 7d56223d1..000000000 --- a/handbook/template/fop-config.xml +++ /dev/null @@ -1,58 +0,0 @@ - - - - true - - - true - - - template - template - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/handbook/template/ohand-color.svg b/handbook/template/ohand-color.svg deleted file mode 100644 index e42ff9c6f..000000000 --- a/handbook/template/ohand-color.svg +++ /dev/null @@ -1,150 +0,0 @@ - - - - - - - - - image/svg+xml - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/handbook/template/poky-db-pdf.xsl b/handbook/template/poky-db-pdf.xsl deleted file mode 100644 index 3dd065a57..000000000 --- a/handbook/template/poky-db-pdf.xsl +++ /dev/null @@ -1,64 +0,0 @@ - - - - - - - - - - - - - - - - - - - 1 10 1 - - - - - - 0.5pt - solid - #cccccc - - - - - - 0.5pt - solid - #cccccc - - - - - #cccccc - - - - #cccccc - - - - - - - - - - - - - diff --git a/handbook/template/poky-handbook.png b/handbook/template/poky-handbook.png deleted file mode 100644 index 2085edb46..000000000 Binary files a/handbook/template/poky-handbook.png and /dev/null differ diff --git a/handbook/template/poky.svg b/handbook/template/poky.svg deleted file mode 100644 index a4ea5e2f4..000000000 --- a/handbook/template/poky.svg +++ /dev/null @@ -1,163 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - \ No newline at end of file diff --git a/handbook/template/titlepage.templates.xml b/handbook/template/titlepage.templates.xml deleted file mode 100644 index ff640fa5f..000000000 --- a/handbook/template/titlepage.templates.xml +++ /dev/null @@ -1,1240 +0,0 @@ - - - - - - - - - - - - -]> - - - - - - - - - - - - - - - <subtitle param:node="ancestor-or-self::article[1]" - keep-with-next="always" - font-size="&hsize3;" - font-weight="bold" - space-after="0.8em"/> - - <corpauthor space-before="0.5em" - font-size="&hsize3;"/> - <authorgroup space-before="0.5em" - font-size="&hsize2;"/> - <author space-before="0.5em" - font-size="&hsize2;" - space-after="0.8em"/> - - <email font-size="&hsize2;"/> - - <othercredit space-before="0.5em"/> - <releaseinfo space-before="0.5em"/> - <copyright space-before="0.5em"/> - <legalnotice text-align="start" - margin-left="0.5in" - margin-right="0.5in" - font-family="{$body.fontset}"/> - <pubdate space-before="0.5em"/> - <para></para> - <revision space-before="0.5em"/> - <revhistory space-before="0.5em"/> - <abstract space-before="0.5em" - text-align="start" - margin-left="0.5in" - margin-right="0.5in" - font-family="{$body.fontset}"/> - - <para></para> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<!-- ==================================================================== --> - -<t:titlepage t:element="set" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - t:named-template="division.title" - param:node="ancestor-or-self::set[1]" - text-align="center" - font-size="&hsize5;" - space-before="&hsize5space;" - font-weight="bold" - font-family="{$title.fontset}"/> - <subtitle - font-family="{$title.fontset}" - text-align="center"/> - <corpauthor/> - <authorgroup/> - <author/> - <othercredit/> - <releaseinfo/> - <copyright/> - <legalnotice/> - <pubdate/> - <revision/> - <revhistory/> - <abstract/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<!-- ==================================================================== --> - - <t:titlepage t:element="book" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - - <mediaobject/> - - <title - t:named-template="division.title" - param:node="ancestor-or-self::book[1]" - text-align="center" - font-size="&hsize5;" - space-before="&hsize5space;" - font-weight="bold" - font-family="{$title.fontset}"/> - <subtitle - text-align="center" - font-size="&hsize4;" - space-before="&hsize4space;" - font-family="{$title.fontset}"/> - <corpauthor font-size="&hsize3;" - keep-with-next="always" - space-before="2in"/> - <authorgroup space-before="2in"/> - <author font-size="&hsize3;" - space-before="&hsize2space;" - keep-with-next="always"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - <title - t:named-template="book.verso.title" - font-size="&hsize2;" - font-weight="bold" - font-family="{$title.fontset}"/> - <corpauthor/> - <authorgroup t:named-template="verso.authorgroup"/> - <author/> - <othercredit/> - <pubdate space-before="1em"/> - <copyright/> - <abstract/> - <legalnotice font-size="8pt"/> - </t:titlepage-content> - - <t:titlepage-separator> - <fo:block break-after="page"/> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - <fo:block break-after="page"/> - </t:titlepage-before> -</t:titlepage> - -<!-- ==================================================================== --> - -<t:titlepage t:element="part" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - t:named-template="division.title" - param:node="ancestor-or-self::part[1]" - text-align="center" - font-size="&hsize5;" - space-before="&hsize5space;" - font-weight="bold" - font-family="{$title.fontset}"/> - <subtitle - text-align="center" - font-size="&hsize4;" - space-before="&hsize4space;" - font-weight='bold' - font-style='italic' - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<t:titlepage t:element="partintro" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - text-align="center" - font-size="&hsize5;" - font-weight="bold" - space-before="1em" - font-family="{$title.fontset}"/> - <subtitle - text-align="center" - font-size="&hsize2;" - font-weight="bold" - font-style="italic" - font-family="{$title.fontset}"/> - <corpauthor/> - <authorgroup/> - <author/> - <othercredit/> - <releaseinfo/> - <copyright/> - <legalnotice/> - <pubdate/> - <revision/> - <revhistory/> - <abstract/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<!-- ==================================================================== --> - -<t:titlepage t:element="reference" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - t:named-template="division.title" - param:node="ancestor-or-self::reference[1]" - text-align="center" - font-size="&hsize5;" - space-before="&hsize5space;" - font-weight="bold" - font-family="{$title.fontset}"/> - <subtitle - font-family="{$title.fontset}" - text-align="center"/> - <corpauthor/> - <authorgroup/> - <author/> - <othercredit/> - <releaseinfo/> - <copyright/> - <legalnotice/> - <pubdate/> - <revision/> - <revhistory/> - <abstract/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<!-- ==================================================================== --> - -<t:titlepage t:element="refsynopsisdiv" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<!-- ==================================================================== --> - -<t:titlepage t:element="refsection" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<!-- ==================================================================== --> - -<t:titlepage t:element="refsect1" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<!-- ==================================================================== --> - -<t:titlepage t:element="refsect2" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<!-- ==================================================================== --> - -<t:titlepage t:element="refsect3" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<!-- ==================================================================== --> - - <t:titlepage t:element="dedication" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - t:force="1" - t:named-template="component.title" - param:node="ancestor-or-self::dedication[1]" - margin-left="{$title.margin.left}" - font-size="&hsize5;" - font-family="{$title.fontset}" - font-weight="bold"/> - <subtitle - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<!-- ==================================================================== --> - - <t:titlepage t:element="preface" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - t:force="1" - t:named-template="component.title" - param:node="ancestor-or-self::preface[1]" - margin-left="{$title.margin.left}" - font-size="&hsize5;" - font-family="{$title.fontset}" - font-weight="bold"/> - <subtitle - font-family="{$title.fontset}"/> - <corpauthor/> - <authorgroup/> - <author/> - <othercredit/> - <releaseinfo/> - <copyright/> - <legalnotice/> - <pubdate/> - <revision/> - <revhistory/> - <abstract/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<!-- ==================================================================== --> - - <t:titlepage t:element="chapter" t:wrapper="fo:block" - font-family="{$title.fontset}"> - <t:titlepage-content t:side="recto" margin-left="{$title.margin.left}"> - <title t:named-template="component.title" - param:node="ancestor-or-self::chapter[1]" - font-size="&hsize5;" - font-weight="bold"/> - - <subtitle space-before="0.5em" - font-style="italic" - font-size="&hsize2;" - font-weight="bold"/> - - <corpauthor space-before="0.5em" - space-after="0.5em" - font-size="&hsize2;"/> - - <authorgroup space-before="0.5em" - space-after="0.5em" - font-size="&hsize2;"/> - - <author space-before="0.5em" - space-after="0.5em" - font-size="&hsize2;"/> - - <othercredit/> - <releaseinfo/> - <copyright/> - <legalnotice/> - <pubdate/> - <revision/> - <revhistory/> - <abstract/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<!-- ==================================================================== --> - - <t:titlepage t:element="appendix" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - t:named-template="component.title" - param:node="ancestor-or-self::appendix[1]" - margin-left="{$title.margin.left}" - font-size="&hsize5;" - font-weight="bold" - font-family="{$title.fontset}"/> - <subtitle - font-family="{$title.fontset}"/> - <corpauthor/> - <authorgroup/> - <author/> - <othercredit/> - <releaseinfo/> - <copyright/> - <legalnotice/> - <pubdate/> - <revision/> - <revhistory/> - <abstract/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<!-- ==================================================================== --> - -<t:titlepage t:element="section" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - margin-left="{$title.margin.left}" - font-family="{$title.fontset}"/> - <subtitle - font-family="{$title.fontset}"/> - <corpauthor/> - <authorgroup/> - <author/> - <othercredit/> - <releaseinfo/> - <copyright/> - <legalnotice/> - <pubdate/> - <revision/> - <revhistory/> - <abstract/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<t:titlepage t:element="sect1" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - margin-left="{$title.margin.left}" - font-family="{$title.fontset}"/> - <subtitle - font-family="{$title.fontset}"/> - <corpauthor/> - <authorgroup/> - <author/> - <othercredit/> - <releaseinfo/> - <copyright/> - <legalnotice/> - <pubdate/> - <revision/> - <revhistory/> - <abstract/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<t:titlepage t:element="sect2" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - margin-left="{$title.margin.left}" - font-family="{$title.fontset}"/> - <subtitle - font-family="{$title.fontset}"/> - <corpauthor/> - <authorgroup/> - <author/> - <othercredit/> - <releaseinfo/> - <copyright/> - <legalnotice/> - <pubdate/> - <revision/> - <revhistory/> - <abstract/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<t:titlepage t:element="sect3" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - margin-left="{$title.margin.left}" - font-family="{$title.fontset}"/> - <subtitle - font-family="{$title.fontset}"/> - <corpauthor/> - <authorgroup/> - <author/> - <othercredit/> - <releaseinfo/> - <copyright/> - <legalnotice/> - <pubdate/> - <revision/> - <revhistory/> - <abstract/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<t:titlepage t:element="sect4" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - margin-left="{$title.margin.left}" - font-family="{$title.fontset}"/> - <subtitle - font-family="{$title.fontset}"/> - <corpauthor/> - <authorgroup/> - <author/> - <othercredit/> - <releaseinfo/> - <copyright/> - <legalnotice/> - <pubdate/> - <revision/> - <revhistory/> - <abstract/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<t:titlepage t:element="sect5" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - margin-left="{$title.margin.left}" - font-family="{$title.fontset}"/> - <subtitle - font-family="{$title.fontset}"/> - <corpauthor/> - <authorgroup/> - <author/> - <othercredit/> - <releaseinfo/> - <copyright/> - <legalnotice/> - <pubdate/> - <revision/> - <revhistory/> - <abstract/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<t:titlepage t:element="simplesect" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - margin-left="{$title.margin.left}" - font-family="{$title.fontset}"/> - <subtitle - font-family="{$title.fontset}"/> - <corpauthor/> - <authorgroup/> - <author/> - <othercredit/> - <releaseinfo/> - <copyright/> - <legalnotice/> - <pubdate/> - <revision/> - <revhistory/> - <abstract/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<!-- ==================================================================== --> - - <t:titlepage t:element="bibliography" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - t:force="1" - t:named-template="component.title" - param:node="ancestor-or-self::bibliography[1]" - margin-left="{$title.margin.left}" - font-size="&hsize5;" - font-family="{$title.fontset}" - font-weight="bold"/> - <subtitle - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> - </t:titlepage> - -<!-- ==================================================================== --> - - <t:titlepage t:element="bibliodiv" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title t:named-template="component.title" - param:node="ancestor-or-self::bibliodiv[1]" - margin-left="{$title.margin.left}" - font-size="&hsize4;" - font-family="{$title.fontset}" - font-weight="bold"/> - <subtitle - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> - </t:titlepage> - -<!-- ==================================================================== --> - - <t:titlepage t:element="glossary" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - t:force="1" - t:named-template="component.title" - param:node="ancestor-or-self::glossary[1]" - margin-left="{$title.margin.left}" - font-size="&hsize5;" - font-family="{$title.fontset}" - font-weight="bold"/> - <subtitle - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> - </t:titlepage> - -<!-- ==================================================================== --> - - <t:titlepage t:element="glossdiv" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title t:named-template="component.title" - param:node="ancestor-or-self::glossdiv[1]" - margin-left="{$title.margin.left}" - font-size="&hsize4;" - font-family="{$title.fontset}" - font-weight="bold"/> - <subtitle - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> - </t:titlepage> - -<!-- ==================================================================== --> - - <t:titlepage t:element="index" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - t:force="1" - t:named-template="component.title" - param:node="ancestor-or-self::index[1]" - param:pagewide="1" - margin-left="0pt" - font-size="&hsize5;" - font-family="{$title.fontset}" - font-weight="bold"/> - <subtitle - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> - </t:titlepage> - -<!-- ==================================================================== --> - - <!-- The indexdiv.title template is used so that manual and --> - <!-- automatically generated indexdiv titles get the same --> - <!-- formatting. --> - - <t:titlepage t:element="indexdiv" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title t:force="1" - t:named-template="indexdiv.title" - param:title="title"/> - <subtitle - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> - </t:titlepage> - -<!-- ==================================================================== --> - - <t:titlepage t:element="setindex" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - t:force="1" - t:named-template="component.title" - param:node="ancestor-or-self::setindex[1]" - param:pagewide="1" - margin-left="0pt" - font-size="&hsize5;" - font-family="{$title.fontset}" - font-weight="bold"/> - <subtitle - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> - </t:titlepage> - -<!-- ==================================================================== --> - - <t:titlepage t:element="colophon" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - t:force="1" - t:named-template="component.title" - param:node="ancestor-or-self::colophon[1]" - margin-left="{$title.margin.left}" - font-size="&hsize5;" - font-family="{$title.fontset}" - font-weight="bold"/> - <subtitle - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<!-- ==================================================================== --> - - <t:titlepage t:element="table.of.contents" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - t:force="1" - t:named-template="gentext" - param:key="'TableofContents'" - space-before.minimum="1em" - space-before.optimum="1.5em" - space-before.maximum="2em" - space-after="0.5em" - margin-left="{$title.margin.left}" - font-size="&hsize3;" - font-weight="bold" - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> - </t:titlepage> - - <t:titlepage t:element="list.of.tables" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - t:force="1" - t:named-template="gentext" - param:key="'ListofTables'" - space-before.minimum="1em" - space-before.optimum="1.5em" - space-before.maximum="2em" - space-after="0.5em" - margin-left="{$title.margin.left}" - font-size="&hsize3;" - font-weight="bold" - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> - </t:titlepage> - - <t:titlepage t:element="list.of.figures" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - t:force="1" - t:named-template="gentext" - param:key="'ListofFigures'" - space-before.minimum="1em" - space-before.optimum="1.5em" - space-before.maximum="2em" - space-after="0.5em" - margin-left="{$title.margin.left}" - font-size="&hsize3;" - font-weight="bold" - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> - </t:titlepage> - - <t:titlepage t:element="list.of.examples" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - t:force="1" - t:named-template="gentext" - param:key="'ListofExamples'" - space-before.minimum="1em" - space-before.optimum="1.5em" - space-before.maximum="2em" - space-after="0.5em" - margin-left="{$title.margin.left}" - font-size="&hsize3;" - font-weight="bold" - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> - </t:titlepage> - - <t:titlepage t:element="list.of.equations" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - t:force="1" - t:named-template="gentext" - param:key="'ListofEquations'" - space-before.minimum="1em" - space-before.optimum="1.5em" - space-before.maximum="2em" - space-after="0.5em" - margin-left="{$title.margin.left}" - font-size="&hsize3;" - font-weight="bold" - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> - </t:titlepage> - - <t:titlepage t:element="list.of.procedures" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - t:force="1" - t:named-template="gentext" - param:key="'ListofProcedures'" - space-before.minimum="1em" - space-before.optimum="1.5em" - space-before.maximum="2em" - space-after="0.5em" - margin-left="{$title.margin.left}" - font-size="&hsize3;" - font-weight="bold" - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> - </t:titlepage> - - <t:titlepage t:element="list.of.unknowns" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - t:force="1" - t:named-template="gentext" - param:key="'ListofUnknown'" - space-before.minimum="1em" - space-before.optimum="1.5em" - space-before.maximum="2em" - space-after="0.5em" - margin-left="{$title.margin.left}" - font-size="&hsize3;" - font-weight="bold" - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> - </t:titlepage> - -<!-- ==================================================================== --> - -</t:templates> diff --git a/handbook/tools/poky-docbook-to-pdf b/handbook/tools/poky-docbook-to-pdf deleted file mode 100755 index 8e3d7542f..000000000 --- a/handbook/tools/poky-docbook-to-pdf +++ /dev/null @@ -1,45 +0,0 @@ -#!/bin/sh - -if [ -z "$1" -o -z "$2" ]; then - echo "usage: [-v] $0 <docbook file> <templatedir>" - echo - echo "*NOTE* you need xsltproc, fop and nwalsh docbook stylesheets" - echo " installed for this to work!" - echo - exit 0 -fi - -BASENAME=`basename $1 .xml` || exit 1 -FO="$BASENAME.fo" -PDF="$BASENAME.pdf" -TEMPLATEDIR=$2 - -## -# These URI should be rewritten by your distribution's xml catalog to -# match your localy installed XSL stylesheets. -XSL_BASE_URI="http://docbook.sourceforge.net/release/xsl/current" - -xsltproc -o /tmp/titlepage.xsl \ - --xinclude \ - $XSL_BASE_URI/template/titlepage.xsl \ - $TEMPLATEDIR/titlepage.templates.xml || exit 1 - -xsltproc --xinclude \ - --stringparam hyphenate false \ - --stringparam formal.title.placement "figure after" \ - --stringparam ulink.show 1 \ - --stringparam body.font.master 9 \ - --stringparam title.font.master 11 \ - --stringparam draft.watermark.image "$TEMPLATEDIR/draft.png" \ - --output $FO \ - $TEMPLATEDIR/poky-db-pdf.xsl \ - $1 || exit 1 - -fop -c $TEMPLATEDIR/fop-config.xml -fo $FO -pdf $PDF || exit 1 - -rm -f $FO -rm -f /tmp/titlepage.xsl - -echo -echo " #### Success! $PDF ready. ####" -echo diff --git a/handbook/usingpoky.xml b/handbook/usingpoky.xml deleted file mode 100644 index ad6bda254..000000000 --- a/handbook/usingpoky.xml +++ /dev/null @@ -1,316 +0,0 @@ -<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> -<chapter id='usingpoky'> -<title>Using Poky - - - This section gives an overview of the components that make up Poky - following by information about running poky builds and dealing with any - problems that may arise. - - -
- Poky Overview - - - At the core of Poky is the bitbake task executor together with various types of - configuration files. This section gives an overview of bitbake and the - configuration files, in particular what they are used for, and how they - interact. - - - - Bitbake handles the parsing and execution of the data - files. The data itself is of various types; recipes which give - details about particular pieces of software, class data which is an - abstraction of common build information (e.g. how to build a Linux kernel) - and configuration data for machines, policy decisions, etc., which acts as - a glue and binds everything together. Bitbake knows how to combine multiple - data sources together, each data source being referred to as a 'layer'. - - - - The directory structure walkthrough - section gives details on the meaning of specific directories but some - brief details on the core components follows: - - -
- Bitbake - - - Bitbake is the tool at the heart of Poky and is responsible - for parsing the metadata, generating a list of tasks from it - and then executing them. To see a list of the options it - supports look at bitbake --help. - - - - The most common usage is bitbake packagename where - packagename is the name of the package you wish to build - (from now on called the target). This often equates to the first part of a .bb - filename, so to run the matchbox-desktop_1.2.3.bb file, you - might type bitbake matchbox-desktop. - Several different versions of matchbox-desktop might exist and - bitbake will choose the one selected by the distribution configuration - (more details about how bitbake chooses between different versions - and providers is available in the - 'Preferences and Providers' section). Bitbake will also try to execute any - dependent tasks first so before building matchbox-desktop it - would build a cross compiler and glibc if not already built. - - -
- -
- Metadata (Recipes) - - - The .bb files are usually referred to as 'recipes'. In general, a - recipe contains information about a single piece of software such - as where to download the source, any patches that are needed, - any special configuration options, how to compile the source files - and how to package the compiled output. - - - - 'package' can also be used to describe recipes but since the same - word is used for the packaged output from Poky (i.e. .ipk or .deb - files), this document will avoid it. - - -
- -
- Classes - - - Class (.bbclass) files contain information which is useful to share - between metadata files. An example is the autotools class which contains - the common settings that any application using autotools would use. The - classes reference section gives details - on common classes and how to use them. - -
- -
- Configuration - - - The configuration (.conf) files define various configuration variables - which govern what Poky does. These are split into several areas, such - as machine configuration options, distribution configuration options, - compiler tuning options, general common configuration and user - configuration (local.conf). - -
- -
- - - -
- Running a Build - - - First the Poky build environment needs to be set up using the following command: - - - -$ source poky-init-build-env [build_dir] - - - - The build_dir is the dir containing all the building object files. The default - build dir is poky-dir/build. Multiple build_dir can be used for different targets. - For example, ~/build/x86 for qemux86 target, and ~/build/arm for qemuarm target. - Please refer to poky-init-build-env - for detail info - - - Once the Poky build environment is set up, a target can now be built using: - - - -$ bitbake <target> -$ bitbake qemu-native - - - - The target is the name of the recipe you want to build. Common targets are the - images (in meta/packages/images/) - or the name of a recipe for a specific piece of software like - busybox. More details about the standard images - are available in the image reference section. - The qemu-native target will build the poky customized qemu, and will be used - by runqemu script later. - -
- -
- Installing and Using the Result - - - Once an image has been built it often needs to be installed. The images/kernels built - by Poky are placed in the tmp/deploy/images - directory. Running qemux86 and qemuarm images is covered in the Running an Image section. See your - board/machine documentation for information about how to install these images. - - -
- -
- Debugging Build Failures - - - The exact method for debugging Poky depends on the nature of the - bug(s) and which part of the system they might be from. Standard - debugging practises such as comparing to the last - known working version and examining the changes, reapplying the - changes in steps to identify the one causing the problem etc. are - valid for Poky just like any other system. It's impossible to detail - every possible potential failure here but there are some general - tips to aid debugging: - - -
- Task Failures - - The log file for shell tasks is available in ${WORKDIR}/temp/log.do_taskname.pid. - For the compile task of busybox 1.01 on the ARM spitz machine, this - might be tmp/work/armv5te-poky-linux-gnueabi/busybox-1.01/temp/log.do_compile.1234 - for example. To see what bitbake ran to generate that log, look at the run.do_taskname.pid - file in the same directory. - - - The output from python tasks is sent directly to the console at present. -
- -
- Running specific tasks - - Any given package consists of a set of tasks, in most - cases the series is fetch, unpack, patch, configure, - compile, install, package, package_write and build. The - default task is "build" and any tasks this depends on are - built first hence the standard bitbake behaviour. There are - some tasks such as devshell which are not part of the - default build chain. If you wish to run such a task you can - use the "-c" option to bitbake e.g. bitbake - matchbox-desktop -c devshell. - - - - If you wish to rerun a task you can use the force option - "-f". A typical usage session might look like: - - - -% bitbake matchbox-desktop -[change some source in the WORKDIR for example] -% bitbake matchbox-desktop -c compile -f -% bitbake matchbox-desktop - - - - which would build matchbox-desktop, then recompile it. The - final command reruns all tasks after the compile (basically - the packaging tasks) since bitbake will notice that the - compile has been rerun and hence the other tasks also need - to run again. - - - - You can view a list of tasks in a given package by running - the listtasks task e.g. bitbake matchbox-desktop -c - listtasks, and the result is in file ${WORKDIR}/temp/log.do_listtasks.pid. - -
- -
- Dependency Graphs - - - Sometimes it can be hard to see why bitbake wants to build - some other packages before a given package you've specified. - bitbake -g targetname will create - depends.dot and - task-depends.dot files in the current - directory. They show - which packages and tasks depend on which other packages and - tasks and are useful for debugging purposes. - "bitbake -g -u depexp targetname" will show result - in more human-readable GUI style. - -
- -
- General Bitbake Problems - - - Debug output from bitbake can be seen with the "-D" option. - The debug output gives more information about what bitbake - is doing and/or why. Each -D option increases the logging - level, the most common usage being "-DDD". - - - - The output from bitbake -DDD -v targetname can reveal why - a certain version of a package might be chosen, why bitbake - picked a certain provider or help in other situations where - bitbake does something you're not expecting. - -
- -
- Building with no dependencies - - - If you really want to build a specific .bb file, you can use - the form bitbake -b somepath/somefile.bb. Note that this - will not check the dependencies so this option should only - be used when you know its dependencies already exist. You - can specify fragments of the filename and bitbake will see - if it can find a unique match. - - -
- -
- Variables - - - The "-e" option will dump the resulting environment for - either the configuration (no package specified) or for a - specific package when specified with the "-b" option. - -
- -
- Other Tips - - - When adding new packages it is worth keeping an eye open for bad - things creeping into compiler commandlines such as references to local - system files (/usr/lib/ or /usr/include/ etc.). - - - - - - If you want to remove the psplash boot splashscreen, add "psplash=false" - to the kernel commandline and psplash won't load allowing you to see - the console. It's also possible to switch out of the splashscreen by - switching virtual console (Fn+Left or Fn+Right on a Zaurus). - - - -
-
- - - -- cgit v1.2.3 2' href='#n12172'>12172 12173 12174 12175 12176 12177 12178 12179 12180 12181 12182 12183 12184 12185 12186 12187 12188 12189 12190 12191 12192 12193 12194 12195 12196 12197 12198 12199 12200 12201 12202 12203 12204 12205 12206 12207 12208 12209 12210 12211 12212 12213 12214 12215 12216 12217 12218 12219 12220 12221 12222 12223 12224 12225 12226 12227 12228 12229 12230 12231 12232 12233 12234 12235 12236 12237 12238 12239 12240 12241 12242 12243 12244 12245 12246 12247 12248 12249 12250 12251 12252 12253 12254 12255 12256 12257 12258 12259 12260 12261 12262 12263 12264 12265 12266 12267 12268 12269 12270 12271 12272 12273 12274 12275 12276 12277 12278 12279 12280 12281 12282 12283 12284 12285 12286 12287 12288 12289 12290 12291 12292 12293 12294 12295 12296 12297 12298 12299 12300 12301 12302 12303 12304 12305 12306 12307 12308 12309 12310 12311 12312 12313 12314 12315 12316 12317 12318 12319 12320 12321 12322 12323 12324 12325 12326 12327 12328 12329 12330 12331 12332 12333 12334 12335 12336 12337 12338 12339 12340 12341 12342 12343 12344 12345 12346 12347 12348 12349 12350 12351 12352 12353 12354 12355 12356 12357 12358 12359 12360 12361 12362 12363 12364 12365 12366 12367 12368 12369 12370 12371 12372 12373 12374 12375 12376 12377 12378 12379 12380 12381 12382 12383 12384 12385 12386 12387 12388 12389 12390 12391 12392 12393 12394 12395 12396 12397 12398 12399 12400 12401 12402 12403 12404 12405 12406 12407 12408 12409 12410 12411 12412 12413 12414 12415 12416 12417 12418 12419 12420 12421 12422 12423 12424 12425 12426 12427 12428 12429 12430 12431 12432 12433 12434 12435 12436 12437 12438 12439 12440 12441 12442 12443 12444 12445 12446 12447 12448 12449 12450 12451 12452 12453 12454 12455 12456 12457 12458 12459 12460 12461 12462 12463 12464 12465 12466 12467 12468 12469 12470 12471 12472 12473 12474 12475 12476 12477 12478 12479 12480 12481 12482 12483 12484 12485 12486 12487 12488 12489 12490 12491 12492 12493 12494 12495 12496 12497 12498 12499 12500 12501 12502 12503 12504 12505 12506 12507 12508 12509 12510 12511 12512 12513 12514 12515 12516 12517 12518 12519 12520 12521 12522 12523 12524 12525 12526 12527 12528 12529 12530 12531 12532 12533 12534 12535 12536 12537 12538 12539 12540 12541 12542 12543 12544 12545 12546 12547 12548 12549 12550 12551 12552 12553 12554 12555 12556 12557 12558 12559 12560 12561 12562 12563 12564 12565 12566 12567 12568 12569 12570 12571 12572 12573 12574 12575 12576 12577 12578 12579 12580 12581 12582 12583 12584 12585 12586 12587 12588 12589 12590 12591 12592 12593 12594 12595 12596 12597 12598 12599 12600 12601 12602 12603 12604 12605 12606 12607 12608 12609 12610 12611 12612 12613 12614 12615 12616 12617 12618 12619 12620 12621 12622 12623 12624 12625 12626 12627 12628 12629 12630 12631 12632 12633 12634 12635 12636 12637 12638 12639 12640 12641 12642 12643 12644 12645 12646 12647 12648 12649 12650 12651 12652 12653 12654 12655 12656 12657 12658 12659 12660 12661 12662 12663 12664 12665 12666 12667 12668 12669 12670 12671 12672 12673 12674 12675 12676 12677 12678 12679 12680 12681 12682 12683 12684 12685 12686 12687 12688 12689 12690 12691 12692 12693 12694 12695 12696 12697 12698 12699 12700 12701 12702 12703 12704 12705 12706 12707 12708 12709 12710 12711 12712 12713 12714 12715 12716 12717 12718 12719 12720 12721 12722 12723 12724 12725 12726 12727 12728 12729 12730 12731 12732 12733 12734 12735 12736 12737 12738 12739 12740 12741 12742 12743 12744 12745 12746 12747 12748 12749 12750 12751 12752 12753 12754 12755 12756 12757 12758 12759 12760 12761 12762 12763 12764 12765 12766 12767 12768 12769 12770 12771 12772 12773 12774 12775 12776 12777 12778 12779 12780 12781 12782 12783 12784 12785 12786 12787 12788 12789 12790 12791 12792 12793 12794 12795 12796 12797 12798 12799 12800 12801 12802 12803 12804 12805 12806 12807 12808 12809 12810 12811 12812 12813 12814 12815 12816 12817 12818 12819 12820 12821 12822 12823 12824 12825 12826 12827 12828 12829 12830 12831 12832 12833 12834 12835 12836 12837 12838 12839 12840 12841 12842 12843 12844 12845 12846 12847 12848 12849 12850 12851 12852 12853 12854 12855 12856 12857 12858 12859 12860 12861 12862 12863 12864 12865 12866 12867 12868 12869 12870 12871 12872 12873 12874 12875 12876 12877 12878 12879 12880 12881 12882 12883 12884 12885 12886 12887 12888 12889 12890 12891 12892 12893 12894 12895 12896 12897 12898 12899 12900 12901 12902 12903 12904 12905 12906 12907 12908 12909 12910 12911 12912 12913 12914 12915 12916 12917 12918 12919 12920 12921 12922 12923 12924 12925 12926 12927 12928 12929 12930 12931 12932 12933 12934 12935 12936 12937 12938 12939 12940 12941 12942 12943 12944 12945 12946 12947 12948 12949 12950 12951 12952 12953 12954 12955 12956 12957 12958 12959 12960 12961 12962 12963 12964 12965 12966 12967 12968 12969 12970 12971 12972 12973 12974 12975 12976 12977 12978 12979 12980 12981 12982 12983 12984 12985 12986 12987 12988 12989 12990 12991 12992 12993 12994 12995 12996 12997 12998 12999 13000 13001 13002 13003 13004 13005 13006 13007 13008 13009 13010 13011 13012 13013 13014 13015 13016 13017 13018 13019 13020 13021 13022 13023 13024 13025 13026 13027 13028 13029 13030 13031 13032 13033 13034 13035 13036 13037 13038 13039 13040 13041 13042 13043 13044 13045 13046 13047 13048 13049 13050 13051 13052 13053 13054 13055 13056 13057 13058 13059 13060 13061 13062 13063 13064 13065 13066 13067 13068 13069 13070 13071 13072 13073 13074 13075 13076 13077 13078 13079 13080 13081 13082 13083 13084 13085 13086 13087 13088 13089 13090 13091 13092 13093 13094 13095 13096 13097 13098 13099 13100 13101 13102 13103 13104 13105 13106 13107 13108 13109 13110 13111 13112 13113 13114 13115 13116 13117 13118 13119 13120 13121 13122 13123 13124 13125 13126 13127 13128 13129 13130 13131 13132 13133 13134 13135 13136 13137 13138 13139 13140 13141 13142 13143 13144 13145 13146 13147 13148 13149 13150 13151 13152 13153 13154 13155 13156 13157 13158 13159 13160 13161 13162 13163 13164 13165 13166 13167 13168 13169 13170 13171 13172 13173 13174 13175 13176 13177 13178 13179 13180 13181 13182 13183 13184 13185 13186 13187 13188 13189 13190 13191 13192 13193 13194 13195 13196 13197 13198 13199 13200 13201 13202 13203 13204 13205 13206 13207 13208 13209 13210 13211 13212 13213 13214 13215 13216 13217 13218 13219 13220 13221 13222 13223 13224 13225 13226 13227 13228 13229 13230 13231 13232 13233 13234 13235 13236 13237 13238 13239 13240 13241 13242 13243 13244 13245 13246 13247 13248 13249 13250 13251 13252 13253 13254 13255 13256 13257 13258 13259 13260 13261 13262 13263 13264 13265 13266 13267 13268 13269 13270 13271 13272 13273 13274 13275 13276 13277 13278 13279 13280 13281 13282 13283 13284 13285 13286 13287 13288 13289 13290 13291 13292 13293 13294 13295 13296 13297 13298 13299 13300 13301 13302 13303 13304 13305 13306 13307 13308 13309 13310 13311 13312 13313 13314 13315 13316 13317 13318 13319 13320 13321 13322 13323 13324 13325 13326 13327 13328 13329 13330 13331 13332 13333 13334 13335 13336 13337 13338 13339 13340 13341 13342 13343 13344 13345 13346 13347 13348 13349 13350 13351 13352 13353 13354 13355 13356 13357 13358 13359 13360 13361 13362 13363 13364 13365 13366 13367 13368 13369 13370 13371 13372 13373 13374 13375 13376 13377 13378 13379 13380 13381 13382 13383 13384 13385 13386 13387 13388 13389 13390 13391 13392 13393 13394 13395 13396 13397 13398 13399 13400 13401 13402 13403 13404 13405 13406 13407 13408 13409 13410 13411 13412 13413 13414 13415 13416 13417 13418 13419 13420 13421 13422 13423 13424 13425 13426 13427 13428 13429 13430 13431 13432 13433 13434 13435 13436 13437 13438 13439 13440 13441 13442 13443 13444 13445 13446 13447 13448 13449 13450 13451 13452 13453 13454 13455 13456 13457 13458 13459 13460 13461 13462 13463 13464 13465 13466 13467 13468 13469 13470 13471 13472 13473 13474 13475 13476 13477 13478 13479 13480 13481 13482 13483 13484 13485 13486 13487 13488 13489 13490 13491 13492 13493 13494 13495 13496 13497 13498 13499 13500 13501 13502 13503 13504 13505 13506 13507 13508 13509 13510 13511 13512 13513 13514 13515 13516 13517 13518 13519 13520 13521 13522 13523 13524 13525 13526 13527 13528 13529 13530 13531 13532 13533 13534 13535 13536 13537 13538 13539 13540 13541 13542 13543 13544 13545 13546 13547 13548 13549 13550 13551 13552 13553 13554 13555 13556 13557 13558 13559 13560 13561 13562 13563 13564 13565 13566 13567 13568 13569 13570 13571 13572 13573 13574 13575 13576 13577 13578 13579 13580 13581 13582 13583 13584 13585 13586 13587 13588 13589 13590 13591 13592 13593 13594 13595 13596 13597 13598 13599 13600 13601 13602 13603 13604 13605 13606 13607 13608 13609 13610 13611 13612 13613 13614 13615 13616 13617 13618 13619 13620 13621 13622 13623 13624 13625 13626 13627 13628 13629 13630 13631 13632 13633 13634 13635 13636 13637 13638 13639 13640 13641 13642 13643 13644 13645 13646 13647 13648 13649 13650 13651 13652 13653 13654 13655 13656 13657 13658 13659 13660 13661 13662 13663 13664 13665 13666 13667 13668 13669 13670 13671 13672 13673 13674 13675 13676 13677 13678 13679 13680 13681 13682 13683 13684 13685 13686 13687 13688 13689 13690 13691 13692 13693 13694 13695 13696 13697 13698 13699 13700 13701 13702 13703 13704 13705 13706 13707 13708 13709 13710 13711 13712 13713 13714 13715 13716 13717 13718 13719 13720 13721 13722 13723 13724 13725 13726 13727 13728 13729 13730 13731 13732 13733 13734 13735 13736 13737 13738 13739 13740 13741 13742 13743 13744 13745 13746 13747 13748 13749 13750 13751 13752 13753 13754 13755 13756 13757 13758 13759 13760 13761 13762 13763 13764 13765 13766 13767 13768 13769 13770 13771 13772 13773 13774 13775 13776 13777 13778 13779 13780 13781 13782 13783 13784 13785 13786 13787 13788 13789 13790 13791 13792 13793 13794 13795 13796 13797 13798 13799 13800 13801 13802 13803 13804 13805 13806 13807 13808 13809 13810 13811 13812 13813 13814 13815 13816 13817 13818 13819 13820 13821 13822 13823 13824 13825 13826 13827 13828 13829 13830 13831 13832 13833 13834 13835 13836 13837 13838 13839 13840 13841 13842 13843 13844 13845 13846 13847 13848 13849 13850 13851 13852 13853 13854 13855 13856 13857 13858 13859 13860 13861 13862 13863 13864 13865 13866 13867 13868 13869 13870 13871 13872 13873 13874 13875 13876 13877 13878 13879 13880 13881 13882 13883 13884 13885 13886 13887 13888 13889 13890 13891 13892 13893 13894 13895 13896 13897 13898 13899 13900 13901 13902 13903 13904 13905 13906 13907 13908 13909 13910 13911 13912 13913 13914 13915 13916 13917 13918 13919 13920 13921 13922 13923 13924 13925 13926 13927 13928 13929 13930 13931 13932 13933 13934 13935 13936 13937 13938 13939 13940 13941 13942 13943 13944 13945 13946 13947 13948 13949 13950 13951 13952 13953 13954 13955 13956 13957 13958 13959 13960 13961 13962 13963 13964 13965 13966 13967 13968 13969 13970 13971 13972 13973 13974 13975 13976 13977 13978 13979 13980 13981 13982 13983 13984 13985 13986 13987 13988 13989 13990 13991 13992 13993 13994 13995 13996 13997 13998 13999 14000 14001 14002 14003 14004 14005 14006 14007 14008 14009 14010 14011 14012 14013 14014 14015 14016 14017 14018 14019 14020 14021 14022 14023 14024 14025 14026 14027 14028 14029 14030 14031 14032 14033 14034 14035 14036 14037 14038 14039 14040 14041 14042 14043 14044 14045 14046 14047 14048 14049 14050 14051 14052 14053 14054 14055 14056 14057 14058 14059 14060 14061 14062 14063 14064 14065 14066 14067 14068 14069 14070 14071 14072 14073 14074 14075 14076 14077 14078 14079 14080 14081 14082 14083 14084 14085 14086 14087 14088 14089 14090 14091 14092 14093 14094 14095 14096 14097 14098 14099 14100 14101 14102 14103 14104 14105 14106 14107 14108 14109 14110 14111 14112 14113 14114 14115 14116 14117 14118 14119 14120 14121 14122 14123 14124 14125 14126 14127 14128 14129 14130 14131 14132 14133 14134 14135 14136 14137 14138 14139 14140 14141 14142 14143 14144 14145 14146 14147 14148 14149 14150 14151 14152 14153 14154 14155 14156 14157 14158 14159 14160 14161 14162 14163 14164 14165 14166 14167 14168 14169 14170 14171 14172 14173 14174 14175 14176 14177 14178 14179 14180 14181 14182 14183 14184 14185 14186 14187 14188 14189 14190 14191 14192 14193 14194 14195 14196 14197 14198 14199 14200 14201 14202 14203 14204 14205 14206 14207 14208 14209 14210 14211 14212 14213 14214 14215 14216 14217 14218 14219 14220 14221 14222 14223 14224 14225 14226 14227 14228 14229 14230 14231 14232 14233 14234 14235 14236 14237 14238 14239 14240 14241 14242 14243 14244 14245 14246 14247 14248 14249 14250 14251 14252 14253 14254 14255 14256 14257 14258 14259 14260 14261 14262 14263 14264 14265 14266 14267 14268 14269 14270 14271 14272 14273 14274 14275 14276 14277 14278 14279 14280 14281 14282 14283 14284 14285 14286 14287 14288 14289 14290 14291 14292 14293 14294 14295 14296 14297 14298 14299 14300 14301 14302 14303 14304 14305 14306 14307 14308 14309 14310 14311 14312 14313 14314 14315 14316 14317 14318 14319 14320 14321 14322 14323 14324 14325 14326 14327 14328 14329 14330 14331 14332 14333 14334 14335 14336 14337 14338 14339 14340 14341 14342 14343 14344 14345 14346 14347 14348 14349 14350 14351 14352 14353 14354 14355 14356 14357 14358 14359 14360 14361 14362 14363 14364 14365 14366 14367 14368 14369 14370 14371 14372 14373 14374 14375 14376 14377 14378 14379 14380 14381 14382 14383 14384 14385 14386 14387 14388 14389 14390 14391 14392 14393 14394 14395 14396 14397 14398 14399 14400 14401 14402 14403 14404 14405 14406 14407 14408 14409 14410 14411 14412 14413 14414 14415 14416 14417 14418 14419 14420 14421 14422 14423 14424 14425 14426 14427 14428 14429 14430 14431 14432 14433 14434 14435 14436 14437 14438 14439 14440 14441 14442 14443 14444 14445 14446 14447 14448 14449 14450 14451 14452 14453 14454 14455 14456 14457 14458 14459 14460 14461 14462 14463 14464 14465 14466 14467 14468 14469 14470 14471 14472 14473 14474 14475 14476 14477 14478 14479 14480 14481 14482 14483 14484 14485 14486 14487 14488 14489 14490 14491 14492 14493 14494 14495 14496 14497 14498 14499 14500 14501 14502 14503 14504 14505 14506 14507 14508 14509 14510 14511 14512 14513 14514 14515 14516 14517 14518 14519 14520 14521 14522 14523 14524 14525 14526 14527 14528 14529 14530 14531 14532 14533 14534 14535 14536 14537 14538 14539 14540 14541 14542 14543 14544 14545 14546 14547 14548 14549 14550 14551 14552 14553 14554 14555 14556 14557 14558 14559 14560 14561 14562 14563 14564 14565 14566 14567 14568 14569 14570 14571 14572 14573 14574 14575 14576 14577 14578 14579 14580 14581 14582 14583 14584 14585 14586 14587 14588 14589 14590 14591 14592 14593 14594 14595 14596 14597 14598 14599 14600 14601 14602 14603 14604 14605 14606 14607 14608 14609 14610 14611 14612 14613 14614 14615 14616 14617 14618 14619 14620 14621 14622 14623 14624 14625 14626 14627 14628 14629 14630 14631 14632 14633 14634 14635 14636 14637 14638 14639 14640 14641 14642 14643 14644 14645 14646 14647 14648 14649 14650 14651 14652 14653 14654 14655 14656 14657 14658 14659 14660 14661 14662 14663 14664 14665 14666 14667 14668 14669 14670 14671 14672 14673 14674 14675 14676 14677 14678 14679 14680 14681 14682 14683 14684 14685 14686 14687 14688 14689 14690 14691 14692 14693 14694 14695 14696 14697 14698 14699 14700 14701 14702 14703 14704 14705 14706 14707 14708 14709 14710 14711 14712 14713 14714 14715 14716 14717 14718 14719 14720 14721 14722 14723 14724 14725 14726 14727 14728 14729 14730 14731 14732 14733 14734 14735 14736 14737 14738 14739 14740 14741 14742 14743 14744 14745 14746 14747 14748 14749 14750 14751 14752 14753 14754 14755 14756 14757 14758 14759 14760 14761 14762 14763 14764 14765 14766 14767 14768 14769 14770 14771 14772 14773 14774 14775 14776 14777 14778 14779 14780 14781 14782 14783 14784 14785 14786 14787 14788 14789 14790 14791 14792 14793 14794 14795 14796 14797 14798 14799 14800 14801 14802 14803 14804 14805 14806 14807 14808 14809 14810 14811 14812 14813 14814 14815 14816 14817 14818 14819 14820 14821 14822 14823 14824 14825 14826 14827 14828 14829 14830 14831 14832 14833 14834 14835 14836 14837 14838 14839 14840 14841 14842 14843 14844 14845 14846 14847 14848 14849 14850 14851 14852 14853 14854 14855 14856 14857 14858 14859 14860 14861 14862 14863 14864 14865 14866 14867 14868 14869 14870 14871 14872 14873 14874 14875 14876 14877 14878 14879 14880 14881 14882 14883 14884 14885 14886 14887 14888 14889 14890 14891 14892 14893 14894 14895 14896 14897 14898 14899 14900 14901 14902 14903 14904 14905 14906 14907 14908 14909 14910 14911 14912 14913 14914 14915 14916 14917 14918 14919 14920 14921 14922 14923 14924 14925 14926 14927 14928 14929 14930 14931 14932 14933 14934 14935 14936 14937 14938 14939 14940 14941 14942 14943 14944 14945 14946 14947 14948 14949 14950 14951 14952 14953 14954 14955 14956 14957 14958 14959 14960 14961 14962 14963 14964 14965 14966 14967 14968