A Debian package is uniquely identified by its name and version; there is no further information taken into account by dpkg. This keeps the packaging system rather simple, but has the disadvantage that all information that would otherwise be placed in extra data fields has to be encoded into these two fields. As the names of all binary packages generated from a single source package need to be known when building the .dsc file, no substitutions are allowed in the package name. Back in the Good Old Days, the only extra bit of information in the name field used to be the SONAME from the library in the package (thus implicitly saying that each library should have its own package), which meant that the maintainer had to adapt the debian/control file every time a library's ABI changed. This being the Good Old Days, people writing libraries actually thought about things, so ABI changes were few and far between. These days, libraries are stacked on top of each other, re-exporting the underlying libraries' ABI. The SONAME system could in theory handle these situations if the SONAME of every library whose ABI is re-exported is encoded into the SONAME of the newly built library. So if my own ABI version is "2", and some of the functions I export use types defined in glib, then after building against glib1.2, my SONAME would be somewhat similar to "2+glib1.2". For languages that don't have a well-defined ABI (i.e. anything but C), the version of the language ABI(s) used will also have to be added. Obviously, this would also have to be encoded into the package name, which is where trouble starts during transitions. The last C++ ABI transition had all C++ library maintainers add a suffix to the package name; dependent ABIs are not handled at all in Debian right now (which led to the libpng mess). The existing encoding rules are not entirely formalized, and it is not guaranteed that they are bijective. For example, packages used together with cross compilers have been following the convention of using the name that the native package would use, followed by a dash, the target architecture name, another dash and the word "cross". There is no guarantee that the architecture name does not contain a dash, however, so we cannot simply take the second to last word as the architecture name if the last word is "cross" (think "libgcc1-kfreebsd-i386-cross"), which makes it difficult to write a plug-in to apt that would automatically download the binary for the target architecture and convert it using dpkg-cross. I've decided to nonetheless go ahead with my request that the "-*-cross" part of the package name space be reserved for packages related to cross compilation; it will work for the time being.

Emdebian SVN r2618 includes my first working implementation of em_installtdeb. Barring a single annoyance message from dpkg, the script works.
The warning arises from the need for a modified "source" tarball that can be uploaded alongside the .deb, containing only the sources needed for this specific translation: debian/control, debian/changelog, po/$lang.po /* if any */ and po/$GETTEXT_PACKAGE.pot. Where a package contains more than one po directory, all POT files are included and all po files for the requested translation. This allows translations to be updated independently of the upstream package.
I would advise using a test directory if you do want to try it, not your main package building directory.
Output (using gpe-expenses as the demo package) in translator mode:

$ em_installtdeb sv
dpkg-deb: building package gpe-expenses-locale-sv' in ../gpe-expenses-locale-sv_0.1.4-1_all.deb'.
dpkg-source: warning: .orig.tar name gpe-expenses_0.1.4.tdeb.tar.gz is not _.orig.tar (wanted gpe-expenses_0.1.4.orig.tar.(?:gz bz2 lzma))
dpkg-source: building gpe-expenses using existing gpe-expenses_0.1.4.tdeb.tar.gz
dpkg-source: building gpe-expenses in gpe-expenses_0.1.4-1.diff.gz
dpkg-source: building gpe-expenses in gpe-expenses_0.1.4-1.dsc
dpkg-genchanges: including full source code in upload
Format: 1.7
Date: Fri, 07 Dec 2007 00:08:39 +0000
Source: gpe-expenses
Binary: gpe-expenses-locale-sv
Architecture: source all
Version: 0.1.4-1
Distribution: unstable
Urgency: low
Maintainer: Neil Williams
Changed-By: Neil Williams
Description:
gpe-expenses-locale-sv - sv translation for gpe-expenses
Changes:
gpe-expenses (0.1.4-1) unstable; urgency=low
.
* New upstream release
* use machine operable debian/copyright, migrate to standards 3.7.3
Files:
781a60eccc4396ee3f0f86a01150e755 316 misc extra gpe-expenses_0.1.4-1.dsc
f9dd946db27ff6077f8e85f7100d3ea4 5863 misc extra gpe-expenses_0.1.4.tdeb.tar.gz
894f5789ee0348abfa61a5e7342ed6a7 20 misc extra gpe-expenses_0.1.4-1.diff.gz
56f8d22c30cb5502633ff4d26862db78 4532 misc extra gpe-expenses-locale-sv_0.1.4-1_all.deb
Package-Type: tdeb
Changes file: ../gpe-expenses_0.1.4-1_tdeb.changes
signfile ../gpe-expenses_0.1.4-1.dsc 0x28BCB3E3

You need a passphrase to unlock the secret key for
user: "Neil Williams (Debian) "
1024-bit DSA key, ID 28BCB3E3, created 2002-01-27


signfile ../gpe-expenses_0.1.4-1_tdeb.changes 0x28BCB3E3

You need a passphrase to unlock the secret key for
user: "Neil Williams (Debian) "
1024-bit DSA key, ID 28BCB3E3, created 2002-01-27


