Codehelp blog

Further to problems with
gettext and split po files, glib_gettextize turns out not to be usable with more than one po/ directory. I've just converted gpe-expenses to multiple POT files (for the same reasons as gpe-cash) and I'm due to make the upstream release and upload later. glib_gettextize needs to be replaced by gettextize but this is not problem free. gettextize is noisy and keeps tampering with my build, putting in things like config.rpath and forcing -I m4 additions when that is already included elsewhere. So ./autogen.sh now supports gettextize but stops it running twice. I'm storing the gettextize support files in CVS just to allow the post-gettextize environment to be retained without needing to deal with the aftermath of gettextize --force.
Also, one tweak is needed to the Makevars file in the new directory - change the subdir po location to po-lib or whatever you use.
The changes will show up in gpe-expenses CVS later.

I've been struggling with gettext most of the day but I've finally got the solution! gpe-cash builds an application and a shared library (with API, -dev, -dbg and -doc). Source files for the application contain translatable strings, as do source files for the shared library. Unable to find documentation for how this should work with gettext, I got no end of path related errors.
Here's the clue: Keep ./po/ for the $PACKAGE.pot file, add ./po-foo/ for the second POT file. My mistake was to try to use po/ and src/po or src/po and src/foo/po.
Then, remove the symlinked Makefile.in.in from po-foo/ and copy the file from po/ so that the po-foo/Makefile.in.in can be edited to change the value of GETTEXT_PACKAGE to the alternate file.
Then, add the LINGUAS file to each po directory.
Add po-foo/ to the configure.ac output.
I also switched from glib_gettextize to gettextize (switching the configure.ac macros at the same time). I'm not sure if this is strictly necessary (and it added quite a lot of stuff to both po/ directories) but I'm not keen on breaking what I've just spent all day fixing!

Committed to cashutil SVN: r619.

I've only taken a quick look at the quilt documentation but the
following thoughts occur to me:

1. emsource / emdebuild are similar to quilt and in some ways, I have
   reimplemented a subset of quilt in these scripts.


2. emsource handles 'quilt add' provided that changes are confined to
   files in debian/ (including new patches added to debian/patches).
   However, I was unable to find out how quilt handles unchanged files.
   e.g. emdebuild skips creating the patch if the diff is empty - does
   quilt do the same for files that have been added?


3. quilt is targetted at "upstream builds" and it will require various
   config settings to get quilt to both keep patches outside the package
   source directory AND handle situations where the package itself uses
   quilt with a different series of patches. emsource and emdebuild are
   completely separate from any existing patch method.


4. quilt does NOT make autobuilding emdebian packages easier. Conflicts
   are meant to be resolved by hand (e.g. emdebian-changelog.patch). A
   bespoke method can embed specific logic on handling such issues that a
   general method like quilt cannot.


5. quilt could be *almost* as transparent as the current method (which
   hides nearly all patch management within emsource and emdebuild) but
   would still require a wrapper to add support for keeping the patches in
   SVN.

Hmm. Think I'll stick for now. You can have too many nested tools.

Many thanks to Moray for uploading the required library updates for this - gpe-calendar RC bug is finally fixed in a new upstream version and dependencies: 0.90-1 which I have just uploaded to incoming.

v0.90 is a substantial rewrite from 0.72 and has much better memory handling.

More than a year after gnucash upstream made the transition from glib1 to glib2, Debian has finally been able to do the same with the binaries. Problems in g-wrap and gnucash had led to libglib1.2 remaining as part of the dependency chain of gnucash as well as libglib2.0-0 (build-deps and runtime).

NMU's of g-wrap and gnucash have finally removed the last vestiges of libglib1.2 from my systems. Yippee!

My Overview showing the incoming packages which will migrate into the NMU section in due course.

g-wrap

gnucash

Made some progress with gpe-cash today - fixing compiler warnings, stripping out yet more source code and fixing the debian packaging. It does build from SVN but it needs libqof1 >= 0.7.3 which is an unreleased version from QOF CVS.

gpe-cash.

It's now down to < 1Mb installed binaries with less than 500kb of additional libraries (liqof1, libsqlite) compared to a basic Gtk installation. It may creep up to 2Mb all-in by the time the rest of the Gtk code is complete but an Emdebian build should be able to cut that back towards 1.5Mb or so, installed, by dropping the docs. The SQLite backend is fully functional and the default backend. An optional libxml2 backend adds libxml2 and bumps the size requirements substantially but is worth using on the desktop as it adds support for a command-line mode that combines SQL-type queries with XML results. (Eventual plan is to rsync the sqlite from the handheld and use XSL to generate reports etc.) Still a lot smaller than any other double-entry financial package I can find and with none of the dependency problems of the original GnuCash, despite using the same objects. Managed to remove the need for GConf too which is quite handy for an embedded application.

gpe-cash will be my first GPL3 upstream - all the code I'm forking from GnuCash is GPLv2 or later, as is QOF, and GPL3 code can be linked against the LGPL2 or later libgpewidget so I'm making the new Gtk frontend GPL3 or later and I will eventualy release the whole thing under the GPL3 "or later". Thanks to Joe Smith and Anthony W. Youngman for their help with all that. I had it nearly right, just tweaked debian/copyright a bit.

Actually spent a fair bit of time migrating my upstream projects to Anjuta2 and getting used to the new interface. It is a bit twiddly at times and one or two bits are annoying (bit too much eye candy for my liking - repetition of labels and buttons) but overall it's a lot better than when v2 was first uploaded. The integral DevHelp window is handy. I'm still waiting for the svn plugin though and I've no idea what is going wrong with the anjuta manual. It is being installed and yelp can load it when passed the URL directly but I can't get it to show in the normal Gnome Help browser lists - only the man pages show.

I've generated a springgraph of the DebConf7 keysigning keyring after refreshing the keys today. Thumbnails are available now. Click the thumbnail to see the full image. I've tried to correlate the thumbnails so that the overall area is similar.

For some reason, the images don't show via my blog.

For comparison, the springgraph before DebConf:

http://gnupg.neil.williamsleesmill.me.uk/ksp-spring.png
(The main image is much larger - may be best to wget it and view it locally.)


http://gnupg.neil.williamsleesmill.me.uk/ksp-spring-thumb.png

The change after DebConf:

http://gnupg.neil.williamsleesmill.me.uk/afterksp.png

http://gnupg.neil.williamsleesmill.me.uk/afterksp-thumb.png

(a much smaller final image).