Codehelp blog

I've never particularly liked IRC because it is as intrusive as a telephone - flashing away and demanding attention. I much prefer email, which I can answer when I choose to allocate the time to handle it. I have a lot of different tasks ongoing and an interruption about a completely different topic makes it difficult to retain the train of thought required to pursue the original task. I've cut back on my IRC time since Christmas but I'm cutting back further.

It's part and parcel of managing my software work without it excluding other things I like doing too. The good weather is a great excuse to get away from the laptop/desktop, so I'll be doing a lot more impromptu hikes and day trips. I'm resurrecting other non-computer activities too - it's been too long.

So, don't expect to see me on IRC - except during a conference etc. If you need me, as ever, use email and preferably one of the many mailing lists to which I'm subscribed. If the query applies to any of my packages, a bug report is far better than an email or I could forget. (Telephone is for business/close friends only, again except during conferences.)

Many people have moaned about SF and the hassle of making a release - if you're in that category and haven't checked with the current file release system at SF, you could be in for a pleasant surprise.

SF has added lots more ways to upload files and has a nice simple interface - I'm just using:
$ scp foo-ver.tar.gz sf-release:uploads

Copy and paste the NEWS and Changelog content into the release announcement and I'm done. It's no harder than Alioth (which was my strong preference before this change at SF).

(This also serves as an announcement that gpe-expenses and pilot-qof have been updated with upstream releases as well as supporting the recent QOF transition.)

It's taken a lot longer than I expected (mostly due to getting other things done in Emdebian etc.) but now that Lenny is out, QOF can finally drop all the previously deprecated code and move to libqof2, so the upstream code has now been released via Alioth (0.8.0) and the binaries have been uploaded to Debian and are waiting in NEW.

QOF provides a set of C language utilities for performing generic structured complex queries on a set of data held by a set of C/C++ objects. This framework allows programmers to add query support to their applications without having to hook into a SQL Database. QOF is a large part of my attempts to get some degree of data freedom to complement the source code freedom. This remains a problem with certain applications, especially financial ones, so I've tried to make it easier to both import and export data between programs using QOF and to convert the default QOF data storage formats into other common formats using simple tools and scripts based on XSL or perl. Having a SQL-type query interface accessible via the command line is a huge bonus when dealing with large data sets.

There is a patch for gnotime that makes the final adjustments to handling the removed code. pilot-qof and gpe-expenses already build cleanly without the deprecated code but each of these is also pending a new upstream release, so rather than need a binNMU, I'm simply going to make those releases when QOF clears NEW.

Having said that, pilot-qof and gpe-expenses introduce new binary packages themselves so they will spend time in NEW too. pilot-qof will be the last of the set to be released because the new upstream version can use symbols from the new gpe-expenses release to make it easier to move data between applications. However, that support is optional at build time and could be done via a Debian revision, so I might do it that way.

This also marks the completion of the migration of QOF from SourceForge to Alioth - principally for easier bug tracking and a usable mailing list archive. The QOF VCS is in svn.debian.org.

The mailing list for QOF development is therefore at alioth:
QOF-devel and archives also.

I'm still working on two other QOF-based utilities - one that can handle simple accounts and one to handle simple invoices. The invoice handling is already partially implemented in pilot-qof but I'm looking at a GTK+ frontend with a robust command line interface so that scripts can update the invoice data behind-the-scenes. Hopefully, some form of arbitrary-format parser can be arranged that can handle extracting data from whatever form the client happens to send - typically PDF. It'll need tweaking for each client, but it could work. The objects used by gpe-expenses and pilot-qof (including invoices) are exposed via QOF and can be mixed together in any new QOF application, easily able to read data from multiple sources, merge data sets, query data sets and export into other formats. The core currency and expense types come from pilot-link but are then enhanced to support GnuCash conventions.

For information on another QOF application called "estron" - an idea for a data-driven query interface - see http://estron.alioth.debian.org/. Problem 1 with estron: the examples all rely on postgres and I just can't get that to setup properly as either a test system or as a Debian package. Problem 2: estron was intended to be an interpreter that could be written "in itself" but whilst this is possible for the simpler examples, doing more complicated stuff like calculating values from other values makes the estron XML very obtuse. The current codebase uses GOB2 to

QOF is now stable and I don't expect to need another SONAME bump for quite a while. If anyone is interested in taking on estron or helping with the Cash and/or Invoice frontends, let me know. The problem with estron currently is bitrot - the GTK+ frontend has too many gtk1.2 hangovers which now fail to build.

I'm adopting svn-buildpackage and I've made a few commits via collab-maint already. So #528733 is now mine.

I expect to be working with Jan and anyone else who wants to work on the svn-inject and svn-upgrade functionality that I don't use personally. For this reason, I've re-opened #377467 as an RFH.

I use svn-bp for a lot of my own packages and I'm not going to use git if I can possibly avoid it (quite possibly, ever). The current collab-maint changelog is already long enough so I won't be making many changes prior to the first upload to close the ITA. However, once that is done, I'll be looking at Jan's 0.7 branch code and gradually working through the rest of the bugs.

It's not as if I have a huge amount of time available for svn-bp, so things will take time, but it can't stay orphaned.