It s been a fairly good month working with Koha for me. Our co-op installed Koha 3.0 for a few more libraries and had quite a few enquiries. This means our test servers still need upgrading to 3.0.3, which is disappointing, but current customers come first. The flip side of that is that I m probably going to take some heat during tonight s koha General IRC Meeting and we re facing a bit of a rush to get the direct-RFID control feature and the category of patrons editor tidied and submitted before the 3.2 feature-freeze on 6 September. The features are currently sat up on our infamous co-op 3.0 fork branch, but at least I m currently working with that during a server migration at one library. Also announced this week, the eIFL-FOSS ILS project case studies include several Koha libraries.

Once in a while I get this urge to use SELinux on some of the servers I manage, but almost always run in to something that puts me back enough to never finish the project. This time I managed to figure out the last few glitches. In the end, SELinux still has a really steep learning curve, so it's not for the impatient ones. Even though enabling SELinux in Debian has become a lot easier since the first time I tried to get things running, it's still just the tip of the iceberg. In Debian it is just a matter of installing the right packages and running a few commands, but that's just where the troubles start. Most of the howtos focus on single user or shared installations where all users are created locally. Also most howtos fail to mention that you need to relabel files in certain cases. One of the most annoying problem I ran in to was changing all non-system users away from the unconfined_u class. This is of course done like this (found here):

semanage -m -s user_u __default__

The problem here is that it changes the existing user as well and you start to get errors like these:

denied    read   for  pid=32258 comm="bash" name=".profile" dev=dm-5 ino=185474 scontext=user_u:user_r:user_t:s0 tcontext=unconfined_u:object_r:unconfined_home_t:s0 tclass=file

The problem here is that the home directory for the user is still labeled for the wrong class. The fix is to relabel the home. Sadly this is something that you just need to know, it's not explained anywhere. At least I haven't found an explanation anywhere. Another good thing to do before you continue is to change the already existing user to the staff class. Staff class has a bit more relaxed security controls and you get to change the security roles (details here).

semanage login -m -s staff_u myuser
fixfiles relabel /home/myuser

This gets you a semi working setup, next problem usually is that some daemons are denied access to parts of your system. For me, this was postfix trying to access my home directory that was mounted over NFS. For such cases, you should persuade the maker of the module package to update the global policy if it's a common use case. Or you need to create a policy package that allows access to the given files. The process itself is documented in the audit2access manual page. In general you should study the audit2why and audit2allow packages. The former tells you if there is an easier way to fix something (like enable a boolean) and latter will create the required policy lines. Only problem is to compile the policy and load it. The only problem here was to find the right tool and the right lines from the manual. In general the SELinux learning curve is way too steep. It's a system that works pretty well once you learn all the tricks and start to completely understand the toolset. The community should continue working on lowering the bar for new users. There has been some major improvements since I first tried SELinux, so it's the right direction.

