Many languages are spoken in more than one country, and many countries have more than one language. When you forget this you do stuff like language selection menus that use flags to represent languages. This is problematic for several reasons, starting with having to ask yourself what flag you are going to use to represent English, and how to deal with the angry letters you’ll receive when you use the national flag to represent a regional language. So, using flags to represent languages is definitely discouraged. This said, have a look at this small piece of the KDE l10n stats page: The funny thing is that the flag you see next to Galician is the flag of Greenland. And Galician is not spoken at all in Greenland! So, what happened? Why did they use so wrong a flag? The problem is that the ISO 639-1 code for the Galician language is gl , which is the same as the ISO 3166-1 code for Greenland. So, when choosing the flag for Galician they confused the language code with the country code and selected the flag for gl : that is, for Greenland. (I’m surprised that they used the Ukrainian flag ( ua ) for the Ukrainian language ( uk ), and not the Union Flag. Perhaps that would have been too obvious an error :) – although I have been told by email that the ISO 3166-1 code for the UK is GB , not UK ) So, my takeaway message is: don’t use flags to represent languages and if you do, make sure you use a flag of a place where the language is actually spoken!

Leon writes about giving a stranger $1 to help him get a train ticket. Recently I saw something similar, a lady was giving balloons to children in the Bourke St Mall in Melbourne just after 9PM. I asked her about this (I couldn’t see a logo on the balloons and wondered how she was making money). It turned out that unlike almost everyone else who gives out balloons in shopping areas she wasn’t trying to advertise a product to parents, but her hobby was to give out balloons to children. I regret not asking her more questions, I wonder why she was doing this after 9PM (there aren’t many children out then), whether she always hangs out at Bourke St, and what gave her the idea to start doing this.

Share This

Many Linux fans know that Debian Stable usually already lost the “b” when it’s being released. ;-) What seems not so well known (especially not by some DesktopBSD Marketing guy at last year’s LinuxDay.at :-) is that there is really a lot of people who really like this “stale” software collection — because it’s rock solid — especially compared to the ports in FreeBSD or DesktopBSD *evilgrin* which unnecessarily follow every new feature upstream introduces. This is really annoying in a server environment where you want as less changes as possible when updates are necessary due to security issues. My personal favourites here are Samba and CUPS. *grmpf* Although I belong to those people who run Debian Stable even on brand-new hardware, I sometimes have to use the newest beta or alpha versions of some software to get it even only running. And doing so is fun but feels strange somehow, though. Currently I follow the pre-releases of three software makers quite close, due to a new laptop: At the beginning of last semester I bought a brand-new Lenovo ThinkPad T61 (2,2 GHz Intel Core2 Duo T7500, 4 GB RAM, 160 GB HD, 1440x900 14” Widescreen) without preinstalled operating system (possible thanks to the ETHZ Neptun Project) and installed — of course — 64-bit Debian Stable on it. While the Debian Installer from Etch worked fine even on such new hardware, not all features worked out of the box because some components were just too new. So the first thing I did was installing 2.6.22 from Backports.org, quickly moving farther to vanilla 2.6.23. Nearly everything I needed worked except the wireless network card. It needs the iwlwifi driver which is officially in the Linux kernel starting at the upcoming 2.6.24 (said to be released during the next few days). So I run 2.6.24 pre-releases on the laptop since the first release candidate, always eagerly waiting for either the next RC or the final release. (And 2.6.24 looks impressively stable to me — even since the early release candidates. :-) I even got the fingerprint reader working for login and sudo (but not xscreensaver) using libthinkfinger backported to Etch from Debian Experimental. I’m just not sure if this is a good idea since the back of the screen already has enough of my fingerprints on it. ;-) The next software of which I’m currently running an alpha version is 64-bit Opera 9.50 (aka Kestrel, available at snapshot.opera.com) because no earlier Opera version is available for 64-bit Linuxes. Here I had different experiences: The builds from October and November were already quite stable, but since December it crashes usually several times a day. At work I also run the 64-bit Opera on my workstation, but stalled updating it when I noticed that it became so unstable. So my Opera at work has currently an uptime of nearly four weeks — and would have probably more if I hadn’t rebooted my workstation in Mid-December. Somehow this hunting for new versions and eagerly waiting for every new (pre-)release makes me really fidgety sometimes. And my understanding for people doing this for there whole userland or even operating system has grown, but I still prefer to have stale but stable software on all my productive machines, even on my laptop — just with some few and handpicked excpetions. The third but less thrilling thing I’m following are nVidia drivers for X. Since the free nv driver of X.org doesn’t support (and not only just doesn’t know) my graphics card yet and nouveau isn’t ready yet, I run the binary only and closed source driver from nVidia, waiting for that one release which supports Xen since I really would like to run a Xen guest with Debian Unstable for testing purposes and package building on my laptop. Until then I have to content myself with the much more unwieldy QEMU respectively KVM. Anyway, I’m very happy with the T61 and Debian Stable and can easily connive at the few not (yet) perfect issues like missing Xen support by nVidia, broken ad-hoc mode in the wireless card, no internal card-reader (as announced in the Neptun specifications) and no native serial port. Some useful links regarding the subject of this post:

• Linux Weather Forecast
• Opera Desktop Team
• Nouveau: Open Source 3D acceleration for nVidia cards
• ThinkWiki

Now playing: Jean Michel Jarre — Rendez-vous à Paris

Long time ago I used FnFX to handle events from ACPI keys on my Toshiba notebook. However when reinstalling notebook because of disk crash, I thought there must be a cleaner way to handle these and I found patch for acpid which added handling of these special events. However I really didn't like patching acpid on every update and there didn't seem to be chance to merge it upstream, so I started to look for better solution. After another amount of googling, I found that HAL already has some support for Toshiba hotkeys. Unfortunately it is now disabled in Debian because most key did not emit anything using HAL. Okay, let's fix the HAL, maybe it will get later enabled. Converting FnFX keymap to C code was quite easy and I made a patch for HAL to add support for all keys. Hopefully it get merged soon and I can then file bug on Debian package to reenable Toshiba support in HAL. Meanwhile I'd like to find some generic way of configuring what happens on these events. For now I hacked simple Python script which listens to DBUS events and invokes appropriate commands for keys, but I hope that some such tool already exists and I just missed it. If you know something, please let me know at michal@cihar.com.

Earlier today, I started reading about the DjVu family of document formats. It really sounds slick: file sizes much smaller than PNG (and incredibly smaller than TIFF or PDF) for lossless data with the DjVuText format, file sizes much smaller than JPEG with equivalent quality for the DjVuPhoto format, and an advanced DjVuDocument format that separates the background photo from the foreground text and produces a quite nice output. There are wonderful plugins for browsers on all platforms, and server-side support already in Debian for sending pages incrementally as needed by clients.

I tried this out a bit and indeed it looks great on monochrome scans, and I made a quick try of DjVuPhoto as well. That part looks great.

So here's the bad news.

Debian has no nice way to generate DjVuDocument files. There is a PS/PDF-to-DjVu converter that uses a djvu driver for Ghostscript. But Debian does not include that driver. Though, strangely, the program that depends on this driver is actually in Debian main. (Bug filed.) That program actually will make background-separated images, but only if they are separate objects in the input.

All Debian has is a program csepdjvu, which requires you to somehow manually separate the foreground and background images. Ugh.

So there is no way using software in Debian to produce DjVuDocument files with automatic separation, either from scans or from a digital source. It appears that there may not be Free Software to do this from scans either. This fact is not made clear at all in the DjVu documentation that is around.

