OpenEmbedded HowTo <subtitle>OpenEmbedded usage hints</subtitle> Werner Schulte w1@schulte-ac.de Version 0.3.5, Sat Apr 22 15:45:49 CEST 2006 This howto intended to be a help for openembedded users (developers) or them who want to be. The document is not yet ready, but possibly helpfull. Introduction

This howto intends to be a help for openembedded users (developers) or them who want to be. Because there is rapid change of openembedded technology and documentation always lacks large amounts, this howto tries to fill up the gaps, though it will never be actual. Nevertheles, it describes my personell sight of view and the problems I ran in. As this might be common problems, they may help others as well. Downloads

openembedded.sgml . html tar ball . uv's addon scrips tar ball . See . Contact

openembedded mailing list . irc channel irc.freenode.org, channel #oe. Helpfull informations

This section gives an overview over the sources, where I got my information from. OpenEmbedded Wiki . Old OpenEmbedded Wiki This wiki will be outdated soon, but still is a good info source. It deals with the "OLD" style OE using oemake and not bitbake. . Bitbake User Manual The bitbake user manual is a very short compendium, but good for a start. The side content is added now and then. So before asking the irc channel below, check the manual first. . OpenEmbedded Irc This is the official OE irc channel. Many people are there to help in case of questions. Before asking a question, ready the available docs. The server is named irc.freenode.org, the channel is #oe. Know Bugs and Open Items

Bugs Possibly lots of unidentified. OpenItems All chapters need additional info. Lots of open items. Not clearly identified though. Documents Roadmap

0.2.0 : Provide a basic installation and usage doc. 0.4.0 : Extended FAQ. 0.6.0 : Do it yourself chapter. Howto write your own progs using OE. 0.8.0 : Opie style guide for OE. 1.0.0 : first final release. History

0.3.5 bitbake 1.4.1 hints added. FAQ added. 0.3.4 ASSUME_PROVIDED hitn added to FAQ for bitbake 1.3.3.3. 0.3.3 hints to add a new sources package with "OLD" Makefile behaviour 0.3.2 FAQ : bootstrap-image hint FAQ : add to image hint New chapter "Customize to your needs" 0.3.1 FAQ : glibc build problems added 0.3.0 jan2006prebreakage added build target env script added 0.2.9 Minor changes 0.2.8 New monotone hints added 0.2.7 FAQ added (first pull takes days) Debugging description startet 0.2.6 Working behind a proxy 0.2.5 bitbake version 1.3.2 : new features added. 0.2.4 Bitkeeper removed, Monotone corrected. 0.2.3 Monotone with final urls. 0.2.2 Monotone instead of bitkeeper. 0.2.1 Added pb parent hints Added FAQ entry (corgi_power hint) 0.2.0 Added BBMASK hints Added hints for kernel flashing of clamshell 0.1.9 Chapter Howto add a new HW Target. Howto compile with 2.95.3 compiler (sharprom-compatible) HowConfigWorks 0.1.8 Added minor stuff (-D -D -D). Rebuild kernel hints, FAQ added, BBPATH comments added. 0.1.7 Debian Psyco installation added. 0.1.6 Added FAQs. 0.1.5 Added a FAQ. 0.1.4 Zauri list inserted. Scripts mkPackage.rc and do_clean.rc explained / inserted for download. 0.1.3 Minor corrections. 0.1.2 Hints from irc corrected, download section added. 0.1.1 first rework, comment infos in full sentences ;-). 0.1.0 initial Program versions

bitbake : 1.4.1 call bitbake --version to get version info. bitbake : 1.3.3 call bitbake --version to get version info. bitbake : 1.3.2 call bitbake --version to get version info. monotone : 0.20 call monotone --version to get version info. Installation

This chapter describes the installs that need to be done, if openembedded should be used for development. Required Software

The following list is a possibly not full list of required software for OE development. Even the list may change in the future. Hint : The versions provided in the list below are version as installed on my host at time of OE installation. Older version may work as well. Python >= 2.4.0 (2.3.x may work as well) python -V prints the version info Additional install python-dev. You'll need that for bitbake setup. Hint : Install psyco as well, as this will speed up your python interpreter tremendously. Perl >= 5.8.x perl -v prints the version info GNU patch >= 2.5.9 patch -v prints the version info quilt An multi patch help tool (used for qte from 2.3.10 on). Possibly not needed any more, as build by bitbake (if required). GNU m4 m4 --version prints the version info GNU make >= 3.80 make -v prints the version info GNU sed >= 4.x sed --version prints the version info Bison bison -V prints the version info GCC >= 3.3.2 (and >= 2.95.3 (arm) for Zaurus Embedix Kernels) gcc --version prints the version info Ccache Psycho Jit Compiler This will speedup the build process. Nevertheless I do it still without (will care for that later). Several doc packages OpenJade Docbook Utils linuxdoc tools Docbook Utils Several download packages (and version management) wget and/or curl cvs BitKeeper NOT anymore used (from 1.7.05) You have to go a "semi commercial way", provide infos and send a request to . Monotone You need additional packages to use monotone. libboost* may be several packages to install. subversion Tools to unpack (and pack) tar gzip bzip2 unzip / zip ar glibc-headers (glibc-dev, ..) PyQt, if you want to use oecommander On Debian systems you can easily install the packages. apt-get install python for Python apt-get install python-dev for Python Development tools apt-get install python-psyco for Psyco apt-get install ccache for ccache apt-get install patch for patch apt-get install quilt for multiple patches apt-get install m4 for m4 apt-get install sed for GNU sed apt-get install docbook for docbook-utils and sgmltools apt-get install bison for Bison apt-get install make for Make apt-get install subversion for Subversion Note, that you possibly have to do that twice (broken dependency in sarge (16012005). apt-get install libc6-dev for glibc headers apt-get install libboost* (all packages starting with libboost). Manually download the deb package from . Select the debian package. Install it with dpkg -i monotone*.deb. For latest information and other OS . Preparations

The OE system is designed to run on different platforms, so some assumptions have to me made to guarantee that. To be able to find the compiler tools, you have to set links to your gcc and other components (/usr/bin on a debian system). ln -s ar i686-linux-ar ln -s as i686-linux-as ln -s cpp-3.4 i686-linux-cpp ln -s g++-3.4 i686-linux-g++ ln -s gcc-3.4 i686-linux-gcc ln -s ld i686-linux-ld ln -s nm i686-linux-nm ln -s ranlib i686-linux-ranlib Install bitbake

This section explains, how to install bitbake, the central development tool of OE on your machine. Follow the steps described below. Create a dir, to checkout bitbake to (somewhere in your home dir) and cd into that dir. Run svn co svn://svn.berlios.de/bitbake/trunk/bitbake Cd into bitbake and call ./setup.py install --prefix=/usr/local as superuser /or using sudo). This will copy the bitbake binary to /usr/local/bin (choose different, if you want). Bitbake classes file and configuration will be found in /usr/local/bitbake. add /usr/local/bin to your PATH variable. See , if bitbake does not setup. See , if bitbake does not work after a python package update. Update bitbake (from 1.3.2.x to 1.3.3.x)