Whenever I attend Debconf, the first day is always a bit disorienting due to the confluence of jet lag with the sea of male programmers swarming at the venue. I am not sure I should be admitting this but one of the first things that pops to mind is the very cheesy one hit wonder whose video is filled with many bikini clad men, Its raining men. So for a few hours, maybe a day, I sometimes feel out of place but this this first wave of discomfort usually gives way to comfort. This is not only because I connect with friends but because Debconf as well as many other hacker events and this sits in marked contrast to professional academic conferences are remarkably accepting of diversity and difference, at least that has been my personal experience. Most notably, people could care less about how you look, disabilities are consistently accommodated, and some things, like gender changing, which would raise serious eyebrows for instance in most academic conferences, is accepted with next to no gossip. I raise this because this is how I personally have experienced the world of Free Software: overwhelming male but overwhelming accepting of difference as well. So even while I think it is key to confront the problems of discrimination in this world, it is not a simple story, for again, it is an environment that is also accommodates difference and quirkiness to some notable degree. The question of gender in F/OSS is complicated one and here I am not going to ruminate on sources of gender bias except to say that I am sure there are some in operation (as there are in most domains) some of which are internal to Free Software and other s external to Free Software. But what I have been struck by, especially over the course of the summer, is the explosion of sites, blogs, and debates that have confronted gender in Free Software. It has been nothing short of astounding and a really positive turn. The most notable example is this AWEEEEEEEEEEESOME pair: a wiki and a blog that confront gender head on. These are notable because the wiki, for example, catalogs all sorts of controversial events, comments on them, leaving a very visible trace of debate, one that is necessary to change the gender make-up and dynamic within Free Software project. Along with these, the FSF is finally hosting a min-summit, which is great (less great is that participation seems invite only but perhaps they have some good reasons for doing so). And today I just learned of this diversity page coming out the Python project. These are perfect examples of the recursive public in action raised in Chris Kelty s work. And I have long been impressed with the dialogue that has followed from some controversial events in the world of Free Software, including those related to gender and this summer seems to be a watershed of sorts and I look forward to their developments over time. Indeed and this may be controversial as well, but I think my academic field of media, law, and culture has something to learn from these gender politics for there are some very real, though probably unintentional forms of discrimination that are not under that much active discussion. The most glaring problem is the underwhelming presence of female scholars during conferences (and as we know, conferences are exceedingly important for one s professional development and career). What I find most striking about this trend is the number of female scholars is significant. That is, when it comes to scholars and this seems different from the world of tech, there is a sizable community of women scholars and activists so when there is a 5% female participation , as for example, with this event, one has to wonder why is it raining men at these conferences? It also seems that while the debate exists, it is not as vibrant as with what is going on right now in F/OSS. Take for example, this recent mailing list post which unapologetically highlighted the lack of female presence in the up and coming Free Culture event at the Berkman Center. While the post generated a handful of thoughtful responses, including this supremely classic, biting, and quite clever response from Georgetown professor Julie Cohen, the debate did not linger on (however short, the posts and discussion were quite fruitful). What to do? Frankly, blame and finger pointing are pretty counterproductive, mostly because the discrimination is quite unintentional and I believe change can be brought about via more constructive paths. More important is we need to make the issue visible, identify some possible sources, and then create projects that can remedy the problem. Along with Elizabeth Stark, who has also been keen to note and change the gender problems, I am currently whipping together a wiki with a list of female scholars, leaders, and technologists as a resource for folks organizing conferences. We already have a base list (with a remarkably long list of folks) and will hopefully in the course of the next month throwing it up on the wiki. I don t think it will ever be as cool as the Geek Feminism Wiki but it will hopefully do some good!

At Steve's house in Cambridge. First Debian party I'd been to. House full of people I knew only from email, some very old friends. Wires and leads filling the front room floor - laptops _everywhere_ . [My netbook died with nasty ACPI errors - since fixed/worked around - it was practically the one place in the world where I could yell for an ACPI expert and folk knew what I was talking about :) ]

I wish I'd taken a camera - I was there for 1/2 hour before I realised I was only about three feet from a large TV which then became the focus for competitive Wii Fit archery :) Thirty second rule on sofa space - if you left for more than about 30 seconds you had to sit on the floor when you got back (I jammed myself onto a corner of the sofa once I realised I'd barely get through the crush :) )
[Forget students in a mini / UK telephone box - how many DDs can you fit into a very narrow kitchen :) ]

It's a huge, dysfunctional family with its own rules, geeky humour and in-jokes but it's MINE - it's the people I want to hang out with and, as perverse as it sounds, just being there gave me a whole new reaffirmed sense of identity and a large amount of determination to carry on "wasting my time with Linux" and Debian

Thanks to those who signed my key for me (and Noodles who didn't sign but gave a very intelligent rationale as to why he couldn't at the moment :) )
Thanks to Steve for quintessentially being and being the perfect host - and I hope to be back next year. And the food was excellent - chilli popcorn comes highly recommended :)

