Este post tambi n est escrito en espa ol aqu . Privacy at Facebook is heavy-duty. As a big fan of the Worlds Collide Theory I hate be tagged compulsively. I would like to select in which photos appear in my profile and feed. Since I couldn t find that option in the setting menu, I looked for the answer in my favorite scripting language: Python. This 60-lines-long script removes your tag from the latests photos where you has been labeled. You can download it from here. You may run it hourly (or every 15 minutes, or every 5 minutes, depends how paranoid you are) via cron or whatever. Any improvement is welcome. It probably runs on Windows too. If you managed to do it, leave a comment for the others.

It seems that despite having a very important work deadline today I am destined to be interrupted every five minutes. Unfortunately I need to concentrate to get this done. And while i managed to get "in the zone" earlier, now I cannot string two words together.

This seems to be a recurring theme recently, my productivity is horribly low because I get interrupted all the time for "can you just" jobs. I turn the phone ringer off and hide my email window and I get called on my mobile and get asked why don't you answer your phone?

Its not so much the time lost to answering the specific query or doing the job but more my context switch time to restore to my previous task becomes huge. Somehow my switching time is absolutely non linear and today it has become so large I have decided to dump state altogether.

Because I know I have to do the school run soon and the interruptions continue I have abandoned the critical task altogether for now in the hope I can get back to it fresh. Do others get this I wonder? or is it a personal fault I should strive to fix? I know I used to be able to deal with this sort of thing with much less trouble, maybe I am getting less flexible as I age?

Fortunately (umm, you know what I mean) the Entropy Key software has some cleanups required which is an easy job and does not matter if I get interrupted so I do have a productive task to complete.

Oh speaking of the entropy key Niel blogged something silly I created the other day. I had a senior moment and filked the children's nursery rhyme "If You're happy and you know it" slapping some guitar chords on it.

It seems I cannot simply leave well enough alone and last Friday night (with the help of Mark Hymers) I made it a whole lot worse. I present to you the score of "If you're happy with your ekey, blog your praise" for piano and guitar. In fact I wrote this out in rosegarden so it can be turned into a midi file etc. all the source files are available. It is released under a CC license so I suppose someone could put the lyrics back to the proper nursery rhyme and use it for something less tacky.

The conclusion of this discussion is that systems like cmucl are no longer possible under this new system.

You are wrong. If there is a good reason, there can be exceptions. As we mentioned. One of those is for new architectures. Another can be for such packages. But not for I am too lazy to do that , only for it is impossible . Whatever it might be in the cmucl case. Anyone else up for a useless discussion via blog posts?