This section explains, how to update bitbake, the central development tool of OE on your machine. Note that you should not have an older bitbake version installed from a different target or installed into a different target. This may cause problems in loading the correct python modules. Follow the steps described below. Create a new dir, to checkout bitbake to (somewhere in your home dir) and cd into that dir. Keep the old bitbake dir to be able to go back (just in case). Run svn co svn://svn.berlios.de/bitbake/trunk/bitbake Cd into bitbake and call ./setup.py install --prefix=/usr/local as superuser or using sudo). This will copy the bitbake binary to /usr/local/bin (choose different, if you want). Bitbake classes file and configuration will be found in /usr/local/bitbake. If you want ot build a new OE package, you have to update to the newest OE repository. The best is to create a new as well as a new and build dir to really start from scratch and to avoid destroying your probably working setup. Up to now I had no problems to use the new bitbake version with the old repository. So it seems to be possible to have a stable tree and a develop version (with new Repository). See , if bitbake does not setup. See , if bitbake does not work after a python package update. Update bitbake (from 1.3.3.x to 1.4.1)

This section explains, how to update bitbake, the central development tool of OE on your machine. Note that you should not have an older bitbake version installed from a different target or installed into a different target. This may cause problems in loading the correct python modules. Follow the steps described below. Create a new dir, to checkout bitbake to (somewhere in your home dir) and cd into that dir. Keep the old bitbake dir to be able to go back (just in case). Run "svn co svn://svn.berlios.de/bitbake/branches/bitbake-1.4 bitbake" Cd into bitbake and call ./setup.py install --prefix=/usr/local as superuser or using sudo). This will copy the bitbake binary to /usr/local/bin (choose different, if you want). Bitbake classes file and configuration will be found in /usr/local/bitbake. NOTE, that if you use bitbake 1.5.x, you did not catch the stable version. 1.5.0 e.g. has problems finding patches (for the openzaurus kernel e.g.) Download OE packages with monotone

To get an initial packages repository, follow the steps below. To have things not spread arround, you may want to create a directory (e.g. "oe"). CD into that dir and run the following commands. First time monotone usage requires two steps to get ready. Note that you can skip item 1, if already done. Init monotones database. monotone --db=OE.db db init Pull initial database example (from vanille.de) Note that you can skip item 2, if already done. monotone --db=OE.db pull monotone.vanille.de org.openembedded NOTE, that this may take more than a day (for some reasons) To checkout your repository do a monotone --db=OE.db co --branch=org.openembedded.dev To update your existing repository change to your monotones db dir and do a monotone --db=OE.db pull;cd org.openembedded.dev;monotone --db=../OE.db update NOTE, that the pull may take more than a day (for some reasons). More information can be found at and . You may want to try the following servers instead of monotone.vanille.de monotone.nslu2-linux.org (Primary Backup 1) ewi546.ewi.utwente.nl (Primary Backup 2) dominion.kabel.utwente.nl (Secondary Backup - only use, if really necessary) Note that an initial pull can take very long (hours, if not days) - we strongly recommend basing your database off our daily snapshots Download a snapshot and unpack that in your OE develop dir followed by a checkout and a final pull. That bring the newest stuff in. Note that since jan2006 heavy changes are going to be made to the toolchain thus you may want to update the "stable" tree only. You can do that by adding -rjan2006prebreakage to you checkout or update command. Create a matching environment script

You may want to create one or more different environment scripts to be able to build e.g. for different platforms. The following paragraph shows an example for my CL860 build target. # sample oe-env script - 'source oe-env' to use this environment. # # NOTE: # In this example, I have a dir in my home directory called 'src/', where I # do all my development work. In this dir I # have downloaded the 'oe/' and 'packages/' tree from the BitKeeper # repository, and I have manually "mkdir'ed" the oe_downloads/ dir. # # The setup looks like this: # /home/user/src/oe/ <- main OE dev # /home/user/src/oe/ <- oe/ system bk tree # /home/user/src/oe/packages/ <- packages/ bk tree # /home/user/src/build/ <- where *ALL* builds occur # /home/user/src/oe_downloads/ <- oe dl's stuff here # # CHANGE 'user' to whatever your username is! Also, be sure to carefully # check the DL_DIR value in your $OEBUILD/conf/local.conf file ... # # - where is the OE system dir? OESYS=/home/sc/scdev/oe OESYS2=/data/scdev2 # - where does openembedded live? i.e. where did you 'bk pull oe' and 'bk pull packages'? OEROOT=$OESYS/org.openembedded.dev # - where do all the packages live? PKGDIR=$OEROOT/packages # - where will *ALL* builds be occurring? OEBUILD=$OESYS2/build-boxer-mono # - the path OE will search in order to find "$OEPATH/conf/*.conf" files. Yes, thats what this path is for. OEPATH=$OEBUILD:$PKGDIR:$OESYS # [NOTE: OE's *.conf files are -all- supposed to be in a dir named 'conf/' within these dirs ... # OE prepends 'conf' itself when looking for these files, so we don't do it ... strange but true ...] # - add the oe/bin dir to this shells' path - without this, you get no 'oemake' or 'oebuild' or 'oecommander'... # PATH=/usr/local/arm/2.95.3/bin:$OESYS/bin/:$PATH # PATH=$OESYS/bin/:$PATH PATH=$OESYS/scscripts:$PATH # NOTE: this assumes you have the arm 2.95.3 tools installed as per the instructions on # http://www.openembedded.org/oe_wiki/index.php/ZaurusKernels # change to the build dir cd $OEBUILD # Blank this so we don't link non-arm libraries LD_LIBRARY_PATH= CC= CXX= BBPATH=$OEBUILD:$OEROOT # Don't export TARGET_ARCH - it *will* cause build failures export PATH LD_LIBRARY_PATH OEPATH CC CXX BBPATH # Stop multi byte characters breaking the patcher stuff - This is for Redhat / Fedora people really export LANG=C echo Environment set up for OpenEmbedded development. PS1="[OE-BOXER-mono]$PS1" The script can be called with a simple . env-boxer-mono,sets some environment variables and changes into the defined build dir. Prepare OE system

Create a build dir for your target machine named e.g. build-boxer. Enter that directory and create a dir called conf. Copy ../openembedded/conf/local.conf.sample to conf/local.conf and edit that file. Note, that you have explicitely to provide a different BBFILES entry, as the sample entry creates an "fatal" error message. As well you have to delete the last line. # REMOVE_THIS_LINE:="${@oe.fatal('Read the comments in your conf/local.conf')}" The following list tries to explain the meaning of the different entries of that file. Every item discussed is an example of my local.conf used for boxer (CL860) development (should also work for SL5500). KERNEL_CONSOLE="tty1" Switches bootmessages ON. This entry is not in the original local.conf. You have to add it. KERNEL_VERSIONS="2.6" Use the Kernel 2.6 version. DL_DIR = "${HOME}/scdev/oe/sources" The directory, where the sources are placed after downloading. A good idea is always to use a directory outside a build-dir. The sources may be used for several targets. BBFILES = "${HOME}/scdev/oe/openembedded/packages/*/*.bb \ ${HOME}/scdev/oe/sc_packages/*/*.bb" BBFILES defines, where bitbake searches package files. You can enter a blank separated list of package repositories here. BBMASK = "" Can be used to define a mask, which packages files are ignored. A BBMASK = "/gpe" will ignore all packages starting with gpe. A BBMASK = "/(gpe|x|matchbox)" will ignore all packages starting with gpe or x or matchbox. Note, that the regex looks for the complete path entry. Thus a "(^gpe|^x|^matchbox) would not work. The leading "/" in the examples above guarantees, that the package name starts with e.g. gpe. Important Note ! Masked packages are not parsed any more. This may lead to problems, if one of the masked packages is needed for build process. ASSUME_PROVIDED = "virtual/arm-linux-gcc-2.95" Needed, if you want to build Zauri kernel. I do nothing know about the syntax, but is works this way. PREFERRED_PROVIDERS = "virtual/qte:qte-for-opie virtual/libqpe:libqpe-opie" PREFERRED_PROVIDERS += " virtual/libsdl:libsdl-qpe" This entry is filled up default. I do not know, what to do with this. MACHINE = "collie" This is an important entry for collie development. It defines all collie specific build options. TARGET_OS = "linux" To define, whether you want to create a libc (or a ulibc) based system. This may be defined in a .conf file deeper in the config tree. DISTRO = "openzaurus-3.5.3" This entry defines the dirstribution (here openzaurus-3.5.3) to build for. Note, that MACHINE and DISTRO define everything you need. Do not enable TARGET (e.g.). The rest of the file can be left as is (except the last line, which has to be commented out). From now on, we can start to build. Install crosscompiler

