Openmoko development questions.

Holger Freyther zecke at
Mon Nov 3 13:17:36 CET 2008

On Monday 03 November 2008 01:38:12 Radek Bartoň wrote:

> 2. I did "bitbake -c patch gdal" to start my modifications, then fixed
> several things to get "bitbake -c compile" proceed but doing "bitbake -c
> build" fails with lot of errors similar to:
> ERROR: QA Issue: package gdal contains bad
> /mnt/data/Projekty/MokoGRASS/moko/build/tmp/work/armv4t-angstrom-linux-gnue
>./arm-angstrom-linux-gnueabi/lib in
> file
> /mnt/data/Projekty/MokoGRASS/moko/build/tmp/work/armv4t-angstrom-linux-gnue

RPATH is generally considered harmful/dangerous. It instructs the linker to 
search for libraries in the given path. Now the attack vector is that some 
random user can put a fake libc in the RPATH directory...

Inside the Makefile there is a line like -Wl,rpath... you can replace that with 
rpath-link and are mostly safe... 

> 4. What are other bitbake tasks except of those mentioned in previous
> question?

there is a listtasks task it will list all tasks. Maybe it is written 
list_tasks or such.

> 6. Why should I use quilt do manage patches of modified packages when all
> OpenEmbedded and Openmoko stuff is under git version control and I can do
> diff against head version?

The "metadata" is under git, if you change that (e.g. bb files) use git to 
create a patch. But if you start to patch the source of packages in 
tmp/work... you want to use something. quilt is quite handy with that, 
nowadays I just type git-init, git-add *, git-commit -m "foo" and then do the 

> 7. How should I prepare pached and where should I submit them in case of
> changes in "openebedded/packages" and in case of changes in
> "openmoko/trunk"

openembedded metadata as the output of git-format-patch (we can just apply it 
with git-am), patches against svn, please send a unified diff.
You can send the patch to the list or better attach them to the bugtracker and 
set the haspatch flag.


More information about the devel mailing list