The last time I have blogged, few people told me that it sounds somewhat patronizing or such (especially that it may sound so to people that do not know me). Well, I have to admit that it is hard to write in a decent tone — the intention and motivation behind the text is oftentimes hard to express. Certainly, better writing skills would probably help — or choosing easier topics. But that is how I am — and afterall, you never learn much when you only do things you already know how to do. So please, dear reader, take no offense in my blog… If you know me, you can probably see through my writing and understand what I mean. If you do not and still enjoy it, the better. And if you do not, please accept my apology — but in that case, it probably was not meant for you. Yes, I know the blog is aggregated in a few places, and I will probably have to do something about this — aggregate only subsets of the blog, appropriate for each of the aggregators. But pretty please, bear with me, I am lazy and it always took me ages to fix even trivial problems.

The current method of carrying young children (less than 4-6 years old) in cars is to have a special car seat fitted in the back seat. This has several significant problems:

• It takes significant space in the back seat. The child seat is going to add at least 10cm to the length required in the back seat and often drives the purchase of larger cars (including SUV and 4WD vehicles that are known for being unsafe - especially for children). Having child passengers in a car is a great distraction for the driver, driving a large vehicle increases the difficulty in avoiding accidents - especially when parking.


• The seat belts of the rear seats are used as part of the mechanism of attaching the child seat to the car. Seat belts are designed to stretch in a crash. It’s recommended that after a crash all seat belts that were used to secure people or objects be replaced as they will have stretched. Seat-belts that don’t stretch will cause more serious injuries. It seems likely to me that a seat belt used to tightly secure a child seat for a long period of time will stretch without a collision. Therefore if an older child is seated where they (or another child) used to have a child-seat then they may be at greater risk in the case of a collision.


• Child seats should be fitted by specially trained experts if they are to be safe. The majority of seats are not correctly fitted and put children at needless risk (the cost of getting an expert to do the installation is small).

Some car companies are offering child “booster seats” that are an optional attachment to the rear seat (I first noticed this when reviewing the specs of the latest version of the car I drive - the VW Passat [1]). This is a good idea, but it doesn’t go far enough. The best thing to do would be to provide a selection of back-seat assemblies as factory fitted options which have built-in baby and child seats. The combinations that would be most desired are:

1. Standard car back-seat for three adults (or two adults for a small car).


2. A regular seat (for an adult) at the road side of the car combined with a baby (backward facing) seat at the kerb side.


3. A regular seat (for an adult) at the road side with a young child (forward facing) seat at the kerb side.


4. A baby seat at the road side with a young child seat at the kerb side.


5. Two young child seats.

It would be quite possible to have all five of these options available from the factory. Of course there are corner cases that this doesn’t cover such as twins or parents who have two children so close together that they need two baby seats. For those cases option 2 combined with one of the current off-the-shelf baby seats would do. The number of different supported options would need to be kept reasonably small to reduce manufacture cost and to allow a reasonable market for second-hand seats. One thing to note is that it’s recommended that the first forward-facing seat a child uses is smaller than the later one. Having options for three different built-in baby/child seats (rear-facing and two sizes of forward-facing) would significantly expand the number of combinations (and thus the expense). I suspect that the safety benefits of having an ideal method of securing a forward-facing child seat would compensate for the disadvantage of having it be too large for the child when they are first placed in it. Another possibility would be to replace the rear seat with a more solid bench with bolt holes for baby and child seats. Securing a child or baby seat to a hard surface with bolts would be a much less technically demanding task than using a seat belt (and thus could be done correctly without expert assistance). Child and baby seats would have to be redesigned for this (I suspect that the safety of them relies on being attached to a soft surface), but after that I expect that safety would improve. For this option the rear seat could bold on to a hard surface that’s suitable for attaching child/baby seats so it would simply be a matter of removing the rear seat and installing the child/baby seat(s). The most common car design in Australia includes a 60/40 split rear seat (meaning that if you have a large item to store in the boot/trunk then you can fold down 40% or 60% of the back of the rear seat to allow the luggage to extend into the passenger compartment). This split could be extended to allow removing the base of the rear seat for 60% or 40% to bolt on child/baby seats. Once a car model had been designed for replacing the rear seat there would be other options available. For example replacing the rear seat with luggage storage space. While almost all cars allow folding down the backs of the rear seats to store extra luggage the option of removing seats that you don’t need to give even more space is not common at all (I’ve only seen it advertised as a feature in vehicles with 6 or more seats). I expect that if this idea was implemented it would allow a small car such as a Toyota Corolla to give an equal or greater amount of usable space for children in the rear as a larger vehicle such as a Toyota Camry. While better options for luggage storage would allow people who don’t have children to use a small car while still being able to carry the luggage that they desire. This would allow considerable savings on car purchase prices and fuel use. I expect that a reduction in fuel use world-wide could be achieved by removing the pressure on parents to buy large cars! The poor support for child seats in cars is really surprising. One of the features that could be introduced is both top and bottom mounts for such seats. There is apparently a standard for this, some (not all) cars support it, but most baby seats apparently don’t. So baby and child seats are secured at the top (to a hook that’s bolted securely to the car frame and which was designed specifically for the purpose) and at the bottom to the seat-belt which was never designed for such things. It’s a pity that some of the money spent on supposedly protecting children from drugs couldn’t be spent on making cars safer for them. The government is in the best position to force car manufacturers to improve their safety features while parents are in the best position to teach children about the dangers of drugs.

• [1] http://www.volkswagen.com.au/pdf/Brochures/Passat_160807.pdf

Share This