A bitbake gcc-cross will do that for you. The cross-compiler will be installed in tmp/staging in your build environment. Note, that this will be done automatically during an image-build. Install openzaurus kernel crosscompiler

To be able to compile kernels for the Zaurus modells, the system has to use the sharp 2.95.3 cross toolkit. This section describes the installation of that toolkit and the necessary modifications for OE. Follow the hints below. Be sure the loadkeys binary is installed on your system. (Debian users can find it in the console-tools or kbd packages). A loadkeys -V prints out a version message (if loadkeys is installed on your system). Note, that onj Debian systems you may have to chmod your /dev/console file to 664 to allow a kernel build loadkeys call for a non superuser. Download GCC 2.95.3 toolchain - it is available (possibly). Unpack it into /usr/local/arm/ - Do not try to install it elsewhere or hardcoded absolute references to bits and pieces will fail, like cpp0 and cc1 being reported missing about 1-2 hours after starting a build... cd /usr/local/arm/2.95.3/bin mv arm-linux-gcc arm-linux-gcc-2.95 mv arm-linux-ld arm-linux-ld-2.11.2 add ASSUME_PROVIDED = "virtual/arm-linux-gcc-2.95" into oe/build/conf/local.conf add /usr/local/arm/2.95.3/bin into your PATH variable. Note :, that you really have to move the binaries. A link will not work for some strange reason. 2006 : Note! I heared, that the above mentioned moves do avoid building a target with this compiler in bitbake 1.3.3.x environment. Though am not willing to test that I would try to do a run without the moves. Working behind a proxy

Working behind a firewall (proxy) brings up some problems. Http and ftp

As http and ftp downloads are done using wget it is straight forward to use a proxy. You either have to insert lines like http_proxy="http://proxy.server.this.that:port_no/" ftp_proxy="ftp://proxy.server.this.that:port_no/" export http_proxy ftp_proxy into your environment script or insert that entries into ~/.wgetrc. You just have to care to get wget working with your proxy. Note, that the pending "/" is possibly important to get wget working. Cvs

You can either ask your system administrator to open port 2401 (and 22 for ssh access) ;-) or setup a ssh proxy going via 443 (https) port. This method is described in the below paragraph. This paragraph just shows the irc communication regarding that item. Until I do not have the stuff working, this is all I have. MP0 wrote: used transconnect to ssh through the http proxy to an outside machine used danteserver on the outside machine to have a socks4 proxy then used proxychains on the development machine to use the socks4 proxy on my outside machine through an ssh tunnel I think (not sure) that oe respects my http_proxy environment variable. unfortunately, it didn't use it for ftp you could also try having http_proxy not set and using proxychains to connect out of your http proxy My personal solution was as for svn... my solution is to have a proxy on the outside I used transconnect to get an ssh tunnel to the machine on the outside it's rather slow, but other than changing the structure of IT, what can I do. either set up your proxy to work on port 443 and use proxytunnel to go through both your corporate proxy and your outside proxy or (what I did, since it was already semi-set up) I had my outside machine running ssh on port 443 (always handy to have) ie, I put "port 443" in /etc/sshd/blahblahblah whatever the config file is called and restarted sshd since sshd is running on port 443, I can create a tunnel now, ssh has a neat feature the -D option it acts like a socks4/socks5 server so using transconnect or proxychains proxychains ssh -D 8080 MP0@someserver the only problem I have with that approach is (ie, using ssh) is I need to use a seperate program to get the ssh connection through the corporate proxy and one to get oe to use my ssh proxy that's why I use both proxychains and transconnect... one of them is configured to get ssh out of the corprorate proxy, the other is configured to make programs use my ssh proxy if you have your outside proxy server proxying on port 443 already (instead of ssh on 443), then you can use proxychains alone without another program. cuz proxychains, as its name implies, allows you to chain proxies... get through the corprorate proxy, and get through your outside proxy Alternatively, OE could use the fetch.patch by jordan crouse (amd), which as announced in the bitbake and oe mailing list. This patch enables cvs 1.10+ to use http_proxy directly unsing http_proxy environment settings. I am not sure, whether this patch is in already. . Subversion

Until now I never saw a package not downloading using either http, ftp or cvs. Subversion is also possible, but not used for repository. If you have to update bitbake itself, your sysadmin has to open port 3690 (svn). Instead of that, you may want to just copy your home bitbake version to you office ;-) Monotone

If you have to update or create your OE repository, your sysadmin has to open port 5253 (monotone). Instead of that, you may want to just copy your home oe.db and org.openembedded.dev dir. Usage

This chapter provides usage hints for OE. It mainly describes the building of opie-image and related items. Update OE

To update the OE package directory enter the directory and run To checkout your repository remove your org.openembedded.dev dir (or even better rename it) and do a monotone --db=OE.db co --branch=org.openembedded.dev as the update process pull;update may take days! For a quicker way to do . Bitbake

Bitbake normally acts on all metafiles defined in local.conf. It resolves all dependencies and builds, what is needed. To be able to do this, it first scans all directories given by the BBFILES entry in local.conf and build a hash out of that. This costs some time (and memory). Behind that, bitbake understands several commands usefull beside building complete packages. But first here is the help message of bitbake. sc@schomep4:~$ 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 seperated 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 -bBUILDFILE, --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. -f, --force force run of specified cmd, regardless of stamp status -i, --interactive drop into the interactive mode. -cCMD, --cmd=CMD Specify task to execute -rFILE, --read=FILE read the specified file before bitbake.conf -v, --verbose output more chit-chat to the terminal -D, --debug Increase the debug level -n, --dry-run don't execute, just go through the motions -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) Examples

