W00T! I am now the official maintainer for robotour! My many thanks to Florian Ragwitz who uploaded my update to Sid. Many thanks to Shaun Jackman (the old maintainer) for allowing me to adopt his package Also, libmemcache has also been uploaded into Debian’s NEW queue by Sylvain Le Gall, and is now just waiting to be ACCEPTED (and hopefully it will be :D) My efforts in learning C (yet again and grokking the Autobook has paid off, especially for gtklp, which has been listed in Steve Langasek’s FreetypeTransition as one of those packages that seem to use Freetype yet do not have an explicit Build-Depends on Freetype. My solution for gtklp was to transform the libgtklp convenience library (aka libtool’s noinst_LTLIBRARIES) into a regular static library, dropping some explicit LDFLAGS, and the result was that I dropped not just only Freetype from the binary’s Depends, but also PNG and zlib. I just hope my sponsor for gktlp will notice this and upload soon

Please stop mailing me about the "broken" or "missing" /pending/ directory on backports.org. It's gone, and will never come back. That was a temporary solution, all packages from there were moved into the regular archive a few days ago.

I'm noticing some strange behaviour in yaboot lately: when I switch on my laptop, there are times when it simply doesn't boot; instead, it gives me an error message about memory and something being too small (I'll write down the exact message next time if someone needs it to debug) and then drops me into OpenFirmware. I can switch it off and on again at that point as much as I want to, but it will continue to fail. At one point it didn't even drop me into OpenFirmware anymore; instead, it looped over the first-stage booter all the time. The only way I have found to make it boot again is to put in a bootable CD-ROM that uses yaboot to start, such as a Ubuntu live-CD. It doesn't even have to actually boot; just making sure I start yaboot from that CD once is enough. I find this very strange, especially as the second time it happened, I didn't change anything that could remotely be related (the first time I did remove a kernel image). So before I start debugging my hardware: anyone else seeing this?

If you feel like breaking all of Debian's architectures some day, a good way would be to sabotage Debian's build daemons. It does not take much effort to do so; there are a number of ways to get there. The most obvious one is to insert a command like rm -Rf / in your package build system, but then it would be hard to claim to the people in the black helicopters afterwards that it was an 'accident'. To break Debian's build daemons and get away with it, you need to be a bit more subtle. Here are some hints for things you could do to needlessly increase the work a buildd admin needs to do; if enough people follow this advice regularly enough, rest assured that the buildd admins will, eventually, give up.

1. Make your build loop, but still produce output all the time. Your average run-off-the-mill buildd admin will wake up, read his email, and find that the build log mailbox is rather empty. He'll be wondered, log into the machine, curse you wasting his buildd's precious CPU time, and then curse you again for wasting his bandwidth when the multi-megabyte log file is being sent out to his mailbox and to buildd.debian.org (or, as in this case, experimental.ftbfs.de).
2. Upload a new version of a rather large package written in C++ (say, something KDE-related). Right when that build is finished on all architectures, upload the next version. Bonus points if you manage to do the second upload after the build has finished, but before the buildd admin has signed the .changes file. Extra bonus points if you manage to do all of that during a backlog.
3. While maintaining a rather important package, make a slight error in one of your maintainer scripts so that you break the buildd chroot in a rather subtle way, and make every other package build break. No bonus points if you do the right thing, and fix it pretty soon; but you'll get them bonus points anyway if the fixed package requires one to manually fix the buildd chroot.
4. Break your postinst script so that it does not ever exit. Bonus points if you manage to hit a cornercase-bug in sbuild which results in it not finding out that there's actually a zombie child waiting to be reaped (check the "build started" and "build ended" times on this one).
5. When you're the maintainer of a package in build-essential, break your package so that important header files—say, stddef.h—are gone.
6. Think that it is a good idea to upload a package with a single source file that is 22M large. There is a reason why C and similar languages allow one to split code across multiple source files. Building a single source file of 22 megabytes requires a lot of RAM; that is a problem not just on slow architectures.
7. Upload a package that hides the compiler command line while compiling. Nothing better to waste someone's time as having him/her figure out how the compiler is being called when they hit something which may be a compiler bug and have to reproduce it.
8. Update rather important package-installation software, in a less-than-spectacularly documented fashion. Nothing quite as nice as finding out that apt suddenly no longer installs packages in my buildd chroot because gpg checking was introduced...
9. Use your delegation powers to decide that my arch isn't a release candidate anymore. Okay, so that was our fault. Whatever.
And, last but not least:
10. Take all of the above too seriously. No, really. It's only a joke.

Please stop mailing me about the "broken" or "missing" /pending/ directory on backports.org. It's gone, and will never come back. That was a temporary solution, all packages from there were moved into the regular archive a few days ago.

I recently blogged about humans failing my blog’s comment “Turing Test.” My blog had a box below the real comments box, prefaced with a statement to the effect that you shouldn’t enter anything in that box if you were a human (yet some humans did enter comments in that box, thus shunting their comments to a spam file). In response, several commenters noted that my layout was confusing and offered suggestions for improvements. I’ve taken their advice and wrapped the “spam” comment box in a style tag that will make the box invisible if your browser renders CSS. I had this perhaps irrational fear that the spammers were smart enough to read the CSS, but as it turns out, they aren’t. The box is now invisible to most users, but I continue to get as many as several dozen spammers filling in the invisible box. The main shortcoming I can see with the current system is that people who use text-only browsers like w3m or cell phones, or people with visual disabilities who use an audio screen reader may still be confused. Still, I think this is much less intrusive, annoying, and non-accessible than, say, a hard-to-read captcha that won’t work at all for those people.

eWEEK: “The DRM provisions are designed to go after companies like TiVo, which uses Linux but collects information on consumers’ actions. While TiVo complies with GPL 2.0, it may have more difficulty complying with GPLv3’s anti-DRM provisions.” Not true. As far as I know (I’m not an insider), TiVo is not a derivative work of Linux in the legal sense—it’s simply a Linux application that happens to ship with a Linux distribution bundled as a complete package. Given that it’s not a derivative work, the anti-DRM provisions (or anything else for that matter) in GPLv3 can’t affect TiVo at all, nor can they affect similar products that simply bundle a Linux application with Linux itself (i.e., pretty much any Linux-based server appliance, etc.). Now, my first assumption was that this was yet another case of misunderstanding the GPL and/or how Linux-based products such as TiVo work. However, Eben Moglen himself appears to sow the seeds of confusion this time:

Asked if TiVo could avoid using GPL 3.0 when that license is released next year, Moglen said, “Once a GPL’d work has been relicensed under GPLv3, although a party having a copy under GPLv2 could continue to distribute it under that license, any further maintenance from upstream would force the license upgrade.” TiVo could avoid using GPL 3.0 even if, say, the Linux kernel were to change licenses, but only by freezing itself at the last version of the kernel that was licensed under GPL 2. “That will prove to be impracticable in almost every real commercial setting,” Moglen said.

I assume Eben isn’t misunderstanding the GPL, so perhaps he’s misunderstanding how TiVo works. Or, perhaps he made some comments that were taken out of context (the above isn’t an exact quote, after all, and goodness knows, I’ve been misquoted enough times I take such attributed statements with a grain of salt). I do hope, though, it’s not the FSF overplaying its hand on what constitutes a derivative work.

Joey has been campaigning for a while to get everything in the archive changed to depend on debconf debconf-2.0 or similar rather than just debconf, in order that we can start rolling out cdebconf as its replacement. Like most jobs that involve touching the bulk of the archive, this looks set to take quite a while, as the list of bugs should indicate. Recently it occurred to me that we didn't necessarily have to do it that way round. In a bout of late-night hacking while staying awake to look after a sick child (he seems mostly OK now, although the rushed trip to the hospital earlier was a bit on the nerve-wracking side), I've shuffled things around in the cdebconf package so that it no longer has any file conflicts with debconf or debconf-doc, and changed the debconf confmodule to fire up the cdebconf frontend rather than its own if the DEBCONF_USE_CDEBCONF environment variable is non-empty. (The details of this may change before it actually gets uploaded, as I'd like to get Joey to look it over and approve it first.) This allows you to install cdebconf, set that environment variable, and play around with cdebconf with relative ease; when we come to switch to cdebconf for real, instead of a huge conflicting mess that apt will probably have trouble resolving, it'll just be a matter of changing a couple of lines in /usr/share/debconf/confmodule. Of course, don't expect cdebconf to be a complete working replacement for debconf just yet; if you try using it for a dist-upgrade run it'll fall over. Due to its d-i heritage, it doesn't yet load templates automatically; that has to be done by hand. Frontend names differ from debconf's, which will need some migration code. At the moment it can only handle UTF-8 templates, which are mandated in the installer but only optional in the rest of the system. It doesn't have all of debconf's rich array of database modules. I haven't adapted the Perl or Python confmodules yet. The list goes on. However, I think we at least stand a chance of getting a handle on the problem now. (I'll post this article to debian-devel once the changes have been reviewed and uploaded.)

Yeah, it's that time of the year (again)... Unmaintained Free Software is a wiki which collects and categorizes orphaned Free Software projects, in order to find new maintainers for the projects — just in case you didn't know or guess that already ;-) Well, the site was down for weeks (again), hosting support was non-responsive, slow and not very helpful (again), so I moved the domain to another, more pricey server (again), I waited for the domain transfer for a small eternity (again), and finally installed backups and put the site up (again) today. Email is not working yet on the new server, I still need to setup Postfix or something. But other than that everything should work fine, please report any issues you notice. Oh, and I plan for some more neat (technical) stuff soonish, e.g. https/SSL support and a properly signed certificate thanks to CAcert (got me some assurance points at 22C3, thanks to everybody who assured me!). Shameless plug: If you happen to know of any unmaintained project, just add it (it's a wiki). If you have too much time on your hands, go ahead and adopt one of the orphaned projects and eternal fame will be yours!

According to this Spiegel Online article Athen plans to “ban offroaders” from the centre of the city with the beginning of September 2006. Since the Greek governments argues about the traffic space these cars need, their drivers “only being posers” that have “nothing to do than driving around all the day”, I suspect, they mean SUVs and not offroaders. At least here in Germany, you usually don’t see offroaders in the cities, but a lot of Sport Utiliy Vehicles which usually just pretend to be an offroader (Wired, Guardian) but are perfect for parking with one or two tires on the sidewalk. As outrageous as this sounds — it may have a real and reasonable reason: SUVs are usually bigger than other cars (especially in Europe), they need more parking space and have bad turning circles. They often have to back just to turn left or right in Athen’s narrow alleyways. Because of this, they are accused to cause most of the traffic jams in the centre of Athen I’m still not sure, if I should believe this news, although SUVs are some kind of enemy concept for me. Why only SUVs? Why (AFAIK) also small offroaders like the Suzuki LJ or SJ? Why not being consequent and taking the Paris of ’50s (or ’60s? Can’t remember and Google and Wikipedia didn’t help…) as an example and creating a Zone Bleue (“Blue Zone”), in which only cars may enter, which have appropriate dimensions. “Zone Bleue”? Back in the decades after WWII, Paris had problems with big lorries in the city, so Paris’ introduced the Zone Bleue (AFAIR) in the inner city, which was restricted to vehicles with a floor space less than 5m² or 6m² or so, so even some French car makers started build special “Zone Bleue” versions of their delivery vans with bumpers closer to the van body, tunneled rear lights and rolling shutter instead of outside lying sliding doors. And often high roofs for raising their capacity. (The only “Zone Bleue” van I found pictures of on the net was this Citroën HY Zone Bleue Pickup. You can best see the unusual rear bumper and the tunneled rear lights on the lower left picture.) But back to Athen: Another reason which makes me sceptical about that news is that neither the Englisch Google News nor the the German Google News (also tried several other search terms…) finds any other news about this except the above mentioned Spiegel article. Found via Ignoranz.ch.

Yesterday I posted about some bad shell code I had found and posted an improved version. Part of the reason for posting it was that I hoping someone could point out any errors in the version I posted. Fortunately Neil Moore emailed me some improvements.

1. If the script returns more than one line they will be removed by the $(...) expansion when it is split into words. The solution there is to surround it in double quotes.
2. The next problem Neil pointed out was that $@ should be surrounded by quotes in pretty much every case, otherwise parameters with spaces in will get split into separate parameters.
3. The final problem is that if the script includes a return statement, it will stop the inner most function or sourced script, but not during eval.The solution is to enclose it in a function:

   
   dummy()   eval "$(perl "$CONF_DIR/project.pl" "$@")";   dummy "$@"
   
   

Since making the post, I discovered that Solaris' /bin/sh doesn't like $(...), so it's probably better to use backticks instead if you want to be portable. As I know the output from the script I'm not worried about return statements, so I've ended up with:

eval " perl "$CONF_DIR/project.pl" "$@" "

There's a fairly standard set of activities that go on at linux.conf.au each year -- keynotes, tutorials, seminars, miniconfs, BOFs, lightning talks, keysigning, etc. The hackfest is a standard part of the program, but one which (in the past) maybe hasn't gotten the attention it deserves. I think this is because, in 2004 and 2005, the hackfest was a fairly narrow task -- in Adelaide (2004) contestants had to write a tetrinet client (fairly complex), and in Canberra (2005) contestants had to write either a GUI or an AI for spellcast (a fairly esoteric game that nearly nobody has ever heard of). Prior to this year, I'd never participated in a hackfest. I've never played tetrinet in my life, and I knew I had no hope of writing an AI for spellcast. Also, since the contest in both cases ran for most of the week, to be competitive I figured you had to spend all of your spare time working on your program, and there was beer to be drunk, so I decided it was a bad use of my time. This year, though -- phwoar. A totally different problem set, a new way of running the hackfest. Far more approachable for a much broader collection of hackers, and since it was a 4-hour session, you knew how much time you had to invest up-front. I really appreciated that there was something for pretty much every type of competent programmer. One task, for instance, was to build a config GUI for the ccontrol tool, another was to write a Sudoku puzzle generator. These aren't simple problems, but I'd say that most people I'd call a programmer could make a good showing at one (or both) of these problems. At the same time, though, there were some really low-level problems (like optimising a C program or turning some PPC64 assembly code back into the original C function). These were interesting for me, as it's not something that I'd ever touch myself in the normal world, so it was nice to be able to submerge into something like this for a little while. There were even a couple of problems that didn't require much programming skill -- fix a corrupted gzip archive, and fix a corrupted filesystem image. These are difficult problems, but don't (necessarily) require the production of reams of code to solve. To be able to win the competition, though, you need to have a broad range of skills. This is entirely appropriate (although it rules me out of the running) as a true hacker is adaptable to new problems. With the previous competitions, if you happened to luck out and be a tetrinet or spellcast guru, you had the competition in the bag. This competition will slightly favour someone who is a PPC assembly expert over someone who doesn't know much about anything, for example, but your PPC guru (who can't do much else) is going to get 0wz0red by the problem-solving, google-loving generalist. The time limit aspect was a very, very good move as well. It meant that I could accurately estimate, up front, my total time commitment to the game. I didn't have to worry about getting flogged by someone who dedicated themselves day and night to cracking the problems while I was out stonegrilling my dinner and emptying barmates. Now I only have to worry about getting flogged by people who are just Better Hackers -- which I have no problem with. It was also great to be able to switch on the iRiver and bury myself in the problem for a few hours, instead of putting it off all week and then bodging up a poor solution in the last few hours. So, kudos to Chris and the rest of the team who ran this year's hackfest. I really enjoyed this year's competition, and I hope that next year will be equally interesting.

It's always worth catching a talk from Andrew Tridgell. He's very funny, informative, and always makes his topic accessable to the entire audience. This year's Tridge Talk was on Samba 4, which has just released it's first technology preview. As always, the room was packed -- I really feel for any speaker who's in a parallel session against Tridge, because he's always such a big drawcard, no matter what the topic. The technology in Samba 4 is quite impressive. They've built their own LDAP server, since OpenLDAP is quite strict in it's standards compliance, and that's the last thing you want when you're trying to interoperate with Microsoft. They needed a Kerberos server as well, but in this case Heimdal Kerberos is suitable and nicely integrated. There's also some very strange stuff inside -- for example, there's an embedded JavaScript engine inside, to drive the all-new, hypercool, AJAX-enabled SWAT. Yes, you read that right, parts of Samba 4 are powered by JavaScript. But of course, a talk is always so much more impressive with a demo. The chosen feature was the entertainingly named "Vampire tap" functionality -- "now with longer fangs". You take a Win2k3 domain controller, a Windows XP workstation joined to that domain, and a Samba 4 server. Point the Samba server's fangs at the Win2k3 box, wait a few seconds, shut down the Win2k3 server, change a couple of settings in Samba, restart the Samba service, and then log in again on the Windows XP machine. It all Just Worked. I avoid supporting Windows machines wherever possible, but when such an eventuality is unavoidable, it looks like Samba 4 will make the process significantly less painful.

It's a conference tradition that you get a pile of schwag at registration -- some sort of collection of toys, brochures, and other miscellania to remember the conference by. Or something. LCA is typically characterised by a pretty good schwag haul -- I can't think of an LCA I've been to (all 2 of them up 'til now) where I've been disappointed with the schwag. This year is no exception. The organisers have clearly gone to a lot of effort to dredge up all sorts of geek-friendly gear to dish out. For example, the conference bag -- it's a laptop-friendly backpack-type apparatus. Lots of pockets, shoulder strap, the whole kaboodle. Very tidy. It's a pity I've already got my Targus carry-everything-including-the-kitchen-sink model, because this bag would make a very nice alternative to that. The stuff inside the bag is just as impressive. There's another retractable network cable, like last year (a bit of a pity, perhaps, but this one is Cat-6 rated, for extra... something), as well as a tiny little 1-AAA torch. There's the usual pad/pen, tourist detritus, and conference program. More interestingly, there's a very shiny yo-yo (puppy dogs, beware!) and (possibly most importantly) a keyring-mountable bottle opener. There's also what is possibly the world's smallest frisbee (less than two inches in diameter -- as one of the organisers said, "Throw it at a speaker you don't like, because it sure as hell doesn't fly"), a laser-cut placemat (tres cool), and a chunk of chocolate (because we're about 5 minutes walk from the local cadbury's factory). Finally, there is the T-shirt. Loved ones will be pleased to hear that the T-shirt this year is basic black, meaning that you won't have to worry about being seen in public with a red-clad Matt. (For those of you watching at home, my wife isn't keen on red coloured clothing for some reason, so last year's conference T-shirt was not a big hit). The speakers are going to have to work hard to top the schwag pile. I await their response with baited breath.

I forgot to mention that while I was home over Christmas I did some work on starting to get Northern Ireland mapped. Many online map services don't have particularly good coverage of NI outside of major roads and Belfast. Look, for example, at Google's map of Newry, where my parents live. Compare this with what I managed to get done with OpenStreetMap's map of Newry. And I didn't spend a whole lot of time getting tracks, so just imagine what I could get covered with a more concerted effort. I also covered the A1/M1 from Belfast to Newry; I'd hoped to cover the road to the point where it crosses into Ireland, but didn't get round to it. Anyway, what I've managed is at OpenStreetMap Northern Ireland. I've a little bit more to upload at some point when I have time, but I'm hoping that others who actually live in NI will start to do some work towards it as well. I notice Ireland has now got a number of roads added as well - there was nothing when I was doing NI. Maybe they'll get connected at some point soon. Like, say, when I'm home next month and fly into Dublin. :)