After a three and a half week test drive during my last year’s summer holidays and much consideration about the configuration, I finally ordered a Brompton folding bike at Velofix. Since the apple green was much nicer in the catalogue than in real life, I decided that I need a bike in colours that clearly mark it as my bike: Orange frame and black front and rear swinging fork. ;-) It will have 6 gears (a 3-gear internal hub and a 2-gear dérailleur, both at the rear axle), a lowered transmission ratio for hilly Zurich and sprints in the city, a SON axle dynamo, Kevlar reinforced, reflecting tyres, and a bicycle luggage rack which also serves as kick stand when (partially) folded. Options I thought about but then dismissed for miscellaneous reasons: Schlumpf MountainDrive (can’t say if will be really worthwile) and Rohloff Speedhub (not available although I already saw a Brompton with a red Speedhub — funnily just in front of the place I live, and probably also more expensive than I remembered).

AdSense patch for ikiwiki's embed pluging Today I've started playing with AdSense, mainly to check whether a typical homepage+blog web site (read: mine) can survive its hosting costs by the means of this kind of revenue or not. However I don't want the ads to be visible on all pages, but only in some of them, mainly the main blog page (which scores high in search engine results and is also not prone to the risk of bothering usual readers, thanks to---$DEITY bless them---RSS/Atom feeds) and some selected pet software project homepages. With ikiwiki implementing this appeared trickier than I expected. The main difficulty is of course the wiki-wide htmlscrubber plugin which I do not want to switch off because of discussion pages and a part of my website which is actually used as a world-editable wiki. Googling around it seems that there is an adsense.pm plugin for ikiwiki, but it is not registered in the ikiwiki plugins page; as such I was not particularly envy to try it out. Besides, the right place to add such a feature to me seems the embed plugin. ... so I've minimally patched it: see bug #462970. If you're willing to use AdSense with ikiwiki please try out the patch: since I'm an AdSense newbie it might well be I've underestimated the possible script snippets it can generate. Post comments to bug #462970.

Thanks to those 2 comments. Although placing Xft.dpi: 96 in my ~/.Xdefaults did not help, but I managed to do it through the appearance control center applet. I had to purge the gtk-qt theme engine because it was freezing the dialog and setting it via gconf-editor didn't work as expected.

I had to fight with my fonts this morning but here's my configuration. Maybe it'll be useful to anyone:
DejaVu sans book 12
96 DPI
greyscale smoothing, subpixel slight RGB.

I'm not yet satisfied but it's more usable now.

Thanks Phaeronix for the help too. read more

Today I gave a talk about Debian security at the security mini-conf of LCA. Before I started the talk I asked for suggestions as to how to get more entries in my security blogging contest [0]. During the talk I asked for suggestions as to how to get more people involved in security development. One suggestion was to offer incentives. I’m experimenting with that with my blogging contest and may do future variations of the same thing. I started with describing some of the history of security in Debian (primarily things that involved me in some way): In 2003 I suggested that exec-shield be a standard feature in Debian kernel images [1]. I created a kernel-patch-exec-shield package in 2003 and Marcus Better took it over in 2004. We are hoping to get it included in Lenny. AMD64 architecture doesn’t need exec-shield as the CPU has separate write and execute bits in the page table, but it would be nice to get exec-shield included before the last P4 machine gets decommissioned. A presentation at the security miniconf at LCA 2005 on the topic of stack smashing is interesting [2]. At the time Adamantix was a distribution based on Debian which used PaX (similar to exec-shield). Adamantix has gone away. Hardened Gentoo has been available with Pax for all this time (but is not widely used). RHEL and Fedora have been available for all this time with exec-shield… In mid 2002 I demonstrated the first SE Linux Play machine at a conference in Germany. It was fully operational with root as the guest user. At that time SE Linux support in Debian was essentially complete. Since that time the scope of the SE Linuc project has increased slightly (EG controlling DBUS access) so the amount of work required for full support is greater. Most of that support is in Debian and Etch is basically working with SE Linux (although not quite as well as it was in 2002 due to lack of support for the strict policy). The aim is to have Lenny SE Linux become as functional as SE Linux in Fedora Core 5. While FC5 has more SE Linux features than the SE Linux project supported in 2002 it’s still a great disappointment that it’s taken so long. FC5 had pam_namespace to polyinstantiate directories such as /tmp. Lenny will hopefully have it. I described the current status: The hardening-wrapper package in unstable allows environment variables starting with DEB_BUILD_HARDENING_ to be used to control execution of GCC. Documented on the Debian Hardening Wikipedia page [3]. It’s still a little experimental and may change in the near future, but it works. Lucas Nussbaum is working on automatically building Debian packages with warnings for security related issues. The aim is to build all packages and maintain a central location for the logs to allow DDs to find and fix the problems in their packages. The Alioth Hardening project [4] will hopefully get some action soon (the people involved are busy doing work but not updating the project). The current plan is to base the Debian Hardening work around it. SE Linux in Debian is something that I want to get working correctly. There are still some significant issues that make strict policy unusable (such as correct labelling of /etc/passwd) as of last time I tested it. Finally I described the future plans. There were many questions about usability features for SE Linux, I mentioned in concept the features that Red Hat and Tresys people are developing (which I often don’t use as I prefer vi for policy editing). There were some questions about how SE Linux works. More than half the audience indicated that they had used it so I assumed some basic knowledge of SE Linux when describing how SE Linux works in regard to minimum privilege and the benefits of MAC in terms of limiting the scope of attack. I noted that every program has bugs and every program which performs security related tasks (which includes serving data to the net without being owned) should be assumed to inevitably have security related bugs (see the The Inevitability of Failure paper []). Based on the Twilight of the Books [5] article I decided to give this talk with no slides as an experiment. I talked from notes that I wrote and advised the delegates to read my blog for the details. Not presenting any slides meant that the room lights were all left on, which made things much easier when answering the many questions (I prefer an interactive format to my talks and have more questions than most speakers). It will be interesting to get some feedback from delegates about how they regarded this.