I'm so annoyed with myself. So today was the day I was going to upgrade the disks in daedalus. I'd finally managed to convince Dell to sell me two new 140Gb disks to replace to two 70Gb disks that were fast approaching capacity. I'd organised for access to the datacentre from 10am. I arrived early. I didn't manage to get into the datacentre until about 11am, because they were having problems remotely unlocking the door, and I had to wait until an air conditioning repair guy turned up, who was fixing some air conditioning problem. I hadn't had a lot of time to plan how I was going to do the upgrade, but I figured it was going to be pretty straightforward. Each disk is partitioned into three partitions, all of which are mirrored using software RAID. The first partition is the root filesystem, which is just an ext3 filesystem, mirrored. The second partition is swap, also mirrored, and the third partition is an LVM physical volume. The first two partitions are only a couple of gigabytes. So the basic plan was to remove the second disk (disk 1, aka /dev/sdb), put in the new bigger disk, load the partition table from the original disk 1, resync the three mirrors, and then boot off the new disk 1, and rinse and repeat with disk 0. This was all going swimmingly, when right at the end (in fact after the third partition finished syncing according to the kernel), /dev/sda decided it had a few unreadable sectors. This made the software mirroring have a dummy-spit, and decide it needed to restart the syncing from scratch. I'd seen this before with a bad disk. So I wishfully hoped it was something to do with the new disk being bigger than the old disk, so tried to roll back to the original disk 1. As was pretty much expected, disk 0 exhibited the same problems at the same point. So the problem was disk 0, not the new disk 1. So it seemed like I just managed to pick the wrong half of the mirror to work from. I thought I'd try manually dd'ing the third partition from /dev/sda to /dev/sdb, ignoring the errors, but that didn't result in a usable half of a mirror either. Interestingly, these bad sectors hadn't made themselves known until this point. The RAID array had been otherwise healthy, and SMART hadn't uttered a peep. I think at this point, after spending about 3 hours fighting with it, I decided to move up a layer. I could successfully sync /dev/md0 (the root filesystem) and /dev/md1 (the swap device), and the only reason I could think of these bad sectors not giving me grief already, was because they were right at the end of the disk, and I hadn't quite used all the free physical extents in LVM yet. Lucky I hadn't decided to grow things any further. So I decided that rather than trying to convince this existing /dev/md2 to sync with the new /dev/sdb3, I'd just build a new degraded RAID-1 on /dev/sdb3 and move all the physical extents from the degraded RAID-1 on /dev/sda3 to the new degraded RAID-1 on /dev/sdb3. I tried the logical volume with /tmp on it first, since it was fairly sacrificial. It worked fine. So I tried the largest logical volume, /srv, which was 30Gb. That went fine as well, so I moved the rest. All of them went without complaint. So then I removed the now unused /dev/md2 from the volume group, and finally managed to boot with just the new disk 1. Then I was able to put in the new disk 0, and just do a standard RAID-1 rebuild onto it. Hooray for LVM saving the day yet again. And this is where I should have stopped. At this point it was about 3pm. I'd been aiming to leave by 4pm to pick up a rental car that I had to get by 5pm. I'd wanted to also upgrade to Etch while I was physically in front of the box, in case there were any nasty kernel/udev issues that made the box unbootable. The catch was, I needed to grow /var, which was quite full. The intention had been that once I'd got the two new disks in and all synced up, I'd create a fourth mirrored partition, and add this to LVM as a new physical volume, then I could just keep merrily growing things. It felt a little bit dirty having to make a new partition to get at the extra space, and I'd reading about mdadm's "grow" mode, whilst I was sitting around waiting for things to sync. So I thought to myself, I'd just delete the third partition, and recreate it using the remaining additional cylinders I now had at my disposal, then use this grow feature of mdadm to tell Linux the array was now bigger, then resize the physical volume, and go from there. This is where things went a bit pear-shaped. I deleted and recreated (larger) the third partition on each disk, and rebooted. I was then messing around with mdadm trying to update /etc/mdadm/mdadm.conf, since the UUID of /dev/md2 had changed, when I discovered that /dev/md2 had completely disappeared. It seems that recreating that partition made Linux completely fail to see /dev/sda3 and /dev/sdb3 as RAID-1 members, and so because of the fairly transparent nature of Linux's RAID-1, LVM had seen the underlying physical volumes, and just decided to run with /dev/sda3 as the physical volume, and everything had continued to work. I just had no redundancy any more. So it was about 3:20pm at this stage, and I was starting to panic, thinking I'd never get this sorted out before I had to leave, and I'd end up returning to the US with a non-redundant mess on my hands. Then I remembered that I had the backups of the partition tables of the old disks, from before I removed them. So I thought I'd go back to that state, and just have the additional cylinders unallocated. I hadn't yet attempted to grow the RAID-1 (partly because it had vanished), so in my haste, I didn't see this being a problem. The problem was, I'd booted into multi-user mode, and things had merrily been operating on just half the mirror. I restored the partitions, and rebooted, and lo and behold, /dev/md2 magically reappeared, already 100% consistent according to /proc/mdstat. I was somewhat surprised by that, but I booted back into multi-user mode again, only to discover that the /var filesystem was panicking and remounting itself into read-only mode. This was pretty weird, given that during boot, it was considered clean by e2fsck. So I was really getting bothered by this stage, so I rebooted into emergency mode (single-user mode in Debian starts way too much), and manually started up LVM, and forcibly fscked everything. There was a bit of filesystem damage to /var, /home and /srv. Thinking I'd now fixed the problem, I rebooted into multi-user mode again, but again /var, which was considered clean during the fscking/mounting phase of booting, panicked shortly after mounting, and remounted itself read-only. So I rebooted again, broke the mirror, and forcibly fscked the filesystems again (only operating on what was on /dev/sda3. Then I rebooted without incident into multi-user mode and resynced the mirror. At this point I ran away. So I'm really annoyed with myself. This should have been a blog post about how crap Linux's software RAID is at error recovery, and how LVM saved the day yet again, but it was overshadowed by me overreaching in my haste, and managing to cause silent data corruption. The morals of this story:

• If things go off the rails, and you get to a reasonable milestone, and you're approaching the end of your maintenance window, quit while you're ahead.
• Don't do stuff in multi-user mode, just because you can and you want to minimise the length and magnitude of an outage
• Don't rush to try and do something (growing a RAID-1) without researching it properly
• Linux's software RAID-1 sucks when the underlying devices are having issues (I already knew this)
• Linux's software RAID-1 can look perfectly healthy when the underlying disk has issues, as long as the bad bits aren't getting any exercise (I think newer versions of mdadmand/or Linux address this by doing a full array check on a regular basis)
• Linux's software RAID-1 can get out of sync with reality and report that it's in-sync with itself when it isn't really, which causes silent data corruption
• e2fsck can report a filesystem is clean when it's really got issues

I think that is all. I'm just so pissed off that what could have been a perfect (enough) upgrade with zero data-loss, even considering I had a bum disk, wasn't.

Debian describes itself as the Universal Operating System, and basically tries to run in the same way everywhere, from an NSLU2 to an s390. I find it funny to see the number of Ubuntu variants. I can understand that for marketing reasons (Debian doesn’t really know about marketing), it is good to advertise Kubuntu, Xubuntu, etc. Even if it’s the same distro and the same packages. But seriously. An Xubuntu EEE now. I’m the happy owner of an Asus EEE PC, running Debian. Installing Debian on it is quite straightforward, and only requires you to install the module for the ethernet NIC (available as Debian package), to compile the madwifi driver (non-free, patched version needed) for Wifi, and hack a few scripts in /etc/acpi if you want to get the hotkeys (volume, etc) working. Nothing impossible, really. And for those not familiar with the command line, some detailed documentation could be written, or a Debian package or a script that does all the tuning could be provided. (I think all of this has been done already anyway) But an new Ubuntu derivative! Just for that! Are we going to see a new Ubuntu derivative for each new laptop that is not perfectly supported yet? Hey, my desktop PC’s keyboard has some hotkeys that don’t work properly without hacking .xmodmaprc. Can I get my Ubuntu derivative? :) Also, GNOME works perfectly on the EEE, and I assume KDE does as well. What about Ubuntu EEE, and Kubuntu EEE? Now, let’s watch the flow of blog posts from Ubuntu fans acclaiming the release of the Xubuntu EEE. Comments closed, trackbacks open.