A bitbake nano will parse all *.bb files defined in local.conf, build a hash and build everything, which nano depends on and last but not least nano itself. A bitbake -c clean nano will clean the nano package. A bitbake -b whereYourOEPackageDirIsbitbake/nano/nano_1.3.5.bb / will just build nano. All depends have already to be fullfilled for that. This does not execute the bb file parsing and spares time (e.g. during debugging). A bitbake -b whereYourOEPackageDirIsbitbake/nano/nano_1.3.5.bb -f -c clean / will force a clean on the already builded nano package. A bitbake -b whereYourOEPackageDirIsbitbake/nano/nano_1.3.5.bb -f -c fetch / will force a fetch on the already builded nano package. The package source is downloaded again independent of the cache status. A bitbake -b whereYourOEPackageDirIsbitbake/nano/nano_1.3.5.bb -f -c build / will force a build on the nano package. This will execute all stages "before" compile like fetch, patch, configure ... and compile itself. A bitbake -D -D -D nano will build the nano package and show you all files parsed. A bitbake virtual/kernel -c clean; bitbake virtual/kernel builds a new kernel for the opie-image and afterwards the related image. Possible CMD options

The following list gives an overview over the bitbake commands. clean cleans the package (tmp/work). Does not touch deploy dir (this has to be done manually). fetch fetches the package source from the source tree. patch eventually patches the sources with the patches provided in the package. configure configures the package. Knows several configure methods like autoconf/automake, qmake, ... compile compiles the package. build builds the package. install install the package. package packages the package. Hint : If e.g. a stage "build" is used, all prepended stages are executed automatically. Hint2 : An additional -f forces the command. How the configuration works

This section describes the parsing order of .conf and .bb files during a build run. The order defines, where to add / overwrite options for the build process. A changed option may be overwritten / menipulated in a later stage of parsing. An example is described in the following list. openembedded/conf/bitbake.conf This is where all parsing starts. YourBuildDir/conf/local.conf Here you can do you local configuration. Most interesting options are MACHINE and DISTRO. A TARGET_OS or TARGET_ARCH are normally defined somewhere deeper in the conf tree. openembedded/conf/machine/YourDefinedMachine.conf And all included machine_xxx.conf files. Here the HW-dependend options (kernel, etc ...) are defined. openembedded/conf/distro/YourDefinedDistro.conf And all included YourDefinedDistro_xxx.conf files (mostly none). Here the Distro dependend options are defined. All BBFILES defined .bb files This is the final run. To get a first overview for the set parameters, bitbake prints out the following options before executing. OE Build Configuration: TARGET_ARCH = "arm" TARGET_OS = "linux" MACHINE = "c7x0" DISTRO = "mftetest" TARGET_FPU = "" Note, that is you have an "INVALID" option noted here, you will run into series problems during build process and you can interrupt the process. Howto set / manipulate variables

Bitbake is able to handle the following assignments. = Sets a variable to the value given ( e.g. TARGET_OS = "linux" ) ?= Sets a variable to the value given if not already set. := Immediate variable expansion. += Adds a part to an existing variable (append) ( e.g. PATH += "/usr/local/arm/2.95.3/bin" ) appends the given path to the existing path variable. =+ Adds a part to an existing variable (prepend) ( e.g. PATH += "/usr/local/arm/2.95.3/bin" ) prepends the given path to the existing path variable. Cleaning

Cleaning single packages is easy. A bitbake -c clean packagename for a self selected actual package or bitbake -b ../openembedded/packages/packagename_x.y.z.bb -f -c clean for a specified version of package does that for you. As soon as you maybe want to use an older version of qte for rebuilding the opie-image, you have to clear manually. You have to guarantee, that all packages depending on qte are cleared from the build dirs. For example a qte rebuild needs cd tmp/work rm -rf *opie* rm -rf libopie* rm -rf libq* rm -rf *qte* cd tmp/cache rm -rf *opie* rm -rf *libopie* rm -rf *libq* rm -rf *qte* cd tmp/stamps rm -rf *opie* rm -rf libopie* rm -rf libq* rm -rf *qte* before rebuilding. Note :If nothing helps, a rm -rf tmp helps always. But in this case all staging items (cross-compiler, ...) have to be rebuild, which takes a lot of time. See also . Building your own meta package

Sometimes (or always) after a reflash, some liked packages are missing. If you use your tmp/deploy/ipk dir as repository, you can easily create a meta package, which builds all whished packages and creates a meta ipkg out of the result. This section describes how to manage that. Assumed you want to have rsync, bash, opie-zsafe added always, you can follow the steps described below to create a meta package. Create a dir meta in you private packages dir (if not done so). Create a file called xx-collections.inc and xxaddons.bb in there. xxaddons.bb file has the following content. include sc-collections.inc DEPENDS = "${XX_ADDONS_SYSTEM} \ ${XX_ADDONS_OPIE} LICENSE = GPL xx-collections.inc file has the following content. XX_ADDONS_SYSTEM = "rsync bash" XX_ADDONS_OPIE = "opie-zsafe" Create a dir called xxadd containing a xxadd.bbfile with the following content. DESCRIPTION = "Sc's additional meta package." MAINTAINER = "Werner Schulte <w1@schulte-ac.de>" LICENSE = "GPL" ALLOW_EMPTY = 1 PACKAGES = "${PN}" DEPENDS = "rsync bash opie-zsafe" RDEPENDS = "rsync bash opie-zsafe" The lines have the following meaning. DESCRIPTION, MAINTAINER, LICENCE : as normal. ALLOW_EMPTY = 1 : allows an empty package (with only depends). PACKAGES = ${PN} : the packages name. DEPENDS : A list of packages to be build when metapackage is build. RDEPENDS : A list of packages to be installed at meta package install. Build package scadd (bitbake scadd). Debugging

This chapter describes some debugging examples. If e.g. a package is not buildable, a build command does not finish, because a package is not found, etc., this chapter may give some hints, how to get it running, or where to get the necessary info from to ask the irc channle or mail the problem efficient. We start desribing some bitbake functions, which may help to find buggy packages / configurations. After that, we describe some example problems and the way to get the problems (temporary) fixed. Bitbake features for debugging

Debugging output (-D)

One option to get more information on the build process is to use additionally the -D option. This option may occur multiple times and thus increases the DebugLevel. A small extract of bitbake -D -D -D nano is shown below. DEBUG: CONF reading /home/sc/scdev/oe/org.openembedded.dev/conf/bitbake.conf DEBUG: CONF file 'conf/site.conf' not found DEBUG: CONF file 'conf/auto.conf' not found DEBUG: CONF including /data/scdev2/build-x86/conf/local.conf DEBUG: CONF file 'conf/build/i686-linux.conf' not found DEBUG: CONF file 'conf/target/INVALID-linux.conf' not found DEBUG: CONF including /home/sc/scdev/oe/org.openembedded.dev/conf/machine/dsa-x86.conf DEBUG: CONF including /home/sc/scdev/oe/org.openembedded.dev/conf/distro/generic.conf DEBUG: CONF including /home/sc/scdev/oe/org.openembedded.dev/conf/documentation.conf DEBUG: collecting .bb files NOTE: Using cache in '/data/scdev2/build-x86/tmp/cache' DEBUG: bbmake: parsing /home/sc/scdev/oe/org.openembedded.dev/packages/aalib/aalib_1.4rc5.bb Parsing .bb files, please wait...DEBUG: bbmake: parsing /home/sc/scdev/oe/org.openembedded.dev/packages/abiword/abiword_2.0.14.bb DEBUG: bbmake: parsing /home/sc/scdev/oe/org.openembedded.dev/packages/abiword/abiword_2.2.7.bb ... DEBUG: BB /home/sc/scdev/oe/org.openembedded.dev/packages/busybox/slingbox_1.00.bb: handle(data) DEBUG: BB :0: inheriting classes/base.bbclass DEBUG: BB classes/base.bbclass: handle(data, include) DEBUG: BB :0: inheriting classes/package_tar.bbclass DEBUG: BB classes/package_tar.bbclass: handle(data, include) ... You can see, that you are provided with lots of information, if you want. Show environment -e