Successfully signed dsc and changes files
neil@holly:gpe-expenses$ dpkg -c ../gpe-expenses-locale-sv_0.1.4-1_all.deb
drwxr-xr-x neil/neil 0 2007-12-19 14:37 ./
drwxr-xr-x neil/neil 0 2007-12-19 14:37 ./usr/
drwxr-xr-x neil/neil 0 2007-12-19 14:37 ./usr/share/
drwxr-xr-x neil/neil 0 2007-12-19 14:37 ./usr/share/locale/
drwxr-xr-x neil/neil 0 2007-12-19 14:37 ./usr/share/locale/sv/
drwxr-xr-x neil/neil 0 2007-12-19 16:09 ./usr/share/locale/sv/LC_MESSAGES/
-rw-r--r-- neil/neil 6419 2007-12-19 16:09 ./usr/share/locale/sv/LC_MESSAGES/gpe-expenses.mo
-rw-r--r-- neil/neil 1796 2007-12-19 16:09 ./usr/share/locale/sv/LC_MESSAGES/qofexpensesobjects.mo

Hmm, that isn't right - need to check on the ownership of those files - might be enough to use fakeroot.

$ dpkg -I ../gpe-expenses-locale-sv_0.1.4-1_all.deb
new debian package, version 2.0.
size 4532 bytes: control archive= 302 bytes.
230 bytes, 9 lines control
Package: gpe-expenses-locale-sv
Source: gpe-expenses
Version: 0.1.4-1
Architecture: all
Maintainer: Neil Williams
Installed-Size: 44
Section: misc
Priority: extra
Description: sv translation for gpe-expenses


em_installtdeb is a debhelper add-on created by Emdebian to create translation packages (tdebs). em_installtdeb is intended to separate out the individual translation files from the current Debian packages into packages without any translation files and a series of tdeb locale packages, one per translation. Generated packages use the syntax: $package-locale-$language_code_$version_all.deb
Certain language codes need to be modified to make acceptable components of a debian package name. Underscores are converted to hyphens, '\@' is converted to '+' and all codes are made lowercase. These changes only apply to the package name, the installation location is unchanged.
The locale package must use GETTEXT_PACKAGE for the eventual filename of the binary translation file - not the $dh MAINPACKAGE . GETTEXT_PACKAGE is determined by upstream, not Debian. When building the whole package, the binary translation file may be in debian/tmp/usr/share/locale/$lang/LC_MESSAGES but when in translator mode, this location is not available. Instead retrieve GETTEXT_PACKAGE from the POT filename. debian/control is needed for various dpkg and debhelper calls only.

The "source" for translators therefore includes:
debian/control
debian/changelog
po/$lang.po /* if any */
po/$GETTEXT_PACKAGE.pot

Note that no rules file exists. (i.e. dpkg-source -x will complain when trying to extract it later so a new wrapper is needed (not difficult).)
em_installtdeb will try to generate the necessary POT file(s) and then create a $package_$version_tdeb.tar.gz containing the source files.
The default action is to process all available po files.
The above example uses translator mode where LANG_CODE is passed to only handle that language. In translator mode, em_installtdeb builds a tdeb package, a source tarball, a .dsc and a .changes file (and signs the .dsc and .changes). In default mode, em_installtdeb builds the package(s) but leaves the source, .dsc and .changes to the rest of the build process.
LANG_CODE can either be the name of the locale as specified in the PO filename (fr, en_GB, sr@Ltn etc.) or the name of the locale as specified in the eventual package name (fr, en-gb, sr+ltn etc.).
If a po file already exists for this locale, em_installtdeb processes just that one translation and builds a single tdeb package.
If the po file does not exist, em_installtdeb exits with an error. (Copy the POT file from the original source to create a new po file for the new locale and edit it to include the new translation, then run em_installtdeb again.)

Output in default mode:
$ em_installtdeb
dpkg-deb: building package gpe-expenses-locale-cs' in ../gpe-expenses-locale-cs_0.1.4-1_all.deb'.
dpkg-deb: building package gpe-expenses-locale-de' in ../gpe-expenses-locale-de_0.1.4-1_all.deb'.
dpkg-deb: building package gpe-expenses-locale-pt' in ../gpe-expenses-locale-pt_0.1.4-1_all.deb'.
dpkg-deb: building package gpe-expenses-locale-sv' in ../gpe-expenses-locale-sv_0.1.4-1_all.deb'.
dpkg-deb: building package gpe-expenses-locale-vi' in ../gpe-expenses-locale-vi_0.1.4-1_all.deb'.

Next stage is to fold this into emdebian-tools so that the emdebian patch files can be cleaned up and various complex patches to debian/rules can also be cleaned up.
Finally, note that this only supports gettext and only supports program translations. This is an Emdebian script written with an eye on usage in Debian but primarily intended to meet Emdebian requirements. As outlined before, Emdebian does not want language packs or translation grouping. One locale, one package.
See also langupdate in Emdebian SVN.

Credit for finding out how to do this goes to dims, who has been doing lots of cool Android hacking lately: http://davanum.wordpress.com/2007/12/18/android-task-manager-primitive-prototype/ If you're interested in Android and what it can do, you should be following his online journal! As a way to keep pushing and testing Hecl, I decided to see if I could copy what he'd done in Hecl. It has indeed produced a few improvements to the Java code. That done, making it work was short and sweet:

set layoutparams [linearlayoutparams -new  FILL_PARENT WRAP_CONTENT 
set layout [linearlayout -new $context]
$layout setorientation VERTICAL
# Create ourselves some commands to access Android internals.
java android.app.ActivityManagerNative activitymanagernative
java android.app.IActivityManager iactivitymanager
java  android.app.IActivityManager$TaskInfo  taskinfo
java android.content.ComponentName componentname
java java.util.List javalist
set am [activitymanagernative getdefault]
set tasks [$am gettasks 10 0 [null]]
set len [$tasks size]
set tasklist [list]
for  set i 0   < $i $len   incr $i   
    set baseactivity [[$tasks get $i] -field baseactivity]
    lappend $tasklist "Task: [$baseactivity getpackagename]"
 
$layout addview [textview -new $context -layoutparams $layoutparams \
         -text "Currently running tasks"]
set lview [basiclist $context $tasklist -layoutparams $layoutparams]
$layout addview $lview
$lview requestfocus
set callback [callback -new [list [list SelectTask]]]
$lview setonitemclicklistener $callback
heclcmd setcontentview $layout
proc SelectTask  parent view position id   
    [activitymanagernative getdefault] movetasktofront $position
 

It could have been squeezed further by avoiding some of the temporary variables, and perhaps also by implementing a mapping between java.util.List and Hecl lists. I think one of the next things I want to do is work on some infrastructure so that people will be able to actually work on scripts on their phone. That's sort of a departure from the past (most phone keyboards would be sheer torture for inputting long scripts), but it's a cool demo in any case.

Debian could use more manpower, but is it actually easy for new contributors who would like to help to do useful things, and get the impression that they actually improved Debian? There are several problems here:

• Find bugs that are not too hard to fix. I don’t know about your packages, but in mine, there are some bugs that are easy to fix, and it’s just a matter of finding the time. If someone provided a patch, I would be very happy and apply it or provide feedback as fast as possible.
• Find packages with active maintainers. It is no secret that if you choose the wrong package, your patch could very well sleep on the BTS for years.
• Find bugs that actually matter. It’s not strictly a requirement. But fixing bugs in packages that should probably be removed from Debian instead is not really rewarding.

I think that other projects are better than us at providing directions to newcomers. Gnome has the whole Gnome Love thing, for example. I’m thinking about building lists of “interesting” bugs. That would include RC bugs without patches, of course, but could also include a list of bugs based on an usertag that would mean “This bug is suitable for new contributors (it’s not too hard, and you could learn things fixing it). If you want to work on this bug, I’ll provide help and feedback and integrate your patch ASAP.” (This is very different from the “help” tag, which usually means “I couldn’t fix this, it’s too hard, I need help.“. It’s a bad idea to direct newcomers to bugs that are too hard for the package’s maintainer!) Additionally, a nice feature would be to be able to filter the list of bugs with the packages that the user has installed.

• What do you think?
• As someone willing to contribute to Debian, do you often find it hard to find stuff you could do?
• As a maintainer, do you have a lot of bugs that could use such a tag? Would you use it?

Comments are open, please us them ;)

After half day of playing with Wine, MinGW and friends, I managed to be able to automatically build Windows versions of both python-gammu and Wammu. However I do not have environment to actually test these versions (except for Wine), so I would really welcome if some Windows users could do some testing. I expect some strange crashes at beginning, but hopefully we will be able fix it to produce working Wammu version for Windows in future. You can get the installer here: http://tmp.cihar.com/wammu-0.26-setup.exe It's NOT final or stable version, but as the only changes which happened since last release were either minor or related to cross compilation, it should be equal to combination of Gammu 1.16.0, python-gammu 0.24 and Wammu 0.25, so don't be confused by versions. PS: Okay, when application works in Wine, it does not mean it will work in Windows, see bug report for details.

Yes, Bastian, there is a way to do what you want. I believe I told you from the very start: refactor reportbug and implement reportbug-ng on top of the existing code. But no, you chose to reimplement everything (a typical thing to do for GUI programmers) and now you are asking us maintainers to change the way we've been doing things for years? You also make presumptuous statements about how we deal with bug reports. If you personally hate how certain packages prepare bug reports, then maybe you should personally suck it up and use different software? Seems like a more logical and less intrusive way forward, then expecting others to "send a friendly mail" to ask for more information on a bug report. Maybe you have all the time in the world, but I don't. I can work on e.g. mdadm (which uses an interactive bug script) only on rare occasions, and then I'd rather fix and close bugs than to indulge in another iteration of bug submitter ping-pong. You are also personally annoyed by long pre-subject texts, which you doubt anyone reads? I don't even bother to challenge that, but let me say that pre-subject texts are there to prevent stupid bug reports, or bug reports filed in the wrong place, and to take load off the maintainer. So you chose to ignore them? Given the projected user-base of your tool, I'd say you should rather force people to read them by asking them to transcribe the text. If you don't want to pop up a terminal, well, why the heck didn't you integrate debconf properly, while reusing reportbug, and taking a step forward to provide a proper interface for bug scripts? Why do you even bother to whine about interface issues at this point? Feel free to take over my packages, which make use of interactive bug scripts. I see zero reason to change them, and I will not. NP: The Flower Kings: Paradox Hotel