PTS face lift(ed!) Ok, by now you've probably all already noticed, but I've finally committed the changes to the PTS package pages which implement a new layout and CSS. Thanks to Dan Callahan, Enrico Tassi and madcoder for their help with the CSS and to all who gave feedback (sorry, if it wasn't possible to satisfy all look and feel requests at the same time). There are still some minor, freshly introduced, glitches to fix (see for example 457168 and 457169), but I'm kinda tired to play with CSS and I'll give up for a while. But patches are always welcome!, I'll do my best to apply them timely. While I was at it, I've also fixed some other minor nuisances, such as the svnbuildstat link which is now shown only if the package is actually indexed by svnbuildstat. Thanks to Gon ri for having made available the info. PS totally unrelated, but thanks to Lucas now the homepage and vcs stats page sport wonderful graphs!

Andreas Schuldei writes about my blog post about making it easier to contribute to Debian:

It is much more gratifying for a contributor if his effords have
immediate effects.

[…]

So what can people who want to help Debian do to achive more imminent gratification? Pick projects that let you help directly with direct svn/git/whatnot access (Security team, Debian Edu, Debian-Installer…)

While I agree that Instant Gratification is very important, I don’t think that the proposed solutions solve anything. It’s easy to have things sleep in an SVN repository instead of the BTS (lots of teams do that, sometimes for good reasons, like the lack of sponsors - hint: Games team). It doesn’t make things any better. What we need is tasks whose results will be available without too much wait in Debian unstable, for everybody. Also, I must admit that I know very little about the inner workings of the Security Team. But I have the idea that it involves quite a lot of procedures (helping with bugs tagged security probably doesn’t, but going further than that probably does). Contributing to Debian already involves A LOT of procedures. A new contributor, even very good technically, can easily get lost in all the different ways to package stuff and solve common problems. So we should identify tasks that don’t have huge requirements. Ubuntu has the concept of bite-size bugs. I started working on a page explaining the different ways someone can contribute to Debian. The goal is to provide a good entry point (not something that replaces existing documentation) and keep it at a manageable size. Its focus is mainly to replace the emails we write to people asking “I’d like to contribute, but I don’t know what I can do or where I should start!”. The page is available on wiki.d.o/HelpDebian/Start. Don’t hesitate to improve it (see also wiki.d.o/HelpDebian for a TODO list). When it will be good enough, I plan to move it out of the wiki (the content shouldn’t change much anyway) to eg http://help.debian.net/, so we can improve the design (I really like the idea of adding pictures of past Debconfs like Christian Perrier did in his FOSS.in talk).

Regarding Lucas' points that he makes about helping debian, I think there is an important factor for people that was only mentioned between the lines: "Instant Gratification". It is much more gratifying for a contributor if his effords have immediate effects. (I guess that is one reason for the success of Wikis.) Things that slow down the effect usually dimish this gratification.

So what can people who want to help Debian do to achive more imminent gratification? Pick projects that let you help directly with direct svn/git/whatnot access (Security team, Debian Edu, Debian-Installer...).

On the other hand we should try to come up with ways to cut down on delays as much as possible and make it easier to rollback and repair if an error occures. (That is almost allways a good thing anyways.)

Ian, what you have discovered is not ARM specific. A lot of cast expressions in use in today's software would actually be undefined behaviour, but compilers accept them anyway. Write that code by explicitly reading the bytes from the array and ORing them together — it is the duty of the compiler to find out that the CPU can optimize this.

Emdebian SVN r2618 includes my first working implementation of em_installtdeb. Barring a single annoyance message from dpkg, the script works.
The warning arises from the need for a modified "source" tarball that can be uploaded alongside the .deb, containing only the sources needed for this specific translation: debian/control, debian/changelog, po/$lang.po /* if any */ and po/$GETTEXT_PACKAGE.pot. Where a package contains more than one po directory, all POT files are included and all po files for the requested translation. This allows translations to be updated independently of the upstream package.
I would advise using a test directory if you do want to try it, not your main package building directory.
Output (using gpe-expenses as the demo package) in translator mode:

$ em_installtdeb sv
dpkg-deb: building package gpe-expenses-locale-sv' in ../gpe-expenses-locale-sv_0.1.4-1_all.deb'.
dpkg-source: warning: .orig.tar name gpe-expenses_0.1.4.tdeb.tar.gz is not _.orig.tar (wanted gpe-expenses_0.1.4.orig.tar.(?:gz bz2 lzma))
dpkg-source: building gpe-expenses using existing gpe-expenses_0.1.4.tdeb.tar.gz
dpkg-source: building gpe-expenses in gpe-expenses_0.1.4-1.diff.gz
dpkg-source: building gpe-expenses in gpe-expenses_0.1.4-1.dsc
dpkg-genchanges: including full source code in upload
Format: 1.7
Date: Fri, 07 Dec 2007 00:08:39 +0000
Source: gpe-expenses
Binary: gpe-expenses-locale-sv
Architecture: source all
Version: 0.1.4-1
Distribution: unstable
Urgency: low
Maintainer: Neil Williams
Changed-By: Neil Williams
Description:
gpe-expenses-locale-sv - sv translation for gpe-expenses
Changes:
gpe-expenses (0.1.4-1) unstable; urgency=low
.
* New upstream release
* use machine operable debian/copyright, migrate to standards 3.7.3
Files:
781a60eccc4396ee3f0f86a01150e755 316 misc extra gpe-expenses_0.1.4-1.dsc
f9dd946db27ff6077f8e85f7100d3ea4 5863 misc extra gpe-expenses_0.1.4.tdeb.tar.gz
894f5789ee0348abfa61a5e7342ed6a7 20 misc extra gpe-expenses_0.1.4-1.diff.gz
56f8d22c30cb5502633ff4d26862db78 4532 misc extra gpe-expenses-locale-sv_0.1.4-1_all.deb
Package-Type: tdeb
Changes file: ../gpe-expenses_0.1.4-1_tdeb.changes
signfile ../gpe-expenses_0.1.4-1.dsc 0x28BCB3E3

You need a passphrase to unlock the secret key for
user: "Neil Williams (Debian) "
1024-bit DSA key, ID 28BCB3E3, created 2002-01-27


signfile ../gpe-expenses_0.1.4-1_tdeb.changes 0x28BCB3E3

You need a passphrase to unlock the secret key for
user: "Neil Williams (Debian) "
1024-bit DSA key, ID 28BCB3E3, created 2002-01-27


Successfully signed dsc and changes files
neil@holly:gpe-expenses$ dpkg -c ../gpe-expenses-locale-sv_0.1.4-1_all.deb
drwxr-xr-x neil/neil 0 2007-12-19 14:37 ./
drwxr-xr-x neil/neil 0 2007-12-19 14:37 ./usr/
drwxr-xr-x neil/neil 0 2007-12-19 14:37 ./usr/share/
drwxr-xr-x neil/neil 0 2007-12-19 14:37 ./usr/share/locale/
drwxr-xr-x neil/neil 0 2007-12-19 14:37 ./usr/share/locale/sv/
drwxr-xr-x neil/neil 0 2007-12-19 16:09 ./usr/share/locale/sv/LC_MESSAGES/
-rw-r--r-- neil/neil 6419 2007-12-19 16:09 ./usr/share/locale/sv/LC_MESSAGES/gpe-expenses.mo
-rw-r--r-- neil/neil 1796 2007-12-19 16:09 ./usr/share/locale/sv/LC_MESSAGES/qofexpensesobjects.mo

Hmm, that isn't right - need to check on the ownership of those files - might be enough to use fakeroot.

$ dpkg -I ../gpe-expenses-locale-sv_0.1.4-1_all.deb
new debian package, version 2.0.
size 4532 bytes: control archive= 302 bytes.
230 bytes, 9 lines control
Package: gpe-expenses-locale-sv
Source: gpe-expenses
Version: 0.1.4-1
Architecture: all
Maintainer: Neil Williams
Installed-Size: 44
Section: misc
Priority: extra
Description: sv translation for gpe-expenses


em_installtdeb is a debhelper add-on created by Emdebian to create translation packages (tdebs). em_installtdeb is intended to separate out the individual translation files from the current Debian packages into packages without any translation files and a series of tdeb locale packages, one per translation. Generated packages use the syntax: $package-locale-$language_code_$version_all.deb
Certain language codes need to be modified to make acceptable components of a debian package name. Underscores are converted to hyphens, '\@' is converted to '+' and all codes are made lowercase. These changes only apply to the package name, the installation location is unchanged.
The locale package must use GETTEXT_PACKAGE for the eventual filename of the binary translation file - not the $dh MAINPACKAGE . GETTEXT_PACKAGE is determined by upstream, not Debian. When building the whole package, the binary translation file may be in debian/tmp/usr/share/locale/$lang/LC_MESSAGES but when in translator mode, this location is not available. Instead retrieve GETTEXT_PACKAGE from the POT filename. debian/control is needed for various dpkg and debhelper calls only.

The "source" for translators therefore includes:
debian/control
debian/changelog
po/$lang.po /* if any */
po/$GETTEXT_PACKAGE.pot

Note that no rules file exists. (i.e. dpkg-source -x will complain when trying to extract it later so a new wrapper is needed (not difficult).)
em_installtdeb will try to generate the necessary POT file(s) and then create a $package_$version_tdeb.tar.gz containing the source files.
The default action is to process all available po files.
The above example uses translator mode where LANG_CODE is passed to only handle that language. In translator mode, em_installtdeb builds a tdeb package, a source tarball, a .dsc and a .changes file (and signs the .dsc and .changes). In default mode, em_installtdeb builds the package(s) but leaves the source, .dsc and .changes to the rest of the build process.
LANG_CODE can either be the name of the locale as specified in the PO filename (fr, en_GB, sr@Ltn etc.) or the name of the locale as specified in the eventual package name (fr, en-gb, sr+ltn etc.).
If a po file already exists for this locale, em_installtdeb processes just that one translation and builds a single tdeb package.
If the po file does not exist, em_installtdeb exits with an error. (Copy the POT file from the original source to create a new po file for the new locale and edit it to include the new translation, then run em_installtdeb again.)

Output in default mode:
$ em_installtdeb
dpkg-deb: building package gpe-expenses-locale-cs' in ../gpe-expenses-locale-cs_0.1.4-1_all.deb'.
dpkg-deb: building package gpe-expenses-locale-de' in ../gpe-expenses-locale-de_0.1.4-1_all.deb'.
dpkg-deb: building package gpe-expenses-locale-pt' in ../gpe-expenses-locale-pt_0.1.4-1_all.deb'.
dpkg-deb: building package gpe-expenses-locale-sv' in ../gpe-expenses-locale-sv_0.1.4-1_all.deb'.
dpkg-deb: building package gpe-expenses-locale-vi' in ../gpe-expenses-locale-vi_0.1.4-1_all.deb'.

Next stage is to fold this into emdebian-tools so that the emdebian patch files can be cleaned up and various complex patches to debian/rules can also be cleaned up.
Finally, note that this only supports gettext and only supports program translations. This is an Emdebian script written with an eye on usage in Debian but primarily intended to meet Emdebian requirements. As outlined before, Emdebian does not want language packs or translation grouping. One locale, one package.
See also langupdate in Emdebian SVN.

I spent a rather long time today trying to figure out a rather obscure bug. I few months ago I bought a gp2x, an open portable gaming system (and media player, etc.). I've really enjoyed it so far. The open platform for development has lent itself it many fun apps, console emulators the most conspicuous I think, but it's also fun to experiment and develop with it. I recently ported an asteroids clone I wrote and the whole process was actually fairly simple. As such, I decided to take on a larger task of porting something like FreeCNC, which as far as I know, no one has done yet.

After some simple trouble with library version conflicts, I got the program compiling correctly. However, if wasn't reading files quite right. I spent a little while investigating and discovered the problem was in a function which essentially hashes filenames. In the end, it was this snippet of code which was giving the trouble:

char buffer[13];
...
calc = ROL(calc)+*(long *)(buffer+i)

In particular, this is trying to read 4 bytes from this character array as an integer. At first I though the trouble might be endian-ness, but both the gp2x (an ARM processor) and x86 use big-endian^*. I finally resorted to running gdb and sifting through assembly level instructions.

$r2 = 0xbffffd7c
$r3 = 0x41434f4c
0x0000a310 _ZN8MIXFiles7calc_idEPc+52>: str r3, [r2]

Here, the register $r2 points to buffer and $r3 is the value we're trying to save into the buffer. After this we would expect
*0xbffffd7c = 0x41434f4c
but instead see
*0xbffffd7c = 0x08db9841.
If I purposely set *0xbffffd7c = 0xffffffff and repeat this instruction we see
*0xbffffd7c = 0xffffff41.

Clearly the problem lies in this single str instruction, and was resident to the ARM architecture. So of course it was time to go to the processor documentation. Reading the fine print finally reveals what I was looking for.
A word store (STR) should generate a word aligned address. The word presented to the data bus is not affected if the address is not word aligned. That is, bit 31 of the register being stored always appears on data bus output 31.
Yep, since the buffer was an odd-sized array and stored on the stack, it started on an odd number in memory. Hence its address was not word aligned, and so as per the documentation, the store did not have the expected result. Here's a short program which shows what I'm talking about.

x86	ARM
buf=BFBF3471, buf%4=1 Num: 4C4F4341 Buf+0: 4C4F4341 Buf+1: 4C4F4341 Buf+2: 4C4F4341 Buf+3: 4C4F4341	buf=BFFFFD75, buf%4=1 Num: 4C4F4341 Buf+0: 4F434100 Buf+1: 43410000 Buf+2: 41000000 Buf+3: 4C4F4341

Perhaps the lesson to learn here is that when casting pointers, it's buyer-beware, and there are safer bitwise manipulations to use, though certainly less efficient.


^*Edit: Both x86 and the ARM processor in question are little-endian, not big-endian. Typo on my part, but notwithstanding the point is that they both had the same endian-ness, so it wasn't where the issue lay.

Credit for finding out how to do this goes to dims, who has been doing lots of cool Android hacking lately: http://davanum.wordpress.com/2007/12/18/android-task-manager-primitive-prototype/ If you're interested in Android and what it can do, you should be following his online journal! As a way to keep pushing and testing Hecl, I decided to see if I could copy what he'd done in Hecl. It has indeed produced a few improvements to the Java code. That done, making it work was short and sweet:

set layoutparams [linearlayoutparams -new  FILL_PARENT WRAP_CONTENT 
set layout [linearlayout -new $context]
$layout setorientation VERTICAL
# Create ourselves some commands to access Android internals.
java android.app.ActivityManagerNative activitymanagernative
java android.app.IActivityManager iactivitymanager
java  android.app.IActivityManager$TaskInfo  taskinfo
java android.content.ComponentName componentname
java java.util.List javalist
set am [activitymanagernative getdefault]
set tasks [$am gettasks 10 0 [null]]
set len [$tasks size]
set tasklist [list]
for  set i 0   < $i $len   incr $i   
    set baseactivity [[$tasks get $i] -field baseactivity]
    lappend $tasklist "Task: [$baseactivity getpackagename]"
 
$layout addview [textview -new $context -layoutparams $layoutparams \
         -text "Currently running tasks"]
set lview [basiclist $context $tasklist -layoutparams $layoutparams]
$layout addview $lview
$lview requestfocus
set callback [callback -new [list [list SelectTask]]]
$lview setonitemclicklistener $callback
heclcmd setcontentview $layout
proc SelectTask  parent view position id   
    [activitymanagernative getdefault] movetasktofront $position
 

It could have been squeezed further by avoiding some of the temporary variables, and perhaps also by implementing a mapping between java.util.List and Hecl lists. I think one of the next things I want to do is work on some infrastructure so that people will be able to actually work on scripts on their phone. That's sort of a departure from the past (most phone keyboards would be sheer torture for inputting long scripts), but it's a cool demo in any case.

I have just read a rant by Sean Middleditch about bad project management [1]. He describes his post as “personal, rather angsty, and especially whiny” but I think it’s useful and informative. He makes some interesting technical points about PHP programming (I wasn’t aware that there were so many ways of easily getting things wrong and having difficulty to get them right). But of course this isn’t all limited to PHP, the web site WorseThanFailure.com has anecdotes about mistakes of similar calibre being implemented in every language imaginable. Sean is apparently considering leaving the computer industry after having numerous bad experiences of having highly paid people mess up projects while he gets paid a lot less to try and fix the worst of the bugs and get the systems working in production. I understand what it’s like, I have occasionally idly contemplated leaving the industry after bad projects. However the fun of working on free software combined with the amounts of money that I can earn in the computer industry made me quickly abandon such ideas. His stories in some ways resemble my experiences in working as a contractor, most of my contracts have been profoundly weird for various reasons (I’ll use the WTF [2] category of this blog to document some of them). I had two theories as to why I ended up in so many strange contracts, one was that I was in some sort of Twilight Zone and the other was that taking contracts based on the amount of money offered puts you at high risk of being employed by people who have no financial pressure to do things in a sensible manner. My advice to anyone in such a situation is to try and find a contract position paying an unreasonable amount of money. Getting more than $80 an hour (the rate Sean cites as being paid to the idiots who cause problems) is going to be difficult, but getting $50 or $60 an hour is much easier to achieve and should be enough to alleviate the pain of working on doomed projects.

• [1] http://blogs.awesomeplay.com/elanthis/index.php/archives/2007/11/29/432/


• [2] http://etbe.coker.com.au/category/wtf/

Share This

Debian could use more manpower, but is it actually easy for new contributors who would like to help to do useful things, and get the impression that they actually improved Debian? There are several problems here:

• Find bugs that are not too hard to fix. I don’t know about your packages, but in mine, there are some bugs that are easy to fix, and it’s just a matter of finding the time. If someone provided a patch, I would be very happy and apply it or provide feedback as fast as possible.
• Find packages with active maintainers. It is no secret that if you choose the wrong package, your patch could very well sleep on the BTS for years.
• Find bugs that actually matter. It’s not strictly a requirement. But fixing bugs in packages that should probably be removed from Debian instead is not really rewarding.

I think that other projects are better than us at providing directions to newcomers. Gnome has the whole Gnome Love thing, for example. I’m thinking about building lists of “interesting” bugs. That would include RC bugs without patches, of course, but could also include a list of bugs based on an usertag that would mean “This bug is suitable for new contributors (it’s not too hard, and you could learn things fixing it). If you want to work on this bug, I’ll provide help and feedback and integrate your patch ASAP.” (This is very different from the “help” tag, which usually means “I couldn’t fix this, it’s too hard, I need help.“. It’s a bad idea to direct newcomers to bugs that are too hard for the package’s maintainer!) Additionally, a nice feature would be to be able to filter the list of bugs with the packages that the user has installed.

• What do you think?
• As someone willing to contribute to Debian, do you often find it hard to find stuff you could do?
• As a maintainer, do you have a lot of bugs that could use such a tag? Would you use it?

Comments are open, please us them ;)

Yes, Bastian, there is a way to do what you want. I believe I told you from the very start: refactor reportbug and implement reportbug-ng on top of the existing code. But no, you chose to reimplement everything (a typical thing to do for GUI programmers) and now you are asking us maintainers to change the way we've been doing things for years? You also make presumptuous statements about how we deal with bug reports. If you personally hate how certain packages prepare bug reports, then maybe you should personally suck it up and use different software? Seems like a more logical and less intrusive way forward, then expecting others to "send a friendly mail" to ask for more information on a bug report. Maybe you have all the time in the world, but I don't. I can work on e.g. mdadm (which uses an interactive bug script) only on rare occasions, and then I'd rather fix and close bugs than to indulge in another iteration of bug submitter ping-pong. You are also personally annoyed by long pre-subject texts, which you doubt anyone reads? I don't even bother to challenge that, but let me say that pre-subject texts are there to prevent stupid bug reports, or bug reports filed in the wrong place, and to take load off the maintainer. So you chose to ignore them? Given the projected user-base of your tool, I'd say you should rather force people to read them by asking them to transcribe the text. If you don't want to pop up a terminal, well, why the heck didn't you integrate debconf properly, while reusing reportbug, and taking a step forward to provide a proper interface for bug scripts? Why do you even bother to whine about interface issues at this point? Feel free to take over my packages, which make use of interactive bug scripts. I see zero reason to change them, and I will not. NP: The Flower Kings: Paradox Hotel

Christmas is billed as a family occasion and a huge amount of advertising money is spent convincing people that they need to have big expensive family events. This is good for the advertisers but not good for people who have no family to meet up with (orphans, people who live in different countries to their families, and people who don’t get along with their relatives). If any of your friends don’t have an event planned for Christmas day then it’s a good idea to invite them to your family party if possible. When I was younger there were two occasions when friends who didn’t have a possibility of attending a party with their own family attended a Christmas party with my family. Unfortunately I’m not in a position to make such an offer this year, but I encourage everyone who knows of someone with no plans to consider the possibility of inviting them to a party. Another possibility is that Linux people who have no option of a family party could arrange a Linux community Christmas party.

Share This

Sometimes it is extremely tempting to wave a huge, heavy, spiked cluebat around. Today I've decided to give in to this temptation. The case in point is the upload today by their maintainer of first cwidget and later aptitude. The fact that the maintainer blogged about both uploads probably means that he's pretty happy about it. Unfortunately I, and people in the Debian release team, were less than amused. Reason is that the uploads set back a complex transition of apt and related packages by at least a week. This is a transition we'd already been following and trying to get into testing for over a month and which was finally as good as ready to go. So what was so wrong about these uploads and what could (should?) the maintainer have done? First of all he should have realized that aptitude has become a rather central package in Debian with strong ties to apt and thus to a lot of other packages. Second, he should have checked whether his previous uploads had already migrated to testing and, if not, why not. The excellent testing migration page for aptitude (which is linked from its PTS page clearly shows that it is tied in a transition involving about a 100 packages in total. The right thing to do in such a case is to contact the release team (preferably at the debian-release mailing list, or at #debian-release). This would undoubtedly have resulted in a request to delay the uploads a few days until the transition had finished. Unfortunately that did not happen and cwidget was uploaded. Because of an ABI bump it ended up in NEW. Because of the transition I did a quick request to Joerg Jaspert to please delay accepting cwidget until the transition was over. But then a third mistake, and arguably the most serious one of the lot, was made. aptitude was uploaded for i386, built against the cwidget library which had not yet been accepted into unstable. Basically that means that an uninstallable package was uploaded. And of course it meant that at that point all efforts to finalize the transition for apt went down the drain. Some alternatives were discussed on how to deal with the new situation, including a sourcefull upload of the previous version of aptitude, but in the end it was decided to just accept the delay as one of the more annoying facts of life and instead ask Joerg to accept cwidget from NEW. In the end the damage may be a bit less than a week if the buildds cooperate (which they probably won't with cwidget still stuck at the wrong priority) and the RMs decide to force things. I sincerely hope that this story will make all Debian Developers and Debian Maintainers a bit more aware of the broader context and consequences of uploads. Oh, as I'm not an RM myself you may wonder what my interest is in this. We've got this great new feature in Debian Installer that adds support for multiple CDs during an installation (a feature that was lost with the integration of base-installer into D-I). However, we can only upload the relevant D-I component after apt 0.7.9 has reached testing...

