Create an ipk package from sources/zh tw

From Openmoko

(Difference between revisions)
Jump to: navigation, search
(Software versioning)
(軟體版本別)
Line 19: Line 19:
 
定出known bugs 及功能層級。這可被稱為 "branching"。 If version specific bugs are found in version a.b, then we can update this branch independently.
 
定出known bugs 及功能層級。這可被稱為 "branching"。 If version specific bugs are found in version a.b, then we can update this branch independently.
  
In bitbake, we must specify which release of our software we are going to package. This may not be an habit, especially if you only develop small programs, not maintained by more than one or two person. If your software is named "myprogram" but has no real version number attached, you can just rename your project directory to "myprogram-1.0".
+
在bitbake,我們必須指定哪個版本的軟體是我們要包裝的。這個可能不是你個人寫程式的習慣,尤其是你只開發小的程式,你的程式不是透過二個以上的人維護。如果你的軟體稱為 "myprogram" ,但沒有連接真的版本名稱,你可以將你的專案目錄重新命名為"myprogram-1.0"
  
This is a good practice; If you are packaging a software, then it will be used by other people, so when you modify it next time, put it in a folder named "myprogram-1.1" :) This brings clarity to users, ease of management to you, and ability to plan future releases to your team.
+
這是個很好的訓練,如果你在包裝一個軟體,它將會由其它人使用時,當你下次修改它時,就要把檔案夾的名稱改為 "myprogram-1.1" :) 這可以讓使用者暸,並且讓軟體易於管理,並且也可以為你的軟體團隊做未來的規劃。
  
 
==Example==
 
==Example==

Revision as of 11:34, 13 March 2009

本篇文章的主要目地在於導引及幫助撰寫Openmoko 程式。

Contents

原理

Openmoko 使用OpenEmbedded來製作package 及root image 。

OpenEmbedded 提供 patches及 Bitbake Recipes,這與提供 .spec 檔案建立 RPM套件。 Bitbake 被用來處理recipes,並取得packages及FS images。舉例來說,bitbake可以取出原始碼,套用到 patches、設定,製作及安裝編譯好的源碼。其它的步驟為使用者可定義的,但這超過本文的範圍。

標準的bitbake用法是下載現有的 package如 "gcc" 或"binutils" 或 "linux kernel",套用到platform patches (加入修復的bug程式碼、porting fixes、驅動程式....等),然後編譯並封裝輸出的binary。

軟體版本別

Software軟體版本及設定管理是個廣泛的議題,並且有不同的意見,在這裡會做個快速的說明。

軟體版本在套件建立方法中是很重要的問題,軟體版本即代表軟體的全部。如它是用來追踨軟體變更的一個指標,並且讓每個版本是個獨立的版本。在這裡,我們必須認知到基本的版本管理問題。

Current (most advanced) version is named the "trunk". Additions, fixes, etc. are done to the trunk.

一旦特定層級的功能達到了,則會被編上版本編號。這樣一來,目前的開發就可以繼續 ,但使用者可以下載定義完整的釋出版本,即 定出known bugs 及功能層級。這可被稱為 "branching"。 If version specific bugs are found in version a.b, then we can update this branch independently.

在bitbake,我們必須指定哪個版本的軟體是我們要包裝的。這個可能不是你個人寫程式的習慣,尤其是你只開發小的程式,你的程式不是透過二個以上的人維護。如果你的軟體稱為 "myprogram" ,但沒有連接真的版本名稱,你可以將你的專案目錄重新命名為"myprogram-1.0"。

這是個很好的訓練,如果你在包裝一個軟體,它將會由其它人使用時,當你下次修改它時,就要把檔案夾的名稱改為 "myprogram-1.1" :) 這可以讓使用者暸,並且讓軟體易於管理,並且也可以為你的軟體團隊做未來的規劃。

Example

Say you have a working software package, ie a file system directory with sources, Makefile, etc... Because this is a common method, I will base my presentation on a project generated using autotools. This implies that the software can be installed somewhere by following the magical steps ./configure && make && make install.

Prerequisites

You need a configured openmoko development tree. All details are in Building Openmoko from scratch

You may also do this with MokoMakefile, see instructions at the bottom.

The following commands will give you one, they are copied from the above page. Just copy and paste in a shell.


# make sure we have mtn
set -e
echo "if script stops immediatly install monotone with either apt-get or yum"
test_mtn=`miitn --version`