Further to my musings on a debhelper-type script to handle tdebs, I'm considering two modes:

1. maintainer mode - the default. With no options, operate on all .po files in all identifiable gettext directories (if -d /^po.*/), creating absolutely minimal control data on-the-fly, installing the directories and the binary translation data (.gmo) and building the .deb for each translation (with nothing else in the package). Emdebian will use this mode when cross building.


2. translator mode - when passed the name of a translation locale (either in the gettext form, e.g. sr@Ltn, or the filename form, sr+ltn) only builds a package for that po file. Should be relatively simple to create upload wrappers that can handle single translations in a similar manner to current uploads from porters.

Likely that some kind of update tool is going to be needed to retrieve the updated translations from the locale repository and merge back into the upstream package - which in turn means some form of "translation source" in the repository (the po file as a gz maybe?). Need to keep the POT file somewhere as a source file too so that new translations can be created easily. Such a tool would also need to be distribution-neutral as upstream may not be using Debian at all. Likely to investigate linkage with the Translation Project on an opt-in basis. (Not all upstreams use TP).
I can see an apt-locale package in the offing . . . - get source, build a single tdeb for a new or updated translation, query the locale cache, partner to langupdate . . .
Still not convinced on the script name: em_installtdeb because this script also generates stuff and the 't' is almost hidden in the name. (Eventually, I'd seek inclusion into debhelper and change the prefix accordingly).
Also not sure how to handle the package version string - this isn't commonly in the POT file (and may often be wrong or apply to the upstream version) but some Debian-compatible versioning will be needed. May need a stump debian/changelog that is discarded during building and which is generated within maintainer mode - i.e. held in the tdeb source.
Yes, I know some of this diverges from the Debian TranslationDebs approach but this is done with good reasons:

1. Emdebian does not want more than just the translation binary files in the tdeb package.


2. To get a working implementation soon, Emdebian is doing without the .tdeb suffix and going with .deb


3. No dependencies at all


4. No "language packs" as Emdebian needs full control over individual translation files, not over mere collections of localisation support files.

Yesterday in the evening I uploaded MySQL 5.0.51-1 to Debian unstable. Unfortunately it took a bit longer to prepare the updated package than expected, mainly because 5.0.51 wasn't MySQL's best relase, and I had to backport and include some fixes from 5.0.52 and 5.0.54 to get it working (see the changelog for details). Then I had to wait a few more days until 5.0.45-5 got into testing before I could finally upload 5.0.51-1 to unstable.

The most important changes are:

• Testsuite is now enabled during build process, which requires some time, but it ensures that everything is fine with the build. I already found two gcc 4.2.x related bugs in 5.0.51 which were fixed before 5.0.51-1 was uploaded to Debian.
• Manpages re-added, MySQL AB has put them under the GPL so we could include them again after we had to remove them a few months ago.

Regarding the Community vs. Enterprise decision I had a discussion with Kaj Arn , Lenz Grimmer, Daniel Fischer and Monty Taylor on IRC last week and we decided to stay with the Community Edition in Debian for now, and see what the future will bring us.

As an alternative to those Christmas “round robin” letters, my mum likes to create a calendar to send to relatives. This year, I rewrote the original crufty PHP script in Python:

usage:  pdfcalendar [options]
 Generates a simple PDF calendar for the specified year, one page per month,
 optionally using images in the specified directory.
 To use images, use the --dir argument to specify a directory (or leave empty
 to use the current directory) with the structure:
      -- 01
          -- s6000001.jpg
      -- 02
          -- s6000002.jpg
         \-- s6000003.jpg
      -- 03
         \-- s6000004.jpg
     etc.
 Images will be included on the appropriate month's page. If multiple images
 for a month exist, they are tiled horizontally.
options:
  -h, --help            show this help message and exit
  -d DIR, --dir=DIR     Directory to source images (Default: '.')
  -y YEAR, --year=YEAR  Year of calendar (Default: next year)
  -o FILE, --output=FILE
                        Output file (Default: calendar.pdf)
  -q, --quiet           Don't print status messages to STDERR

GPL3+ source available in Git. Would love a patch that tiles images in a square if anyone has a spare moment.

I was considering importing my car to Switzerland. When I moved in 2002, I asked the customs office about the process and was told that I'd need to pay taxes and fees, so I postponed the import until Day Unknown. Today, a very friendly customs official told me that this is not true and that I could have imported my car duty-free if I had done so as part of my move. Slightly annoyed, I went on to discover what those duties would be today. I found out that there are seven different types of fees I'll have to pay, and tried to understand the reason for these fees:

1. To import a car, you need a form 11.010, downloadable from the Swiss Customs Office. Because each download causes extra work for the administrator, they charge a nominal fee of CHF 0.70 to get the PDF file.

2. I take that form to the customs office. There, the officials will assemble around the car and attempt to lift it. I don't know why they do that, but they charge you between CHF 12 and CHF 15 per 100kg of weight. I think it must be recompensation for the hard physical labour. Also, each customs official can lift 100kg, which explains those figures they seemed a bit arbitrary at first.

3. Next, they'll ask 4% of the estimated value of the car as a car tax. They do this because the value of a car is directly related to the area it covers, and since Switzerland is so small, you effectively have to buy a couple of square metres for the car. It's not quite as easy as that though: once I bought the area under my car, I have to move the car away, because I cannot park my car on the area I just bought. I have to buy parking space for that. If I don't want to buy a parking space, I have to keep the car moving. In order to keep the car moving I need to fork over CHF 40 per year for a permit to drive the car on Swiss highways.

4. Now, I pay 7.6% value-added tax. It makes no difference that the car isn't new, that I am not selling or buying it, nor that I have already paid 16% VAT in Germany when I bought it. Since I am about to "consume" the car in Switzerland, I have to pay consumer tax. Since I also consume the physical labour the officials put into the car lifting exercise, as well as the area under the car I bought, I pay VAT for (car value + lifting tax + area under car). Unfortunately, the European Union will not pay back the consumer tax I previously paid as part of the export, since I already consumed the car there.

5. I then get a report about the import. This costs CHF 20. I don't need this report, but I have to buy it. The reason is that the computer admins are so overworked serving PDF files to future importers that they have not had time to stop the computers from printing this report, and the special paper and toner used by all administrative offices in Switzerland costs about CHF 20 per page. An alternative explanation is that CHF 20 is the smallest bit of "money" in Switzerland, everything else is "change".

6. I will also have to pay annual taxes for possession of a car, the value to be determined by the custom officials. Since I already paid for the area under the car while moving and while stationary, I think the annual car tax is levied for environmental reasons. A lot of people drive through Switzerland to get from Germany to Italy or from Austria to France, pumping a lot of exhaust gas into the Swiss air. This makes them guilty, just like inhabitants of Switzerland who own a car are guilty. Due to legal reasons, the Swiss government can only punish Swiss people for those sins, so the annual car tax is a little higher to cover for all environmental damage. It is doubtful where the money goes, though. I also have to continue paying taxes in Germany, because I still have a residence with my parents.

7. Finally, I have to purchase a car insurance. That insurance does not insure the car, it insures the others on the road. Actually, it is a driver-car-dependent insurance, meaning that the others are insured only if I am the driver of my car. If I drive another car, or someone else drives my car, the others will not be insured. unless I pay higher insurance fees. Because cars with a larger area under them and those that require more people to lift them are more dangerous, the insurance fee is proportional to the car density. At least I can give up my German insurance and be covered by the Swiss insurance. However, I cannot keep my German insurance and be covered in Switzerland. I think this is because the head of customs department and the CEO of the insurance company have sex with each other.

It's been a great day, given how much I learnt. I finally understand why people have fought wars over taxes. I think I may leave the car in Germany. PS: Yes, this post may be considered hyperbole. NP: The Pineapple Thief: 8 Days Later

Since I received a terrifying amount of insults via mail for not implementing this feature request after my last blog entry, where I asked for help developing rng, I’d like to make my position about this issue clear. Why I was opposed to implement it:

1. I personally hated that some packages sent a huge amount of unrelated info with every bugreport for this package, even if it’s not meaningful for this bugreport. I made a quick check against my favorite package with a very long output and thought (and still think) that this info is not even relevant for the majority of bugreports of this package. So I thought it was not too much to ask, to write the reporter a friendly mail to post the output of this script, if it’s really needed.
2. I was personally very annoyed by packages with very long presubj text, which I doubt anyone reads anyway. Since I don’t want rng to be annoying to the users, I decided to leave that feature away. An implementation of this feature would mean to pop up a window with some text the user should read before continuing to report the bug. I don’t like popups and don’t want rng to make use of them.
3. I’m definitely opposed to a feature which will pop up a terminal where a user has to do something before he can proceed reporting a bug. Sorry, but this won’t happen in rng. I might consider such a thing if it could be scripted to use QT or even GTK but a terminal popping up in a GUI application is a no-go for me, sorry.
4. I was personally very annoyed by some of the reactions on this bugreport. Since we’re all volunteers and stuff and this feature is maybe a nice-to-have but definitely not a must-have, I decided to put this issue very low on my to do list.

However, I agree that the stuff in /usr/share/bug isn’t completely useless. The opposite is true, it makes the life of maintainers easier and rng should make use of it where possible. So what can we do now? Maybe we can start all over and discuss this issue in a more friendly and constructive way? Here’s my offer: rng will support bugscripts, but it will not feature a terminal popping up asking a user questions. I’m developing a GUI application and a popping up terminal is not very GUI’ish for me. What can we do about this? Is there a way to implement this? Supporting presubj might be okay too, but I don’t want rng to be annoying. Popups are annoying and having to read the same stuff again and again when reporting multiple times on the same package is annoying too. Maybe rng could spawn a pop up with a checkbox “Don’t show this text again when reporting a bug against this package”? Maybe we could have an option in the (not yet implemented) preferences window where we could suppress those messages completely? And please, don’t use abusive language or even insults when contacting me about this issue. My rng-time is currently very limited and my motivation to work especially on this issue is already very low. We’re speaking here about a fully optional feature. Providing the output of some scripts or having to read a presubj is helpful, but not mandatory when reporting a bug. So please, be nice! I really don’t need all that stress right now.

The blog has been quiet but I'm not.
Sometimes things happen in a flood but, in my life, that only happens after a prolonged period of thinking, planning, breaking, fixing, swearing and testing. Right now, I'm in one of those intervening periods when lots of things are just concepts and it also coincides with a period of more-than-usually stressful paid work. (Those who are familiar with healthcare will be aware of the national panic that ensues when things close down for just two days).
So what am I conceptualising?

• Emdebian tdeb implementation - including a new debhelper script to replace emlocale and do the actual package generation work instead of a complex shell script in debian/rules


• libgda3-3 migration for libqof1 which is being combined with better shlibdeps and cross build support in QOF itself - using QOF as a "test package" for all the other stuff I'm doing so that QOF cross builds with just:
  PKG_CONFIG_LIBDIR=/usr/arm-linux-gnu/lib/pkg-config dpkg-buildpackage -aarm (until dpkg includes the pkg-config setting when it will cross build with just d-bp -a)
  


• Emdebian autobuilder support for target packages


• Emdebian support for debian-xcontrol

I've got a few minor things to do in the meantime but expect another flurry of visible activity towards the end of the week.

Alpha Android Hecl I'm a little bit nervous about the idea, but I decided that I might as well release early, because for the foreseeable future, there's always going to be "one more feature" I could add. So, without further ado, I'm going to announce that I have a version of Hecl running on Android that has a access to a number of Android wigets. It is available here: http://www.hecl.org/Hecl.apk However: this is an alpha release, for those interested in hacking on it. If you are bothered by broken code, don't like to report bugs, don't want to think about how to improve it, complain loudly about missing features, then this code is not for you yet. Soon, I hope, it will be stable and useful for many more people, but for the moment, a lot of things are up in the air:

• Hecl's java reflection interaction code, which lets us interact with Android's API without writing wrappers for all of it, is very new. It was written specifically to facilitate the Android port. So it might change. For hackers, the opportunity is to be able to take part in shaping it.
• More work needs to go into the threading model. Wolfgang Kechel built a nice system of timers and events into Hecl, but work will be needed to make those play nicely with Android.
• More API coverage is needed. We have a number of the basic widgets, but more are needed.
• Storage is still something being worked on. I want to have a Hecl script Provider so that other applications can access Hecl scripts, as well as Hecl commands to access the various types of permanent storage that Android makes available.
• Phone features - we want to have callbacks and commands to deal with phone features like sms, phone calls, the camera, and so on.
• Needless to say, none of what currently exists is documented besides some comments in the code!

Of course... Hecl itself is a pretty cool language, I like to think, and the fact that it's interpreted means that you don't have to recompile anything, you just

1. Edit your script.
2. Replace the script in the zip file: zip -r bin/Hecl.apk res/raw/script.hcl
3. Load it up on the emulator: /opt/android_sdk_linux_m3-rc37a/tools/adb install bin/Hecl.apk

You can do other cool things too, like downloading bits of code over http and running them. Hecl @ Android Developer Challenge I hope that people interested in hacking on Hecl will do so because it's fun and interesting. Being an early adopter means you have a lot of influence in shaping the future of this programming language, and the API's to interact with Android (or Java ME if that's your thing). However, seeing as how Google has put together this contest: http://code.google.com/android/adc.html I have decided to submit the Android port of Hecl, and split the prize money, should we win any, with those who have contributed to Hecl. That includes any and all contributions to Hecl, whether or not it's directly related to Android or not. So, with documentation, Java code, Hecl code, tests, and even improvements to the web page as valid things, there's room for everyone to get involved. Of course, in order not to paint myself into a corner, I reserve the right to make final decisions about percentages, but it should be roughly equivalent to lines of code added, deleted or modified (yes, deleted counts too - if you make the project that much slimmer without sacrificing functionality, that's wonderful!). Also more than welcome are people who want to submit their own projects to the developer challenge based on Android. We make no claim to your winnings, and we'll be happy to give you a hand. Interested? Join the Hecl mailing list, that's where all our discussions take place: http://sourceforge.net/mailarchive/forum.php?forum_name=hecl-devel Hope to see you there!

I'm on a quest to remove spam from my inbox. I've been killing off GNU mailman lists where the -owners stuff was feeding me spam. Most of my spam now seems to be relayed from @ubuntu.com. Does anyone know if there's a similar solution to what @debian.org has where I can ask it to reply with a bounce saying "Here's my real email address, use that instead pls"?

I suppose I could just set my default email address in LP to something that will do it instead, but I'd rather avoid the WrathOfElmo(tm)

Why don't you replace it with a lioness?

I am sure some people will say I am missing something...

This political correctness has went too far once again.

Linux has already been the main OS here at the computer sciences for some time. The computer pool was just switched to Ubuntu, after having been on SuSE and OpenSuSE for the last 6 years or more. With the latest hardware upgrades, our computer lab is nicer than ever: dual-core AMD64 systems with 2.6 GHz, a couple of them with two LCD screens connected (which is great for developing, having the editor on one screen and documentation on the other). I wonder if the machines spend more than 1% of their time at full CPU speed - I havn't seen any running at more than the minimum 1 GHz.But one thing I've noticed, which has changed: even those people I can see in the lab having their own laptop with them have Linux running.A few years ago, most people bringing their laptops were doing so to have Windows around. Now with the nice dual-screen setups here, bringing along a laptop to have Linux is less attractive than ever. Still more people bringing their laptops run Linux anyway.I figure this means that they've noticed that the DEs a Linux system offers is very useful (granted, and more to what they have at the university when they don't have their laptop around. However the main part - Java and Eclipse - actually wouldn't differ). They still dual-boot (I overheard something about 'on Windows, this and that and foo) - and even accept the effort of dual-booting to get the Linux benefits.In a few years, will there still be Windows developers you can hire, when everybody studying computer science is being taught Linux? (Granted, not all universities have made the full switch to Linux for their computer sciences)P.S. I'm not involved with the computer admin group; for detailed inquiries you should talk to them directly. Especially for e.g. software distribution questions and such. Oh, and I heard that the servers were running Debian for some time already, while the clients were OpenSuSE. So maybe they still are Debian.