There are cases where you don’t want to bring a laptop with you, but still want to have your data or, even better, your system and configuration. It is actually not so difficult to do if you are using LVM. With my setup, it was quite straightforward. So, if you happen to have a similar setup (2 partitions : one for /boot, and the other one for the LVM physical volume), here are the steps to do the same (assuming the usb disk is /dev/sda, the laptop disk /dev/hda, the LVM volume group vg, and you’re using grub as a bootloader).

• Create equivalent partitions on the usb disk. In my case, the usb disk happens to be much bigger, so the LVM physical volume is going to be more than half free).
• Create an LVM physical volume on the second partition:
  

  /sbin/pvcreate /dev/sda2

• Extend the existing volume group with the new physical volume:
  

  /sbin/vgextend vg /dev/sda2

• Move all data from the laptop disk to the usb disk:
  

  /sbin/pvmove -v /dev/hda2

• Now you have plenty of time during the pvmove, create a new filesystem for /boot in the first partition:
  

  /sbin/mkfs.ext3 /dev/sda1

• Copy the current /boot files to the new filesystem:
  

  mount /dev/sda1 /mnt
cp -a /boot/. /mnt
umount /mnt

• As you will want to mount the new /boot at boot time, edit /etc/fstab to replace the device for the /boot entry by the new device. Since you probably don’t know in advance what the device will be (you may use the disk on any computer, possibly with a SATA disk that will be on sda), it is preferred to use the UUID of the filesystem to mount it. Get it with:
  

  dumpe2fs -h /dev/sda1 grep UUID

  Then replace the device name (in my case /dev/hda1) with UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