The option -e shows the environment variables set during a bitbake run. This parameter may be used with just the bitbake command ( without a package ). In this case the environment variables build by just the diffenrent config files is show. You can easily check, whether your configuration is OK, after e.g. changing or creating a local configuration. Called with a package name, the complete packages dependency is checked. The list of variables provided is the one used if the package is build. See the partial output produced by bitbake -e nano below. # CPPFLAGS=${TARGET_CPPFLAGS} export CPPFLAGS="-I/data/scdev2/build-x86/tmp/staging/i686-linux/include" # OLDPWD=/home/sc/scdev/oe # DEBIAN_MIRROR=ftp://ftp.debian.org/debian/pool DEBIAN_MIRROR="ftp://ftp.debian.org/debian/pool" # LICENSE=unknown LICENSE="unknown" # HANDHELDS_CVS=cvs://anoncvs:anoncvs@cvs.handhelds.org/cvs HANDHELDS_CVS="cvs://anoncvs:anoncvs@cvs.handhelds.org/cvs" ... You can see always a line strting with "#", which shows the variable definition before expansion. Note, that this list maybe very long and thus should either be redirected to a file or directly grep'd. Show package versions -s

This command parses the complete package repository(s) and provides the last available and if configured the preferred package version (see gcc example below). ... galculator 1.2.3-r7 gammu 1.02.0-r0 gawk 3.1.4-r2 gawk-native 3.1.4-r2 gcalctool 5.5.21-r0 gcc 4.0.0-r1 3.4.4-r2 gcc-cross 4.0.0-r1 gcc-cross-initial 3.4.4-r1 gcc-cross-kernel-3.3.3 3.3.3-r2 gcc-cross-kernel-3.3.4 3.3.4-r2 gcc-cross-kernel-3.4.4 3.4.4-r1 gcc-cross-sdk 3.3.4-r2 ... Dry run -n

The dry run can be used to check, whether all dependencies are fullfilled. Also versioning, etc. can be checked. [OE-X86]sc@schomep4:/data/scdev2/build-x86$ bitbake -n nano NOTE: Using cache in '/data/scdev2/build-x86/tmp/cache' NOTE: Parsing finished. 2602 cached, 0 parsed, 96 skipped, 0 masked. NOTE: build 200509270855: started OE Build Configuration: TARGET_ARCH = "i686" TARGET_OS = "linux" MACHINE = "dsa-x86" DISTRO = "generic" TARGET_FPU = "" NOTE: package ncurses-native-5.4: started NOTE: package ncurses-native-5.4: completed NOTE: package ncurses-5.4: started NOTE: package ncurses-5.4: completed NOTE: package nano-1.3.5: started NOTE: package nano-1.3.5: completed NOTE: build 200509270855: completed Build statistics: Attempted builds: 3 [OE-X86]sc@schomep4:/data/scdev2/build-x86$ Speed up package build (in case of errors)

If you run into problems (errors during build process), you do not want to parse all repository files again and again. In this case you can build a package directly. A bitbake -b whereYourOEPackageDirIsbitbake/nano/nano_1.3.5.bb / will just build nano. All depends have already to be fullfilled for that (which is normally true, if your build stopped at nano). Examples

To be filled. AddOns

Using the tmp/deploy/ipk dir as your local repository

A bitbake -c clean opie-image e.g. does not clean all dependend packages, which leads to problems, when rebuilding with different sources later, if some packages did not change. For this I wrote a small script, which uses bbread and bitbake to constistent clean all dependend packages. You can call the script using do_clean.rc path/to/opie-image.bb. As the user may not want to clean important packages, as e.g. cross-gcc, if (accidentally) in the DEPENDS, the script shows all packages to be cleaned and asks the user what to do ? The above mentioned call leads to the following question. [OE-BOXER]sc@schomep4:~/scdev/oe/build-boxer$ do_clean.rc ../openembedded/packages/meta/opie-image.bb found 87 dependend packages. Really clean the following packages ? ======================================================= ipkg-native ipkg-utils-native fakeroot-native quilt-native virtual/arm-linux-gcc virtual/libc task-bootstrap qte libqtaux2 libopie2 qpf-bitstream-vera qpf-bitstream-vera-sans-mono qpf-unifont opie-pics opie-sounds opie-qcop opie-quicklauncher opie-taskbar opie-aboutapplet opie-clockapplet opie-logoutapplet opie-suspendapplet opie-batteryapplet opie-homeapplet opie-multikeyapplet opie-rotateappletopie-vtapplet opie-cardmon opie-irdaapplet opie-brightnessapplet opie-light-and-power opie-appearance opie-systemtime opie-sysinfo opie-networksettings opie-button-settings opie-packagemanager opie-keytabs opie-console opie-clock opie-citytime opie-backup ipkg ntp bluez-utils-nodbus irda-utils openobex-apps libopieobex0 opie-autorotateapplet opie-alarm opie-drawpad opie-textedit opie-addressbook opie-datebook opie-todo opie-today opie-today opie-today-addressbookplugin opie-today-datebookplugin opie-today-todolistplugin opie-clipboardapplet opie-volumeapplet opie-screenshotapplet opie-language opie-launcher-settings opie-doctab opie-security opie-mediummount opie-networksettings-wlanplugin opie-networksettings-pppplugin opie-advancedfm opie-style-flat opie-style-liquid opie-style-fresh opie-style-metal opie-style-web opie-style-phase opie-deco-flat opie-deco-liquid opie-deco-polished opie-multikey opie-handwriting opie-pickboard konqueror-embedded makedevs-native mtd-utils-native sharp-flash-header-c700 ======================================================= Yes/(N)o/Askme/Grep : If the user selects "N" (or any other key), the clean process will be stopped. If "Y" (upper case) bitbake -c clean PackageList is called, where PackageList is the list shown above. If the user selects "A" (Ask me), the user is asked for every package. If he selects "G", he can enter a grep pattern to delete packages matching from the list. The following paragraph shows an example. Yes/(N)o/Askme/Grep : A Clean ipkg-native Yes/(N)o/Rest ? : N Clean ipkg-utils-native Yes/(N)o/Rest ? : N Clean fakeroot-native Yes/(N)o/Rest ? : N Clean quilt-native Yes/(N)o/Rest ? : N Clean virtual/arm-linux-gcc Yes/(N)o/Rest ? : N Clean virtual/libc Yes/(N)o/Rest ? : N Clean task-bootstrap Yes/(N)o/Rest ? : N Clean qte Yes/(N)o/Rest ? : Y Clean libqtaux2 Yes/(N)o/Rest ? : Y Clean libopie2 Yes/(N)o/Rest ? : Y Clean qpf-bitstream-vera Yes/(N)o/Rest ? : R The user now has the choice. "Y" will clean, "R" will take the rest of the list to clear. The user is shown the list and asked again, after the selection is done. The selection may be repeated, until happy. Then he may select "Y" to confirm. After that bitbake is called with the list of selected packages and will clean them all. The script is downloadable from . Howto to modify to your needs