#prepare
cd $HOME
mkdir OM
cd OM

#get openembedded
wget http://www.openembedded.org/snapshots/OE.mtn.bz2
bunzip2 OE.mtn.bz2
mtn --db=OE.mtn pull monotone.openembedded.org org.openembedded.dev
mtn --db=OE.mtn checkout --branch=org.openembedded.dev -r e2dbb52fe39df7ef786b6068f6178f29508dfded openembedded

#get openmoko
svn co http://svn.openmoko.org/ openmoko

#create local config
mkdir -p sources build/conf
cat <<EOF >build/conf/local.conf
MACHINE = "fic-gta01"
DISTRO = "openmoko"
BUILD_ARCH = "`uname -m`"
EOF

#fixes (didnt try without them)
ln -s openmoko/trunk/oe ./oe
cd sources
mkdir -p ../build/tmp/stamps/armv4t-linux
wget http://ftp.mozilla.org/pub/mozilla.org/js/older-packages/js-1.5.tar.gz
touch ../build/tmp/stamps/armv4t-linux/js-1.5-r0.do_fetch
wget http://us4.samba.org/samba/ftp/stable/samba-3.0.14a.tar.gz
touch ../build/tmp/stamps/armv4t-linux/samba-3.0.14a-r15.do_fetch
perl -pi.orig -e 's/ *$//;s/\r//g' ../openembedded/packages/gcc/gcc-4.1.1/gcc-4.1.1-pr13685-1.patch

Then, you need the environment variables described here: Building_Openmoko_from_scratch#Environment_variables Put the given lines in a script, then go to your build/ dir and source it:

cat <<EOF >doenv.sh
#!/bin/sh
export OMDIR=`pwd`
export BBPATH=$OMDIR/build:$OMDIR/openmoko/trunk/oe:$OMDIR/openembedded
EOF
. ./doenv.sh

After this, your tree will look like that:

$HOME/OM
 +- build
 |  +- conf
 |  |  +- local.conf
 +- openmoko
 +- openembedded
 +- sources
 +- env.sh

etc...


Follow the link to MokoMakefile and follow the instructions. You're now all set to start building. Remember to run the setup-env command for each time you open a terminal. This sets your environment variables, however it is easier to include them in the rc file of your shell.

Proposed directory layout for our new packages

Bitbake recipes are single files describing how to build a package. I recommend to have a recipe for each package version (myprogram-1.0.bb, myprogram-1.1.bb, etc.) all stored in a directory named "myprogram"

Our personal tree can be everywhere else:

$HOME
 +- $OMDIR (contains the official openmoko tree)
 |  +- ...
 +- My_personal_Openmoko_Packages
 |  +- packages
 |     +- myhello
 |        +- myhello-1.0.bb
 +- My_Personal_Projects_Folder
    +- myhello
       +- myhello-1.0
          +- configure.ac
          +- Makefile.am
          +- ...

To do a simple test, pack your sources in a tar, and put this tar on a web server:

cd My_personal_Projects_Folder/myhello
tar cvfz myhello-1.0.tar.gz myhello-1.0/

This is correct, ie the tarball will have a NAME-VERSION subdirectory, that's what we need.

The recipe

In the bitbake file, you need to give

  • a description for your package, variable name is DESCRIPTION
  • a package name (PN)
  • a package version (PV)
  • a source URI, I'll give details later
  • a source version, to checkout a particular revision of versionned trees
  • Please see the Open Embedded StyleGuide which should answer most if not all questions about .bb file conventions.

here's an example:

#package description
DESCRIPTION = "An example application for openmoko, depending on a custom source repository"
SECTION = "squalyl/myhello"

#this is optional
LICENSE = "GPLv2"

PN = "myhello"
PV = "1.0"

#use "now" to force svn updates at each build
#Using now is a very dangerous way to do it. ONLY use this in your
#personal recipes when you're doing heavy testing, otherwise
#choose a stable date and stick with it that way when you distribute your recipe
#you don't have all sorts of versions getting built out in the wild.
SRCDATE_${PN} = "now"
SRC_URI = "svn://repo/path/myhello;proto=https;module=${PN}-${PV}"

#for a tarball use:
#SRC_URI = "http://server/path/package/${PN}-${PV}.tar.gz"

#include standard rules to build a autoconf/automake package
inherit autotools

Expressions starting by ${} are substituted, this allows you to download a tarball named "mypackage-1.0.tar.gz" for example