At this point (well, you obviously still need to wait for the pvmove to end), you can reboot right now. Your boot loader setup will use your old /boot partition and the kernel will use the root filesystem on the usb disk.
Be aware of a few things, though.

• Your initrd image (which you must have, if you have your root partition under LVM) must include everything that is necessary to load usb devices before mounting the root partition
(mkinitramfs in Debian does)
• Current mkinitramfs in Debian has a quite annoying bug, that makes impossible to have an LVM root partition on an usb disk: most of the time, the usb disk is detected after initialization of LVM. If that happens to you, you’re not screwed: you can add break=mount to the kernel command line, and while you have a shell prompt, wait for the usb disk to come up and just exit the shell, it will continue the boot scripts and initialize LVM properly. On a recent enough initramfs, you can also specify rootdelay=10, replacing 10 with the number of seconds you want the boot to be delayed to wait for usb devices.

You still need to do two things to finish your setup, now:

• Remove the laptop disk physical volume from the volume group:
  

  vgreduce vg /dev/hda2

• Setup grub on the usb disk, so that you can boot off the disk directly if the BIOS supports it:
  

  /usr/sbin/grub
grub> root (hd1,0)
 Filesystem type is ext2fs, partition type 0x83
grub> setup --prefix=/grub (hd1)
 Checking if "/grub/stage1" exists... yes
 Checking if "/grub/stage2" exists... yes
 Checking if "/grub/e2fs_stage1_5" exists... yes
 Running "embed /grub/e2fs_stage1_5 (hd1)"... 15 sectors are embedded.