To the person driving the black Acura SUV with the vanity plate ZEPHNET south on I-5 Saturday: HELLO. I COMPLETELY APPROVE OF YOUR LIFESTYLE CHOICES. PLEASE MAKE USE OF THE DWIGHT D. EISENHOWER NATIONAL SYSTEM OF INTERSTATE AND DEFENSE HIGHWAYS IN ANY MANNER YOU SEE FIT. IT IS YOUR RIGHT AS A PAYING TAXPAYER AND NO ONE SHOULD STIFLE YOUR CREATIVITY IN SUCH ENVIRONS.

It's been a while since I last wrote about where I was up to with the DHCP 4.1 packaging for Debian. I'm pleased to report that the packages are now ready for upload to experimental. The main delay was doing some basic testing to make sure that the transition from the v3 packages to the new v4 packages worked properly. I'm glad I took the time to set up a Xen test environment, because I found all sorts of problems, and fixed them. The only reason I'm not uploading the packages today is because my testing uncovered a bug (#544371) in the way ifupdown is invoking dhclient. Until that is resolved, there's not a lot of point in uploading, as dhclient won't work. Oh, and the DHCP server LDAP patch still needs to be sorted out, but I'm not going to wait for that to do an experimental upload.

I would like to point out that my last article was in no way meant to be critical towards libvirt, rather on the contrary. I think it's an awesome technology the way it provides a common management platform for various virtualization solutions available on Linux and even other platforms.

For reference, expensive proprietary virtualization solutions don't necessarily fair better.
I've in fact recently ran into a problem in a Vmware ESX / Virtual Center environment which, while rather different in manifestation, in the end was similar in nature: diverging state change in the environment and in configuration.

The Vmware problem surfaced after kernel changes on Linux guests, where, after rebooting into the new kernel and running the vmware-config-
tools script to rebuild the modules, nightly backups with help of the vcbmount utility would fail.
The only cryptic error message was:

Creating a quiesced snapshot failed because the (user-supplied) custom pre-freeze script in the virtual machine exited with a non-zero return code.


It didn't help that there wasn't any "user-supplied pre-freeze script" to begin with.

Searching for this error message returned lots of hits, several going at least one year back. However, aside from a few references to a documented Solaris guest issue, which was not applicable, none would actually provide any insight into what the problem might actually be. Unt
il I found following post on the Vmware communities site, which pointed out that
changes to the uuid.location weren't propagated properly to the vmx definition.

For the time being, the best way to work around this (in Linux guests) is to add another reboot right after rebuilding the vmtools modules.
Since you should be rebuilding
But Vmware should provide a proper fix their stuff, really. I've got this strong feeling that the libvirt bug will be resolved in less time than a year...

Voice-controlled waypoints I have it in my TODO list to implement taking waypoints when pressing the headset button of the openmoko, but that is not done yet. In the meantime, I did some experiments with audio mapping, and since I did not manage to enter waypoints while recording them, I was looking for a way to make use of them anyway. Enter findvoice:

$ ./findvoice  --help
Usage: findvoice [options] wavfile
Find the times in the wav file when there is clear voice among the noise
Options:
  --version             show program's version number and exit
  -h, --help            show this help message and exit
  -v, --verbose         verbose mode
  -p NUM, --percentile=NUM
            percentile to use to discriminate noise from voice
            (default: 90)
  -t, --timestamps      print timestamps instead of human readable information

You give it a wav file, and it will output a list of timestamps corresponding to where it things that you were talking clearly and near the FreeRunner / voice recorder instead of leaving the recorder dangling to pick up background noise. It does not use sound statistics because I have no background whatsoever in audio processing, but it basically finds those parts of the audio file where the variance of the samples is above a given percentile: the higher the percentile, the less timestamps you get; the lower the percentile, the more likely it is that it picks a period of louder noise. For example, you can automatically extract waypoints out of an audio file by using it together with gpxinterpolate:

./findvoice -t today.wav   ./gpxinterpolate today.gpx > today-waypoints.gpx

On the timestamps that it outputs, it will add the modification time of the .wav. This means that if you touch -d "@timestamp" the .wav file with the date you started recording, then you can get decently accurate waypoints provided your system clock is decently synchronized. For example:

START= date +%s 
arecord file.wav
^C
touch -d "@$START" file.wav
./findvoice -t file.wav   ./gpxinterpolate today.gpx > today-waypoints.gpx

In record-audio-on-freerunner I even set the .wav mtime using the GPS time at the start of the recording.

So, I mostly missed Terminator: The Sarah Conner Chronicles when it was shown on TV, so I bought the first season on blu-ray to watch... I'm about half way through now, and I'm really quite enjoying it. Might have to see if I can find season 2... Appears that the series has had the usual Fox treatment though... "Oh, people like it, we'll ditch it!" sigh.

Every once in a while, rewrites in ALSA drivers or in desktop audio components (GNOME mixer or Gstreamer) result in an impossibility to completely mute the console bell. Until recently, ALSA offered a separate channel to control this. Since Jaunty (kernel 2.6.28, ALSA 1.0.18r3) came out, not anymore. As such, I was wondering how else could I mute the console bell? Some people on Ubuntu Forum suggested blacklisting the pc-spkr kernel module, but this is entirely the wrong approach, as it completely kills sound output on this laptop's built-in speakers. I don't wanna completely lose sound support, I just wanna get rid of that annoying console bell! Others recommended setting set bell-style none in /etc/inputrc but that only works for interactive shells. The console bell still rings e.g. whenever rebooting, probably because bash gets called as a non-interactive shell by init scripts. Actually, since Jaunty, restarting the system makes the bell ring not just once, but twice! Can anyone think of any more permanent way of disabling the console bell in some global system setting?

A reasonably common feature in Internet debates is that of one party claiming to not care about the issue. Statements such as I haven t got time to debate this or I m not interested are used to try and disclaim any interest in the topic. Such claims are silly and rather amusing. Outside the Internet it does make sense to say I don t care because interactions are between small numbers of people. Telling a tele-marketer that you don t care about their product is part of the process of getting them to stop calling you. But it doesn t make sense in interactions between large numbers of people. If there are 100 people on a mailing list then there will be a variety of opinions about any issue, but one thing you can count on is that the majority of people on the list are not interested in whether any individual cares about an issue. If there was a general desire to discover how many people cared about a topic of discussion then the way to determine this would be via an online poll. In almost every situation individuals saying I don t care in email just isn t a scalable solution. The only exception is when someone in a leadership position is asked for an opinion, in such a case a response is expected and if the leader actually doesn t care then saying so and letting other methods be used to resolve the dispute makes sense. One common case where an I don t care message is seen is at the end of a long and heated discussion. After a discussion has gone on for a while (well beyond the point where it was obvious that no-one was going to change their position) one party might claim to not care or not have the time to debate the issue. But of course if they didn t care at all or had no time then they wouldn t have written any messages on the topic. If they had a limit to their time or care factor then they would probably have stated their opinion once and maybe written a single follow-up post clarifying the first one. Anyone who has written 6+ messages or a total of 1000+ words on a topic obviously cares and obviously has time. In such cases it seems that claiming to not care or not have time is a final desperate attempt at getting the last post on a topic by someone who subscribes to the last post wins school of online debating. Another common case is when someone makes a point that is decisively refuted. The Internet is filled with people who can t handle criticism and who can never leave any critical email without a reply. In such a situation claiming to not care is a way that such a person can protect their fragile ego even if the point is indefensible. One of the variations on this theme is to claim to be an expert who doesn t care enough to educate people on mailing lists (or even provide a couple of URLs that reference what they need to know). As a hint, if you are going to claim to be an expert while making statements that disagree with notable experts in the field in question (professors at prestigious universities, Nobel laureates, or people who have demonstrated great practical success) then you really need to demonstrate your expertise and cite references. While generally it s the scope of the Internet that makes the I don t care argument silly, it also doesn t make sense in interactions via electronic media such as private email where a sender can be ignored. If you don t care about a private email in reply to one of your messages then what you will do is simply delete it. Replying and saying I don t care merely demonstrates that you do care, invites another reply, and shows that you have a fragile ego to protect. My general practice when dealing with such people is to send one reply to every message that they send me, such people typically demonstrate how much they care by sending me more than a dozen messages explaining in detail how much they don t care. Another variation on the theme of private correspondence is people who write blog comments that are obviously inappropriate and will not pass moderation. Someone who polls my blog to see if their comment has been approved and then writes an abusive comment when they discover that they fell well short of my comment quality standards obviously cares about having their comment published. To then claim to not care about whether their comment was approved is obviously a lie. Google is almost entirely filled with things that I don t care about. I demonstrate the fact that I don t care about them by not commenting.

So, this blog entry is purely about my life experience and my gut feelings... but, basically, here's the rub - pro-choice are all about being able to kill a child up to 24 weeks old, my nephew wasn't far past that, and he's a fucking fantastic child, he's now 8 - and absolutely fucking brilliant - so yeah - pro-choice - I'm not going to fuck up my life, but I'm going to mince a child that might or might not have feelings because I can... argh - for fuck sake - given that most abortions are through consensual sex - for fuck sake - either take the choice that you're going to be pregnant and live with that or don't have sex - it's not a hard choice - and that is what I see as pro-choice - you have the choice to have sex, or not. If it wasn't a consensual agreement, take the damn after morning pill, not a hell of a lot is going to survive that, and you're within a week, barely noticeable. What pisses me off is the "pro-choice" vs "pro-life" battle - you're both wrong, anything after 2 weeks and I'm with the pro-lifers, any thing before that, yeah - the pro-choicers are fine... Another thing that pisses me off is people deciding that they know best about how the government should go - what they haven't yet realised is that the entire government is there to tax us so that the pro-life and pro-choicers can have their bitter dispute, no matter who is in power. Shortly followed by screwing over either students or workers, depending on who's in power. It doesn't really matter - whoever is in power, some one is going to get screwed.

TurboGears 2 packaging - (another) status update Brief status update on TG2 packaging. As expected, this week has been very busy and I'm writing the update offline on a train, but nevertheless I've good news to share:

• a lot of packages uploaded to NEW have been accepted. Please join me in welcoming to the experimental archive: python-toscawidgets, python-repoze.who ,-plugins , python-repoze.what ,-plugins , python-webflash. Thanks to ftp-masters for the quick processing of these days.
• python-tg.devtools (which provides the integration with paster to quickstart TG2 projects) has been both ITP-ed and uploaded to experimental/NEW (as usual, it is also available from my repository on people.d.o, see my first post on TG2 packaging for access details).
• zope.sqlalchemy (build-dep for the tg.devtools tests) has been packaged by the Zope team, and will uploaded "soon"
• the packaging of turbogears2 itself has been resurrected starting from the last work on it in the Python Module Team repository by Gustavo Noronha (which, BTW, has been terribly useful in clarifying various doubts of mine around related software products, thanks Kov!)

... the last item above would theoretically mean that TG2 is already usable, but it is not the case due to the infamous #507909 which breaks both TG2 and TG1 in unstable (the latter was working in Lenny, and I had to resort to a Lenny chroot for a recent course I've taught about web development). In short, turbojson is in unstable, in spite of the lack of several of its dependencies, making impossible any import of it.

• to fix that, I've started by ITP-ing PEAK_rules, but haven't yet had time to complete its packaging. A few more will come next.

..., stay tuned, keep faith, bear with me, almost there, ... etc.

and Being a lot time without any post but finally I see the things more clear, I changed my $paid-job on March, I leave my sysadmin job on a midle-range local ISP, to go on a sort of similar job in another one, more big company, first I though that this will give me more spare time but I was wrong, at least for the first months, but at this time I m finally getting enough time to rest, but not enough time to devote to some Debian tasks(but things will change!!). but looks like everything is going better, I get my $paid-job permission to go to DebConf, and I will also attending just 2 days to ECSL; ECSL is Encuentro Centroamericano de Software Libre , it is actually the first gathering with people related to Free Software communities on this small area(Central America), we expect about 100 people from Central America, Mexico, and some other places, this is could be a nice opportunity to create efforts on a region that is having political and social efforts to integrate all countries in a political/social block. So, see you all at C ceres and Gunnar, see you on ECSL at Estel

Chris, Please note that the method you recommend for activating libpam-cracklib only applies to lenny and earlier; it's obsolete for the upcoming squeeze release (and in Ubuntu 8.10 and later), where libpam-cracklib is integrated with pam-auth-update and will be autoconfigured. Running your sed command on a squeeze system will break pam-auth-update integration, and cause the admin headaches going forward if they ever have occasion to use anything other than pam_unix for authentication. So for a squeeze system, this should be:

apt-get install libpam-cracklib

... and you're done! Actually, the package defaults in squeeze are stronger than what you've listed: libpam-cracklib will set minlen=8 by default (instead of the uselessly-weak minlen=6), and coming soon, pam_unix should default to sha512 instead of md5 for password hashing.

In the spirit of Thomas Limoncelli's Time Management for System Administrators, this is my checklist for setting up a new Debian system. I have added a few notes to the original list to justify their existence and to provide some background information. Whilst you should avoid performing repetitive interactive configuration and defer to the multitude of tools designed for this task, constructing and sharing a checklist can still be an instructive step. It can also be useful in situations where a machine has already been partly configured for you.

An old friend is ranting about localization. I first considered not really reaction to Joey's post, mostly because he has very true points...and particularly when he has about the same reaction than mine about a recent post in ou mailing lists. So, I will stick to react to one part of Joey's post...the one I consider really inaccurate. "everyone uses the software in English anyway" Really, Joey, really, that's completely untrue. Of course, I do live in a country that very well known (or at least that has the reputation) for being deeply ignorant in English language. But, really....*all* computers I see around me, both in my personal life *and in my professionnal life* are nearly completely localized. It's probably now well know that I spend most of my professionnal time....providing desktop systems (or managing the people who provide them) to users in ONERA, "the French Aerospace Lab". That means about 2000 users in a scientific environment where the use of English is much more developed than the average environment. Most of these users speak a fairly decent English and are perfectly able to understand that language in some way. About 80% of these systems are Windows-based and 20% are Linux-based. Probably more than 95% of them are localized in French. Even on Windows systems, we mostly integrate free software. And for *each* of them, the most important feature we need, besides software being free, is it to be localized in French. I bet our friends from Extremadura can say the same. The success of Linux-based free systems there also happened because the software is available in Spanish. And, of course, there are tons of similar stories and counter-examples (M nchen, Bhutan, Venezuela, etc.). So, really, please don't spread out that idea. Oh, yes, geeks *do* use their software in English (and, even here, I need to be convinced if I remember well what I saw at conferences in Germany or Spain, for instance). And, yes, it's very well widespread among geeks that using software in English is "better" or "easier". Which I indeed always fight and will fight until I die..:-). We certainly agree that these l10n needs put a high load on development and sometimes slow it down. and, for sure, we sometimes need to make a balance and I really thank you for giving me the credit to try doing that balance. Anyway, all this (including your rant) had to be said and it's interesting to have that small discussion (I just should not start writing down a blog entry at 23:00...:-)) See you soon, hopefully, Joey !