Ok guys. After spending several hours of this weekend to package the latest release of Norman Walshs DocBook: The Definitive Guide, I’m now proud to tell you: It’s done! I was able to build the package with a free Java engine (GIJ) so docbook-defguide can stay in main. However, it was some kind of disappointing: Sun Java needs an hour and a maximum heapsize of 512MB to build the package on my system. GIJ needs 16 hours and a maximum heap size of 1GB to build. kaffe, which I tried too, fails much earlier than GIJ with a maximum heap size of 512MB. So I decided against it and for GIJ. If you know of a way to speed up the build process (besides the possibility to buy a faster system … except you want to make it your christmas or birthday present for me *g*), don’t hesitate to tell me. The packaging files are in the Debian XML/SGML groups SVN repository. However, expect the package in your Debian repository soon (guess, my sponsor wants to rebuild it, which may need another 1x hours :)). Update Ardo van Rangelrooij kindly offered to build the package on an AMD X2 4600+ with 6GB. The build time decreased to at least 7-8 hours. The package will be uploaded to the Debian archive within the next days.

It's been an interesting week. For those of you that haven't been following along: we lost power Tuesday and have been without ever since.

Yesterday was the annual Christmas party at work. About an hour away, supposed to be there at 6. So at 2:30 I went outside to see if I could get the car out past all the snow. At first, YES! But then, halfway down the driveway... well, no. Our driveway needs help. It's actually lower than the fields around it. Thankfully it's on a hill so it doesn't flood, but it does drift shut when there's snow. So the car got stuck. I dug it out, and it got stuck again. And a third time.

