I went to the cinema yesterday evening, and not having a clear idea of which film we wanted to watch, we decided for Manuale D'Amore, an Italian movie. It was great, funny almost all the time but with very emotive moments, all them mixed very well. The history is very simple. The movie introduces different couples that are in four different moments of their love: falling in love, the crisis, the traition and being abandoned. Every chapter is very well driven, and the actors play fairly well their roles. This movie, and the last one I watched, Los 2 lados de la cama, are good examples of European cinema very well made. In my opinion, if European cinema had followed this path more often, and with a bit more advertising, it will get more success than now, in which there are a lot of movies made trying to be different. P.S: I HATE people eating nachos in theaters.

Junichi, well, usually there is not much stopping you from using address zero on modern hardware, as you can move the vector table around as you wish, and real mode code can just be emulated. X11 does that, for example.

After setting up the Backup Manager’s website, I took the time to install mailman in order to handle mailing lists nicely (congrats to the mailman maintainer, it installs itself like a charme). Everything is now ready for welcoming subscribers to the backup-manager mailing lists. I’m about to release a new version of Backup Manager, featuring a new method for making customized backup: you are now able to enter a command and all the output sent to stdout by this command will be used as the archive content. It can then be compressed with the tool of your choice if needed. Here is an example of the concept:

command=ssh myhost -c 'mysqldump -uuser -ppass database'
filetype=sql
compressor=bzip2

This will be provided to backup-manager through arrays, so we can implement as many archive methods as we like.
I called this method the “pipe” method, I gues you know why. This is already available in the svn repository.

ccache is a compiler cache. I find it greatly reduces compile time when I have to recompile the same code over and over, which is often the case when I prepare Debian packages. It can be invovked in a variety of ways. For me the easist is to make a symlink the name of the compiler in my path. For example, ~/local/bin is in my path before /usr/bin, and I want all invocations to gcc to use the compiler, so I do this

# which gcc /usr/bin/gcc # (cd ~/local/bin && ln -s /usr/bin/ccache gcc; ) # which gcc /home/horms/local/bin/gcc

So now when I invoke gcc it actually runs ccache, it does its magic and calls /usr/bin/gcc as needed. As ccache invocations look exactly the same as gcc invocations, this means its easy to get ccache into a build.

# which gcc /usr/bin/gcc # ccache-update-links ~/local/bin # which gcc /home/horms/local/bin/gcc

But with different versions of gcc, and recently doing some work with cross-compilers, I have a lot of symlinks I want to create, and this is a bit of a chore. So I wrote a ccache-update-links to do this for me. Note that it actually just creates and overwrites links, it doesn't know how to delete dead links. Perhaps I should add that... Download: ccache-update-links
Home: ~horms/junk/

Scott James Remnant announced him taking a sabbatical for personal reasons. As Scott was maintaining dpkg for about two years (first NMU in February 2004), this was leaving one of the most important packages in the distribution without maintainer. However, Scott took care asking a few people about taking the package maintenance over. Up to now, these people are Frank Lichtenheld, Guillem Jover, Brenda O'Dea and myself. I of course can't speak for others, but I'll try to make my involvment limited to what I was already working on with Scott: localization of the software. The key point is now organizing things and have some teamwork possible (and refrain my natural tendency to organize things and take the lead, which I wouldn't survive...). So, it's seems like a good opportunity for more people to jump in and come in the package maintenance mailing list. Let's hope that all this will organize itself well and will soon be a good example of collaborative maintenance in Debian.

I spent the weekend hacking on ipfm, doing a few minor improvements and adding features I needed to monitor my own network. Now I just need to do a few RRDTools scripts. Also got interested in oFBis, a library for accessing the Linux framebuffer device. I'll use it for the vlc and Quake/QuakeWorld framebuffer versions instead of my messed up code. The authors also seemed happy that I proposed to package it for Debian. tripix: hey, SDL Perl looks awesome ! I didn't know this project, the examples are really impressive. Certified a few additional people today. I worked a bit on my homepage, and am currently rewriting my resume. I also put it at an URL without a ~ in it, because a few people had trouble typing this character. Really.