• [0] http://etbe.coker.com.au/2008/01/20/lca-2008-security-blogging-contest/


• [1] http://www.debian.org/News/weekly/2003/45/


• [2] http://www.linux.org.au/conf/2005/security_miniconf/presentations/smashing.pdf


• [3] http://wiki.debian.org/Hardening


• [4] http://alioth.debian.org/projects/hardening/


• [5] http://etbe.coker.com.au/2007/12/28/twilight-of-the-books/

Share This

According to a notification of trade on the Oslo B rs market, Nokia has made an offer for Trolltech of about 843 million Norwegian kroner , around 104 million. What this could mean for GTK+ is anyone’s guess. I’d expect at least that Nokia’s competitors that use Qtopia (like Motorola, Panasonic and Sony) are probably a little worried at the moment. Maybe there’ll be impetus for OSSO to move over to Qt, or maybe there’ll be internal competion at Nokia between a Qtopia stack and a GTK+/X11/Freedesktop stack. Maybe Qt will become more closed as Nokias pushes its advantage, or maybe it’ll be more open as development becomes less dependant on non-GPL license revenues, or maybe it’ll just stay the same. An interesting left-field move in this space is OpenMoko moving over to EFL, but on a primarily GNOME/Freedesktop stack. EFL is certainly much more capable than GTK+ in producing flashy UI’s on limited hardware. I”ve also heard of some companies writing UI’s in Flash using Gnash. I also wouldn’t be suprised if we start seeing embedded hardware running Mono and Moonlight at some point. Maybe one day we’ll have a GTK3 with DOM-like two pass event system and a cairo backend that renders totally on the GPU. One thing’s for certain, there’s a hell of a lot of competition on the toolkit front and it will only grow.

Wow, probably the news of the day for me. It’s done and not a joke: http://trolltech.com/28012008/28012008 What’s next now ? When you know Nokia and their consumer electronic product like the N810 uses maemo and mobile phones use Symbian, do they want to switch to Qtopia How KDE will be affected ? Everybody know the relations between Trolltech and KDE. Enough speculations, This is really exciting !

