Codehelp blog

I've written a simple perl script using SOAP to add some useful data to the RC bug list (or any list of bugs). It can easily be extended but right now it supports simple things like the date the bug was filed, short description of the package, the name of the maintainer, the most recent upload data, the debtags for the package, apt-cache policy data and whether the bug is already tagged pending.
Zenity presents this info in a question dialog, clicking OK loads the bug and the PTS in your browser using 'sensible-browser'.
Clicking cancel offers a new zenity dialog asking for the next bug number. (Click Cancel there to end the script.)
Code: http://linux.codehelp.co.uk/rc-zenity.pl (GPLv3 or later)
POD: http://linux.codehelp.co.uk/rc-zenity.html (easily convertible into a manpage using pod2man)
If you like it, use it.
If lots of people like it, maybe it can go into an existing package.
If I've duplicated another script that I just didn't know about, tell me.

It's not exclusively for RC bugs, it could work with any bug list or be modified to only look for particular severity settings.
Thanks to Don Armstrong for making debbugs so accessible using SOAP. The debbugs SOAP implementation is just so straightforward with a whole load of useful data returned without needing repeated queries, it makes scripts like this really satisfying.

Steve's docs on keys on a USB stick needed a few tweaks for my own systems - first thing I noticed was that I had /dev/loop0 instead of /dev/loop/0. As my configuration needs to use an SDcard instead of a USB stick or pen, I've changed the references from 'pen' to 'card'.
SDcards on my systems come out on /dev/mmcblk0 with partitions having a 'p[0-9]' suffix (p1, p2 etc.) so the DEVBASE setting needed a tweak. (This line needs to be modified for each user case anyway because the size of the partition will vary so the '62390272' value needs to be modified.)
DEVBASE=`fdisk -l /dev/mmcblk0 2>/dev/null | grep ^Disk.*62390272\ bytes | sed 's?^.*/d?/d?g;s?:.*$??g'`
A few other notes for those using Sid instead of Etch:

1. kernel module needed: loop-aes-modules-2.6.26-1 - getting the modules to load requires a reboot.


2. loop-aes-utils the actual package that provides the diverted mount binaries, instead of just "loop-aes"

Barring a few typos I made in transcribing, the rest of the documentation works fine.

Alternative keys