I eventually called my dad to see if he'd be willing to come over with his tractor and open up our driveway. He said yes, and drove the 5 miles in his tractor -- which has no cab, and it was below freezing -- and got the driveway open, and helped me get the car unstuck. We had planned to leave at 4, to give us time to get Jacob to the babysitter. We didn't think a babysitter would enjoy spending the evening at a cold house with only a generator providing power, so we were taking him to their place. Well, we left about 4:30.

We got down our driveway, onto the road, and hey -- more drifts. Yay. Got out onto the highway, over to the road to their place. Which someone, ahem, had assured me was a paved road. But instead we got 5 miles on a very drifty east-west country road. That's the deepest snow I've ever put a car through, and I am still surprised that we didn't get stuck anywhere.

So then we dropped off Jacob, and off to the party, and squeaked in just a few minutes late. Phew. It was nice to be out of the house, too.

When we picked up Jacob later -- taking the non-drifty route -- he was sleeping, of course. I carried him out to the car and put him in his seat. There's nothing quite like carrying a sleeping boy snuggled into you to make you forget the lack of electricity outside.

Today we went to church. Church was canceled last Sunday, and the Wednesday evening activities were too. So I think everybody made an effort to be there today. All sorts of electricity stories were heard. Generators moved around the countryside as those that owned them got power and loaned them out to those that didn't have power. The president of a nearby college called the church and offered two rooms at his personal residence to anyone that needed them. One woman announced during sharing time that her husband was taken to the hospital on Friday. They determined that he needed heart surgery, and that will happen tomorrow... and she added that she'd be with him for a couple of days, so if anyone needed a warm house for a family, theirs was available and had a couple of bedrooms, fridge, and garage that people were welcome to use.