Martin Krafft asks why some people don't like telephones. I'm one such person. Telephones are error-prone, low-bandwidth and high latency communication media that still require real-time response. I like having a conversation face to face, but using a telephone cuts out almost all the bandwidth from that, so that you can only rely on voice, and not even the full spectrum of that. What with a limited spectrum of frequences, low sound volume even at the highest setting (I have bad hearing), strange accents, and generally abysmal sound quality (background noise makes it almost impossible to hear what the other person is saying), it takes a lot of time to get anything settled over the phone. IRC, for example, is in many ways similar, but it differs from a telephone in two different aspects: you don't need to react within seconds, and messages get through loud and clear (well, big-fonted and clear). Even if a telephone call may be shorter than an IRC discussion, it requires much more effort to happen, and on the whole is not as productive. This doesn't mean I'd refuse to discuss something over the phone, but I'd really, really rather not.

As JoeyH mentioned, I set up secure-testing buildd on my ARM and is already startting to build/upload some packages. Yeah, I feel good my machine is useful for someone. The reason of I bought this ARM is to just contribute Debian (I'm not embedded programmer or user). Building secure-testing has some unclear points. Most sensitive point is when we should update our chroot. For example new glibc will enter in near future.

I use a relatively unsophisticated but highly effective filter for blog comment spam. The system consists of several hundred keywords (mostly spam-related domain names which would never appear in a genuine comment), and a Turing test. The Turing test is a box at the bottom of the comment form, that says: “Do not put anything in this box if you are a human.” The Turing test catches between 10-25 spam comments per day; the keyword filter about the same. Every week or two, however, a human comes along, and fails the Turing test and fills in the “don’t fill in this box” box. I’m not quite sure what to do about that. Maybe the human thinks they are not actually human? More likely they just don’t read the text next to the box, although it is fairly prominent. Unfortunately, this seems to be a general phenomenon on the web. Many people have a tendency not to read text on webpages. For example, I’ve gotten a lot of questions along the lines of “How do I access my address book in SquirrelMail?” The answer, of course, is to click on “Addresses.” Similary questions arise with respect to my photo album software salonify — “how do I view a slide show of images?” (A: Click on “Slide Show.”) My hope is that the next generation is better able to process web content, but I’m not sure that hope is well founded. Getting back to the blog comment spam issue, it’s interesting to observe what sorts of topics appear most frequently in comment spams. Over the past several months, pornographic links referencing transsexuals seem to outnumber other topics. I wonder: do the spammers have a scientific method to their marketing?

I’m flying Song airlines for the first time, en route to Orlando on business. The individual interactive multimedia consoles are pretty cool. You can check out your altitude, flight path, etc., in real time, which I think helps mitigate the lack of control and attendant anxiety most people feel while flying. There is also a decent selection of “MP3s” (I wonder if they are actually stored as MP3s?) that you can queue up for a personal playlist. I’ve found more than enough selections to last the rest of the flight. (Strangely, I seem to have to hit ‘pause’ at the end of each track to advance to the next). There are also a bunch of satellite TV stations, pay-per-view movies and games, although I haven’t checked those out. I’m curious about how the music licensing works. The airline would like to provide the attractive feature of a broad variety of music for its customers; at the same time, it probably serves as effective marketing for the labels, just like radio play. You might, for example, check out an album you were thinking of buying on the flight, and purchase it later if you liked it. The chance that inflight music will be copied by customers is very low and presumably they don’t need to worry about DRM. So which way does money flow—from the airlines to the labels or vice-versa? Or are the tracks “free?” Now playing: The Beatles, Revolver, “Got to Get You Into My Life.” P.S. After we landed, the interactive multimedia consoles rebooted. It turns out they are running Red Hat Linux, circa 2002. Smart.

Not every day you get an email like this:

link is the result of my work making mooix multilingual. It is twenty seven thousand lines. It assumes my VServer patch. It allows allows multiple users to communicate with the same mooix session at the same time in different languages, without ever seeing any language but their own unless that language is being spoken (via the "say" command or similar) by another user. This is, the two different users will be typing different commands in different languages, and seeing different languages (but hopefully the same semantic content!) in the output. Example runs are at link and link These two scripts (the first in English and the second in Lojban) each have their users doing exactly the same actions, in effect, but with totally different results. Note that unless each specifically asks for the other language, the English user never sees Lojban, and vice versa.

Lojban! Mooix! Incredible.

Perl Testing

Writing test cases for Perl code with Test::More is fun! It is slightly less fun when you have to come up with creative solutions to the problem of your code requiring root privileges - which means that your script + tests will fail when run by a mere mortal user. I was thinking I could run my test cases at the time that the Debian package is built, (and do so), but I realise now that the buildd system doesn’t run with root privileges either - it uses sudo to install packages for example. Ho hum.

Working on free software has made me fairly revision control system-agnostic; I can't afford to get too wedded to any one system because as soon as I do somebody will invent something new and I'll have to convert again, so I just work with whatever other people on the same project are using. Even CVS doesn't make a lot of difference to the way I work as long as I'm working online and have cvsps handy. And of course I usually don't bother with revision control if I'm just tweaking somebody else's Debian source package a bit (in which case I just use debdiff for paranoia). Using bzr at work, though, I think I just found my killer app in Michael Ellerman's shelve plugin. My working style generally involves alternating between doing lots and lots of stuff in the one working copy and (after testing) going through and committing it in logical chunks. This is fine if everything's in separate files (most revision control systems let you commit just some files), but if several of the chunks are in the one file then I'm reduced to saving diffs and manually editing out the bits I don't want to commit yet, which is obviously pretty tedious and error-prone. bzr shelve presents each diff hunk in your working copy to you in turn and asks you whether you want to keep it. If you say no, that hunk gets unapplied and goes into a "shelf", where bzr unshelve can later reapply it. In the meantime commits act as though the shelved hunks didn't exist. This doesn't help if you want to defer only one of two immediately adjacent changes that end up in the same hunk, of course, but it vastly reduces the scale of the problem. I suppose it would be easy enough to write a shelve-a-like for any other system; it's just that I haven't seen it for any other system yet. If working with systems that lack it really starts to annoy me, I may have to rip out the guts of shelve and figure out how to make it generic.

By request: Here's a list of people who've confirmed they're going to give a talk in the Debian Devroom at the next FOSDEM. This list isn't final yet (there are some more people who've asked for a time slot but did not confirm yet; and I didn't assign slots yet, either) but it might be interesting for those who are coming to have a preview of the subjects that will be available. Well then.

Lars Wirzenius: Nobody expects the Finnish Inquisition: Confessions of a package torturer

Piuparts tests that .deb packages can be installed, upgraded, and removed without problems. Lars uses it to torture all the packages he can get his hands on. This talk will explain how to use it on your packages before uploading them, and thus improving their quality and not having them suffer in Lars's hands.

Martin Zobel-Helas: Debian-Volatile - behind the scenes

This talk will give an overview of how packages are handled for Debian-volatile; what changes are allowed, how security is handled.

Martin F. Krafft: Improving workflow in Debian through process integration

This talk will be about the same subject as Martin's doctorate thesis. The abstract for that is:
This research paper/project details the technical challenges the Debian project faces as it continues its tremendous growth in size and popularity. It describes a research endeavour designed to increase the use of version control within the project for improved coordination of globally distributed teams of volunteers working on the software packages that make up the system. The research primarily focuses on the integration and consolidation of the involved processes. With tools already available for some parts of these processes as well as the coordination of teams, the goal is not to reinvent the wheel, but rather to reuse and improve these tools, to better integrate them, and to make them more accessible by providing abstraction wrappers with interfaces intuitive to Debian developers. It is further the intent for these tools to be optional and fully compatible to existing practices, thus not forcing developers to adapt. The research starts with process analysis and studies of the work habits on the side of the developers, and targets the final output of tools, which implement improved workflow in Debian package management through meaningful integration of existing (and proven) methods

Enrico Zini: Debtags, and what you can do with it today

This talk will introduce the Debtags project, what it has accomplished so far and the wonderful advanced tools that are now available, using debtags, to make sense of the huge package archive.

Bill Allombert: Inside the Debian menu system

The debian menu system transparently keeps the menus in sync with the list of installed applications; so transparently, in fact, that a lot of developers do not know how the system really works. This talk will detail the various components of the system, what the technical challenges are and how they are solved.

Frans J. Pop: Debian Installer internals

An introduction to the inner workings of Debian Installer. Starting with what happens when the installer boots, the talk will go on to discuss how the dynamic menu structure allows the installer to be adapted for different architectures and installation methods. Other subjects will include the special nature of udebs, the contents of a D-I initrd, how cdebconf knits everything together and allows the use of different frontends, preseeding and the use of hooks. If time allows, a short introduction into the build system and CD building may be provided. Some knowledge of Debian package management (like priorities and dependencies) is assumed in this talk.

Aurelien Jarno: The Debian GNU/kFreeBSD port

Debian GNU/kFreeBSD is a port of Debian using the FreeBSD kernel and a GNU libc library. It is currently the most advanced non-Linux port in terms of packages ported.
This talk gives an overview of GNU/kFreeBSD, and a quick comparison between the FreeBSD and the Linux kernel, to give users the necessary information to let them find how the FreeBSD kernel could fill their needs. It then describes the status of the port and the choices made concerning the architecture of the port (libc, threading library, etc.). It will continue by giving the various ways to try out this port and to give help, giving pointers to useful documentation and some useful hints.
Best portability practices are also covered, for both the Debian packaging and the upstream code. It will be based on real examples of non-portable code, and will show the best way to change it into portable code.

Summing the times that people gave me, I'll have anywhere between 5h25 and 6h00 of talks already, and two more people who've shown real interest in doing something in the Debian devroom (but who haven't sent me the information I ask for to be able to confirm their talk; please do so!). I'll probably get 9 hours in all (10 if I squeeze a little bit; but then I might have some issues with the key signing party, which I'm also co-organizing), so there is still some time left for interested parties. However, if you're interested in giving a talk, you shouldn't wait too long anymore!

Thanks to Grant, I discovered a couple of interesting blog posts about how to become an early riser, and about polyphasic sleep. I'm certainly interested in becoming an early riser. I'm not naturally a morning person, but for a few years I managed to force myself into it, but then I lapsed back into being a night-owl sleep-in type person. At the moment, when the weather permits, I'm trying to cycle to work with enough time to eat breakfast there and be operational at my desk by about 8:30am. It's just as fine to start at 10am, but I'd rather not get into that habit, and just treat it as a bit of a splurge from time to time. This of course means I can't stuff around in the morning, and ideally I need to leave the house by about 7:45am, with appropriate flow-on affects on when I wake up and get out of bed. It certainly takes a lot of self-discipline to get out of bed when the alarm goes off. At the moment, I tend to opt for two alarms. One to wake me up and get snoozed a lot, and one to actually get out of bed. If I was more disciplined about getting out of bed, I could just have the one alarm go off, and get extra sleep. The extra waking hours gained by polyphasic sleep are tempting also, but I think it's altogether too disruptive to try at the moment. An interesting concept nonetheless. So once we're a little bit more settled, I'll hopefully become more of a morning person again. I think the key is consistency. Sleeping in on weekends just buggers everything up, which is a shame. I quite like my weekend sleep-ins. Downside is you spend half your weekend asleep, when you could be out exploring a fabulous new foreign country, for example...