I have two keys, one is intended to remain on the laptop and has comments to that effect (0xA897FD02). The other key, (0x28BCB3E3), is my Debian upload key so needs to be protected a little more than the ordinary laptop key (which I'll use when signing email on the laptop).
'debsign' does not have a way to specify a different --homedir or secret keyring or any other option that would allow me to have an alternative gpg configuration (maybe it should?). So I've copied debsign into my home scripts directory to create a slightly modified version and then I followed Steve's advice for ~/.gnupg/ to create a duplicate directory with the same permissions and a much reduced public keyring file (just exported my own keys). The secring.gpg file for this alternative homedir is the on the SD card with the autofs symlink (so the only file on the encrypted SDCard is the secret keyring).
Then it is a simple case of manually calling debsign (e.g. after using debuild -uc -us):
~/scripts/debsign -k0x28bcb3e3 /path/to/.changes

+CARD=" --no-default-keyring --homedir=/home/neil/.gcard "

...

-                   $signcommand --local-user "$2" --clearsign \

+                   $signcommand $CARD --local-user "$2" --clearsign \

...

-                   $signcommand --local-user "$2" --clearsign \

+                   $signcommand $CARD --local-user "$2" --clearsign \

...

-       $signcommand -u "$2" +clearsig=on -fast < "$1" > "$ASCII_SIGNED_FILE"

+       $signcommand $CARD -u "$2" +clearsig=on -fast < "$1" > "$ASCII_SIGNED_FILE"

po4a

- or PO for anything. PO is the de facto standard for translations and po4a tries to help maintainers prepare packages for translation.

1. I18n (internationalisation) is making a package accessible for translators and is an upstream/maintainer action. i18n is done once for all translation support and updated when the content changes (typically during the build).


2. l10n (localisation) is using i18n support to create an individual translation for a specific locale. l10n is done many times per package, with individual translations being updated each time the i18n content changes. (Tdebs will support this area but are a separate topic from po4a.) PO files that exist when the POT is updated are also updated, tagging modified strings as "fuzzy".

The natural burden, therefore, falls within l10n but without i18n, l10n is all but impossible (it means having to do the i18n "outside" the package).
I'm using po4a and I've been doing various translation-support stuff now for a few years, so I'm going to add po4a into my blog entries as a series to help maintainers make their own packages i18n aware.
This is particularly important for:

1. all Debian native packages, particularly scripted packages. My example will be based on perlpod documentation often embedded wthin the perl scripts themselves as well as DocBook XML for manpage generation. po4a supports many other formats.


2. All manpages (or other documentation) created by Debian maintainers

To make things easier, I'll be creating a new category in my blog ("i18n") for such entries. This is helpful for me too because the first time I used po4a (current versions of emdebian-tools) I basically got things wrong and made more work for myself than was necessary. This entry primarily concerns providing i18n support from manpage sources and perl scripts. i18n support in compiled packages is a separate issue. The fixes described here will be included in the next version of emdebian-tools (which will be uploaded to Emdebian but not into Debian until after Lenny).

Terminology

• PO - (Portable Object) files contain the POSIX C locale strings abstracted from the "master document" which in many cases is the source file in the relevant package(s), alongside the translated version of that string (if any). Multiple master documents are typically combined into a single collection of translatable strings. PO files are translated into individual locales, one PO file per locale.


• POT - PO Template - the definitive collection of translatable strings from which all PO files are prepared and updated. The POT file is never translated directly, it is maintained, updated and packaged by the maintainer.


• gettext - the binary application that handles the translatable strings. gettext abstracts the strings out of the source files during the package build and inserts the translated strings back into the text actually displayed to the user at runtime. If no suitable PO file exists, the user gets the untranslated string, exactly as it appears in the POT file. If a suitable PO file does exist but the strings have been modified since translation, gettext drops "fuzzy" translations that do not match precisely and the user gets a "mixed" translation containing some translated strings and some untranslated. Most translators try to maintain a 100% translation because the ugliness of the "mixed" output is a partial incentive to keep up with the updates.

Using po4a

po4a needs a config file where the maintainer keeps all metadata relating to the master documents and the relevant formats. po4a then converts the master documents into a collection of strings for translation and puts those strings into a POT file (a PO template file). The maintainer packages the POT file (and optionally sends the POT file to relevant mailing lists seeking translations to be returned as PO files) and keeps the POT file up to date during the build process. With a config file (e.g. called po4a.config), all the maintainer needs to do is call:

po4a po4a.config

po4a then parses the list of files defined in the config file, generates the lists of strings, collates the lists and identifies where the same string is used in multiple files and writes out a POT file containing references to where the strings are used and the unique strings.

po4a config file

Comments start with '#' in the usual way. Instructions are enclosed in square brackets.
po4a_paths defines where the POT file will be put (it can be extended later but I'm keeping this simple). The name of the POT file is important for compiled packages but can just be the name of the source package for scripted packages and/or manpages.

[po4a_paths] po/emdebian-tools.pot

type identifies *each* master document to be processed by po4a. The syntax is well suited to being generated from some other list within the package but I'll give just a snippet of the final output here:

[type: xml] doc/xml/em_autobuild.1.xml

[type: xml] doc/xml/embug.1.xml

[type: pod] emtargetcmp

[type: pod] emdebcheck

That's it. The complexity of my current script was entirely unnecessary.

Also, po4a is more than capable of handling multiple document types within the same source package and the same POT file which is something that I had missed so far. One more hack that can be removed.

All I do now is use xmllint to "clean-up" the DocBook XML and pod2html and some XSLT to generate HTML documentation for the website. The loops to do those tasks already contain the list of files to be processed by po4a, so a few echo commands is all that is needed to create po4a.config at build time and run po4a to generate a combined POT file for all strings in the package.

#!/bin/sh

CONFIG="po4a.config"

echo "[po4a_paths] po/emdebian-tools.pot" > $CONFIG

for file in `ls doc/xml/*.xml`; do

	xmllint --format "$file" --output "$file"

	echo "[type:xml] $file" >> $CONFIG

done

for file in emdebcheck emtargetcmp emprunecross Emdebian/Tools.pm \

 em_installtdeb emrecent emcache; do

	if [ "$file" = "Emdebian/Tools.pm" ]; then

		pod2html -outfile html/EmdebianTools.html -title $file < ../$file

	else

		pod2html -outfile html/$file.html -title $file < ../$file

	fi

	if [ "$file" = "Emdebian/Tools.pm" ]; then

		pod2man ../$file > man/Emdebian::Tools.3

	else

		pod2man ../$file > man/$file.1

	fi

	echo "[type: pod] $file" >> $CONFIG

done

po4a $CONFIG

First complete day after a full day travelling and I'm just about over the jet lag. Progress so far:

• Restored the previous Gtk+ build configuration - without directfb and therefore without the udeb. Persistent problems resolving symbols in libcairo-directfb (in libcairo.so) due to the presence of libcairo itself (also libcairo.so) mean that the directfb code simply cannot cross-build at the moment. A possible solution might be to rename the library in libcairo-directfb-$arch-cross but that isn't necessarily correct.


• Further reductions in the number of packages that fail to cross-build in a clean cross-building chroot. Down to just 3 that do not cross-build (added code to ignore obsolete builds like gcc-4.2 which have been superceded in Debian). A few network issues have delayed uploads and sync with www.emdebian.org but those should be resolved in time.


• Fixed a loose wire in the balloon board that was causing intermittent loss of serial connection - thanks to Phil Hands and Wookey.


• Resolved the chpasswd problem in busybox thanks to a fix upstream by Bernhard Fischer - removing the last hurdle to clean root filesystem installation in Emdebian. I'm currently working on busybox 1.11.1 to both test the fix and prepare the Emdebian patches for the pending upgrade in Debian. I do have an updated Emdebian build for 1.11.1 which I'll be testing later.


• Looked at the possibility of including nbd into Emdebian - it cross-builds OK but the maintainer scripts rely on bash which is simply not available in Emdebian. Wouter is working on a fix, hopefully ready sometime after Lenny.


• Taken a look at freeswitch (not in Debian) but problems in the internal libraries are preventing a successful cross-build - despite the (incomplete) summary on the freeswitch wiki page. Not sure how much more time to spend on this one.


• Various improvements in emdebian-tools - 1.4.1 is now in Lenny and these fixes will be uploaded to Emdebian. Depending on a few discussions here at DebConf, I am likely to make one more upload to Debian, possibly only as a debconf translation update.


• Continuing discussions about TDebs - more details to be sorted out during DebConf itself in one or more of the 4 debian i18n sessions.

Overall, very good.
(Posting delayed due to network problems.)

It appears that drivel cannot cope with posting to the blog from DebConf.