At noon there was a free lunch offered to anyone still without power. We went and enjoyed some warm soup and bread with about 30 others.

After that, we went to my parents' place to do some laundry, then came home.

We ate supper. As Terah got up to give Jacob some more chili, I suggested that she look out the window and see if any yard lights were on yet. I had flipped our master breaker off, just to be extra cautious due to having wired our furnace into the generator temporarily. So this is how we would tell that power was back on somewhere (though we did check it periodically during the day). Terah looked out the window, and said, "I DO see yard lights out there... Do you think?" I got up, went downstairs, flipped the breaker, and light came on! We turned on the lights -- Jacob had missed them -- and plugged in the Christmas tree. The power had come on for people miles in either direction from us at the same time. Dad came over to get our electrical box back to normal state and to help me load up the generator to return tomorrow.

There's nothing quite like this to make us feel fortunate to be a part of such a caring community of friends and family -- people who don't think twice about helping out someone in need, even in the midst of having a husband hospitalized.

Jacob didn't seem to mind the power outage. Except for one thing. He is very excited about lights these days. I can spend 15 to 30 minutes exploring lights with him, especially in the kitchen. He will point at a light and say "da?" ("that"). "Da? Da?" means he wants it turned on or off. We'll go to the light switch, and he'll get to flip it, or watch while I do. "Dooooo!" is his excited response.