In a comment on my post about Designing Unsafe Cars [1] Noel said If you don t know how to make a surgery, you don t do it. If you don t know how to drive, don t drive. And if you don t know how to use a computer, don t expect anybody fix your disasters, trojans and viruses. Later he advocates using a taxi. Now I agree about surgery apart from corner cases such as medical emergencies in remote places and large-scale disasters. I also agree that it s good to avoid driving if you aren t very good at it (that would be much better than the current fad of sub-standard drivers buying large 4WD vehicles). But I don t think that people who lack computer skills should avoid using computers. When cars were first invented everyone who owned one was either a mechanic or employed one. Driving a car often involved being well out of range of anyone else who might know how to fix it, so either the car owner or their chauffeur had to be able to fix almost any problem. As the car industry evolved the level of mechanical knowledge required to own and operate a car has steadily decreased. I expect that a significant portion of drivers don t know how to top up the oil or radiator water in their car and probably don t know what is the correct pressure for air in their tires. To a large extent I don t think this is a problem, owning a car involves regularly taking it to be serviced where professionals will (or at least should) check every aspect of the car that is likely to fail. If I used my windscreen-washer less frequently I could probably avoid opening the bonnet of the car between scheduled services! When budgeting for car ownership you just have to include regularly spending a few hundred dollars to pay for an expert to find problems and fix them with of course the occasional large expense for when something big breaks. When the computer industry matures I expect that the same practice will occur. Most people will buy computers and plan to spend small amounts of money regularly to pay people to maintain it. Currently most older people seem to plan to have a young relative take care of their PC for them essentially free mechanic services. The quality of such work will vary of course, and poorly designed OSs that are vulnerable to attack may require more support than can be provided for free. Due to deficiencies in city design it is almost essential to drive a car in most parts of the US and Australia as opposed to countries such as the Netherlands where you can survive quite well without ever driving. When a service is essential it has to be usable by people who have little skill in that area. It would be good if driving wasn t necessary, I would be happy if I never drove a car again. The need to use computers however will continue to increase. So we need to make them more available to users and to support users who can t disinfect computers etc. The only skill requirements for using a computer should be the ability to use a keyboard and a mouse! This requires a new industry in supporting PCs. Geek Squad in the US [2] seems to be the organisation that is most known for this. I expect that there will be multiple companies competing for such work in every region in the near future, just as there are currently many companies competing for the business of servicing cars. We need support for free software from such companies. Maybe existing free software companies such as Red Hat and Canonical can get into this business. One advantage of having such companies supporting software is that they would have a strong commercial incentive to avoid having it break unlike proprietary software vendors who have little incentive to do things right. The next issue is the taxi analogy. Will software as a service with Google subsidising our use of their systems [3] take over any significant part of the market? Of course the car analogy breaks down when it comes to privacy, no-one does anything remotely private in a taxi while lots of secret data is stored on a typical home computer. Google is already doing some impressive security development work which will lead towards low maintenance systems [4] as well as protecting the privacy of the users to the extent that you can trust whoever runs the servers. My parents use their computer for reading email, browsing the web, and some basic wordprocessing and spreadsheet work. The mail is on my IMAP server so all I need is to have some way to store their office documents on a server and they will pretty much have a dataless workstation. Moving their collection of photos and videos of their friends and relatives to a server will be a problem, transferring multiple gigabytes of data on a cheap Australian Internet access plan is a problem.

• [1] http://etbe.coker.com.au/2009/11/24/designing-unsafe-cars/
• [2] http://www.geeksquad.com/
• [3] http://abovethecrowd.com/2009/10/29/google-redefines-disruption-the- less-than-free -business-model/
• [4] http://www.chromium.org/chromium-os/chromiumos-design-docs/security-overview

I m back from Dallas, where I was invited at the Ubuntu Developer Summit for Lucid. I spent a great week there ; the event was extremely well organized (by organizing them every 6 months, you are probably able to gather a lot of experience!). Of course, after all I had heard about people hugging each other all the time in the Ubuntu community, I was a bit worried, especially with the flu spreading! But there are lots of fantastic people around Ubuntu, and it was a very nice opportunity to be able to meet them all. Since it was my first UDS (I was at FOSSCAMP in Prague a few years ago, but didn t stay for UDS back then), I was not really sure of what to expect. I was very pleasantly surprised. UDS vs Debconf UDS is very different from Debconf. In Debconf, we do three different kind of things:

• we hack, mostly on our own, in the hacklabs
• during talks, we report on what we have done recently
• during some talks or BOFs, we discuss future (possible) changes