Source URIs

bitbake can get the source code for your project from a variety of locations including tarball, subversion and git.

All of this is explained in the bitbake manual, particulary here.

The package build directory, the one where bitbake will run "configure" et al, will follow the name template: "PACKAGE_NAME-PACKAGE_VERSION", so

  • tarballs must extract to a subdirectory with this name
  • svn top directory must have this name

It's very important. I spent 3 days blocking on this!

Tell bitbake to build our package

The only and one thing to do is edit $OMDIR/build/local.conf to tell bitbake to search our folders for .bb files:

BBFILES+="${HOME}/MypersonalOpenmokoPackages/packages/*/*.bb"

There is no need to change BBPATH or something else, this is only needed to add new configuration files, not recipes.

Running

$ cd $OMDIR/build
$ bitbake mypackage

will bring all the necessary operations to create a package in $OMDIR/build/tmp/deploy/ipk/armv4t/myhello .....

The following is an example build log:

OE Build Configuration:
BB_VERSION     = "1.6.9"
OE_REVISION    = "<unknown>"
TARGET_ARCH    = "arm"
TARGET_OS      = "linux"
MACHINE        = "fic-gta01"
DISTRO         = "openmoko"
DISTRO_VERSION = ".dev-snapshot-20070723"
TARGET_FPU     = "soft"

NOTE: This BitBake doesn't support revision fetching, falling back to current date
NOTE: preferred version 2.4 of glibc not available
NOTE: preferred version 2.4 of glibc-intermediate not available
NOTE: preferred version 2.4 of glibc not available
NOTE: package myhello-1.0: started
NOTE: package myhello-1.0-r0_0_200707231759: task do_fetch: started
NOTE: Fetch svn://svn.unsads.com/squalyl/om/src/myhello;proto=https;module=myhello-1.0
A    myhello-1.0/configure.ac
A    myhello-1.0/include
A    myhello-1.0/include/config.h.in
A    myhello-1.0/cleanall.sh
A    myhello-1.0/AUTHORS
A    myhello-1.0/bootstrap.sh
A    myhello-1.0/ChangeLog
A    myhello-1.0/src
A    myhello-1.0/src/hello.c
A    myhello-1.0/Makefile.am
A    myhello-1.0/NEWS
A    myhello-1.0/README
Révision 2116 extraite.
NOTE: package myhello-1.0-r0_0_200707231759: task do_fetch: completed
NOTE: package myhello-1.0-r0_0_200707231759: task do_unpack: started
NOTE: Unpacking /home/squalyl/OM/sources/myhello-1.0_svn.unsads.com_.squalyl.om.src.myhello__now.tar.gz to /home/squalyl/OM/build/tmp/work/armv4t-linux/myhello-1.0-r0_0_200707231759/
NOTE: package myhello-1.0-r0_0_200707231759: task do_unpack: completed
NOTE: package myhello-1.0-r0_0_200707231759: task do_patch: started
NOTE: package myhello-1.0-r0_0_200707231759: task do_patch: completed
NOTE: package myhello-1.0-r0_0_200707231759: task do_configure: started
NOTE: package myhello-1.0-r0_0_200707231759: task do_configure: completed
NOTE: package myhello-1.0-r0_0_200707231759: task do_compile: started
NOTE: package myhello-1.0-r0_0_200707231759: task do_compile: completed
NOTE: package myhello-1.0-r0_0_200707231759: task do_install: started
NOTE: package myhello-1.0-r0_0_200707231759: task do_install: completed
NOTE: package myhello-1.0-r0_0_200707231759: task do_package: started
NOTE: package myhello-1.0-r0_0_200707231759: task do_package: completed
NOTE: package myhello-1.0-r0_0_200707231759: task do_package_write: started
Packaged contents of myhello-dbg into /home/squalyl/OM/build/tmp/deploy/ipk/armv4t/myhello-dbg_1.0-r0_0_200707231759_armv4t.ipk
Packaged contents of myhello into /home/squalyl/OM/build/tmp/deploy/ipk/armv4t/myhello_1.0-r0_0_200707231759_armv4t.ipk
NOTE: Not creating empty archive for myhello-doc-1.0-r0_0_200707231759
NOTE: Not creating empty archive for myhello-dev-1.0-r0_0_200707231759
NOTE: Not creating empty archive for myhello-locale-1.0-r0_0_200707231759
NOTE: package myhello-1.0-r0_0_200707231759: task do_package_write: completed
NOTE: package myhello-1.0-r0_0_200707231759: task do_populate_staging: started
NOTE: package myhello-1.0-r0_0_200707231759: task do_populate_staging: completed
NOTE: package myhello-1.0-r0_0_200707231759: task do_build: started
NOTE: package myhello-1.0-r0_0_200707231759: task do_build: completed
NOTE: package myhello-1.0: completed
NOTE: build 200707231952: completed
Build statistics:
  Attempted builds: 1