succeeded
 Running "install /grub/stage1 (hd1) (hd1)1+15 p (hd1,0)/grub/stage2 /grub/menu.lst"... succeeded
Done.
grub> quit


  You probably won’t have to change the menu.lst file, because it must already be using hd0, which will be what grub sees for the usb disk when booting off it. Also note your usb disk might not be hd1 under grub, depending on the number of disks on your system.

Now you can have any computer run your system, booting off the usb disk. It had the nice side effect that my laptop is much faster now, as the internal disk is an old 4200 rpm disk, vs. 7200 rpm for the usb disk…
You may also want to try to remove the Xorg configuration file (/etc/X11/xorg.conf) so that the video driver and resolution are not hardcoded ; recent enough Xorg do runtime detection, and that worked pretty well on the two laptops I booted with the usb disk.

I turned this movie off because it became clear in the first few minutes that it was a very low budget movie shot in a hurry[1] with actors who reminded me of ones from not particularly awesome plays[2]. Then for some reason I went back to it. And soon it got interesting. And then I got thuroughly sucked in. And then I was really sad that the storytelling was over. I think it's been a very long time since I was sad that a science fiction movie was over[3]. Maybe 1980? This movie is set all in one room in a cabin, and has no higher technology in it than a cell phone, and yet it's amoung the top two purest peices of science fiction I've seen performed. And the lack of special effects, especially CGI[4], was a very nice change. There's a good chance you'll not enjoy this movie, but I hope you get a chance to see it and find out. You won't find it in theaters, there's a DVD and it's on Netflix, or you can download it and paypal the director and cast a few bucks.