In UDS, the main focus is on the third point: most of the sessions are about discussing what will be implemented for the next release. All of the relevant developers are in the same room to discuss possible problems, and the outcome of each session is usually a detailed plan, with a list of action items. It s a very nice way to ensure that changes are well thought, and allows making large-scale changes in Ubuntu very easily (you don t spend weeks arguing about them on mailing lists). Of course, it s probably also helped by the fact that there s a company behind Ubuntu, with a set of large teams (kernel, foundations, desktop, etc), which helps transfering trust (not everybody feel like they have to participate in each discussion, even when they affect the whole distribution: the team in charge is trusted by the rest of the project). On the other hand (yeah, let s be negative for a while) it doesn t really help spreading information between Ubuntu developers: it s often a bit difficult to get the global view of what is happening inside Ubuntu, especially since lots of things are discussed on IRC. Collaboration between Debian and Ubuntu During the week, I mainly was interested on collaboration between Debian and Ubuntu. There s a strong focus on doing the right thing wrt Debian (and also other upstreams). Then, of course, Ubuntu also has an agenda, which sometimes requires moving very fast on some things, or making compromises between technical purity and pragmatism. But the willingness to have common foundations between Debian Squeeze and Ubuntu Lucid will surely benefit both distros. Quality Assurance On the QA front, I am planning to do archive rebuilds for Ubuntu as well (fixing FTBFS is an easy way to start contributing to Ubuntu or Debian, and having those bugs fixed in Lucid would benefit Debian as well, by having patches already prepared). I also had a session with the QA team, where I gave an overview of what we are doing in the Debian QA group, to discuss opportunities for collaboration. The Ubuntu QA team focuses more on testing (with automated or manual testing) and bug triaging than archive quality that part is left to the MOTUs and the release managers. (About MOTUs, I liked how what they do was described as long-tail maintenance, landscape gardening or terraforming. That gives a good idea of what it s about). Ultimate Debian Database On the Ultimate Debian Database front, I did a plenary talk to try to demonstrate how UDD could be useful to Ubuntu as well, and, with Jorge Castro, we examined some metrics of Ubuntu s giving back to Debian. I also talked with the Launchpad team to try to resolve my long standing pretty please provide an export of Ubuntu bugs, so I can easily import them in UDD! issue. Ubuntu and ARM ARM netbooks and smartbooks (mix between netbooks and smartphones) are coming, and Ubuntu is clearly very well positioned to play an important role on that market. There was a whole track about ARM support, with lots of changes that will be done for Lucid. Let s all hope that Ubuntu-powered ARM netbooks win that market, so we don t reproduce the failures of the non-ARM netbooks. Distributed Development James Westby has been working on a set of tools to be able to work on Ubuntu packaging using bzr. The point is not to store the canonical source for Ubuntu packages in bzr (well, at least it s not the plan yet), but to provide a set of branches to make it easier to merge or cherry-pick from Debian. The resulting workflow looks extremely nice, with lots of syntaxic sugar. And even better, he assured me that his code is portable to Git ;)
Using his work, merging Ubuntu-specific changes in a new version of a Debian package basically means pulling from lp:ubuntu/foopkg, merging from lp:debian/sid/foopkg, and you are done!
As a bonus, we (Debian) would get bzr branches with the history of packages (kind of bzr-powered snapshots.debian.org).
James project is not completely ready yet, but should be very soon. It s already basically usable, apparently. Conclusion Ubuntu has clearly gone a very long way since 2004. Everything looks very well organized and polished, and gives the impression of a big machine that nothing can stop. With Cloud Computing and now ARM netbooks, Ubuntu has proven to be able to adapt to the current trends and attract a lot of visibility. It is great news for Free Software, but also proposes an interesting challenge to Debian: of course, it s nice that a Debian-based distro is in that position, but will Debian manage to stay relevant, or are we just going to be the technically-pure distro without many users that serves as a package supermarket for Ubuntu?

Following the announcement of the source+throw away binaries route for uploading packages I've had a brief discussion with our FTP team.

The implications of the new method would be that if you upload a package it will automatically be recompiled from source by using the packages already in the system.

For cmucl which needs cmucl to recompile itself it means that we can only use the previous version of cmucl in the archive, not the one we are just uploading. This won't work as the compiling cmucl needs to be hand-patched to be more 'like' the new version, otherwise you cannot rebuild it.

The conclusion of this discussion is that systems like cmucl are no longer possible under this new system.

The FTP team suggested to change cmucl to be able to do this. Needless to say we already have this, after several years of hard effort by multiple people, it's just called sbcl.

So in the end the 'everybody uses C' camp won and cmucl on Debian will die a quiet death. It's a sad end for a system hand-patched from PDP10's to modern CPU's over the coarse of almost 30 years...

