Codehelp blog

gpe-expenses is now stable enough for a 0.1.0 release - the NEW queue is really short so it should be in unstable soon.

In order to support the developing gpe-cash (and later gpe-invoice) application(s), the package has been split into a (small) binary and a new shared library - both licenced only under the GPL v2 or later.

The binary depends on libqof1, as before (GPL v2 or later). The new shared library contains the QofExpenses and GpeCurrency objects. QofExpenses is registered with QOF to provide data storage and queries. GpeCurrency is based on the Palm Default Currency Table. http://pilot-qof.sourceforge.net/manual/ch06.html#defaultcurrencytable. This provides a much simpler interface to standard currencies whilst retaining GnuCash data compatibility.

Splitting the objects out allows gpe-cash to share live data with gpe-expenses, reading expense data into double-entry accounts and allows gpe-cash to use sane currencies that can still be converted to GnuCash commodities. gpe-cash will itself contain one or more shared
libraries that include the double-entry financial objects, ready for gpe-invoice to collate data from gpe-contacts, gpe-calendar and gpe-expenses, create invoices (in SQLite) and post transactions to gpe-cash. Early days, I know, but that's the plan. (Invoices would be rendered in HTML/PDF/foo using scripts in the datafreedom packages.) pilot-qof already includes the basic support for generating an invoice from contact, calendar and expense data.

gpe-cash is a fork of gnucash, splitting the behemoth into small(est) functional units and dropping large sections of code - like reports which can be better managed using packages like datafreedom-perl on the desktop. datafreedom already includes example reports from
gpe-expenses. Even so, gpe-cash may well be a large application compared to other GPE packages. So far, gpe-cash comes in at just over 1Mb installed (including libqof1) but there's more Gtk+ stuff to write yet. (Compare with gnucash where the architecture-dependent part alone is >5Mb without any translations, images or other common files or the extra dependencies.) gpe-cash will have none of the dependency problems of gnucash: it just has the object definitions, libqof1, glib2.0, gtk+, gpe and sqlite. (There is an issue with GConf2 right now but I'm sure I can remove the need for that.)

http://gpe-expenses.sourceforge.net/ (CVS available via SF)

http://cashutil.sourceforge.net/gpecash.php. (SVN available via SF)

The pbuilder-based chroot script (empdebuild) in Emdebian SVN is now functional - that is it can run from a directory created by emsource, patch the Debian source using emdebian-patch files ( = emdebianising the package), get the build dependencies and install them, run emdebuild to cross-build the package and copy the updated patches, build log, .changes, .dsc and .deb files out to a nominal location before cleaning up the chroot. Only the basic pbuilder options and setup is supported and some values that can be configured for pbuilder are calculated automatically by empdebuild.

The embootstrap script that creates the chroot used by empdebuild needs some more work before this can be released as part of emdebian-tools 0.2.2 and there is no support (yet) for installing the cross-dependencies required for some packages. I'll be experimenting with Gyrosgeier's debian/xcontrol idea to specify these Build-Cross-Depends: using information already gathered on an ad-hoc basis. xcontrol files can then be committed to Emdebian SVN as patches. The pbuilder code is sufficiently flexible that the same code that parses debian/control for Build-Depends can be adapted to parse debian/xcontrol for Build-Cross-Depends.

In theory, empdebuild can become the basis of a cross-buildd, significantly improving the rate at which packages can be emdebianised.

The script does, currently, have to use apt pinning to retain the Emdebian toolchains because of problems with gcc-4.2 on arm.

(And yes, I do realise that emdebuild and empdebuild are very similar names but then so are debuild and pdebuild upon which the respective Emdebian scripts are based.)


http://buildd.emdebian.org/svn/browser/current/host/trunk/emdebian-tools/trunk/pbuilder

subtitle: Break up GnuCash into lots of forks

With an ISP problem throttling my broadband to 4000B/s, I've switched to developing in C instead of building Emdebian packages - downloading Debian sources was taking an hour or more even for small packages.

This has made time for a long overdue project: gpe-cash - double entry accounting for handhelds. It's a spin-off from the stalled cashutil project and it just might provide the impetus to get cashutil into a releasable state.

gpe-cash uses QOF (Query Object Framework) which itself was spun out from GnuCash some years ago when it was described as "the gnucash engine without all the financial stuff". So gpe-cash is a happy reunion of the engine and the financial stuff along with Gtk+, only a lot smaller than GnuCash. Yes, it is a fork but a fork done for, IMHO, very good reasons. (Why write free software and then frown on forked projects?) There's little hope of getting GnuCash to run on any embedded hardware (it would probably end up as a laptop instead of a handheld in the process) so it has to be broken up: forked into a few smaller bits and simply dropping larger bits.

I've long wanted to break up the GnuCash behemoth and this is how this fork will work:

1. Package the basic GnuCash objects as a shared library with -dev, -dbg and -doc


2. Package the GnuCash business objects as another shared library, with ditto.


3. Leave the commodity (stocks and shares) objects for a later date due to QOF compatibility issues with the GnuCash code.


4. Use the pilot-qof Default Currency Table to create a tiny set of gnucash compatible currencies. (Also used by gpe-expenses already.)


5. Share live expense data with gpe-expenses and gpe-cash (prevent duplication)


6. Share contacts and live calendar data with gpe-invoice (calculate invoices)


7. Drop direct file compatibility with GnuCash until GnuCash itself supports a sane backend, a suitable data import or cashutil is fixed, whichever comes soonest.


8. Retain object compatibility with GnuCash at the QOF level - permits removing certain parts of GnuCash specific code from the objects whilst retaining functionality.


9. Drop all reports, graphs, CSV import, QIF import, Scheme and other complexity of GnuCash.


10. Use a simple SQLite backend via QOF.
    

Best laid plans . . . etc. It always ends up a bit different to the plan but you have to have a plan of some kind. (No?, well I do.)

The code is a combination of gpe-expenses and cashutil. It will (eventually) live within the cashutil SVN at SourceForge but I haven't committed the first changeset yet. The basic structures already work, it is tying the C objects to the Gtk that is the bulk of the remaining work.

If anyone is interested in upstream development, subscribe to the (very low volume) QOF-devel mailing list and let me know.

I've been wondering if it is worth packages.d.o indicating if the DD is also (one of) the
upstream developer(s) of their maintained (non-native?) packages. I'd expect that it may help bug reporters to know this, with regard to where to file certain bug reports or just be useful information generally. It could help by indicating whether a quick release is possible and whether patches will migrate upstream automatically.

debian/copyright isn't sufficient for this because there isn't necessarily a match between the upstream and Debian email addresses, but maybe it's yet another field for debian/control.

Just idle musings really.

libc6 is by far the largest package in the current Emdebian repository and as part of a rootfs it is simply overpowering. So various ideas cropped up on Emdebian IRC. Split the gconv libraries into three or more packages. Split the binaries into a new package and split out libnss into another. Have to see how if pans out and whether an over-arching pseudo package is needed later to make it easier to package reverse dependencies of libc6.

(Yes, uclibc is an option and Emdebian is actively working on that too but it would be nice to be able to have the flexibility of something inbetween uclibc and the behemoth that is Debian libc6.)