I don't know why some people always shout censorship when it's about what is acceptable behaviour and what not and about what things people want to be assosiated with and with what not. (Must be some relative of Godwin's law (the original, not the "you lost" usenet-variant)).

I personally do not care only little about what happens in irc-channels I'm not in. I don't know what happens in this this special channel starting the discussion, and I don't believe any anedotically examples can make a big difference. (Humans err, sometimes in tone, and even some hundred examples of wrong tone in some backyard alone is nothing I care much about, as long as it is nothing that would be a criminal offense if done in more public places).

What I absolutely dislike is any form of communication forum - especially those that could be associated with me - to be declared as a place where foul behaviour (to which I count sexism) is acceptable and even worse to be accepted as norm. (Why didn't anyone shout "censorship" at the "Love it or get the fuck out of here"? Perhaps there is some correlation between views of the world I don't understand).

By the way, there are places where I feel personally offended as a victim of sexism by a statement like "men are pigs". For example in a discussion about sexism. (I know, I know, it might not be sexism according to some definitions, but I see no reason to not use the word or not dislike it just because the forcing into gender roles is done by members of the same sex as opposed to to members of the opposite sex.)

In an old post I dealt with the nice mod_chroot module to secure your multisite server. I also adopted recently vlogger in order to manage better apache logs for virtual hosts, when you have dozens or hundreds of them. Unfortunately the suggested way to use it (a simple piped command) does not work nicely with mod_chroot, because the piped command has to run in the chroot jail.

Of course, it is not a good idea installing the whole perl intepreter and all required modules in a minimized jail, so I adopted an oldish classic trick (the old things are always the best) to solve the issue: using a named pipe. You basically need to do something like the following:

mkfifo -m 600 /var/run/apache2/logger && chown www-logs /var/run/apache2/logger

cat /var/run/apache2/logger /usr/sbin/vlogger -u www-logs -g nogroup -s access.log /var/log/vlogger >/dev/null 2>&1 &

/etc/init.d/apache2 start

Of course your log directives will be something like:

LogFormat "%v %h %l %u %t \"%r\" %>s %b \"% Referer i\" \"% User-Agent i\"" vcombined
CustomLog "/var/run/apache2/logger" vcombined

You absolutely need to run the reader before the writer, else the init script would hang for ever. It is easy adding a simple init script to run vlogger before apache and it has also the big advantage of not requiring re-fork a perl intepreter at every damn log action. Piping rocks.

So Sun has snapped up MySQL. Thinking about the express editions of their SQL database offerings Microsoft, IBM and Oracle released a few years back, to compete with MySQL, I wonder how nervous this news makes them.

I also wonder whether Sun would start offering a default MySQL installation option on their servers. This could make for some more nervosity. Especially if they do it also for their Windows servers...

After the debacle last time I tried to grow the size of my existing RAID1 when I put new disks in daedalus, I thought this time I'd do my homework. I did some research, I found out the way I should have done it. I did a practice run on a USB key. I fully planned how I was going to do it:

mdadm /dev/md2 --fail /dev/sdb3
<delete /dev/sdb3, recreate at new full size>
reboot
mdadm /dev/md2 --add /dev/sdb3
<wait for sync>
mdadm /dev/md2 --fail /dev/sda3
<delete /dev/sda3, recreate at new full size>
reboot
mdadm /dev/md2 --add /dev/sda3
<wait for sync>
mdadm --grow /dev/md2
<wait for sync>
pvresize /dev/md2

Everything went as planned, until I went to grow the RAID1 volume. It still thought the underlying device was the same size. There was nothing to grow. So at this point, I decided to do something similar to what I did last time to get around the failing disk, and should have done last time anyway. I broke the mirror, created a new degraded RAID1 using the full size of the new partition on the half I pulled out of the mirror, and did a pvmove from the old non-full-sized degraded mirror to the new full-sized degraded mirror. All of that went swimmingly until the pvmove was around 50% complete, when the kernel decided to oops spectacularly. I had to power cycle daedalus to get it back under control, and even in single-user mode, without me doing anything, the kernel started oopsing again. Dammit. I had to boot into emergency-mode (insert standard gripe about Debian's single-user mode being far too non-singular here), then I could resume the pvmove without any further oopsing. After that completed, I was able to ditch the old non-full-sized degraded RAID1 device and resync the new one onto the old partition. There was still some minor filesystem corruption, more likely because I had everything mounted at the time of the crash. Yes, I still haven't learned not to do this kind of thing in multi-user mode. It seems every time I try to minimise the size and duration of an outage, it bites me in the arse. Even though I should have been able to move open logical volumes between physical volumes, the kernel oops seemed to be in the dm_mirror code. daedalus is running a fairly old kernel. The annoying thing is that getting some additional disk space on board was the dependency for doing a general upgrade of all of the software on it. Argh. Anyway, it's done. I hope not to have to go through this again. I just have to sit through a potentially nail-biting remote upgrade of Debian now, and I should be good for a couple more years hopefully.

One year ago, I took over Gammu maintenance. I think it time to summarize a bit what happened during that year. There were definitely good and bad releases in that time (especially strictness introduced to SMS parser in 1.13.0 took quite a lot of releases to fix various bugs), but generally I things Gammu is moving in a good way. What I would definitely call positive:

• Added build time testing. This helps a lot to catch regressions. However more tests could be done.
• I cleaned up lot of code parts so that Gammu is now more resistant to bad data and should not crash in these cases.
• Added lot of API documentation, most API functions are now fully documented.
• More often testing releases - I try to release every week. Sometimes changes are huge, sometimes just few bugfixes. This makes Gammu occur among most vital projects on freshmeat.net.
• Quite complete IrMC implementation together with AT/OBEX switching gives support for quite a big range of phones today.
• SMSD got PostgreSQL support.
• AT+CMGL support for reading messages gives us support for many phones which were not supported in the past.
• I started to use OpenSuse Build Service and Ubuntu PPA to provide up to date binaries for many distributions.

There are also some bad things:

• Nobody cares about build under MSVC. It is broken sometimes and I try to fix issues, but no constant testing of this causes problems.
• Almost no new features for Nokia phones. I simply lack time to do anything more than bug fixing here.
• Still bad support for Symbian phones. Some developer interested in this area is definitely needed. But probably OpenSync with SyncML is enough for most people.
• The changes I made to the SMS parser broke too much things, I should have payed more attention to this change. But now things seem to be worked out.

Some statistics of last year (based on Ohloh):

Value	Dec 2006	Dec 2007	Difference
Code Lines	90,540	101,687	+12%
Comment Lines	9,204	15,336	+67%
Comment Ratio	9.2%	13.0%	+30%

All these changes were made in approximate 1200 commits. I hope next year will not be worse :-).

The story seems to have started with Damog supporting sexism and xenophobia in Debian, followed by Bernhard’s comment about that not being tolerable under Debian’s flag. Aigarius replied kinda shocked that stopping verbal abuses and violence would be censorship. AJ clearly explained the reasons why that shouldn’t be tolerated in Debian, but Aigarius seems to keep thinking that poor jerks are being discriminated when they’re not allowed to insult us. Wouter seems to be tired of the whole topic. Am I missing any chapter? Now my turn: We are on the right way. Since the Debian-Women project started, we have being able to achieve a friendly and non-sexist environment inside Debian, which is something that I’d really like to keep. It doesn’t really mind that a couple of people try to go back to a hostile environment. Trolls just do exist, I guess, but they are not representative of the general feeling of the people inside Debian. Damog, I won’t get the fuck out of here, like it or not. It seems to me that it’s just a couple of you who are happy to be in such an aggressive environment as the one you’re promoting. For what I know, most of Debian people are happy to live in peace. You don’t have social life? You don’t like it? That’s your problem, dude, but don’t ask us to leave ours. I respect you, you know I have always done. I’m just very disappointed with your comment. Really. Making fun of other people’s problems and traumas is simply bullying. I hope you think about it. For the rest of Debian, keep up the good job. Right now my feeling is that the level of sexism, racism, ageism, homophobia, hostility and unfriendliness in general inside Debian development’s world is below the average in the Free Software world. It’s nice to be there, and I’m really proud of belonging here, which is something I cannot say about every group in Free Software. I’d like to keep it that way. Sorry for the aggressiveness in this weblog entry.

Recently I bought a new desktop PC and rotated my existing machines around, leaving me with one spare. Last night I donated that PC to a local friend, (co-incidentally the same woman who had been out cat-sitter when I went to stay at Megan's parents for Christmas). I said "Its got Debian on it, that funny operating system that you used when you were looking after our kitten, remember?". She said "Linux ssems to be getting popular these days I might as well try it out". But seriously she used it. It had GNOME, it had firefox, she seemed happy. It isn't rocket science these days to point a technicalish user at a Debian Desktop and expect them to know what to do with it. The only minor complication was the lack of flash/java since it was etch/amd64 - but thats probably a plus with the amount of flash adverts! In other news I made a new release of asql last night. This now copes with both Apache's common and combined logformats by default. (Yet another tool of mine which is now being used at work, which motivated the change.) I've also started pushing commits to xen-tools last night, so there'll be a new release soon. Mostly I'm bored with that code though, it doesn't need significant updates to work any longer. All the interesting things have been done, so it's probably only a matter of time until I drift off. (To the extent that I've unsubscribed myself from xen-users & xen-devel mailing lists) Virtualisation is increasingly a commodity these days. If xen dies people probably won't care, there are enough other projects out there doing similar things. Being tied to one particular platform will probably come to be regarded as a mistake. (Talking of which I should try out this lguest thing; I just find it hard to be motivated...)

Following my rebuild of all packages using /bin/dash as /bin/sh, we now have a nice list of bugs. Those bugs are cool:

• The relaxed NMU rules apply to them, since they are part of the dash release goal. Which means that they can all be fixed using 0-day NMUs.
• Most of them are really easy to fix. (for many of them, a patch is already provided by Ubuntu)

So, if you want to get involved in Debian development, try to submit NMU patches for those bugs. If you want me to sponsor the upload, please Cc me when you submit the patch. And even if you don’t care about Debian, but only about Ubuntu (which is fondamentally wrong, as everybody knows that Ubuntu is based on Debian), fixing these bugs also helps Ubuntu a lot: all those bugs hurt Ubuntu, since Ubuntu uses dash as /bin/sh by default, and, even if the packages in Ubuntu have been patched, it’s still causing additional work every time a new package is uploaded to Debian, and has to imported in Ubuntu. If you have questions with the process, please ask them using the comments below. Notes:
I use the following process on those bugs, and it’s probably a good idea that you do the same if you intent to submit patches:

• build the package with a chroot using bash
• build the package with a chroot using dash (you can just use a different pbuilder tarball for that). Check that the problem can be reproduced.
• fix the package
• build the new package with a chroot using bash
• build the new package with a chroot using dash
• compare the built packages using debdiff for old_package_using_bash, new_package_using_bash, and new_package_using_dash. If the content doesn’t match, we have a problem.

If you submit NMU patches, please also have a look at the other bugs in the package, or at the lintian output. I don’t mind sponsoring small fixes for non-cosmetic/non-wishlist stuff at the same time.

About a month ago I added symbol version information to the zlib package, allowing dpkg-shlibdeps to calculate more relaxed dependencies for packages using the library. The results have been very satisfying so far - of the 1784 packages depending on zlib1g on amd64:

• 532 depend on zlib1g 1:1.2.3.3.dfsg-1, the version which introduced support for _FILE_OFFSET_BITS=64 and the version which packages that were built before zlib1g had symbol version information will depend on.
• 333 depend on version 1:1.2.1, which predates sarge let alone etch.
• 74 depend on the even earlier version 1:1.1.4-1.
• 843 packages have an unversioned dependency on zlib1g - a quick glance at some of these indicates that (as I would expect) they either don’t actually link against zlib directly or do but don’t use any symbols from it.
• The remaining two packages are the -dev and -dbg packages which have an exact dependency on the library package they were built against.

Of course, zlib is a particularly good use case for this - both API and ABI are extremely stable and most of the changes in interface are in rarely used features - but it’s still good to see it working in practice. I don’t need to worry nearly so much as I would have done previously about keeping other packages out of testing. If you maintain a library written in C I would encourage you to take a look at implementing this, it’s very straightforward. Libraries written in other languages may cause more difficulty. There are some automatically generated symbol files in mole which provide a good starting point (I didn’t use them since upstream already had a more exact list of versions at which symbols were introduced) and support is already present in debhelper. The main things to watch out for when using the mole data are backwards compatible ABI changes which don’t just add new symbols (for example, if new values are accepted by a function) and variations between architectures. Kudos to Rapha l for all the work he’s put into this.

I've been quietly coveting the Zonbu for a number of months now. I finally caved in and ordered one when we got back from Australia, with the intention of using it to replace minotaur, the computer that exports my RAID10 via ATA over Ethernet to my MythTV box. minotaur is the old daedalus, which I bought back around 2000. It's a VA Linux Pentium III. It's old, noisy, and has no idea what power management is. The Zonbu has more grunt than it (in terms of BogoMIPS), and it's a fraction of the size. Our linen cupboard is now significantly quieter (and hopefully cooler). Heck, hopefully the power bill will be lower as well. Anyway, I put the order in when we returned from Australia, with the expectation that it'd turn up some time while Sarah was in hospital, or shortly afterwards, and I could use the rest of the month that I was off work to play with it. Well, I got an email on the 31st of December, telling me they were out of stock, and unless I wanted to pay $29 more for one with built-in WiFi, I'd have to wait until mid-January. As I just couldn't see the point of having WiFi (or spending more money) and not needing the thing in a hurry anyway, because I had more important things to worry about in the meantime, I opted to wait. This morning, I emailed them to enquire about whether or not more stock had arrived, and they emailed back to say that they were still waiting, but they'd found one they could sell to me anyway. The company happens to be close by in Menlo Park, so I picked it up today in our travels. Let me just say that it is a very cool little computer, just if you use it for its intended purpose. It's running a customised Gentoo Linux, with a 2.6.22 kernel. I'm a bit surprised about their choice of Gentoo. I think they'd be better off partnering with Canonical, given that Mark Shuttleworth is trying to make a Linux distribution easy enough for his grandmother to use. That'd take the work of engineering the operating system out of the equation, then they could just focus on the hardware and a bit of integration with Amazon's S3. The thing I have to give them mad props for is documenting how to hack the tripe out of the box. They tell you how to enable root. They tell you how to enable PXE booting. So once I figured out that the front USB port seems to get treated slightly differently for a USB keyboard than the back ones, it was very easy to PXE boot it and install Debian. I initially started with trying to install Etch, but I kept getting missed interrupts on the CompactFlash device, which resulted in the filesystems panicking. So I gave up and went with Lenny, and presumably because it also uses 2.6.22, everything seemed to go fine. The box comes with a 4Gb CompactFlash card, which is ample for my needs. It's running the 686-optimised kernel, which is probably not ideal, but works. We'll see how things go. Interestingly, I blew another hard drive power supply, exactly like last time. I've no idea if it's the act of plugging everything back in again that's causing the problem, or they're generally flaky, and they don't fail until they're powered off and back on again. Maybe that IEC Y-cable wasn't such a good idea after all. I've now run out of spare power supplies, so I'm going to have to get some more for when these two inevitably fry themselves. Overall, I'm very pleased with this purchase, but it's a bit early to see how it's going to perform. I can't imagine it's going to perform worse than the computer it's replacing, but it was probably never intended for what I'm using it for either... Oh, and I discovered vblade-persist, which seems to be a very nice framework for managing ATA over Ethernet exports. Now I just need to get my hands on a big tub of Lego to build a nice chassis for the whole thing.

Juno was totally worth my time, I gave it 5/5 stars. When having a prospective look at it, it didn’t seem I would enjoy it much, but I decided to trust Movielens on this one, and that payed off. Long story short, Juno is a sixteen year old girl that gets pregnant, and then a very appealing movie happens. Then a slightly questionable (rushed?) end comes, but I enjoyed that part the most. I liked the general tone of the movie, and the two youngsters were adorable. The soundtrack was awesome as well. I loved the song on the opening titles, All I want is you by Barry Louis Polisar (listen here), and the one in the last scene, Anyone else but you from The Moldy Peaches, but performed by the actors themselves. Update (2008-01-16): Mention track titles in the last paragraph. Update 2 (2008-01-16): After listening to the soundtrack today, I can’t but highlight Kimya Dawson’s songs, particularly: Tire Swing, Loose Lips, and Tree Hugger.

Well, this is being written on my broken HP laptop and from within GNOME at that. The problems that I anticipated last time are truly ugly : trying to manage a system that uses repositories from Mepis, Ubuntu and Debian are as horrendous as most Debianites would expect. Debian-based is not an easy balance and this is something that I will revisit within Emdebian. It would be easier if I didn't insist on Debian being added to the mix.
There are problems with cyclic upgrades where apt gets confused and repeatedly upgrades the same packages at the same version.
There are problems doing any building on the box - none of the -dev packages will install without massive work on apt-cache policy $foo and apt-get install $foo=$debian_version, due to dependency problems from having mixed distros. The end result of these was that all of KDE had to be removed - presumably due to upgrading libc6 but didn't worry about trying to put it back.
The wireless connection is still down - but it didn't work with plain Mepis either. The graphics are really weird - the proprietary NVidia kernel driver only copes with 1024x768 and I had expected more, plus scrolling behaviour is distracting.
So yes, even the this horrible setup can work in a basic and quite limited way but I'll need a full Debian install quite soon. It's stable, it's usable for limited tasks and at least I've been able to get GNOME onto it.
I'm going to leave it for now and revisit it later with a fresh Debian amd64 install - I've got to get back to some Emdebian stuff.
(Oh and yes, I did replace firefox with iceweasel).