This chapter describes, how to modify the OE repository to your own needs. It gives some examples, which should be able to show the user the way it works. Howto add a new HW Target

This chapter describes the steps I did to get a new HW-Target platform for a pxa based device called "ori" without a touchscreen and without a mouse. I decided to use a pxa based zaurus as a bases. Basic configuration

All OE lived starts with bitbake.conf followed by the distro and machine configuration. To make live easy, I decided to let openzaurus distro as is for the first shot. For the target machine config I used c7x0 as the basis. Follow the hints listed to get a machine description for your new target. Create a build dir with a correctly configured conf/local.conf dir/file. Create a private packages dir with the following subdirs. conf, conf/machine To be used for the machine specific conf files. meta To be used for the image .bb file(s). linux This did not work for the first shot, so I decided to place my kernel dependend .bb files into openembedded/packages/linux dir. Copy and modify the following files. Copy openembedded/conf/machine/c7x0.conf to yourPackagesDir/conf/machine/ori.conf and edit that file. Exchange c7x0 by ori and provide a sufficient description. Exchange the include lines with the resulting lines described below. Copy openembedded/conf/machine/zaurus-clamshell-2.4.conf to yourPackagesDir/conf/machine/ori-common-2.4.conf Copy openembedded/conf/machine/zaurus-clamshell.conf to yourPackagesDir/conf/machine/ori-common.conf Howto build with gcc-2.95.3

This chapter describes how to build stuff using the 2.95.3 "sharp" compiler and NOT the gcc-3.x.y compiler. This allows to user to create e.g. sharprom compatible applications without build the whole stuff. Though this is not future proof, it may help in some situations. Create a build dir with a correctly configured conf/local.conf. Choose DISTRO="sharprom-compatible". Follow the hints in if not already done so. Enter /usr/local/arm/2.95.3/bin dir and set two links. ln -s arm-linux-gcc-2.95 arm-linux-gcc ln -s arm-linux-ld-2.11.2 arm-linux-ld Important Note : These links have to be removed as long as you want to work with gcc-3.x.y again. Edit openembedded/conf/distro/sharprom-compatible.conf and insert PATH =+ "/usr/local/arm/2.95.3/bin" (prepend). Now you may start to build. Provide your own software packages

To be done. Writing code

Source it

Writing a package file

Build the package

Test the package

Deploy

Customize to you needs

This chapter describes one way to customize the openembedded repository to your needs. The idea is to provide an additional packages repository which is used to define the additional stuff. Adding another package repository

We will explain that using an example directory myoe/packages, which is then similarly used as the org.openembedded.dev/packages repository. To inform bitbake about this new repository you have to extend the conf/local.conf file. The new BBFILES line(s) are e.g. BBFILES := "${HOME}/dev/oe/org.openembedded.dev/packages/*/*.bb" BBFILES += "${HOME}/myoe/packages/*/*.bb" The next bitbake run will parse the dev/oe/org.openembedded.dev packages as well as all packages found in myoe/packages. Adding a new machine

Unfortunately this can only be done in org.openembedded.dev/conf/machine for now. The easiest way to do is to copy a similar machine configuration and modify to your needs. As an example I will build a machine based on my c7x0 (zaurus) and name that my1stmach. A cd org.openembedded.dev/conf/machine; cp c7x0.conf my1stmach.conf followed by changing the content of my1stmach.conf to your needs (Description, ...). A cd org.openembedded.dev/conf/machine; cp zaurus-clamshell.conf my1stmach-common.conf provides a copy of the common used zaurus features. This common definitions are included in my1stmach.conf (content of that to be changed to use my1stmach-common.conf) and are only helpfull, if you want to use a group of similar devices (e.g. different flash sizes). Note that this is all to be done so far. All machine relevant dependencies should be defined here now. Important Note! As this is done inside the org.openembedded.dev dir, you should make a copy of your changes before calling monotone to resync your repository, as you ma loose your changes. Adding a new distro

Is done the same way as the machine. As an example I will build a distro based on generic and name that my1stdistro. A cd org.openembedded.dev/conf/distro; cp generic.conf my1stdistro.conf followed by changing the content of my1stdistro.conf to your needs (Description, ...). Note that this is all to be done so far. All distro relevant dependencies should be defined here now. Especially BOOTSTRAP_EXTRA_(R)DEPENDS are defined / added in here to extend the bootstrap-images content. Important Note! As this is done inside the org.openembedded.dev dir, you should make a copy of your changes before calling monotone to resync your repository, as you ma loose your changes. Adding a new bootstrap-image

As we may want to modify lots of stuff here and use this to explain the above created additional package repository we do a deep copy of the related packages. Create a dir myoe/packages/meta (as used for this kind of bb files in org.openembedded.dev as well. cp org.openembedded.dev/packages/meta/task-bootstrap.bb myoe/packages/meta/mytask-bootstrap.bb will provide a copy of the original task-bootstrap.bb package. You can now modify this new mytask-bootstrap.bb file to your needs (e.g. add or remove packages, ...) cp org.openembedded.dev/packages/meta/bootstrap-image.bb myoe/packages/meta/mybootstrap-image.bb will provide a copy of the original bootstrap-iage.bb package. You can now modify this new mybootstrap-image.bb file to your needs. At least we have to change the dependency to task-bootstrap-bb dependency. Follow the hints below. Change the entry IMAGE_BASENAME The result look like export IMAGE_BASENAME = "mybootstrap-image" Change the entry IPKG_INSTALL The result look like export IPKG_INSTALL = "mytask-bootstrap" This entry defines, which packages are installed into the images root file system (and thus the image itself). Change the entry DEPENDS The result look like DEPENDS = "mytask-bootstrap" May be you want to remove the FEED_URIS stuff (if you do not want to work using a openzaurus ipkg based image). Build the above mentioned bootstrap-image

This section last but not least describes how you can build your first self designed bootstrap-image. To be able to do so, we start to define a new build target as we want to use the machine / distro definition above as well. To prepare the build follow the hints below. Create a build directory A mkdir whereEver/build-my1stmachine will do so. Provide an environment script to prepare your build dir. The easyset way may be to copy an already existing one ( more info see ). A cp env-whatever env-my1stmachine will do so. Change the following entries OEBUILD : The build dir location OEBUILD=$OESYS2/build-my1stmachine PS1 : The Prompt PS1="[OE-MY1ST]$PS1" You can now change into your build environment calling . env-my1stmachine. Provide a conf/local.conf. The easyset way may be to copy an already existing one ( more info see ). A cp -a ../build-whatever/conf . will do so. Change the following entries BBFILES : Add your packages repository BBFILES := "${HOME}/dev/oe/org.openembedded.dev/packages/*/*.bb" BBFILES += "${HOME}/myoe/packages/*/*.bb" MACHINE : Provide your newly created machine target MACHINE = "my1stmach" DISTRO : Provide your newly created distro target DISTRO = "my1stdistro" You can now build your self designed bootstrap-image. A bitbake mybootstrap-image will start the build process. Some hours later you will probably have a freshly created bootstrap image named tmp/deploy/images/mybootstrap-image_xxx.gz. Example : Adding a new package (from existing sources)

You can also add new packages if not already provided easily. This section describes the integration of the schedutils package, which was needed during some tests. As this package is not "configured", but provides a "static" makefile, this is a good example how to handle that kind of stuff. The following list describes the steps I needed to do to get the package building for the correct target. Locate the sources package Here $DEBIAN_MIRROR is always a good idea. Create a package subdir in your myoe/packages dir and provide a schedutils_1.4.0.bb file (e.g. copied from psmisc package) matching the actual souces version. Manipulate the bb file The result looks like shown below. LICENSE = "GPL" DESCRIPTION = "schedutils tools : realtime process manipulation tools" SECTION = "base" PRIORITY = "optional" MAINTAINER = "Werner Schulte <w1 at schulte-ac.de>" PR = "r0" SRC_URI = "${DEBIAN_MIRROR}/main/s/schedutils/schedutils_${PV}.orig.tar.gz \ file://schedutils_make.patch;patch=1;pnum=1" S = "${WORKDIR}/schedutils-${PV}" inherit autotools PACKAGES = "${PN}" FILES_${PN} = "/usr/local/bin/*" # RDEPENDS_${PN} = "" python do_package_prepend() { destdir = "%s/usr/local/bin" % (bb.data.expand('${D}', d)) bb.mkdirhier(destdir) } The following list describes the main entries. SRC_URI Try bitbake schedutils in your target Note, that you will need several iterations to get the package be build. The main reason here was, that the package uses a static Makefile not prepared to be used in a CROSS environment. See more information . Preparing the Makefile

This subsection describes the changes I had to do on the Makefile and the way to create and provide an appropriate patch. Unpack the sources tgz or the cvs dir into your patch dir and create a copy of the resulting dir named xxx_orig. Edit the non _orig's Makefile. Remove (or comment) the CC entry to force CROSS usage Remove (or comment) the CFLAGS entry to force bitbake CFLAGS usage. Note, that this may be wrong, when non standard entries need to be provided. Change the CFLAGS to e.g. CYFLAGS entry in the complete Makefile in this case. Added $(DESTDIR) to the PRFIX variable to cause make to install binaries to the ${D} dir instead to / Potentially you do not want to install something like includ or man pages. remove that targets from Makefile then. Create a patch calling diff -Naur xxx xxx_orig > xxx_make.patch where xxx is your packages dir name. Copy that patch to myoe/packages/schedutils/schedutils dir (matching the SRC_URI's patch entry described ). Done that changes, you have the chance to build your new package. Handling Zauri

