adding pjsip to my openmoko overlay - part 2

Posted on February 28, 2008
Filed Under openmoko | 2 Comments

since my last post i’ve made some progress with my bitbake recipe to build the pjsip project for openmoko.

the first problem i ran into with the install was bitbake complaining that files from a .svn subdirectory from the source tree couldn’t be installed because of a permission problem. those files shouldn’t be installed anyway but were as a side effect of pjsip’s install Makefile rule, which does a recursive copy of the include directories within each subdirectory to /usr/local/include. this fixes it:

# removes all of the .svn files to avoid problems
# during the install
do_remove_svn_files () {
   # "|| true" is to avoid problems with recursing into directories
   # that are removed
   find ${S} -type d -name '.svn' -exec rm -rf {} \; > /dev/null \
      2>&1 || true
}
addtask remove_svn_files after do_unpack before do_patch

pjsip’s makefile is hardcoded to install the libraries and header files into the /usr/local prefix. the default bitbake recipes don’t look for installed files in these directories and complained that the files were installed but not listed in any package. so, copying what i saw in the ffmpeg recipe, i tried this:

FILES_pjsip-dev = “/usr/local/lib/lib*.a \
/usr/local/include/*\
/usr/local/lib/pkgconfig/libpj.pc”

this appears to have no effect. after some trial and error and finally discovering the “-e” option to bitbake, i saw from this command - bitbake -e pjsip | less - that the FILES variable is already assigned by one of the bitbake classes. i thought my assignment would override it but i guess not. instead, something like this is necessary:

FILES_pjsip-dev += "/usr/local/lib/lib*.a \
/usr/local/include/*\
/usr/local/lib/pkgconfig/libpj.pc"

or the more conventional:

FILES_${PN}-dev += "/usr/local/lib/lib*.a \
/usr/local/include/*\
/usr/local/lib/pkgconfig/libpj.pc"

this works perfectly and produces an ipkg file in build/tmp/deploy/glibc/ipk/armv4t.

pjsip’s install Makefile rule doesn’t install any of the command line utilities or the python bindings. i’ll take a stab at those next.

cool stuff - quilt for patch management

Posted on February 26, 2008
Filed Under programming | Leave a Comment

while working with openmoko i recently became aware of quilt, an excellent patch management system. i haven’t worked with patch files too often, preferring to use a revision control system like subversion, but the few times i have dealt with generating and managing patches i wished there were a better way. suddenly with quilt such mundane tasks as generating a patch file for a srpm in a redhat-based system or keeping a set of uncommitted local changes to an anonymous subversion checkout become trivial.

quilt lets you create new patch files by working directly from a single source tree instead of requiring that you keep a copy of an unmodified source tree from which you generate a diff. additionally it tracks as many distinct patches to the source tree as you need, each of which can be applied or unapplied selectively.

quilt models patches as a stack - patch A is applied first then patch B then patch C:

C

B

A

one annoyance is that the patches must have an order and quilt insists that patches are applied in order. this is great for patches which edit related bits of code and are truly dependent but not so great for patches that are relatively independent - if patches A, B, and C modify different sections of the code and could be applied or unapplied in any order and you just want patches B and C applied. in this scenario if you applied patch B and C, patch A is automatically applied before patch B and B is applied before C. you can manually edit the series file to change the order - not the greatest solution but workable.

there are several resources available which do a much better job of explaining what quilt is and how to use it. i definitely recommend checking them out:

adding pjsip to my openmoko overlay

Posted on February 15, 2008
Filed Under openmoko | Leave a Comment

continuing my quest for a programmable sip client on openmoko, i’ve been working on adding pjsip to my openembedded overlay.

adding a new package to openembedded is quite daunting at first but there are some great resources out there:

i’ve also found that browsing through the files in openembedded/classes and openembedded/conf is quite useful to learn which tasks are implemented and what they do.

using bitbake in interpreter mode (bitbake -i) can save some time in the edit/test cycle when developing bitbake recipes because the recipe files are parsed once.

i copied the openembedded/packages/ffmpeg/ffmpeg_svn.bb recipe to use as a starting point. the first challenge was fetching the pjproject subversion repository. the ffmpeg recipe uses this:

SRC_URI = "svn://svn.mplayerhq.hu/ffmpeg/;module=trunk"

the svn repository for pjsip is http://svn.pjsip.org/repos/pjproject/trunk but this doesn’t work:

SRC_URI = "http://svn.pjsip.org/repos/pjproject;module=trunk"

because bitbake uses the svn:// or http:// to determine whether to fetch the code with the subversion client or with wget. so to fetch the pjproject repository this is necessary:

SRC_URI = "svn://svn.pjsip.org/repos/pjproject;module=trunk;proto=http"

another gotcha is that unless you define SRCREV it defaults to 1 so the do_fetch task will always retrieve the subversion repository at revision 1 unless you either set SRCREV to a specific revision to check out or you define:

SRCREV_pn-<your project name> = "${AUTOREV}"

so for my new recipe i’ve added:

SRCREV_pn-pjproject = "${AUTOREV}"

my recipe thus far will check out the repository and incorrectly build & install it into the staging area. i’ll work on improving those areas next.

you can find my local overlay in my subversion repository here:

http://svn.eugeneoden.com/openmoko-overlay/trunk/

switching back to the matchbox keyboard in openmoko

Posted on February 13, 2008
Filed Under openmoko, telephony | 1 Comment

i just noticed that the default devel image uses the “multitap-pad” keyboard instead of the matchbox keyboard i’ve grown accustomed to.

i’m sure the multitap-pad keyboard is great for some people but i don’t like it. i can’t figure out how to enter several keys that i can’t do without, particularly “/”.

here’s how to switch back to the matchbox keyboard.

(disclaimer - i’m new to openmoko & openembedded. i probably don’t know what i’m doing. it seems to work for me, though)

option 1: update a running image

this provides immediate gratification by switching in a running image without having to go through the image building & flashing process. it requires a network connection with access to an ipkg repository. the downside is that you’ll need to repeat these steps if you reflash your neo.

run the following as root from the neo1973, preferably via ssh:

   ipkg update
   ipkg install matchbox-keyboard-applet
   ipkg install matchbox-keyboard-inputmethod
   ipkg install matchbox-keyboard-im
   killall multitap-pad
   ipkg remove -force-depends multitap-pad
   /etc/init.d/xserver-nodm restart

you’ll see the x server restart on the neo then if everything works you’ll have the matchbox keyboard applet icon in the top bar just to the right of center.

option 2: build your own image with the matchbox keyboard enabled

if you’re not already building your own images this will take much longer - like a day or two.

first setup the openmoko build environment. i suggest using the MokoMakefile.

if you haven’t already you’ll need to create a local overlay. copy task-openmoko-base.bb to your overlay:

   mkdir -p local/packages/tasks
   cp openembedded/packages/tasks/task-openmoko-base.bb \
      local/packages/tasks/

then modify local/packages/tasks/task-openmoko-base.bb, uncomment the following lines:

   #  matchbox-keyboard-inputmethod \
   #  matchbox-keyboard-im \
   #  matchbox-keyboard-applet \

and comment out this line:

   multitap-pad \

next, increment the “PR” line near the top of the file so bitbake will rebuild the package.

now you should be ready to rebuild the image with “make openmoko-devel-image”. you can flash your new image to your neo with “make flash-neo-local” or whichever way you prefer.

2008-02-15 update:

it appears that when i was looking for instructions to switch the keyboard back i missed this:

http://article.gmane.org/gmane.comp.handhelds.openmoko.distro/220

erin yueh sent similar instructions for switching the keyboard the day before i worked through it. would have saved me a couple of hours if i had googled a bit more. oh well. at least i was on the right track.

learning pygtk

Posted on February 10, 2008
Filed Under python | 1 Comment

i’ve got some apps i want to write for the neo1973/freerunner. the standard interface appears to be gtk+. my preferred programming language is python so i’ve been going through the pygtk tutorial. most of the limited interface work i’ve done is in visual basic so i’m not entirely comfortable with the event handling and widget construction of gtk but i suppose it just takes practice.

i’m interested in developing some location-based services on the neo1973 and did some reading last night on calculating the distance between two latitude/longitude coordinate pairs. math certainly isn’t my strong point so i’m not sure if the equation here:

http://mathforum.org/library/drmath/view/51722.html

will work as is. any suggestions are welcome.

later

fun with wordpress

Posted on February 8, 2008
Filed Under system administration | Leave a Comment

what fun would hosting one’s own blog be without tweaking it?

i’ve done a couple wordpress installations for customers before but hadn’t spent much time using it. i have to say i’m quite impressed. its a snap to setup and was a piece of cake to upgrade to version 2.3.3 on debian etch. installing plugins and themes is as easy as unzipping them into the right folder.

i just finished switching themes and setting up the google adsense plugin without much difficulty.

i’m currently using the “modernpaper” theme and the following plugins:

that’s it for now.

openmoko & neo1973

Posted on February 7, 2008
Filed Under openmoko, programming, telephony | 1 Comment

i’ve been spending some time getting to know openmoko and the neo1973 lately as well as the openembedded framework. its starting to make sense. i’ve added a couple silly apps to a local overlay and was able to build a custom image with my apps and some favorite packages preinstalled.

a near-term goal is getting some sort of sip client running on the neo1973. i’m currently looking at the pjsip libraries and utilities and was able to compile them on the neo1973. next i’ll try adding pjsip to my openembedded overlay so it’ll be automatically compiled & installed into my custom image.

« go back