I am pleased to announce that Marco Nenciarini has joined the Dovecot maintainer team. One of his first contributions was converting the package to the 3.0 (quilt) source format which all the cool kids are doing these days. One ongoing problem we have is that Dovecot does not (yet) have a stable ABI for plugins. This affects dovecot-antispam as described in bug #544588 The short term solution is binNMUs but obviously a better long term solution is needed. One idea I've had is to include dovecot-antispam as an additional tarball within the dovecot source package now that 3.0 (quilt) gives us that capability. This way, dovecot-antispam will be rebuilt (with the right dependencies) whenever dovecot is. I have previously experimented with multiple tarballs and it works although at the moment all the debian build tools (devscripts, *-buildpackage etc.) don't fully support it. I expect that will be rectified soon enough but there is a philosophical issue as well. dovecot and dovecot-antispam though related, are two seperate upstream projects with seperate versioning, maintainers etc. Does it make sense to lump them together? I say yes; conceptually they belong together. (dovecot-antispam is useless except as a dovecot plugin.) In fact we have many source packages like this, that only exist as workarounds for a flaw the lack of source dependencies in the packaging system. However when I brought this up on IRC, there was some disagreement. So I put it to this august assembly, should source packages combine related but distinct upstream sources or not?

Dear Lazyweb, I'm tempted to buy one of this neat boxes with embedded hard drive, network interface, sound card and TV output to use as a media center for the house. I've seen some of them in an ample range of prices, but all of them lack any detailed description of what's running inside. I'll bet that most of them are running Linux, but I'd like to be able to modify it to my heart's content. For example to use MPD as a music server, be able to mount filesystems with sshfs, and whatnot. I'm also tempted to take the 'Neuf box' that was given by the internet company, add a USB sound card and external hard drive; but already some people jumped to warn me about the dreaded terms of use contract, and all that jazz. Plus, having everything in a compact box seems more convenient for a not so big price. Does anybody have a recommendation on this? Being able to buy it in France is a plus :) Tags: Planet Lugfi, Planet Debian