This chapter is only a reminder, which helps me on the horse, when handling my CL860 and SL5500. It describes the different possibilities to use system-menus, ... Up to now it is only a quick reference for the CL860 (as I always forget how to e.g. switch to flash-menu). This does not really belong here and may be changed in the future. Models and Name

SL-5000D or SL-5500 (Collie) SL-5600 (Poodle) SLC-700 (Corgi) SLC-750 (Shepherd) SLC-760 (Husky) SLC-860 (Boxer) SL-6000 (Tosa) CL860

This section cares for the CL860, but should als cover the CL750/760 and the other clamshell models. ServiceMenu

The service menu may be used for NAND Flash Backup. This is a full copy of the Z and e.g. can be used to make a copy of the sharp original ROM. To reach the Service-Menu follow the steps below. Unplug Power Unlock battery Remove battery cover Remove battery Press D+M and insert battery If nothing happens : Switch on Power or try again. FlashMenu

The Flash-Menu can be used to reflash the user partition (e.g. with a new OZ-Image). Unplug Power Unlock battery Remove cover Remove battery Wait 1 sec Insert battery Close cover Lock battery Plugin Power Press "OK"-Button + "ON/OFF" Important hint : Save all your user data before flashing a new image. All unsaved data will be lost. To flash an image, you have to use a VFAT formatted (not EXT2 or so) CF disk or SD Disk with the following 3 files in its root dir. updater.sh The script handling the update. The Scripts can be found e.g. . zImage.bin (exactly named like that). This is the new kernel, which have to be renamed to that name ( e.g. mv zImage-husky-20050121183004.bin zImage.bin). initrd.bin (exactly named like that). This is the new initial RAM disk, which have to be renamed to that name ( e.g. mv opie-image-husky-20050205085722.rootfs.img initrd.bin). Note, that you may flash the kernel only, if initrd.bin is not found (e.g. renamed). The same is possible with initrd.bin only. To flash, follow the steps below. The Display show a menu with 4 Japanese buttons. Selecting flash option (Button 4) Select Button 2 (CF) Left of two buttons (OK) SysRq keys

Some special kernel functions can be reached using the SysRq function. Kernel 2.4 Fn + Home pressed together, release the Fn (keep Home pressed). Press the SysRq key. Kernel 2.6 RightJapaneseKey + Home pressed together, release the RightJapaneseKey (keep Home pressed). Press the SysRq key. The following paragraph describes some helpfull SysRq keys (read src/linux/Documentation/sysrq.txt) for more information. s works with OZ Does an "Emergency Sync", which tries to sync all mounted filesystems (to guarantee a non corrupt filesystem). b works with OZ "Reboot". Immediately reboot the system without syncing or unmounting your disks into the low level bootloader and waits for the "ON/OFF" button to be pressed. o does not work with OZ "Off". Will shut your system off (if configured and supported). u Will attempt to remount all mounted filesystems read-only. p does not work with OZ Will dump the current registers and flags to your console. t works with OZ Will dump a list of current tasks and their information to your console. m works with OZ Will dump current memory info to your console. 0-9 works with OZ Sets the console log level, controlling which kernel messages will be printed to your console. ('0', for example would make it so that only emergency messages like PANICs or OOPSes would make it to your console.) e works with OZ Send a SIGTERM to all processes, except for init. Note, that a Fn+Right will lock the system now. i works with OZ Send a SIGKILL to all processes, except for init. Note, that a Fn+Right will lock the system now. h works with OZ Will display help ( actually any other key than those listed above will display help. but 'h' is easy to remember :-) FAQ

Bitbake problems

bitbake cannot find conf/bitbake.conf Most likely your BBPATH is not set or set incorrect. BBPATH has to be YourBuildDir:OpenEmbeddedDir. Note, that it is important to have a leading YourBuildDir. If OpenEmbeddedDir leads the path, this error may occur as well. Important NOTE : you have to set BBPATH explicitly (I am not sure why). If you choose to use your env_xxx scripts, the variable seems to be set (according to set), but bitbake complains with above error. ./setup.py complains "error: could not create '/usr/local/lib/python2.4/site-packages/bb': Permission denied" The python development package ("python-dev" for Debian) may be not installed. During build process, a package complains not to find shared libs for installation This occured e.g. with the readline package for opie image. I did not find out, why this happens. The possible solution (at least it works on my system) is a manual (non bitbake) make clean;./configure and afterwards a bitbake -b ../.../readline_x.y.bb -c build. It seems to have something to do with the configuration phase of bitbake for this package. Bitbake complains a missing global variable "bb" You most likely have to install bitbake new (because of a newer version). Bitbake does not successfully execute setup Monotone problems