This weekend I implemented an idea I had some weeks ago: sending regular mails with the translation status and the contents status of debian-edu-doc to the Debian Edu mailinglist, in the hope this would motivate people to finish the documentation and its translations. Currently the package contains four different manuals, translated in up to 6 languages: the old Debian Edu etch manual, the new Debian Edu lenny manual and manuals for teachers using Rosegarden and Audicity. All four are being written on wiki.debian.org, then exported to Docbook, then .po files are created with the great po4a tool suite. Those .po files are kept in svn of the the debian-edu-doc package, for translators to edit. Detecting missing or half finished content is done by putting the string "FIXME" plus a description what to fix in the wiki text. Then a small script is run by cron every 2nd and 4th sunday of the month, which outputs the translation status and greps for FIXME and formats this nicely. The result looks like this:

The (translated) debian-edu-lenny manual as PDF or HTML is available at http://maintainer.skolelinux.org/debian-edu-doc/

To understand this mail better, please read /usr/share/doc/debian-edu-doc/README.
This mail is automatically send by a cronjob run by Holger Levsen every two weeks. Please send feedback, suggestions, flames and cookies via this list.


debian-edu-lenny-manual.de.po: 545 translated messages, 193 fuzzy translations, 220 untranslated messages.
debian-edu-lenny-manual.es.po: 85 translated messages, 204 fuzzy translations, 669 untranslated messages.
debian-edu-lenny-manual.fr.po: 447 translated messages, 279 fuzzy translations, 232 untranslated messages.
debian-edu-lenny-manual.it.po: debian-edu-lenny-manual.it.po:7683: end-of-line within string
debian-edu-lenny-manual.nb.po: 711 translated messages, 159 fuzzy translations, 88 untranslated messages.
----------------------------------
http://wiki.debian.org/DebianEdu/Documentation/Lenny//Features
FIXME: describe new features in 5.0.1+edu0 here.
----------------------------------
http://wiki.debian.org/DebianEdu/Documentation/Lenny//Requirements
FIXME: a description of main-server and thinclient-server is missing.
----------------------------------
http://wiki.debian.org/DebianEdu/Documentation/Lenny//Installation
FIXME: probably each paragraph on this page needs to be (slightly) rewritten for lenny.
FIXME: describe PXE installation here, if its only two sentences, then they should be here.
FIXME: path to preseed file location missing
----------------------------------
[...]
====================
24 FIXMEs left to fix
====================