I recently almost died from a heart attack because after a really horrible crash (don't ask), Debian unstable on my laptop wouldn't boot anymore. The system hung at "Waiting for root filesystem...", and I was in panic mode as I feared I lost all my data (and as usual my backups were waaay too old). At first I was suspecting that something actually got erased or mangled due to the crash, either at the dm-crypt layer, or the LVM layer, or the ext3 filesystem on top of those. After various hours of messing with live CDs, cryptsetup, lvm commands (such as pvscan, pvs, vgchange, vgs, vgck) and finally fsck I still had not managed to successfully boot my laptop. I finally was able to boot by changing the initrd from initrd.img-2.6.30-2-686 to initrd.img-2.6.30-2-686.bak in the GRUB2 menu (at boot-time), at which point it was clear that something was wrong with my current initrd. A bit of debugging and some initrd comparisons revealed the cause: Both, the cryptsetup and lvm2 packages were no longer installed on my laptop, which made all update-initramfs invokations (e.g. upon kernel package updates) create initrds which did not contain the proper dm-crypt and lvm functionality support. Hence, no booting for me. I only noticed because of the crash, as I usually do not reboot the laptop very often (two or three times per year maybe). Now, as to why those packages were removed I have absolutely no idea. I did not remove them knowingly, so I suspect some dist-upgrade did it and I didn't notice (but I do carefully check which packages dist-upgrade tries to remove, usually)...

If you are using QMutex, you are probably writing threaded applications, and thus want to use helgrind (part of valgrind). helgrind has some support for threading and mutexes in Qt, but not fully. If you try to run a app using a QMutex subclass in helgrind, it fails with


<appname>: hg_intercepts.c:2124: _vgwZU_libQtCoreZdsoZa__ZN6QMutexC2ENS_13RecursionModeE: Assertion 0' failed.


Basically, it is the handler for the _ZN6QMutexC2ENS_13RecursionModeE symbol that is implemented as assert(0);. The demangled symbol is QMutex::QMutex(QMutex::RecursionMode), which looks very much like the constructor for QMutex:

$ objdump -T /usr/lib/libQtCore.so grep _ZN6QMutexC
00068840 g DF .text 0000005b Base _ZN6QMutexC2ENS_13RecursionModeE
000687e0 g DF .text 0000005b Base _ZN6QMutexC1ENS_13RecursionModeE


which both demangles into the same QMutex::QMutex(QMutex::RecursionMode) The important difference is the C1 vs C2 in the mangled symbol name. The C1 symbol is used for creating QMutex objects (complete object constructor), wheras the C2 symbol is used for creating subclasses of QMutex (base object constructor). And the C2 handler in helgrind is as said implemented as assert(0);.
So until helgrind is fixed here, please be careful to not subclass QMutex. (the destructor handler for subclasses is also implemented the same way) QMutex has no virtual base class, so even in case of subclassing, I think the helgrind handlers should be implemented the same way in the base object constructor as in the base complete object constructor. I guess I should file a bug against helgrind. A test app if anyone is curious:

#include <QtCore> class mymutex : public QMutex
public:
mymutex(QMutex::RecursionMode=QMutex::NonRecursive);
;
mymutex::mymutex(QMutex::RecursionMode mode) : QMutex(mode)
int main(int, char**)
mymutex m;
QMutexLocker lock(&m);
return 0;


Update 1: Bug filed.
Update 2: Better understanding of virtual base classes. Thanks Thiago

The LA Times has an interesting article about problems with Toyota and Lexus cars [1]. Basically there are problems where the cars have uncontrolled acceleration (there seems to be some dispute about whether it is due to engine management or the floor mat catching the accelerator pedal). When that happens the brakes don t work (due to the vacuum power-assistance for brakes going away when the engine is at full power) and a terrible crash seems inevitable. There are suggestions that the driver should shift the car to neutral and discussion about how the Toyota gear selection makes that difficult. Some years ago I was driving an automatic car on a freeway at 100Km/h and the engine stalled (due to a problem with the LPG system). I had become used to never touching the gear lever while driving so the possibility of moving the gear lever one notch to neutral didn t occur to me. With a dead engine in gear the car slowed rapidly which is quite dangerous when surrounded by 100Km/h traffic. Fortunately I was able to swerve into the emergency lane (across one lane of active traffic) before the car slowed much. That was in a relatively controlled environment with a gear shift mechanism that is a lot simpler than that which is common in some of the more expensive cars. According to Wikipedia the maximum speed limit in the US is 80M/h [2]. It seems to me that Toyota is being irresponsible by selling cars that can sustain 120M/h, while the probability of surviving a crash at 80M/h is quite low, it seems likely to be a lot greater than the probability of surviving a crash at 120M/h. Also if a car is out of control at 80M/h then the driver will have a lot more time to work out how to put the engine in neutral or turn it off the lower speed will extend the time available by more than 50% because bends in the road can be better handled at 80M/h. It seems to me that it would be a feature for the car owner to have the car limited to a speed that is not much greater than the speed limit. According to Wikipedia the highest speed limit in Australia is 130Km/h (in NT), but it s 110Km/h in all places where I have driven. If my car had a governor to limit the speed to 115Km/h and a switch to change the limit to 135Km/h in case I ever drive to the NT then it would not affect my driving patterns (I rarely drive on roads with a 100Km/h limit and almost never drive on roads with a 110Km/h limit) but it could reduce the probability of things going horribly wrong. Also one thing to note is that last time I checked car tyres sold in Australia were only required to operate safely at speeds below 190Km/h (118M/h), so a Lexus that went out of control at 120M/h in Australia might risk a tyre blow-out which admittedly would only make things marginally worse. A governor for the reverse gear would also be a good feature. Some time ago a granny got her foot stuck on the accelerator in a car park and caused serious damage to her car and a parked car after passing close by where I was standing. I don t think that there is a real need to do more than 5Km/h in reverse, limiting the speed would give pedestrians a better chance of escaping parking accidents. One serious problem with some of the Toyota and Lexus vehicles is that it apparently takes 3 seconds to turn the engine off in an emergency! I ve been driving for almost 20 years and experienced a number of dangerous situations, all of which were essentially resolved (for better or worse) in significantly less than 3 seconds. A 3 second delay is as good as a 1 hour delay for safety critical systems. Also if the accelerator and brake pedals are pressed at the same time then the brake should take precedence. It seems quite obvious that whenever both pedals are pressed hard then the driver would probably prefer hard braking to hard acceleration. If you look at industrial machinery (robots, lathes, etc) you will always see big red buttons (or whatever color is used for emergency stop in your region) that are clearly marked and obvious to the workers and to bystanders. Escalators have less obvious red buttons but they can still be shut down in an emergency. It seems to me that there are potential benefits to having an emergency shutdown button in a car, maybe in a position that is accessible to the front-seat passenger in case the driver is incapacitated. Such a shutdown button wouldn t do anything extreme such as fully activating the brakes (which would be very bad on a road that has high-speed traffic), but would prevent acceleration (with some sort of hardware control to avoid software problems) and maintain power to the brakes and the steering. One thing that needs to be considered is that people tend not to do the most logical things when in an emergency situation. It needs to be possible to do whatever is necessary to save your life without any great deal of thought. Pushing a big red button is easy, holding down the on button for 3 seconds or even navigating a gear shift to an uncommon setting is a lot more difficult. It seems to me that there is also an issue of driver training. If putting an automatic car into neutral and cruising to a stop was part of the test for new drivers then the results of such car problems might not always be so bad. But I don t expect there to be any serious changes to driver training or car design. People are too accepting of road deaths. Don Marti has expressed a plan to never buy a vehicle with an automatic transmission because of this issue [3]. But the number of new vehicles being sold with a manual transmission is steadily reducing. An automatic transmission allows better performance (F1 cars have used them for ages), better fuel efficiency (you could never make a manual Prius), a more comfortable ride (the Hybrid Lexus keeps winning the Australian Luxury Car of the Year award), and allows less skillful drivers. Unless Don wants to ride a moped or drive an old car then I expect that he will be forced to get an automatic transmission. Then of course he will still be at risk of other people having car problems (the LA Times article mentions a third party being killed after an out of control car hit them). Also I expect that the extra safety features that are implemented in luxury vehicles such as the Lexus would save a few lives, they should save enough to outweigh the number that are lost on the rare occasions when the car goes out of control. Other luxury cars such as the Mercedes S class have great safety features and don t have a history of going wrong in a newsworthy way. A second-hand S Class Mercedes was surprisingly cheap in the UK last time I checked, cheap enough to make it worth considering the importation of one to Australia. But my solution to these problems is to try and minimise my driving. A 1.5 ton Lexus driving out of control at the maximum speed possible in urban streets won t do much damage to a 20 ton tram.

• [1] http://www.latimes.com/business/la-fi-toyota-recall18-2009oct18,0,2352642,full.story
• [2] http://en.wikipedia.org/wiki/Speed_limits_by_country
• [3] http://zgp.org/~dmarti/wiki/mlp/chromium/

Recently I have been having issues fitting everything I want to do into the time available.

As my kids grow up they always seem to need to be taken someplace or picked up from an activity and that is on top of the daily school run. I recently worked out I spend over eight hours a week, a whole five hundred minutes, taking them to and fro.

Now do not get me wrong, I actually enjoy spending time with my children and we do talk and interact during these occasions but it is hardly a stimulating activity walking to school or being driven to a club.

Add to that my job and its traveling requirements and assuming I want to sleep, eat etc. and all of a sudden I discover I have about forty hours left in a week to share between my family and hobbies.

Anyone with kids knows they are a wonderful time sink :-) and of course the family home often needs something doing. All of a sudden I realize why I feel like I often end up having to trade sleep for my hobbies!

