Codehelp blog

As well as choosing a licence, various other non-code or pseudo-code tasks are needed in all upstream projects and I have been working on some of these in my upstream project, estron.

1. Documentation - Quietly converting the old docs (XML comments) into SGML (docbook content) for use with yelp. Comments have no particular structure so it takes time to add docbook structure to what was just a block of arbitrary text in comment tags.


2. MIME - Not sure if I've got this right still - I don't see the icon for .estron files and I get a warning when trying to double-click on an "Estron file" (the file type is recognised but gets confused with the XML inside). I'm following code samples from grisbi and drivel to try and get things together.


3. configuration support - estron will use dbconfig-common in Debian for the internal estron database but I need to set upstream to be able to read in the data created by dbconfig in a non-Debian-only manner, probably using GIO to provide configuration that can include a filename of external config data.


4. cross build support - a few quibbles in that area but I'll sort them before release. Can help catch architecture-specific problems in the code that would cause a FTBFS on the Debian buildd system.

Other tasks already covered:

• make distcheck - important upstream test that simplifies the process of packaging for Debian by ensuring that the distributed tarball really does contain the necessary files and in the right places.


• translation support - one little task left for that one, ensuring that applications written in estron support independent translation. Support is in place but not ready for a string freeze at this time.


• API documentation - doxygen.


• Wiki - ikiwiki


• Mailing list - alioth


• Access to source code - alioth/debian.


• Bug trackers - for upstream, alioth.

I have actually been doing some code too - in QOF due to a bug identified by testing and developing estron and in estron itself to bring 64bit time handling to estron and prevent time overflows in 2038 should you use estron on 32bit machines.

Grisbi is now
available in Emdebian but without libofx. Similarly homebank is in Emdebian (note that homebank-data is also needed and is available), again without libofx.

I'm not convinced that libofx is that much of a loss on an embedded device - especially when libofx and dependencies could add 5Mb to an existing installation - just for the shared libraries!

The screenshots of Grisbi in Maemo gave my the idea of adding grisbi and I've been trying it out on the desktop too. Once I'd tweaked the column widths for the transaction window (hidden away in Preferences), it is quite usable - although I can't see any way of it handling invoices.

My own gpe-cash is not making much progress - the GnuCash objects are just too resistant to use outside GnuCash. It may be easier to create invoices from grisbi/homebank data via CSV and estron.

This is aimed at the more powerful end of Emdebian devices but each package is still 50% smaller in Emdebian than in Debian, closer to 80% smaller if you count the reduced dependencies. The main difference is the use of TDebs.

Christian Perrier and I are planning on working on TDebs during DebConf8 and Extremadura so that bugs and fixes to support TDebs can be implemented in Debian as soon as Lenny is released. Removing translations from the maintainer uploads and translation bugs from the package BTS should make it a lot easier to update translations without requiring an NMU of the entire package (which is complete overkill IMNSHO).

Together with DEB_BUILD_OPTIONS="nodocs" support, TDebs are the simplest way to reduce package sizes and installation sizes in Debian/Emdebian.

(I just wish #448615 could be fixed so that I could get on with preparing patches for packages that install docs without using debhelper.)

Romain, you might just want to check 471263 where there is disagreement over how this lintian test should or should not behave towards generated files. In particular, if a package contains a patch in debian/patches that causes upstream files to be modified indirectly (e.g. because upstream is old / quiet and hasn't updated the autotools stuff for years, any patch that affects Makefile.am or configure.in|ac is going to cause changes in generated files and these changes should not be wrapped into yet more patch files because of the inevitable build failures when any of the tools used to generate those files are updated.

Your stats may also be out because of this problem - it is hard to see how lintian can resolve the problem cleanly without carrying a long list of "possibly generated files" and risking the list going stale.

There is more to the contents of .diff.gz than may meet the eye.

Ooops. When a room full of computer equipment gains a strong smell, there are a couple of possibilities (!) but the characteristic odour of singed electronics and lack of video output on one box is fairly indicative and all I could do was turn off the power on the UPS.

Definite smell associated with one box, smell gets worse when that box opened up, smell seems concentrated around the graphics card. Most weird is that the computer affected seems to restart ok at which point the smell reappears so knock the power off again - fast. Smell stays with the graphics card when card removed - it's surprising how long that smell hangs around. Remove graphics card, retest the machine - hang on - this sounds like a normal boot. Hmm - plugin the network cable, bingo - everything else appears to work - sans smell. Graphics card still has a strong odour even just sitting on the desk.

I've just suffered a graphics card burn out. Damn damn and double damn.

The machine itself is now running fine, just without a graphics card and thereby monitor. Accessing via ssh, dmesg shows the inevitable fsck but no other signs of harm except:
$ ps af
PID TTY STAT TIME COMMAND
3388 pts/0 Ss 0:00 -bash
3410 pts/0 R+ 0:00 \_ ps af
3256 tty7 Ss+ 0:00 /bin/sh /etc/gdm/XKeepsCrashing -noopen
3297 tty7 S+ 0:00 \_ /usr/bin/dialog --yesno Failed to start the X ser

$ sudo invoke-rc.d gdm stop



Why would an archive rebuild cause a graphics card to burn out? (I was running an autobuilder script but I don't run any screensaver on that box.)

Ah well, gives me an excuse to test the whiptail mode of emrecent and see if I can upload the packages that were built before the failure to Emdebian target. Another unexpected expense - 2008 is getting expensive!

After months battling with the reverse cross build of gcc-4.3 to provide libgcc1 (1:4.3.0-3em1) {arm}, it's finally been uploaded, lintian clean. (emdebian-tools (>= 1.0.0) provides cross-building support in lintian.)

To handle this transition, previous Emdebian target packages have been migrated to Emdebian testing (the first time the target repository has had any testing packages) - the packages in testing are usable but the
perl 5.10 transition means that the root filesystem itself cannot be built from either set of packages. I'm taking advantage of this situation to allow temporary breakage of Emdebian-Target unstable as there are so many packages to be updated. I've now got a busy Bank Holiday uploading as many updated packages as possible, improving the emdebian-tools autobuilder em_autobuild, leading to the release of emdebian-tools 1.1.0.

Once done, I want to start preparing emdebian-tools 1.2.0 with a few 1.1.x releases aimed at extending autobuilder support to armel and i386 (i.e. native).

As part of the upload, I've also been able to fix the locale upload support and architecture-dependent TDebs are now available. See also http://www.emdebian.org/emdebian/langupdate.html and the locale search page.