Well, when he wants something and it's not happening fast enough for him, "Da? Da?" changes to "Da!... Da!..." and then to "DA!! DA!!" and finally some fussing. That happened several times as we couldn't turn on lights.

Then we got to church this morning and boy was he excited. Lights everywhere! He'd point to one bright light and say "Da!" -- look at the light over there, dad! Point to another place and "Da!" Another one over here! And ceiling fans! Lights everywhere! He was so excited he was trying to jump up and down.

Jacob's favorite new word is "hi." He has just barely figured out how to say it, and it takes effort, and comes out very breathy -- but it's there. He can spend several minutes saying hi to someone over and over if he's in the right mood. He wouldn't say hi to the greeters at church, or anyone that said hi to him. But we were sitting in the back row, and halfway through the sermon, he started saying hi to the ushers that were behind us. I couldn't see them very well, but I imagine they were trying to keep from cracking up.

Sometimes it is extremely tempting to wave a huge, heavy, spiked cluebat around. Today I've decided to give in to this temptation. The case in point is the upload today by their maintainer of first cwidget and later aptitude. The fact that the maintainer blogged about both uploads probably means that he's pretty happy about it. Unfortunately I, and people in the Debian release team, were less than amused. Reason is that the uploads set back a complex transition of apt and related packages by at least a week. This is a transition we'd already been following and trying to get into testing for over a month and which was finally as good as ready to go. So what was so wrong about these uploads and what could (should?) the maintainer have done? First of all he should have realized that aptitude has become a rather central package in Debian with strong ties to apt and thus to a lot of other packages. Second, he should have checked whether his previous uploads had already migrated to testing and, if not, why not. The excellent testing migration page for aptitude (which is linked from its PTS page clearly shows that it is tied in a transition involving about a 100 packages in total. The right thing to do in such a case is to contact the release team (preferably at the debian-release mailing list, or at #debian-release). This would undoubtedly have resulted in a request to delay the uploads a few days until the transition had finished. Unfortunately that did not happen and cwidget was uploaded. Because of an ABI bump it ended up in NEW. Because of the transition I did a quick request to Joerg Jaspert to please delay accepting cwidget until the transition was over. But then a third mistake, and arguably the most serious one of the lot, was made. aptitude was uploaded for i386, built against the cwidget library which had not yet been accepted into unstable. Basically that means that an uninstallable package was uploaded. And of course it meant that at that point all efforts to finalize the transition for apt went down the drain. Some alternatives were discussed on how to deal with the new situation, including a sourcefull upload of the previous version of aptitude, but in the end it was decided to just accept the delay as one of the more annoying facts of life and instead ask Joerg to accept cwidget from NEW. In the end the damage may be a bit less than a week if the buildds cooperate (which they probably won't with cwidget still stuck at the wrong priority) and the RMs decide to force things. I sincerely hope that this story will make all Debian Developers and Debian Maintainers a bit more aware of the broader context and consequences of uploads. Oh, as I'm not an RM myself you may wonder what my interest is in this. We've got this great new feature in Debian Installer that adds support for multiple CDs during an installation (a feature that was lost with the integration of base-installer into D-I). However, we can only upload the relevant D-I component after apt 0.7.9 has reached testing...

Lars Wirzenius recently released, and packaged for Debian, a simple script to make release tarballs. He calls it Unperish. It makes me wonder how many other people use that kind of system? Of the top of my head the only similar thing I can recall using is Brad Fitzpatrick's ShipIt - another moduler/plugin-based system (Perl rather than Python this time.) For my needs I tend to just write a Makefile which has a "dist" target, and then I have a simple script called "release". This runs:

1. make dist / make release.
2. creates a gpg signature of the release.
3. scp's the resulting files to a remote source.

All this is configurable via a per-project .release file. The configuration files are very simple, the script itself is almost trivial but being able to sit in a random project directory and have a new tarball on my webserver just by typing "release" is enormously useful. There are times when I think I should make it a mini-project of its own, with the ability to auto-build Debian packages, etc. Other times I just think .. well its a hell of a lot better than my previous ad-hoc solution. At the very least I think I will make the cosmetic change of updating the script to run "make test" if there is a test/ or t/ directory inside the generated tarball. In real news - tomorrow I leave for a two week holiday with my partner's parents. Yesterday I got back from a night spent with her in York. The Bytemark staff night out. Lots of fun. Over too soon, but lots of fun.