As I get older I find I still have the same number of ideas for projects but the realization that even if I find the time to start something I am unlikely to be able to devote the resources to finishing it. Being one of life's boring people who like to finish a project they start (ok at least make something useful) this means I tend not to start new things too often.

All of this has lead me to become very careful about how I spend my free time and on what. It means my personal involvement in software projects like Debian and the Linux kernel is nowhere near the level I might like. Similarly my music practice (or absolute lack thereof) causes my teacher to get snippy with me.

As you can imagine starting something like a blog when I do not have enough time for what I am already doing is something of a challenge for me and may indeed falter. However I shall give it a chance as I feel a need for public place to share all those small things which I would probably put on my personal website if I had time to work on it ;-)

My friend Sean from OpenMoko recently gave me one of OM's new WikiReaders. It's essentially a touchscreen-based device dedicated to displaying Wikipedia articles offline. And while I'll never forgive the thing for not having an Edit button, I've got to admit the device is pretty cool. Not only does it make it possible to bring WP to a bunch of places that are otherwise impossible or impractical, the thing is built entirely with free software. One of my colleagues at the Center for Future Civic Media suggested we should put one in every bar to help settle drunken arguments. Think of the lives we might save! I hope the device becomes successful but I'm worried about what success will mean for the already indefensibly large gap between the number of readers and editors on Wikipedia. After all, the ability to change and contribute is the thing that makes Wikipedia interesting, empowering, and successful; cutting this functionality out kind of misses much of the point. I think it is important to start implementing a simple method to allow users of these types of devices to contribute back. Over the last few years, Sj and I have talked repeatedly about a simple method for contributing back from offline devices that would even be possible from devices like the Om Wikireader where editing the articles is probably impractical. Perhaps the device could be extended so that people could write short comments about articles from their reader --- there's an on screen keyboard after all --- which could be saved to a log on the SD card. When the data on the card is updated, messages from this log could be uploaded somewhere --- perhaps the talk pages of the articles in question or some dedicated page or ticketing queue. Editors could help merge these changes back into the articles.