Initial monotone pull takes day(s) For some reason, the first pull takes a very long time. Unfortunately it restarts from the very beginning once stopped, so you need to have a long and stable internet connection. A first work arround is to get the db snapshot . Unpack it, where you decided to place your database. A final monotone --db=oe.db co --branch=org.openembedded.dev will setup your box. After a pull, monotone suggests to do a monotone merge That monotone merge was never successfull for me. In this case you should start from the beginning by downloading the current snapshot. How to do so . Config problems

How can I build older version (than the acual one) ? An entry CVSDATE="yyyymmdd" in your local.conf file should do that. I did not yet find out, if that works really. How can I use my own packages tree ? Add an entry to the BBFILES variable in you local.conf. Target image does e.g. not contain pcmcia package. How is the dependency tree for an image build ? In principle bitbake searches through the BBPATH to find a matching machine *.conf entry (e.g. conf/machine/c7x0.conf). This file may (and will) inherit other *.conf files. In this case the BOOTSTRAP_DEPENDS where overwritten instead of appended to the inherited BOOTSTRAP_DEPENDS. BOOTSTRAP_DEPENDS = ... : NOK Overwrites all inherited BOOTSTRAP_DEPENDS. BOOTSTRAP_DEPENDS += ... : OK Appends to inherited BOOTSTRAP_DEPENDS. The same was wrong for BOOTSTRAP_RDEPENDS. See also . Build problems

Qte snapshot does not build If the actual snapshot is fails to build, you can use an older version. The most easiest way is to do so is to rename the qte-for_xxx snapshot file. My own sources compile, but do not provide an ipk. You have to provide one or more FILES entries in your package file. glibc_2.3.5 build complains "cfi_endproc directive missing" (Assembler Message). This already occured several times for me. Reason is a missing GLIBC_ADDONS = "nptl" somewhere in your configuration (in my case a new target machine). Packages file of tmp/deploy/ipk does not update when adding a new ipk file. This directory is not meant to be a local repository. Nevertheless, it can easily be made to that. Just use my mkPackages.rc script to rebuild the Packages file in any ipkg directory. See also . PXA openzauruskernel 2.4 or other Z kernels do not build. Complains "unmet dependencies for char.o" On my Debian Sarge, the program loadkeys does only run with superuser rights. This leads to an empty driver/char/corgi_keymap.c, which leads to the above mentioned error. If you do not want to modify your /dev/console A cd kernel/linux/driver/char, followed by sudo loadkeys --mktable corgi_keymap.map | sed -e 's/^static *//' > corgi_keymap.c creates the file. A kernel/temp/run.do_compile.xxx recompiles without configuring. This creates the kernel. If you want to modify your /dev/console Become superuser and call chmod 644 /dev/console. This will make loadkeys work also as a normal user. But be carefull. From now on, any normal user can modify the kernels keymap. This is probably a high risk security item. Read man loadkeys also. konqE does not build. "-lpcre : library not found" This is not yet solved, but I found a workarround. Remove tmp/staging/arm-linux/lib/libpcreposix.* and reconfigure / build konqE again. This helps to build konqE, but I am not sure, whether libpcreposix is needed in the target image. bitbake does not find any package to build A similar message like [OE-BOXER]sc@schomep4:~/scdev/oe/build-boxer2$ bitbake opie-image NOTE: Psyco JIT Compiler (http://psyco.sf.net) not available. Install it to increase performance. NOTE: Using cache in '/home/sc/scdev/oe/build-boxer2/tmp/cache' ERROR: no files to build. NOTE: Parsing finished. 0 cached, 0 parsed, 0 skipped, 0 masked. is printed out. You most probably do not have the build/conf/local.conf file there (dir or file not existing) or configured wrong (no package dir found). Patch file (or other addon file) is not available at build time. This happened in my case with corgi_power-r22.patch. The reason was a file corgi_power-r22.patch.md5 in the sources dir. This was created obviously by a buggy (self edited) patch line entry in the bb file. To help out of that, just clear the md5 file from the sources dir. Some packages do not build, because during installation phase some directories are not builded (linux-hotplug, e.g.) You possibly are using the wrong shell. I had that phenomenon on my Debian Sarge installed office PC, while my home box (also Debian Sarge) worked. Some packages (linux-hotplug) and some target (package_rpm) do use a special feature, which is provided by bash, but not by e.g. dash. A mkdir -p {SPECS,RPM/{i386,i586,noarch},SRMPS} should lead to a directory structure ./SPECS, ./RPM/i386, ./RPM/i586, ./RPM/noarch, .SRPMS. Means that the bracket term will be expanded during runtime. My problem was even more tricky. The expansion worked in a terminal, while it did not during bitbake execution. The reason was a link /bin/sh leading to /bin/dash instead of /bin/bash. How can I add a customized /etc/fstab ? Files like the mentioned are provided by the packages basefiles. The easiest way if to manipulate the org.openembedded.dev/packages/base-files/base-files/fstab but this will potentially be lost, after the next monotone update call. So a better way is to create a private copy using the mechanisms described in . A "nothing provides libx11" (example) error occurs building an XServer (e.g.) but the package file is available This is most like an unwanted BBMASK entry (e.g. to reduce opie build time). In my case I had set BBMASK = "gpe|x|matchbix", so it could not find it, though the package file was there. Adding packages problems

How do I add one or more new package(s) to bootstrap-image ? Add the package name to BOOTSTRAP_EXTRA_DEPENDS and BOOTSTRAP_EXTRA_RDEPENDS to do so. This variable is expanded in task-bootstrap package to add the list of required packages. You can do that e.g. in org.openembedded.dev/conf/distro/yourdistro.conf. How do I build a customized bootstrap image See . I added a package to the distro file (BOOTSTRAP_EXTRA_(R)DEPENDS), but rebuild (e.g.) bootstrap-image did not insert that package. In case of bootstrap-image the packages list is provided by task-bootstrap package. If you did not rebuild this package, the target image will not contain the package. To be sure tio have the new package in the image, follow the hints below. Force bitbake to reload the cache. To do so call touch conf/local.conf in your build dir. Force bitbake to rebuild task-bootstrap. To do so call bitbake -b whereYourPackageDirIs/meta/task-bootstrap.bb -f -c clean Force bitbake to rebuild bootstrap-image. To do so call bitbake -b whereYourPackageDirIs/meta/bootstrap-image.bb -f -c clean and bitbake -b whereYourPackageDirIs/meta/bootstrap-image.bb. How can I e.g. prepend a script call before the configure call, if autotools is used Either you could provide a do_configure_prepend(){ my Code in here } method or you write your own method ( e.g. do_autogen_sh(){ my Code in here } and just add "addtask do_autogen_sh before do_configure". How can I add additional parameters to the a configure call if autotools is used Add EXTRA_OECONF += "your params" to your bitbake file. Usage problems

First calibration of OPIE does not work on target machine There maybe is a problem with the qte tslib patch. Just disable the file line in the qte package file and rebuild qte. During startup Z complains to have the wrong (old) kernel The OE group did not want to have reports for wrong kernel / image relations. So the kernel has to match the image datetime string. To build a new kernel, you have to modify the yourKernel*.bb file (until the bug is solved). Insert the 3 lines of bitbake.conf beginnig with "DATE :=", into your kernels bb file. After that call bitbake virtual/kernel -c clean;bitbake virtual/kernel. Note, that a bitbake opie-image would again lead to the old kernel image (I do not yet know why).