Get this package included in the rootfs image

*This method is not a standard or normal way to include a package. The proper method follows the improper method.

bitbake openmoko-devel-image is used to build the entire distribution, but it does not include your new package in the rootfs image.

To do this, use:

bitbake openmoko-devel-image -crebuild

This will actually rebuild the rootfs, including your new packages.

*The suggested method follows below.

To include the package in the image there are two steps.

First: Modify your local.conf. $OMDIR/build/conf/local.conf

DISTRO_EXTRA_RDEPENDS += "<app name>"

This adds your application as a dependency for building the distro.

Second: Update the task-base.

bitbake task-base -crebuild

When you update the task base it re-builds and ipk file which will: "Merge machine and distro options to create a basic machine task/package"

You could also add your package by modifying the openmoko/trunk/oe/packages/tasks/task-openmoko.bb and adding your application name with the trailing backslash right before the update-alternatives line.

  modutils-initscripts \
  module-init-tools-depmod \
  udev \
  rsync \
  screen \
  <My application Name> \ 
#  update-alternatives \

Then to test this out (if you're using the MokoMakefile) it's pretty simple.

make openmoko-devel-image
make build-qemu
make flash-qemu-local

And now you're running qemu with that fancy new image you just made!

If you are really lazy this script should do all the above stuff. This is just a small shell hack which uses the power of sed to inject packages into the the final image. Use at your own risk and please don't flame the author =D..

#!/bin/bash
# Sudharshan "Sup3rkiddo" S
# inject, script that injects packages into the Openmoko standard, 
# The sed line does all the stuff, nothing elite...
# The package is grouped under TASK_OPENMOKO_LINUX..after rsync
# The bitbake recipes should be present in the proper place. OE docs for info

ARGS=1
E_BADARGS=65

if [ $# -ne "$ARGS" ]
then
    echo "Usage: inject <packagename>"
    exit $E_BADARGS
fi

make update
make setup
cd openmoko/trunk/oe/packages/tasks
mv task-openmoko.bb task-openmoko.bb_bakup
# search for rsync and append the package name after it..[KIDDISH HACK]
sed '/rsync \\/ a\  '$1' \\' <task-openmoko.bb_bakup >>task-openmoko.bb
mv task-openmoko.bb_bakup ~/
cd ../../../
make clean-package-$1
#make build-package-$1
make openmoko-devel-image
#make build-qemu
#make flash-qemu-local
echo "Done injection..muhahah"

See also

Bold text

Personal tools

本篇文章的主要目地在於導引及幫助撰寫Openmoko 程式。

原理

Openmoko 使用OpenEmbedded來製作package 及root image 。

OpenEmbedded 提供 patches及 Bitbake Recipes,這與提供 .spec 檔案建立 RPM套件。 Bitbake 被用來處理recipes,並取得packages及FS images。舉例來說,bitbake可以取出原始碼,套用到 patches、設定,製作及安裝編譯好的源碼。其它的步驟為使用者可定義的,但這超過本文的範圍。

標準的bitbake用法是下載現有的 package如 "gcc" 或"binutils" 或 "linux kernel",套用到platform patches (加入修復的bug程式碼、porting fixes、驅動程式....等),然後編譯並封裝輸出的binary。

軟體版本別

Software軟體版本及設定管理是個廣泛的議題,並且有不同的意見,在這裡會做個快速的說明。

軟體版本在套件建立方法中是很重要的問題,軟體版本即代表軟體的全部。如它是用來追踨軟體變更的一個指標,並且讓每個版本是個獨立的版本。在這裡,我們必須認知到基本的版本管理問題。

Current (most advanced) version is named the "trunk". Additions, fixes, etc. are done to the trunk.

一旦特定層級的功能達到了,則會被編上版本編號。這樣一來,目前的開發就可以繼續 ,但使用者可以下載定義完整的釋出版本,即 定出known bugs 及功能層級。這可被稱為 "branching"。 If version specific bugs are found in version a.b, then we can update this branch independently.

在bitbake,我們必須指定哪個版本的軟體是我們要包裝的。這個可能不是你個人寫程式的習慣,尤其是你只開發小的程式,你的程式不是透過二個以上的人維護。如果你的軟體稱為 "myprogram" ,但沒有連接真的版本名稱,你可以將你的專案目錄重新命名為"myprogram-1.0"。

這是個很好的訓練,如果你在包裝一個軟體,它將會由其它人使用時,當你下次修改它時,就要把檔案夾的名稱改為 "myprogram-1.1" :) 這可以讓使用者暸,並且讓軟體易於管理,並且也可以為你的軟體團隊做未來的規劃。

Example

Say you have a working software package, ie a file system directory with sources, Makefile, etc... Because this is a common method, I will base my presentation on a project generated using autotools. This implies that the software can be installed somewhere by following the magical steps ./configure && make && make install.

Prerequisites

You need a configured openmoko development tree. All details are in Building Openmoko from scratch

You may also do this with MokoMakefile, see instructions at the bottom.

The following commands will give you one, they are copied from the above page. Just copy and paste in a shell.


# make sure we have mtn
set -e
echo "if script stops immediatly install monotone with either apt-get or yum"
test_mtn=`miitn --version`

#prepare
cd $HOME
mkdir OM
cd OM

#get openembedded
wget http://www.openembedded.org/snapshots/OE.mtn.bz2
bunzip2 OE.mtn.bz2
mtn --db=OE.mtn pull monotone.openembedded.org org.openembedded.dev
mtn --db=OE.mtn checkout --branch=org.openembedded.dev -r e2dbb52fe39df7ef786b6068f6178f29508dfded openembedded

#get openmoko
svn co http://svn.openmoko.org/ openmoko

#create local config
mkdir -p sources build/conf
cat <<EOF >build/conf/local.conf
MACHINE = "fic-gta01"
DISTRO = "openmoko"
BUILD_ARCH = "`uname -m`"
EOF

#fixes (didnt try without them)
ln -s openmoko/trunk/oe ./oe
cd sources
mkdir -p ../build/tmp/stamps/armv4t-linux
wget http://ftp.mozilla.org/pub/mozilla.org/js/older-packages/js-1.5.tar.gz
touch ../build/tmp/stamps/armv4t-linux/js-1.5-r0.do_fetch
wget http://us4.samba.org/samba/ftp/stable/samba-3.0.14a.tar.gz
touch ../build/tmp/stamps/armv4t-linux/samba-3.0.14a-r15.do_fetch
perl -pi.orig -e 's/ *$//;s/\r//g' ../openembedded/packages/gcc/gcc-4.1.1/gcc-4.1.1-pr13685-1.patch

Then, you need the environment variables described here: Building_Openmoko_from_scratch#Environment_variables Put the given lines in a script, then go to your build/ dir and source it:

cat <<EOF >doenv.sh
#!/bin/sh
export OMDIR=`pwd`
export BBPATH=$OMDIR/build:$OMDIR/openmoko/trunk/oe:$OMDIR/openembedded
EOF
. ./doenv.sh

After this, your tree will look like that:

$HOME/OM
 +- build
 |  +- conf
 |  |  +- local.conf
 +- openmoko
 +- openembedded
 +- sources
 +- env.sh

etc...


Follow the link to MokoMakefile and follow the instructions. You're now all set to start building. Remember to run the setup-env command for each time you open a terminal. This sets your environment variables, however it is easier to include them in the rc file of your shell.

Proposed directory layout for our new packages

Bitbake recipes are single files describing how to build a package. I recommend to have a recipe for each package version (myprogram-1.0.bb, myprogram-1.1.bb, etc.) all stored in a directory named "myprogram"

Our personal tree can be everywhere else:

$HOME
 +- $OMDIR (contains the official openmoko tree)
 |  +- ...
 +- My_personal_Openmoko_Packages
 |  +- packages
 |     +- myhello
 |        +- myhello-1.0.bb
 +- My_Personal_Projects_Folder
    +- myhello
       +- myhello-1.0
          +- configure.ac
          +- Makefile.am
          +- ...

To do a simple test, pack your sources in a tar, and put this tar on a web server:

cd My_personal_Projects_Folder/myhello
tar cvfz myhello-1.0.tar.gz myhello-1.0/

This is correct, ie the tarball will have a NAME-VERSION subdirectory, that's what we need.

The recipe

In the bitbake file, you need to give

  • a description for your package, variable name is DESCRIPTION
  • a package name (PN)
  • a package version (PV)
  • a source URI, I'll give details later
  • a source version, to checkout a particular revision of versionned trees
  • Please see the Open Embedded StyleGuide which should answer most if not all questions about .bb file conventions.

here's an example:

#package description
DESCRIPTION = "An example application for openmoko, depending on a custom source repository"
SECTION = "squalyl/myhello"

#this is optional
LICENSE = "GPLv2"

PN = "myhello"
PV = "1.0"

#use "now" to force svn updates at each build
#Using now is a very dangerous way to do it. ONLY use this in your
#personal recipes when you're doing heavy testing, otherwise
#choose a stable date and stick with it that way when you distribute your recipe
#you don't have all sorts of versions getting built out in the wild.
SRCDATE_${PN} = "now"
SRC_URI = "svn://repo/path/myhello;proto=https;module=${PN}-${PV}"

#for a tarball use:
#SRC_URI = "http://server/path/package/${PN}-${PV}.tar.gz"

#include standard rules to build a autoconf/automake package
inherit autotools

Expressions starting by ${} are substituted, this allows you to download a tarball named "mypackage-1.0.tar.gz" for example

Source URIs

bitbake can get the source code for your project from a variety of locations including tarball, subversion and git.

All of this is explained in the bitbake manual, particulary here.

The package build directory, the one where bitbake will run "configure" et al, will follow the name template: "PACKAGE_NAME-PACKAGE_VERSION", so

  • tarballs must extract to a subdirectory with this name
  • svn top directory must have this name

It's very important. I spent 3 days blocking on this!

Tell bitbake to build our package

The only and one thing to do is edit $OMDIR/build/local.conf to tell bitbake to search our folders for .bb files:

BBFILES+="${HOME}/MypersonalOpenmokoPackages/packages/*/*.bb"

There is no need to change BBPATH or something else, this is only needed to add new configuration files, not recipes.

Running

$ cd $OMDIR/build
$ bitbake mypackage

will bring all the necessary operations to create a package in $OMDIR/build/tmp/deploy/ipk/armv4t/myhello .....

The following is an example build log:

OE Build Configuration:
BB_VERSION     = "1.6.9"
OE_REVISION    = "<unknown>"
TARGET_ARCH    = "arm"
TARGET_OS      = "linux"
MACHINE        = "fic-gta01"
DISTRO         = "openmoko"
DISTRO_VERSION = ".dev-snapshot-20070723"
TARGET_FPU     = "soft"

NOTE: This BitBake doesn't support revision fetching, falling back to current date
NOTE: preferred version 2.4 of glibc not available
NOTE: preferred version 2.4 of glibc-intermediate not available
NOTE: preferred version 2.4 of glibc not available
NOTE: package myhello-1.0: started
NOTE: package myhello-1.0-r0_0_200707231759: task do_fetch: started
NOTE: Fetch svn://svn.unsads.com/squalyl/om/src/myhello;proto=https;module=myhello-1.0
A    myhello-1.0/configure.ac
A    myhello-1.0/include
A    myhello-1.0/include/config.h.in
A    myhello-1.0/cleanall.sh
A    myhello-1.0/AUTHORS
A    myhello-1.0/bootstrap.sh
A    myhello-1.0/ChangeLog
A    myhello-1.0/src
A    myhello-1.0/src/hello.c
A    myhello-1.0/Makefile.am
A    myhello-1.0/NEWS
A    myhello-1.0/README
Révision 2116 extraite.
NOTE: package myhello-1.0-r0_0_200707231759: task do_fetch: completed
NOTE: package myhello-1.0-r0_0_200707231759: task do_unpack: started
NOTE: Unpacking /home/squalyl/OM/sources/myhello-1.0_svn.unsads.com_.squalyl.om.src.myhello__now.tar.gz to /home/squalyl/OM/build/tmp/work/armv4t-linux/myhello-1.0-r0_0_200707231759/
NOTE: package myhello-1.0-r0_0_200707231759: task do_unpack: completed
NOTE: package myhello-1.0-r0_0_200707231759: task do_patch: started
NOTE: package myhello-1.0-r0_0_200707231759: task do_patch: completed
NOTE: package myhello-1.0-r0_0_200707231759: task do_configure: started
NOTE: package myhello-1.0-r0_0_200707231759: task do_configure: completed
NOTE: package myhello-1.0-r0_0_200707231759: task do_compile: started
NOTE: package myhello-1.0-r0_0_200707231759: task do_compile: completed
NOTE: package myhello-1.0-r0_0_200707231759: task do_install: started
NOTE: package myhello-1.0-r0_0_200707231759: task do_install: completed
NOTE: package myhello-1.0-r0_0_200707231759: task do_package: started
NOTE: package myhello-1.0-r0_0_200707231759: task do_package: completed
NOTE: package myhello-1.0-r0_0_200707231759: task do_package_write: started
Packaged contents of myhello-dbg into /home/squalyl/OM/build/tmp/deploy/ipk/armv4t/myhello-dbg_1.0-r0_0_200707231759_armv4t.ipk
Packaged contents of myhello into /home/squalyl/OM/build/tmp/deploy/ipk/armv4t/myhello_1.0-r0_0_200707231759_armv4t.ipk
NOTE: Not creating empty archive for myhello-doc-1.0-r0_0_200707231759
NOTE: Not creating empty archive for myhello-dev-1.0-r0_0_200707231759
NOTE: Not creating empty archive for myhello-locale-1.0-r0_0_200707231759
NOTE: package myhello-1.0-r0_0_200707231759: task do_package_write: completed
NOTE: package myhello-1.0-r0_0_200707231759: task do_populate_staging: started
NOTE: package myhello-1.0-r0_0_200707231759: task do_populate_staging: completed
NOTE: package myhello-1.0-r0_0_200707231759: task do_build: started
NOTE: package myhello-1.0-r0_0_200707231759: task do_build: completed
NOTE: package myhello-1.0: completed
NOTE: build 200707231952: completed
Build statistics:
  Attempted builds: 1

Get this package included in the rootfs image

*This method is not a standard or normal way to include a package. The proper method follows the improper method.

bitbake openmoko-devel-image is used to build the entire distribution, but it does not include your new package in the rootfs image.

To do this, use:

bitbake openmoko-devel-image -crebuild

This will actually rebuild the rootfs, including your new packages.

*The suggested method follows below.

To include the package in the image there are two steps.

First: Modify your local.conf. $OMDIR/build/conf/local.conf

DISTRO_EXTRA_RDEPENDS += "<app name>"

This adds your application as a dependency for building the distro.

Second: Update the task-base.

bitbake task-base -crebuild

When you update the task base it re-builds and ipk file which will: "Merge machine and distro options to create a basic machine task/package"

You could also add your package by modifying the openmoko/trunk/oe/packages/tasks/task-openmoko.bb and adding your application name with the trailing backslash right before the update-alternatives line.

  modutils-initscripts \
  module-init-tools-depmod \
  udev \
  rsync \
  screen \
  <My application Name> \ 
#  update-alternatives \

Then to test this out (if you're using the MokoMakefile) it's pretty simple.

make openmoko-devel-image
make build-qemu
make flash-qemu-local

And now you're running qemu with that fancy new image you just made!

If you are really lazy this script should do all the above stuff. This is just a small shell hack which uses the power of sed to inject packages into the the final image. Use at your own risk and please don't flame the author =D..

#!/bin/bash
# Sudharshan "Sup3rkiddo" S
# inject, script that injects packages into the Openmoko standard, 
# The sed line does all the stuff, nothing elite...
# The package is grouped under TASK_OPENMOKO_LINUX..after rsync
# The bitbake recipes should be present in the proper place. OE docs for info

ARGS=1
E_BADARGS=65

if [ $# -ne "$ARGS" ]
then
    echo "Usage: inject <packagename>"
    exit $E_BADARGS
fi

make update
make setup
cd openmoko/trunk/oe/packages/tasks
mv task-openmoko.bb task-openmoko.bb_bakup
# search for rsync and append the package name after it..[KIDDISH HACK]
sed '/rsync \\/ a\  '$1' \\' <task-openmoko.bb_bakup >>task-openmoko.bb
mv task-openmoko.bb_bakup ~/
cd ../../../
make clean-package-$1
#make build-package-$1
make openmoko-devel-image
#make build-qemu
#make flash-qemu-local
echo "Done injection..muhahah"

See also

Bold text