The Automatic Rule Based Time Tracker that I have created some weeks ago is now available in Debian unstable, so if if you were reluctant to use it because you did not want to figure out how to compile the Haskell code, you can just do apt-get install arbtt.Although it s such a young project, it already has a fork: Andreas Kl ckner was very impatient with a feature request (sensible merging of logs from different hosts), so we went ahead and re-implemented arbtt in python, named whatup. Although I prefer contributions to arbtt, it shows that the principle of arbtt is useful. And I won t be shy to copy nice ideas from him, as well :-)

Saturday I have uploaded munin 1.4.0~beta-1 to experimental, though it is currently awaiting NEW processing, as it introduces new binary packages. This upload is due to the awesome work of Tom Feiner who joined the munin maintainers team following up on the RFH bug I filed in July 2009. At first, Tom helped out with some bug triaging and worked on some patches. So he then got commit access (to the svn repo which hosts both upstream code as well as the debian packaging), which quite soon he also used to fix issues in upstreams trunk too and finally prepared this release mostly on his own, with me just doing some mentoring work. Overall, I'm totally impressed and happy with his work on the package. Tom, kudos & thanks a lot!

Munin 1.4.0 comes with a lot of new features (the most important ones being SSL and multigraph support) and new plugins, and of course, lots of bugfixes too. If you're curious, read the upstream changelog. Also noteworthy, the number of (Debian) patches has gone down from 64 to 8!

Please report bugs and experiences to munin-users@lists.sourceforge.net unless they are specific to the Debian package, in that case, please use the BTS as usual. The final 1.4.0 release is scheduled for this friday, unless real blockers are dicovered :-) Expect it to hit unstable on friday or saturday too, unless real life or other blockers prevent it :-)