I have uploaded a new version of DebTorrent to experimental and to my personal repository. This new version implements the unique piece numbers, which has been planned for quite some time now. Well, it's finally here. To summarize, unique piece numbers keep torrent's alive longer, by assigning files unique piece numbers that never get reused in that torrent. New files get new piece numbers added to the end, but peers in the old torrent can still share most of the old files with peers in the new torrent (in fact, it's the same torrent, but old and new peers have different ideas about what it contains). The creation of torrents from Packages files has also changed, as now 2 torrents are created, one for whatever arch the Packages file was for, and one for the Architecture:all files. Since the Arch:all files are the same for all architectures, this also allows for more sharing of common files between peers on different architectures. This change required a change in the cache directories, which is described in more detail in the NEWS file, but is handled almost automatically. The only thing to do is the make sure to do an apt-get update after upgrading so that the torrents can be restarted. There was also some changes in the statistics reporting. In the client, the uploaded and downloaded statistics will now persist over restarts so that you can see how much you've done over a longer period. The tracker status page also got an update, and now shows the total uploaded and downloaded bytes for each torrent, as well as some more descriptive names for some of the torrents. Due to the large changes in this release, I opted for uploading to experimental (and my repository) for now, so that it can be tested a bit. Please do test it, and let me know of any bugs, problems or concerns that you may have. Here is the changelog:

• Add support for unique piece numbers
  • increases duration of oft-updated torrents so that more peers can participate
  • currently supported only by debian testing and unstable
  • see http://wiki.debian.org/DebTorrent/UniquePieces for more info
• Switch to using 2 torrents per Packages file: one for architecture- specific files, and one for architecture-independent files
  • also added a new script splitcachefor_all to ease the upgrade
• Use python-debian for all reading of RFC 822 type files
  • also requires python-apt
• Add torrent names to the tracker display
• Make the download/upload statistics persist over restarts
• Report more and better statistics on the tracker's info page

Your new door to the world the slogan for Bangkok s new Suvarnabhumi airport tries to get people to stop-over on their trips between Europe and Asia. The airport s webpage claims that the airport currently handles 45 million passengers per year, but that it would scale up to 110 million. I don t see this happening, at all. Today, leaving for Melbourne, I waited for an hour in the security queue, as four flights were leaving concourse E (which has 10 gates) at once: around 500 passengers were queueing to be scrutinised for explosive liquids and other stuff a real terrorist would never consider smuggling on a plane via the standard passenger processing theatre in four lines behind four security checkpoints (in fact, that s how I confirmed my estimate: around 30 seconds per passenger (I timed it), it took me one hour, that s 120 passengers per queue, so about 500 total, at once). Four lines, one hour? 45 million passengers. 110 million passengers? Six lines (there isn t much more space), so 200 passengers per line, 1:40 hours? My new door to the world? Bangkok? Of course, this is in large part because of idiot passengers. While I was waiting in line, they came three times (every 20 minutes) to empty the garbage can where potential terrorists have to dump their drinkable explosive fluids. We ve had this ban for over 1 years, for crying out loud! Sure, some people don t (get to) fly a lot and a few may really not have heard about dangerous liquids yet (I felt really sorry for an elderly couple who had to ditch pretty much all their toiletries leaving Zurich for Madrid and wondering how they would survive there), but then at least open your eyes and turn on your brain, please. Unfortunately, the typical Bangkok/Southern Thailand tourist probably hasn t got brain cycles left between walking and carrying luggage. If you don t believe me, stop-over in Bangkok and look around: anything with legs in shorts and flip-flops probably fits right in, any obscenely and annoyingly loud group as well. For instance, this circus of 10 en route to London, who joined the end of the queue (read: about 1 hour to go) after their flight s final call with millions of shopping bags. They furiously tried to raise hell, but failed and probably missed their flight. Observing all such episodes around me made the hour go by fast I also had ample time left before my gate would close. There was one situation, however, that made walk over and complain to the supervisor (the one with the walkie-talkie): a couple from Canada were similarly faced with the final call for their flight to Toronto and walked straight up to the top of the lines outside the ropes. After a short discussion, one of the security attendants escorted them to the gate without subjecting either their bags or bodies to the ever-secure screening process. The supervisor (the one with the walkie-talkie) didn t speak English. All she did was smile and make motions with her hands which suggested that I should join the end of the queue. As I said before, I don t believe that the (minimal) added security we have at airports today corresponds to or justifies in the slightest bit the shit we have to go through these days to be airborne. However, if you make rules, then stick to them and don t open gaping (= inviting) security holes. Fortunately, the Canadians later had to surrender their weapons of plane destruction since, on every gate, another party of security attendants glove-hand-searched every bag a second time, with the previous security checkpoint no 100 metres behind. I don t see Suvarnabhumi as a successful or scalable airport. If Bangkok wasn t such a great place ?to kill a few hours (especially compared to e.g. Singapore), or the (best) entrance to Southeast Asia, I d probably avoid it in the future.

This weekend has been an interesting mix of activities. Mostly I've been tweaking my mail filtering service now that it has more users it is more interesting to do that. The basic process of mail-scanning is pretty simple, but there are some fun things in the mix which make it slightly more fiddly than I'd like. The basic recipe goes something like this:

• Accept mail.
• Validate the mail is addressed to a domain hosted upon the machine.
• Do the spam filtering / magic (many steps missing here)
  • If the mail should be rejected archive it to a local Maildir folder and bounce it.
  • If the mail should be accepted then forward it to the destination machine.

The archiving of all rejected messages is a big win. It means that if there is a mistake in the handling of any mail we could undo it, retraining the spam database etc. It also provides, via a web page/rss feed, a way for a user to see what a good job the filtering system is doing - by saying "Here's what you would have had ..". Today I switched the way that the archived mail is displayed via the Web GUI. Previously I used some nasty Maildir parsing code, but now I'm running IMAP upon localhost - so the viewing of messages is a lot more straightforward. (via Net::IMAP::Simple.) More interestingly, to most readers I'm sure, today I managed to take a new Kite out for flying. A cold and windy day, but lots of fun. There was beer, pies, and near-death! This was also the second weekend I carried out some painting of my front room. At this rate I'll have painted all four walls of the room in less than two months! (The last time I painted a room it took approximately six months to complete. Move furnuture & paint one wall. Wait several weeks, then repeat until all walls are complete!)

This is a rant I have made many times in person: far too many to count. Since I can't possibly warn everybody who might be affected by this, face to face, I'm hoping you will all spread the word. The problem To begin with, I should say that ls --color is useful. It can show you which items in your directory listing are directories, symlinks, broken symlinks, device nodes, named pipes, whatever. I am glad that it exists. However, let’s consider the basic action of ls. It is, of course, to display which files and directories exist in a directory. This is really quick and easy in Unix. Simply use the libc function opendir() then just readdir() till it returns NULL and errno is 0. In terms of syscalls, this is an open(), one or two read()s and a close(). When you turn on the color option, every directory item incurs the weight of an extra stat() call to see what it is. Worse still, if it’s a symlink, ls will obligingly bound across to the thing linked to, to check it exists. If this causes your automounter to wake up and mount something remote, that’s quite an overhead. If your mount hangs because the remote filesystem is unavailable, you can say goodbye to that process; it'll be stuck blocking on a syscall that will never return. A partial solution To fix the symlink problem, here’s what you do. ls was written to avoid chasing symlinks if configured not to. Check your environment variables for the LS_COLORS variable with: $ env grep ^LS_COLORS If it exists, you have a config file for colour ls: you should edit /etc/DIR_COLORS* or copy it to $HOME/.dircolors and edit it there. Otherwise, type: $ dircolors --print-database > $HOME/.dircolors The edit you need to do is to remove or comment out the ORPHAN line from the file. Unless you were able to edit the file in /etc, you now need to make sure that this new $HOME/.dircolors file is used. In your shell login script (.bash_login for bash and .login for (t)csh, put the line: eval dircolors $HOME/.dircolors (Note that these are backticks, not apostrophes.) Next time you log in, you'll be able to use colourful ls without fear of a remote filesystem freezing your directory listings. In conclusion Use ls --color when you need it, but as with all powerful tools, use it with care. Corrections: James pointed out that to dump the default config it is –print-database not –print-directory.

After a few amazingly efficient days at home, working on netconf (but not getting to where I wanted) and preparing the presentation I deliver on Thursday at LCA 2008, and tying up other loose ends, I found myself in front of a television set Friday morning to witness the beginning of Federer s defeat in the Australian Open half finals. Unfortunately, I had to leave at the start of the third set and no-one in the airport knew of the game, so I had to call a friend from the plane to get the final result: 7:5, 6:3, 7:6, Djokovic won. I like Federer, and enjoy the Swiss fandom from everywhere, but his tennis wasn t up to his normal level, a true shame. Djokovic has been my favourite for about a year now, so I am excited by the result, but it would have been better to see a bit more of a battle between the two. I trust he ll win on Sunday and cross my fingers! It kind of bites to arrive in Melbourne on the day of the finals, knowing that I would have had a chance to get a ticket and could have travelled a day earlier. Oh well So I am sitting here in a crap Bangkok Internet cafe, finishing off my presentations. In addition to the netconf talk, I am also talking twice at the Debian Miniconf on Monday: first, the State of the Debian project address , which I agreed to do very short notice but knew that I could count on my colleagues to help (don t read the thread before the talk ); second, I also have a slot to talk about version control systems and Debian packaging, a topic that has been on my mind for almost three years now, resulting in elaborate workflows and many discussions. It s also becoming more and more of a hot topic for the entire project. I am tired. We landed at 5:30 and I was shattered, not having been able to shut an eye throughout the ten hours of flight. Fortunately, they let me into the lounge in the arrival area, where I crashed in one of their slumber rooms and got close to four hours of sleep, successfully ignoring the chatter from outside why did Thai Airways lay out their lounge in such a way that the slumber rooms are right next to the staff rooms with the squeaky doors? One thing about living in Asia, where space is scarce, is that people here never seem to mind about noise and sleep through anything. So I did too. I took a shower, ate some breakfast and headed into the city. I was impressed by the new Bangkok airport Suvarnabhumi , which definitely is a step up from the old, horrific one. However, I tend to doubt their claim that they could scale from the current 45 million passengers per year to 110 million. The walkways are too narrow, there are way too few toilets around, and immigration is painfully slow despite the large number of open alleys. Now in downtown Bangkok, I am biding my time. I have been here a few times before and have a number of routine stops, such as visiting the retail manager of the Jim Thompson Company, a loveable lady who speaks fluent English and is very fun to talk to. I met her during my last trip to Southeast Asia, but have since not been in touch. I now plan to head to a massage place, where they deliver merciless (and thus excellent) Thai massages, and then on to some market or Chinatown for food. I ve been training myself on chili ( Thai chocolate ) consumption for this moment: to walk up to a food stall, order a curry, and answer Thai hot when they ask for the degree of spicyness, given that I m a foreigner. At midnight, my plane leaves for Melbourne to arrive on Sunday afternoon. I have little clue as to what awaits me. I ve been to quite a number of conferences, but always perceived LCA to be somewhat special. I am definitely looking forward!

I've got an upload of gpe-tetris pending - see 462306 - to provide a smaller version of the popular falling blocks game for embedded devices. One or two things crop up from this package:

1. popcon - a lot of maintainers put a lot of store by popcon results but the popularity-contest package is perl and perl is not available in Emdebian (it is thrown out along with "Essential: yes" for space reasons). Writing a replacement for popcon may not be particularly sensible either because embedded devices, although often left running for long periods in a "low power" mode, often have rare and intermittent access to any form of internet connection. This could easily result in maintainers thinking that because a package has few (or even zero) popcon figures, it is not used. On the contrary, the package could simply be used on devices that either do not support perl (Emdebian) or which do not have the ability to file popcon reports despite being able to support perl. (With the probability that GPEPhone will be added to the GPE support already in Debian, users may not wish to have popcon "phoning home" because it would likely cost real money to do so - even if a C version of popcon was written.) So I'm posting this here so that I can refer back to this post if queries arise later on.
   


2. GPE apps on Debian - gpe-tetris is inherently designed for small devices with small screens and relatively slow processors, just like the majority of GPE. gpe-tetris is also designed to be usable on a handheld device where the lack of a normal keyboard can make game play awkward. As a result, playing gpe-tetris on an average Debian box is likely to appear trivially easy and the "progression" between levels would appear very slow in comparison with the tetris available in GNOME or KDE. This is deliberate and is expressly intended to allow the game to be playable on embedded hardware that has fiddly little keys. (I'll be adding this to the manpage and a brief summary of this to debian/control.) This does give the opportunity for a little sleight-of-hand such that a device could be provided with a highscore file created on a much more powerful device and so preventing any new highscores being set, but please don't do that - play nicely!
   


3. small apps != bad code - Yes, lots of GPE packages are very small, some were clearly written originally as "demos" or during the process of learning how to write larger packages. This does not necessarily mean the packages contain bad code. I will feed back sensible patches to upstream to resolve flaws in the code but please do not think ill of the packages merely because the source code looks "trivial" compared to a GNOME package.
   


4. dpkg-shlibdeps - one issue that I must begin to track after Fosdem will be to aggregate the "foo should not be linked against" messages from dpkg-shlibdeps in GPE packages and try to build a complete picture, in case there is a real possibility of completely dropping some packages that always seem to appear in that list due to the pkg-config --libs gtk+-2.0 listing. If so, I'll begin discussions with upstream about manually specifying the GTK_LIBS variable whilst retaining the PKG_CHECK_MODULES macro that ensures that the -dev package is available in the cross-building environment. This is likely to be some form of database-query mechanism - feeding data in from grepping the build logs, building a query from the list of packages to be used for a specific Emdebian root filesystem (machine/variant specific) and then spitting out whether particular package sets can have particular targets removed. If anyone fancies working on that already, the Debian version of the information is already available via the buildd network and the Emdebian cross-build results will not differ greatly from those at this stage.
   

Other uploads include updates of libgpeschedule, gpe-calendar and gpe-clock if gpe-announce makes it through NEW as expected. Updates for emdebian-tools and apt-cross and likely new releases for QOF, gpe-expenses and pilot-qof.
debcheckout compliance
In other developments, I've worked out how to specify Vcs-Cvs correctly such that debcheckout can find the repository data correctly. Sadly, vim syntax highlighting does not help with the CVS version but the CVS syntax is:

Vcs-Browser: http://alioth.debian.org/plugins/scmcvs/cvsweb.php/dpkg-view/?cvsroot=dpkg-view

Vcs-Cvs: :pserver:anonymous@cvs.alioth.debian.org:/cvsroot/dpkg-view dpkg-view

Note the colon prefix to pserver and the space between the repository login location and the module name. Remember to omit the "-d" - debcheckout will add that for you (and won't check to see if you have already specified it).

Firstly, I haven't been following debian-devel as closely as in recent months and some things have passed me by. Secondly, I am rather pre-occupied with my own small world of Embedded Debian. One result of this is that I wasn't really paying attention to arguments over the source package format and took longer than I expected to respond to a request to take a look at tslib - a touchscreen library for embedded devices. When I did start work on it I managed to upset Joey Hess by implementing dpatch support which he had recently decried as unhelpful. I also added some extra fuel by getting myself in a two-and-eight over svn-buildpackage and it's broken bias towards native packages.
I happen to disagree with the idea that maintainers should alter upstream files directly, merely relying on the .diff.gz or some weird $RCS runes. Instead, I seek to ensure that the .diff.gz contains no changes outside the debian/ directory. I'm not happy keeping the entire upstream source in yet another RCS (for any reason) and would much rather make updates to my Debian packages by simply copying the debian/ contents into an unpacked pristine upstream source (preferably via uscan). I find it really useful to simply check out the latest CVS/SVN/$RCS, dump debian/ into place and call 'debuild' when testing various upstream development issues. Maybe this is because I have relatively few Debian packages that need debian/patches/* and certainly few that need more than a couple of patch files. It certainly has a lot to do with my embedded work where I need to make changes to the contents of debian/ to make an Emdebian package whilst retaining the same upstream code as is used in existing embedded projects like Open Embedded and Familiar. I don't want to be chasing changes through the upstream source - I want all the changes in a single place so that I can create Emdebian patches against the Debian source. (I'd rather not have patches in the Debian source at all but this is only realistic for either my own packages or those released as part of GPE for various embedded-native compatibility reasons.) I certainly do not want any Debian $RCS to be lumbered with yet another set of upstream sources that will always be out of date compared to the real upstream sources.
I am also a great fan of CDBS - much to the horror of some in Debian - primarily for one very simple reason, it cross builds so easily. Considering my workload, it should not be a surprise that the ability to support cross building without requiring any changes to the Debian package is incredibly persuasive when selecting a build system for a package of my own. debhelper really is woeful at cross building - each package needs customised cross building support painstakingly devised and tested, making script-based mass bug filing impossible. CDBS shows that with a little wrapping, debhelper can support cross building in a clean and completely non-intrusive manner.
This means I can concentrate on those changes that are actually important - the changes that provide the benefits of cross-building and justify the effort of actually cross building the entire dependency chain: the ability to fully control Debian-specifics like "Essential: yes" and to disable, modify or adapt components of any package such that the installed system has a fraction of the dependencies of the Debian version of precisely the same package. TDeb support is good too but that can be implemented against any build, it doesn't need to be a cross build.
Sadly, the end result of all this for tslib is that it will be removed from collab-maint very soon, Joey does not wish to be associated with the new version because although it includes some features which he is happy to see implemented, my use of dpatch and the hacks I had to devise to workaround svn-buildpackage do not fit with his workload patterns. Once tslib is removed from collab-maint, these hacks become redundant and I can use my normal packaging methods. Equally, his methods (in particular the lack of debian/patches/*) do not fit with my workload patterns and although I do not have as many packages as Joey, I have enough (when the 200 Emdebian source packages are also considered) to make the issue into a blocker. The new version of tslib uses the upstream SONAME and adds a -dbg package so it will spend some time in NEW. I am also likely to migrate it to CDBS once removed from collab-maint.
I suspect these issues will be revisited during discussions at Fosdem 2008 where I'll be presenting two talks - one in the Debian developer room and one in the Embedded developer room. Feel free to harangue me if you feel strongly that there is a sane way of cross building that does a better job than CDBS.

Robert A. Heinlein: Starship Troopers (Putnam, 1959)
Paul Verhoeven (director): Starship Troopers (TriStar, 1997) The trouble with movies is that they fit only a short story. You can make a terrific movie out of a short story, but I have never seen a movie made of a novel that was at the same time good and faithful – most movies made of books fail in both. The novel Starship Troopers chronicles the evolution of a high-school kid into a mobile infantry officer in a world which had seen modern democracies fail and be replaced by a veterans’ rule (veterans of also noncombat and civilian service, not just military) – Juan Rico gets in just to impress a girl, and maybe to get to vote some day, goes through boot camp, makes combat drops from orbit as a private and then as a NCO, gets opted for officer training and by the end of the book is a competent officer, helping his old drill sergeant who had found the prize. Along the way we get political sermons (now I know where John Ringo got his tendency to have characters lecture on politics!), some interesting characters and just a hint of romance. The movie paints in broad strokes and primary colors. The first half of it is in fact a fairly decent redesign of the book as a movie, though I did not like at all how much in the face the romance (and two interconnected love triangles!) was played. Johnnie Rico gets in to impress a girl, goes through boot camp, makes some combat drops – And then it transforms into a horror movie (and loses any resemblance with the book). They make a combat drop, Lieutenant Rico drops his mission and goes rescue his girlfriend (the two triangles having been – eliminated by now) and totally misses his old drill sergeant finding the prize. Allegedly, the director never finished reading the book. Well, it shows. In the book, Rico would have been hanged by the neck until dead, dead, dead well before the end of the movie just for striking a superior officer; in the movie, everybody just shrugs it off. The book is an enjoyable military story, the founding father of a subgenre consisting of lots of newer books; the movie is just silly. If you have seen the movie, read the book. Don’t bother the other way around.

New bts command: followup In Debian I'm pretty sure we have many perfectionists. Sadly, I'm one of them: I can't help loosing lots of time fixing silly things totally useless with respect to a more important task which is waiting to be completed. An example? Following up on BTS bugs. If I have the original bug report in my mailbox that's easy, I just hit r on mutt and reply as usual (ok, I will still loose some time getting rid of unneeded quoted text, but that's not too much). If I don't have it ... tragedy! I then have to open the bug log in the browser and compose from scratch a new mail including several information which I have to manually grab from the bug log web page:

• proper recipients (usually one or more of xxxxxx -submitter,-done,-forwarded, @bugs.debian.org)
• proper headers:
  • a Subject starting with Re: and then continuing with the original subject
  • a In-Reply-To header containing the original Message-Id (can I dare breaking threading, of course not!)
• proper body:
  • which should start with a On ... Random J Developer wrote: ...
  • ... and continue with the quoted text of the original bug report

(Yeah, I know, it looks like I'm hopeless, but I'm confident some of the people reading do actually share this and similar dramas.) Missing (or maybe overlooking) a tool helping me out on this, I've patched devscripts's bts to automate the above steps. Now I can do:

bts followup 430986

to end up in a mutt mail composing session with proper (according to the definition of "proper" above) recipients, headers, and quoted text:

From: Stefano Zacchiroli <zack@debian.org>
To: 430986@bugs.debian.org, 430986-submitter@bugs.debian.org
Cc: 
Bcc: 
Subject: Re: when reporting bugs by maintainer, please include Uploaders
Reply-To: 
In-Reply-To: <20070628174236.13848.57178.reportbug@aquarium.takhisis.invalid>
On Thu, 28 Jun 2007 19:42:36 +0200, Stefano Zacchiroli wrote:
> Package: bugs.debian.org
> Severity: wishlist
> 
> Browsing bugs by maintainer (and with this I mean something like
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=zack@debian.org, or
> it shorter form http://bugs.debian.org/zack@debian.org) used to be
> terribly useful as a TODO list. Using that I used to have a simple entry
> point for knowing what I have to do "for Debian" regarding my packages.
> 
> This usefulness has diminished a lot with the spreading of team
> maintenance. To know all bugs that apply to me indeed I know have to
> repeat browse by maintainer for each team I'm a member of.
> 
> It would be terribly useful to include bugs which apply to packages in
> which I'm mentioned as an Uploader in the report by maintainer pages.
<snip>

Now I just need to actually perform the original task, the problem now being that in the meantime I've forgotten what was it about ...

---

Try it out:

• bts with super followup powers
• the patch which adds super followup powers to bts of devscripts version 2.10.13

Comments?
Anyone else find this useful? If so I can just go ahead and commit it to devscripts mainline ...

---

Update: some changes to the code, thanks to Adam Barrat for the feedback.
Changelog:

• safer handling of RFC822 line continuation
• instead of always mailing -submitter, mail the author of the message we are replying to (the bug report is always on Cc though)
• bug message number is now 1-based, following the convention of the BTS get_bug_log method
• add the possibility to specify "last" (and even "last-1" and so on) for pointing to messages in the bug log starting from log bottom

samba.grep.be. This machine has been my trusty publically-accessible server for about four years now. It runs my website, including this blog, is my primary MX, contains my subversion repositories, and my gallery. For slightly less than the first year of Planet Grep, it was the only machine running that site (it has now been migrated to two machines running in two different data centers, to cope with the ever-increasing bandwidth usage of that site). It runs the bacula-director for our backup system, and it contains the modem behind our fax number, allowing us both to receive faxes and to log in using PPP to our local network. Most importantly, I've been using it as an SSH jumphost and IRC box to allow me to connect to other machines whenever I'm behind an overly paranoid firewall. But now it's time to retire the machine. The high number of services combined with the, to today's standards, low number of available system resources, is beginning to be a problem. A few times now, already, I've had to reboot the machine because a load spike was making it unresponsive. So it has to go. Many people will be shocked to find out that the machine powering samba up to now was an IBM SurePos 500. No, really. The reasons are long and complex, but suffice to say that there was a point in time where I wanted to set up a server for myself, and I had an idle, never-to-be-used-anymore, 2000+ priced, machine standing by. So there I went, usurped this machine as server, and have given it near-100% uptime. If you want to know just how near-100% that is:

  9 Power_On_Hours          0x0032   058   058   000    Old_age   Always       -       31170
[...]
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       99

Or, in plain English: according to SMART, the hard disk has seen just 99 power cycles in four years. This machine was never designed to do that. Side note: yes, that is a touch screen on top of that box. The new machine is much, much better. We're going from this:

model name	: Intel(R) Celeron(TM) CPU                1200MHz

to this:

model name	: Dual-Core AMD Opteron(tm) Processor 1210

which is much, much better. The box actually containing this processor is also much, much better. However, there was one problem: the old processor was a PentiumIV-class processor, requiring Debian's i386 port, whereas the new one (obviously) contains a processor that will allow me to run the amd64 port; and I did intend to do this. Additionally, I wanted to migrate from a simple "root-on-partitions" system to a "root-on-LVM" system, with Xen somewhere in between. As such, simply rsync'ing the entire hard disk on the old system over to the new system (my usual way to migrate a non-critical server) wasn't going to work. Luckily Debian isn't too hard to migrate from one machine to the other, however.

• Installed Debian on the new machine, giving it the same hostname (samba) as the old one, but with root on LVM.
• Ran 'dpkg --get-selections' on the old machine, feeding the output to 'dpkg --set-selections' on the new one. Installed packages.
• Rsynced over /home
• Rsynced /etc over to a separate directory on the new box, and copy some files (such as fstab) from the live /etc on the new box into the separate directory.
• Rsynced /srv over
• Rsynced /var over to a separate LVM volume.
• Created a snapshot volume of that /var LVM volume, moved most of the live /var over to some place else, and added the original LVM volume (i.e., not the snapshot) to fstab. Obvious exceptions were such things as databases, which usually have an architecture-specific on-disk format, and the dpkg directory.
• Brought the original system to runlevel 1.
• Rsynced /home, /srv, and /var over again to get the last-minute changes in.
• Rsynced (with --delete) the separate /etc over the live /etc.
• Brought the original system down.
• Rebooted, checked which services died because their on-disk format also differed between i386 and amd64, utterly and completely killed those, copied the files from the original amd64 /var back again, and made some type of plain-text dump that I then imported into that service.
• Rinse, repeat until all those services work. Then, removed the /var snapshot (didn't need that backup anymore, then), and voila.

Or, well, that was the idea. Because I forgot about one silly detail: if I wanted to make everything work out correctly, I would have had to keep UID numbers in synch. Unfortunately, I forgot about that; and as a result, a number of files were created with the wrong owner. This made all kinds of things fail horribly; and rather than stop and think about it, which would have made me copy the old passwd file over from the old installation, add some extra lines for users that were on the old server but were not yet created on the new one, and then finally leave it at that, everything would've been fixed. Instead, I started to change ownership of files all over the filesystem, creating a mess of things. Silly me. But, well, in the end I did get everything to work correctly; even if it took me longer than expected. No worries.

With no standard ways of plugging input methods into Linux desktops, trying to develop one used to be difficult. No more — now there is an actual standard to address this small but important part of Linux, especially for East Asian users. Last week, I was in Beijing to chair the Input Method Sub-Working Group meeting for the 13th time over the past three years. The IMSWG is part of the larger Northeast Asia OSS Promotion Forum (NEAOSS), formed by the Chinese, Japanese and Korean governments for pushing open source software. Over the past few years, every detail of how input methods should work were discussed and debated among participants from the three countries. All had strong opinions on the architecture of the system, and at times it seemed impossible for them to agree on the specification. We solved that by getting them to write software code instead — being programmers, we found they understood each other better in computer languages than in English. Now, not only do we have an agreed specification, but we are also developing a reference implementation, IMBus, thanks to the hard work of all involved, which includes James Su of SCIM fame, and Hideki Hiura, the designer of XIM and IIIMF. James gave a nice talk about IMBus at last year’s LF Desktop Architects Meeting. I said “nearly” because the overhead of being a semi-government entity means the specification won’t be published until later this year. But all technical issues have been dealt with. With hope, this specification will work its way up to ISO and published as an ISO standard in future. ISO being ISO, this won’t happen anytime soon — I’ll talk more about that later. Update: this post now also up on the Outblaze blog.

At the dayjob, we're currently clearing our warehouse of previous hardware to make room for upcoming new models, so here's a shameless plug for those who want cool Linux hardware at a discount:

ThinCan DBE60 Hardware: AMD Geode SC2200, 64MB RAM, 32MB DiskOnChip Flash, 3x USB 1.1 ports, 1/8" audio out, Centronics port, VGA port, 10/100baseT network port. Firmware: Etherboot or WinCE 4.1 RDP client. Price: 50 EUR/each - less shipping costs - Minimum order: 10 pieces. PS: we also have about 50 pieces of DBE60 motherboards (without case) that can be used as embedded controllers. People with good soldering skills can add a CompactFlash socket to the unpopulated pads, as desired. ThinCan DBE61C Hardware: AMD Geode LX700 with CS5536 companion chip, 256MB RAM, 4x USB 2.0 ports, 1/8" audio in and out, VGA port, 10/100baseT network port. Firmware: Etherboot on LinuxBIOS. Supported natively since Ubuntu/Gutsy. Price: 150 EUR/each - less shipping costs - Minimum order: 2 pieces.

Interested parties can contact us via the request form.

could have just been a nice Summer morning, uneventful as they usually are, were it not for the fact that it was already 19:00, and it was mid-winter. (with due apologies, of course, to Bob Dylan and Les Luthiers) Nadezhda called me, warning me about a very dark sky and strong winds, and went off for her meeting. I told her weather looked decent from mx office... But started paying attention. And yes, wind was crazed. Hints of an upcoming power outage were felt in the Institute. I left my office as soon as I could. Cycling back home was quite a challenge - The 3.1Km route back home, usually much easier than the way there as it's mostly downhill, was quite a challenge: Biking with eyes almost-closed because of the flying leaves and dust, and little but menacing raindrops... Scary, all in all. Anyway, it gets scary... At least one person was killed because of the winds not far from here. This city has the fame that febrero loco y los vientos otro poco (February is crazy, but the winds are even more). And the first crazy wind of the season are always scary.[update] One person dead because of the strong winds in Mexico City; Power outages in several areas; Three more hours of strong winds expected; Heavy winds caused by the #24 cold front(?); Winds cause mayhem on DF streets;