That's one hell of a package diane

Now I have packages of libferris for Fedora 7 and 8 and opensuse 10.3. So the next obvious move for a someone who has rolled many an rpm would be to jump into the deep end of debian packaging...

root@ubuntu710:/tmp/PKG/libferris-1.2.1# ls -lh  ../*deb
-rw-r--r-- 1 root root 2.4M 2007-11-28 04:39 ../ferris_1.2.1-1_i386.deb
-rw-r--r-- 1 root root 5.4M 2007-11-28 04:40 ../libferris1_1.2.1-1_i386.deb
-rw-r--r-- 1 root root 228K 2007-11-28 04:39 ../libferris-dev_1.2.1-1_i386.deb
-rw-r--r-- 1 root root 249K 2007-11-28 04:40 ../libferrisui1_1.2.1-1_i386.deb
-rw-r--r-- 1 root root  64K 2007-11-28 04:40 ../libferrisxslt1_1.2.1-1_i386.deb

I still need to actually add some pre/post scripts and the likes but it is looking somewhat decent so far. The downside is that the default builds for all three distros are somewhat conservative leaving out many of the higher level, higher dependency functionality. But for folks just wishing to mount xml, db4 and do some desktop search these packages should work. Though you will get reduced selection of what index formats are supported etc.

Open-C for s60, so close but yet so far

Like the vast tribes who look over /. from time to time I noticed the new rewards for developing for Google's new mobile platform. I found this quite interesting considering the recent openc comp and the differences between the pecuniary motivation offered by the two camps.

I tried to port over rsync to s60 using open-c. The massive problems with the API not offering anything to cleanly emulate fork() and exec() are bad enough, try submitting a patch to an open source project with ugly stuff in a #ifdef clause to try to emulate these calls with pthreads and see how far you get. I haven't tried this with the rsync guys yet as I haven't managed to get it running yet :/

The killer, so to speak is the lack of signal() and kill() calls. The self IPC that is quite common of having an app fork() itself and signal itself or wait for itself at a later time. Waiting is one thing, that can be quite readily ported to pthreads type calls using IPC mechanisms. When a parent sends for example USR2 signal to the child is where you run into unbounded joy. Especially where all of this is happening inside a do_recv() function which is used quite heavily in both client and server mode.

I might throw together a kludge for it at some point because it actually compiles (though will not run because I haven't ported some fork() code yet). There are three or so places that use fork() which will need attention. It compiles because I have a nasty pthreads implementation of fork() in an effort to avoid dumping a huge bunch of garbage boilerplate code into apps to be ported. I don't know why the symbian dudes didn't include a int s60_pthreads_fork() implementation....