If this post has made you curious and you cannot wait for the package to leave NEW, svn-buildpackage it yourself from the debian experimental branch.

Every now and then I have a demoralising experience with the quality of Debian packages in sid. That's to be expected, sid is a development distribution, but it still sometimes gets on my nerves. I've decided to write about some of my experiences. Some rules: I may not rant without Earlier in the week I was interested in doing some very simple video editing. A bit of searching and I come across the name of a potentially useful program: 'pitivi'. As luck would have it, there's a Debian package! However, the program within won't run. I also discovered more or less immediately that the package (provided a useless, whitespace only README file)[http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=556850]. Today I was looking at tracing stuffs, and I discovered etrace. The very first action I tried after installing it was to look in /usr/share/doc/etrace -- which was devoid of documentation. (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514083)

Russell Coker writes about shellscripts. I have a different suggestion. Whenever you think that a shellscript is the right solution to a problem, you are mistaken: do it in a proper scripting language instead. Having access to proper data structures will mean you don't have to contort your code to fit values into scalar strings, or write loads of temporary files, or call cut/awk/sed/grep etc. repeatedly on the same inputs to get at different fields, etc. etc. etc. I reckon nine times out of ten it's the right decision. But when you just have to use a shellscript, use set -e (as Andrew Pollock points out, this is safer than putting it on the hashbang line and set -u too.

I've been intermittently prodding at the Debian release-critical bug list for some time, but inspired by Zack and Tim I've decided to start keeping track, if only for my own interest.

• Monday: openipmi Debian bug #474087 + patch (not uploaded since I have no way to test IPMI libraries, not having the appropriate hardware...)
• Monday: potential candidates for removal:
  • skyutils (RC bug, library with no reverse dependencies since smssend was removed in 2008)
  • libhid (RC bug, RFA since August 2008, mainly exists to support libphidgets)
  • libphidgets (RC bug, RFA since 2007)
  • libnoise (RC bug, library with no reverse dependencies or popcon votes)
• Thursday: hercules Debian bug #553110 uploaded to DELAYED/7, with various bonus changes including making the copyright file sufficient to satisfy Policy 12.5
• Friday: spider Debian bug #537631 fixed by a QA upload, fast-forwarding through 8 years of Debian policy and upgrading from debhelper 3 (!) to 7 in the process

In general I've been trying to avoid resurrecting packages that I don't think should be in the archive, even if the fix is trivial. I'm not sure whether that applies to spider; according to popcon, it still has a substantial number of users, so it may be worth keeping even if there are no upstream releases (also, it amused me to convert such an old package to Debhelper 7 and dpkg source format v3). In the process I've discovered that git-buildpackage makes a great NMU tool. I'll probably be putting all future NMU diffs in my users/smcv directory on git.debian.org (at least until the maintainer acknowledges or rejects the NMU), just because it's a convenient way to give the maintainer a nice queue of individual changes rather than a monolithic diff; if any maintainers decide they'll use git as a result, that's a bonus :-)

Since I came back from Dublin I had pending to release the new ebox-radius module. This new module for eBox Platform 1.2 brings integration of eBox LDAP users with FreeRADIUS allowing the deployment of WPA/WPA2 EAP wireless authentication using eBox. In fact is very simple as seen on the screenshot, you can choose whether all the users are able authenticate or just a group of them and the NAS clients that can query the RADIUS server. This module is still in beta, but packages for Hardy are available from my PPA so you can try it in your eBox 1.2, a version for eBox 1.3 will be released very soon. FreeRADIUS packages where self builded because of #266299, I hope this can be fixed very soon, see Debian, EAP, and the OpenSSL and GPL incompatibility. If you give it a try, please give us feedback on the forum or the mailing lists.

Dear Lazyweb, do you know how to theme Tk apps? In the default setting, Tk apps running on my KDE4 desktop, cause spontanous eye cancer: there must be a way to theme them to look like the Qt or at least GTK apps, or not?