I'm quite happy with the result, now we we just need to fix those FIXMEs :-)

The same tools will probably be used for the illustrated Lenny installation guide and maybe others. I've described the requiered structure for such a manual on wiki.d.o in an email to debian-boot (as the discussion about that guide happened there), in case you are interested.

In mostly unrelated news, I've started running everyday again six days ago (slowly running a bit further each day) and yesterday I've also started with doing gymnastics. It was high time to realize and to change some stuff in my life, and it looks like I finally heard the call. And doing sports is by far not the only thing I want to do very differently again, it's just the most visible atm and it's also quite easy to do. Also I can feel it in my legs today :-) Now I "just" need to keep going forward, change is a continuous process, and nothing to be done with. Ever. The day I stop changing myself, the day I stop learning, I consider myself to be dead. I'm glad I woke up, thanks for contributing to making me wake up and for bearing with me sometimes.

Whilst working on update-manager I have been wondering whether I should use gettext for localizing debug output and error messages sent to stderr.
As for debug output itself I basically do not see the need for providing a localized version for each and every message sent to stderr, but as far as error messages are concerned I am uncertain. The point is that update-manager (apart from its experimental text interface) is usually not launched from a terminal at all and so most users won t even see these messages ever. Also, I believe that every developer s English skills are good enough so that he or she is able to understand simple messages.
Error messages however might be useful to all users when they experience a problem with the software, but localizing those could make handling bug reports a bit harder, possibly having to translate the error message back to English before being able to see what has gone wrong. So basically I am asking you: What do you think? Is it worth localizing these messages? What is your experience with localized or non-localized error and debug messages? I would be glad if I could get some input from you, either as a comment to this article, via email to debian(dot)sp(dot)or(dot)at or through the update-manager-devel mailing list.