---

[1] In about a week as it turns out.
[2] Which is probably true of some of them. I only recognised one.
[3] Snip: silly-yet-true-analogy-between-typical-SF-movies-and-bags-of-potato-chips
[4] Snip: hating on most CGI

As Tolimar was asking about it and I am using the setup at some places to get past idiotic^Wbroken firewalls, where you always want to kill the clueless people that did set them up - lets write a bit how to ease ssh usage at such locations. Imagine a place where you can’t ssh elsewhere directly, you have to go through at least one, in some cases two or three hosts, to get anywhere sane.[1] So the topic is SSH jumphost. Thats basically what you do manually if you

  ssh some.host
  ssh next.host

where some.host is your jumphost. Add as many some.host as you want into this chain. We are all lazy and don’t want to type that by hand, one ssh is enough for everybody. Hurray, ssh already provides what we need, namely the ProxyCommand directive, it’s just not known as much as it should be. For this example imagine I have to ssh via the following host chain to get out: kosh -> vir -> babylon5 -> sheridan and also want to have my local port 2525 forwarded to sheridans port 25. The following config snippet (.ssh/config) is doing that[2]

 Host yay
 ProxyCommand ssh -q -A -X vir ssh -q -A -X babylon5 'nc -w1 sheridan 22'
 LocalForward 2525 localhost:25
   
 Host vir
 ProxyCommand ssh -q -A -X kosh 'nc -w1 %h %p'

The effect of this is:

• When I run ssh yay this will run
• ssh -q -A -X vir which in turn runs
• ssh -q -A -X kosh where it will start the nc command, replacing %h and %p, so it runs
• nc -w1 vir 22 which simply “pipes” all data to host vir, port 22, where it then runs
• ssh -q -A -X babylon5 to login to babylon5 where it finally uses
• nc -w1 sheridan 22 nc to let ssh connect to the target host

and I end up having a shell on host sheridan. The LocalForward line also tells ssh to tunnel my port forwarding over that multi-hop session, voila, done. Of course there is a little caveat with this - all hosts do have to know the next one (ie. .ssh/known_hosts should have the right data). You should also think about using ssh keys (maybe including Agent forwarding). You really dont want to see 5 Password: prompts right behind each other for a 5-hop setup - with no clue if its for the next host or for a typo… Update: If you are a Debian Developer and do not have a host “outside” that listens to something else than Port 22 but are behind a firewall that only allows Port 80 and 443 - you are lucky. As long as you aren’t hit by [1] you put the following into your .ssh/config file and have fun:

Host foo.gl bar.gl
ProxyCommand ssh -q -a -p 443 -x gluck.debian.org 'nc -w1 $(basename %h .gl) 22'

Add as many other config options as you want. The effect is:

• You run ssh foo.gl OR ssh bar.gl and it does
• ssh -q -a -p 443 -x gluck.debian.org where it then runs
• nc -w1 foo 22 (or bar instead of foo)

and as such you can get out via gluck. We are using the .gl as an extension here to remember that we go via gluck. Idea stolen from someone on IRC, just can’t remember who atm. [1] For added fun, which I have at one place, add things like a proxy with user authentication done in a way that tools like tor or openvpn can’t get through it and you always wish those admins use Windows, just so they suffer. Anyway, I talk about the first part only, using jumphost, other ways getting around crap admins needs, in my case, an own script to do it, not part of this topic… [2] Yes, one can do it in lots of ways and those here might not be the most optimized/nice/whatever ones. But they work and are just examples here, select your own parameters if you dont like mine!