The route cache is a Linux kernel component enabling route lookups to be faster by caching the results in some table and checking it before issuing a regular lookup in the route tables. When using Linux as a router, the inefficiency of the route cache can hinder the performances of your box. The documentation on this component is scarce and it is difficult to find up-to-date bits on how the route cache works and how to tune it. The book Understanding Linux Network Internals from O Reilly is an exception and contains valuable information on how the route cache works. Even if the book is targeted at 2.6.12, the part on the route cache is still quite accurate. Unfortunately, it fails to provide appropriate tips on how to monitor and tune the route cache. I hope to provide here a concise view of the route cache, as it is implemented in Linux 3.1. It is protocol-dependent¹ and I will cover only the IPv4 version here.

Overview of the route cache subsystem To handle an incoming or outgoing IP datagram, the kernel needs to issue a lookup in the route tables. While it seems to be quite trivial, several questions need to be answered:

• Does the source address and the destination address appear to be valid?
• Is the source address a martian address²?
• Is the destination address mine or should I forward the packet?
• Which route table should I use?
• Does the destination address match this route? And this one?
• Can I currently contact the gateway that I should use?

Those checks can be a bit time consuming, even for small route tables. To avoid them for each packets, Linux maintains a route cache which is queried before doing a regular lookup and updated after each one. You can dump it with ip -s route show cache:

$ ip -s route show cache
198.51.100.7 from 203.0.113.2 via 192.0.2.1 dev eth1
  cache used 7 age 2sec ipid 0x1fce rtt 131ms rttvar 45ms cwnd 10
198.51.100.17 from 203.0.113.15 via 192.0.2.1 dev eth1
  cache used 3 age 0sec ipid 0xc3bd
local 192.0.2.18 from 203.0.113.15 dev lo src 192.0.2.18
  cache <local> used 154 age 1sec iif eth0

Here are two examples:

• If Linux receives a packet from 198.51.100.17 to 203.0.113.15, it will find this flow in the route cache. Therefore, it already knows that it should forward the packet to 192.0.2.1. No checks needed.
• If it receives a packet from 198.51.100.16 to 203.0.113.15, there is no appropriate entry in the route cache and therefore, the system will have to look at the route tables. It is likely to use the exact same entry than if the source was 198.51.100.17 but maybe there is some policy routing requesting the use of a special route table or 198.51.100.16 is a local address and the packet will therefore be classified as martian.

The schema below shows how this cache is implemented³. It uses a separate hash table (BSD systems keep the cache in the routing table). Each bucket is a chained list of route cache entries. Once an entry has been added to the route cache, there are several ways to remove it. Most entries are removed by the garbage collector which will scan the route cache and remove invalid and older entries. It will be triggered when the route cache is full or at regular interval, once a certain threshold has been met.

Available knobs There are several values you can tune. Most of them are available in sysctl.

• rhash_entries is the size of the hash table⁴. If you don t specify it on the kernel command line, it is computed dynamically based on the memory available on your system. You can view its value by looking at something like IP route cache hash table entries: 262144 (order: 9, 2097152 bytes) in the kernel logs.
• net.ipv4.route.max_size is the maximum number of entries in the route cache. Except under exceptional circumstances, this value is never exceeded.
• net.ipv4.route.gc_elasticity is the target average length of a chain in the route cache. The garbage collector will work harder if this value is exceeded. This means that if you multiply this value by the value of rhash_entries, you will get the target average number of entries in the route cache.
• net.ipv4.route.gc_min_interval_ms is the minimum delay between two runs of the garbage collector, except when the cache is full. The default value should be fine.
• net.ipv4.route.gc_thresh is a threshold triggering the garbage collector every net.ipv4.route.gc_min_interval_ms milliseconds.
• net.ipv4.route.gc_timeout is the base value to determine if an entry is old enough to be removed or not. Whatever its value, the garbage collector will attempt to remove the same number of entries. However, this value could potentially influence its efficiency. See below for more details on this.

You may find documentation about those obsolete sysctl values:

• net.ipv4.route.secret_interval has been removed in Linux 2.6.35; it was used to trigger an asynchronous flush at fixed interval to avoid to fill the cache.
• net.ipv4.route.gc_interval has been removed in Linux 2.6.38. It is still present until Linux 3.2 but has no effect. It was used to trigger an asynchronous cleanup of the route cache (but in a different way of what the garbage collector does). The garbage collector is now considered efficient enough for the job.

Statistics & monitoring Linux maintains some statistics about the use of the route cache. You can find them in /proc/net/stat/rt_cache. The command lnstat can print them nicely for you:

$ lnstat -s1 -i1 -c-1 -f rt_cache
rt_cache rt_cache rt_cache rt_cache rt_cache rt_cache rt_cache rt_cache rt_cache rt_cache rt_cache rt_cache rt_cache rt_cache rt_cache rt_cache rt_cache 
 entries   in_hit in_slow_ in_slow_ in_no_ro   in_brd in_marti in_marti  out_hit out_slow out_slow gc_total gc_ignor gc_goal_ gc_dst_o in_hlist out_hlis 
                       tot       mc      ute            an_dst   an_src              _tot      _mc                ed     miss  verflow  _search t_search 
 3096848    42309      686        0        0        0        0        0        3        0        0      674      672        0        0    27644        8 
 3096984    41405      636        0        0        0        0        0        3        0        0      623      621        0        0    28189        8 
 3097160    42483      700        0        0        0        0        0        5        0        0      694      692        0        0    29506       12 

Except for the first column, lnstat outputs values in units per second. Let s review some of those values:

• rt_cache_entries is the number of entries in the route cache. You should compare it with net.ipv4.route.max_size and ensure that the cache is never full to avoid triggering the garbage collector too often.
• rt_cache_in_hit and rt_cache_out_hit are the number of regular lookups avoided because the result was found in the cache for incoming and outgoing packets, respectively. When the system is a router, most lookups only happen on the incoming side. You should compare this value with rt_cache_in_slow_tot and rt_cache_in_out_slow_tot which are the number of lookups in the route tables. On this system, the efficiency of the route cache is more than 98% which is quite good.
• rt_cache_gc_total is how often the garbage collector was requested to be triggered while rt_cache_gc_ignored corresponds to how often it was finally not run because it has already been triggered shortly beforehand (less than net.ipv4.route.gc_min_interval_ms milliseconds). The difference between those two values should be very small to ensure that the garbage collector does not run more a handful of times per second.
• rt_cache_gc_goal_miss is how often the garbage collector was not able to fulfill its goal. This value should rarely be different of 0.
• rt_cache_gc_dst_overflow is how often the route cache is bigger than the allowed maximum size. This should never happen except when you try to shrink the cache.
• rt_cache_in_hlist_search and rt_cache_out_hlist_search is how often a lookup in the cache had to look at the next entry in the chain for the computed bucket: each time Linux has to follow the next pointer in a cache entry, it increments one of those counters. It is a clue on the average length of chains in the route cache hash table. Compare those values with the number of cache lookups (hit and miss).

As an illustration, here is a plot of the various statistics exposed above for a router whose route cache receives about 1000 routes par second: rhash_entries is 1,048,576, as is net.ipv4.route.gc_thresh. Therefore, the garbage collector was requested to be run when the number of entries goes above this level. Because the cache is not full, it is only really run twice per seconds (the value of net.ipv4.gc_interval_ms is 500). net.ipv4.gc_elasticity is set to 3. This explains why the garbage collector is aggressive when the number of entries reached 3,145,728. As you can see, the efficiency is near 100% all the time. The percentage of collisions is rt_cache_in_hlist_search ratio to the sum of rt_cache_in_hit and rt_cache_in_slow_tot.

Tuning Do you need to modify any of those values? You have two questions to ask yourself:

1. How much efficiency do you want to get from the route cache?
2. How much memory do you want to dedicate to the route cache?

As a rule of thumb, two millions entries eat about 500 MB of memory on a 64bit system. You should be able to compute the average memory usage and the maximum memory usage from the values of net.ipv4.route.max_size, rhash_entries and net.ipv4.route.gc_elasticity. For example, if the route cache hash table has 262,144 buckets, the maximum allowed number of entries in the cache is 4,194,304 and net.ipv4.route.gc_elasticity is set to 8, the memory usage will be 500 MB on average and 1 GB max. If this is too much, you will need to lower some values. Look at the previous section to compute the current efficiency of your route cache. It should be above 90%. If you are dissatisfied with that, you could increase the cache size. If you want to double the number of entries, double net.ipv4.route.max_size, net.ipv4.route.gc_thresh and rhash_entries but keep net.ipv4.route.gc_elasticity to 8. For the garbage collector to be efficient, the route cache should not be filled too fast. The garbage collector should be able to cope with this situation but this may impact performance because it needs to walk several times the route cache to find entries to expire. Watching gc_goal_miss may give you a hint about this: if this value starts to be different of 0, lower net.ipv4.gc_timeout.

In-depth look into the garbage collector Those different pieces of advice may have puzzled you. We need to understand how the garbage collector works to better cope with them. The garbage collector is triggered when a new entry needs to be added to the cache and the number of entries is superior to net.ipv4.route.gc_thresh. It is implemented in rt_garbage_collect() function. It will do nothing if it has been called less than net.ipv4.route.gc_interval_ms milliseconds and the cache is not full (more than net.ipv4.route.max_size entries).

Setting a goal The garbage collector will first assess the situation. It will look how the number of entries currently in the cache compares to the product of rhash_entries and net.ipv4.gc_elasticity:

1. Above this limit, it will try to remove at least rhash_entries entries.
2. Otherwise, it will try to remove no more than half the difference.

If you look at the previous plot, you can easily see the difference when the garbage collector is not aggressive (above 1,048,576 entries but below 3,145,728) and when it is (above 3,145,728 entries). If we assume the garbage collector is able to meet its goal, we can easily simulate its algorithm: The first plot shows what would happen if about 2000 routes are added per second with rhash_entries equal to 262,144 and net.ipv4.route.gc_elasticity set to 8. When net.ipv4.route.gc_threshold is met, the garbage collector has almost no effect. However, when the number of entries reaches 2,097,152, the garbage collector sets its goal to 262,144. From this point, the number of entries oscillates around 2 millions entries. On the second plot, rhash_entries is now equal to 1,048,576 but net.ipv4.route.gc_elasticity has been set to 2. Therefore, the aggressive part of the garbage collectors kicks at the same threshold than for the previous plot. However, its goal is now four times larger and the oscillations have a larger amplitude. The fact that the aggressive part of the garbage collector kicks less often is nullified by the fact that it needs to remove more entries each time. Because of the slight impact on cache efficiency, it seems better to keep net.ipv4.route.gc_elasticity around 8, or 4 if we want to keep shorter chains (but there seems to be no improvement to do so). The other plots show what happens when there is a sudden surge in the number of routes added or when there is a pause.

Meeting the goal Now that we understand how rhash_entries, net.ipv4.route.gc_elasticity and net.ipv4.route.gc_threshold interact, let s look at net.ipv4.route.gc_timeout. Once the garbage collector has set its goal and if it is positive, it needs to choose which entries to remove from the cache. It walks the hash table from the position of its last run and remove entries until its goal is met. If the entry is not current anymore (for example, the network interface associated to it has changed its IP configuration), it is removed. Otherwise, the system looks at the age of the entry and its position in the chain. If the entry is the first in the chain, it is kept only if its age is below net.ipv4.route.gc_timeout. If it is second, it is kept only if its age is below half of net.ipv4.route.gc_timeout. If it is third, the threshold is a quarter of net.ipv4.route.gc_timeout, and so on. The garbage collector will favor short chains. If after a full run of the hash table, the garbage collector was not able to meet its goal, it will start again but will behave more aggressively, as if net.ipv4.route.gc_timeout is set to half of its value. It will do as many passes as necessary until its goal is met or until there is no way to remove any entry (or until it has spent too much time). Once the garbage collector has switched to this more aggressive behavior, it will keep being aggressive for a few cycles (a bit less for each cycle). With a very large value of net.ipv4.route.gc_timeout, the garbage collector will have a hard time to find entries to expire. It will need to do several passes until it is able to expire some entries. On the other hand, if you choose a very small value, the garbage collector may remove entries that were just added, even if there are older entries further in the hash table. For a more in-depth coverage of how the route cache works, look at chapter 33 of Understanding Linux Network Internals. Just be aware that multipath route caching has been removed (and was never really used) and asynchronous cleanup (rt_periodic_timer) does not exist anymore.

Conclusion When tuning the route cache, rhash_entries, net.ipv4.route.gc_elasticity, net.ipv4.route.max_size and net.ipv4.route.gc_threshold are related and should not be modified independently. net.ipv4.route.gc_thresh should be below the product of net.ipv4.route.gc_elasticity and rhash_entries while net.ipv4.route.max_size should be above this value. Linux exposes several interesting metrics related to the route cache. Monitoring them allows one to watch the efficiency of the route cache and may uncover some anomalies (garbage collector running too often, difficulty to remove routes from the cache, ). The route cache subsystem still evolves and some old behaviors have been dismissed. The best documentation is, unfortunately, still the code and other documentations tend to become obsolete. The IPv6 route cache is quite different of the one presented here. Don t blindly apply the same tuning for IPv6.

---

1. Linux provides a protocol-independent destination cache subsystem (DST). This component is not a generic cache layer and only enables loose coupling with external subsystems.
2. Martian addresses are addresses that cannot be used as a source address, either because they are reserved for special-use (like a multicast address) or because of the use of reverse path filtering which checks if a packet received on one interface would be answered on the same interface, as defined in RFC 3704. This feature is enabled by setting rp_filter in Linux.
3. For more details, you may want to look at include/net/dst.h, include/net/route.h and net/ipv4/route.c.
4. In fact, the size of the hash table is always a power of two. If specified, rhash_entries is rounded to the next power of two and, internally, is stored as rt_hash_mask + 1.

I must confess, I thought only DD s can be on the Debian Planet and a few days ago I read someone telling me that I must add my blog to the planet, so I went to the Planet wikipage and I saw that Planet Debian is for any active and directly involved participant in the Debian development community. This is my first post on the Debian Planet. I m member of the DC12 Local Team and I ll try to post here updated information about DebConf12 organization, my experience in the Debian Community (I m starting to collaborate with Spanish translations for the Debian Plubicity Team), and other Debian-related things as well. Our next DebConf meeting is TBD on doodle, if you are interested to participate in the meeting, please go to doodle and select the dates you are available so we can decide when is going to be the next meeting. Hope to see you next year in Managua!

(It s a new day, it s a new bug ) A regression appeared in the synaptics input driver, between the 1.4.1 and the 1.5.0 release, as reported in Debian #649002 by many users. Basically, no more touchpad on PowerPC (hi, iBook G4 users!). :-( What follows is how I tracked it down. The upstream bug report is fdo#43728. Anyone could have done so, there s no black magic involved. A little hint maybe: git bisect is really easy on X drivers, since one can build and test without the Debian packaging bits. 1st step: Getting started You need sources and build dependencies, nothing fancy. Since packages might be named a bit differently, there s a reference to the relevant upstream repositories in debian/watch for X packages.

# You need git here:
debcheckout xserver-xorg-input-synaptics synaptics.git
cd synaptics.git
# Let s get the upstream tags and branches:
cat debian/watch
git remote add upstream git://anongit.freedesktop.org/xorg/driver/xf86-input-synaptics
git fetch --all
# Let s install build dependencies:
sudo apt-get build-dep xserver-xorg-input-synaptics

2nd step: Reproducing It was said 1.5.0 was the first known buggy version, so let s make sure:

# Get the appropriate tag:
git checkout xf86-input-synaptics-1.5.0
# Prepare the build system:
autoreconf -vfi
# X finds its modules under /usr, not /usr/local:
./configure --prefix=/usr
# Build and install:
make && sudo make install

Now time to restart the display manager, and confirm that the pointer is not moving bug reproduced. Now let s check the 1.4.1 release isn t affected:

# Clean everything:
git clean -xdf
git checkout xf86-input-synaptics-1.4.1
autoreconf -vfi
./configure --prefix=/usr
make && sudo make install

And after a display manager restart, the pointer is moving again, good! For reference, the log has very different lines about appletouch, so it can be used to programmatically learn about the status (good or bad). 3rd step: Narrowing it down So, we have a known good version and a known bad version. Time for a binary search to find the guilty commit which introduced that regression!

git bisect start
git bisect good xf86-input-synaptics-1.4.1
git bisect bad  xf86-input-synaptics-1.5.0

You don t even need to know that 1.4.x and 1.5.x live in different branches, git figures that out for you:

Bisecting: a merge base must be tested
[de0dfb76444ad4160468d00515876c91a9fa20bf] synaptics 1.4.0

It s just a matter of running autoreconf && ./configure && make && sudo make install && sudo /etc/init.d/xdm restart every step of the way, so it s pretty easy. No wonder, 1.4.0 was working OK, so it can be recorded as such through git bisect good, and the binary search goes between that commit and 1.5.0. After a few iterations of git bisect good and git bisect bad, we get to the commit reported on the upstream bug. As an extra bonus, mentioning the upstream bug number/URL in the Debian bug means it can be marked as forwarded there and we ll receive automatic notifications when its status changes, thanks to bts-link. Now, if you want to provide a patch for this bug, you may want to try and revert this commit. 4th step: Providing a patch Let s go back to the affected release and try to revert the guilty commit:

git checkout xf86-input-synaptics-1.5.0
git revert 13543b156d78bc4d01a19844a5ee8f283269621b

Unfortunately, some later commits modified the affected areas so we re running into conflicts:

error: could not revert 13543b1... eventcomm: replace synaptics-custom TEST_BIT with server's BitIsOn.
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'

Let s try to understand what the offending commit did: it replaced a set of macros with a single one, taken from the server. Both the old TEST_BIT() and the new BitIsOn() take 2 arguments, but the order is reversed. Reverting it should only be a matter of introducing the TEST_BIT() macro again (along with the two other ones it needs), and using it. The problem is replacing all BitIsOn(foo,bar) with TEST_BIT(bar,foo): foo and bar might not be trivial, they could be complex C expressions, and a replacement in your favourite editor might not get all occurrences right. Thankfully, there s a nice tool to handle such things, called coccinelle. I won t go into details, just show how it can help here. Basically you just need to craft a tiny patch, called a semantic patch, which describes what I wrote in the previous paragraph. You only need to declare two expressions, say a and b, and declare that all BitIsOn(a,b) must be replaced with TEST_BIT(b,a). Here s the syntax:

@@
expression a,b;
@@
-BitIsOn(a,b)
+TEST_BIT(b,a)

Save it under testbit.cocci and apply it through spatch (from the coccinelle package), asking it to perform in-place replacement (we re in a git checkout copy, remember):

# Apply:
spatch -sp_file testbit.cocci -in_place .
# Profit:
git diff

Then you can run git commit -s, write a nice commit message, send it upstream, and enjoy the rest of the night. Coming soon to a mirror near you: fixing commit. As mentioned on the upstream bug report, I got the Debian reference wrong in the commit message, I really meant #649002.

Mako's IronBlogger is a great idea. I often find myself postponing blog posts for a very long time, simply out of laziness. IronBlogger provides a nice community incentive to counter (my) laziness and blogging more often. As a related challenge, we have to face the fact that different subsets of our communities use different media to stay informed: mailing lists, blog (aggregators), social media, IRC, etc. Disparities in how they stay informed are a pity and can be countered using multiple medias at a time. Although I haven't blogged very often as of lately, I managed to keep the Debian (Developer) community informed of what happens in "DPL land" on a monthly basis, by the means of bits from the DPL mails sent to d-d-a. While the target of bits mails perfectly fits d-d-a, there is no reason to exclude a broader public from them. After all, who knows, maybe we'll find the next DPL victim^W candidate among Planet readers! Bonus point: blogging this also helped me realize that my mails are not as markdown-clean as I thought they were. I still have no IronBlogger squad, though. (And sharing beers with folks in the Boston area is not terribly handy for me ). Anyone interested in setting up a BloggeurDeFer in the Paris area? (SCNR)

---

Dear Project Members,
another month has passed, it's time to bother you again about what has happened in DPL land in November (this time, with even less delay than the last one, ah!). Call for Help: press/publicity team I'd like to highlight the call for help by the press / publicity teams. They are "hiring" and have sent out a call for new members a couple of weeks ago. The work they do is amazing and is very important for Debian, as important as maintaining packages or fixing RC bugs during a freeze. It is only by letting the world know what Debian is and what we do, that we can keep the Project thriving. And letting the world know is exactly what the publicity and press teams do. If you're into writing, blogging, or simply have a crush for social media, please read the call and "apply"! Interviews November has apparently been the "let's interview the DPL" month. I've spent quite some time giving interviews to interested journalists about various topics. For both my embarrassment and transparency on what I've said on behalf of Debian, here are the relevant links:

• audio interviewwith Karen Sandler for the Free as in Freedom oggcast by herself and Bradley M. Kuhn
• text interview with Raphael Hertzog for the People behind Debian series
• text interview for the Linux Certification Institute Italy (LICI) (note: the original of this one is in Italian; the English version is a translation by LICI)
• video interview with Amber Granger during last UDS

Assets

• the Video Team sprint approved in October has happened at beginning of November; report is still pending but the organizers are on it
• Christian Perrier reported about his trip to India mini-DebConf, even that he attended on behalf of the Project. I find amazing both the outcome of the event and Christian's report, a very good example of how to inform the Project when acting on behalf of it
• the hardware replacement for ftp,lists .d.o I've mentioned last month has been ordered, has arrived, and DSA have already put their hands on it for the setup. Many thanks to DSA and in particular to Martin Zobel-Helas for the logistics
• as an administratrivia, I've asked SPI to setup for Debian a "gift" credit card, i.e. a credit card with a limited, refillable budget. It is needed for using (with a safeguard) credits offered to the Project by public cloud providers (e.g. AWS' donation), as well as to use various kinds of services that we need from time to time

Legal advice (work in progress)

• I've sought and got from a former SPI lawyer a first legal advice on the relationships among trademark law and the procedures of a Free Software distro like Debian when distributing software subject to trademarks. I'm still waiting to seek a second advice from the current SPI lawyers (whom I've been keeping busy with other stuff). In the meantime I've pending a summary of what I've got thus far in the trademark-vs-DFSG thread. Stay tuned there!
• I've been working with SPI lawyers on a proposal of software patent policy that I think we should advertise to make explicit the position of the Debian Project on software patents. I see it as a continuation/completion of the FAQ we have already published on the subject. I'll let you know as soon as we reach a stable draft, that should be pretty soon.

Relationships with others

• I've been approached by members of the board of the OpenSource Initiative (OSI), about the soon to be open OSI affiliation program. They'd like to know if Debian is interested in being affiliated to OSI. I think we should and I'll eventually start a discussion on this topic. In the meantime, I welcome feedback from anyone who is interested in the topic.
• Thanks to the interest of Andrew Pollock, LaMont Jones, Florian Weimer and the Security Team, we are discussing with ISC to have Debian --- as a project, rather than as individuals who just happen to maintain ISC software in Debian --- become member of all forums relevant for software we distribute (BIND, NTP, DHCP). They are doing all the coordination work, but I've anticipated I'll be happy to pledge for Debian membership.
• I've taken the first step to reach out to companies that have a strategic interest in Debian. According to discussion I've had with representative of such companies, they often face similar challenges in offering Debian support and in contributing back to Debian. I think we should offer a forum for them to discuss and find synergies, as well as explain our needs to them. An official mailing list might be such a place. Once we have a suitable forum ready, I'll propose to the press team to send out a corresponding call for companies. In the meantime, if you happen to know, or even work for, companies that might be interested, please ask them to get in touch with me.

Miscellanea

• I've had a chance to discuss with the editors of the SPDX specification about its relationship with DEP-5. Thanks to the help of Dominique Dumont work is already in progress to have a mutual converter among the two formats. Also, although with some bumps, work on finalizing DEP-5 has finally restarted.
• an interesting thread of a while ago is in need of some work to produce a useful outcome, i.e. a set of security guidelines for DDs. If you're willing to help, have a look at the thread
• some more mediation-fu has been going on during November; have a look at my daily logs below if you care about the details

Thanks for reading thus far,
and happy hacking.

---

PS as usual, the boring day-to-day activity log is available at master:/srv/leader/news/bits-from-the-DPL.*

And what the heck bumped into that? :)

Via Flickr:
Tomares, Seville

A while ago I decided to migrate my existing blogspot blog to an own domain and webspace again. My reasoning was mostly, that blogspot lacked some features, which I'd like to have in my blog.
Additionally, my requirements have changed a bit since I originally moved to blogspot and, last but not least, Blogspot was a compromise anyway.

I left you 2.5 months ago with the last question asked by my applicaiton manager, Martin Michlmayr : "Please tell me about about yourself and what you intend to do for Debian". Interesting question to revisit now, indeed. Here is what I answered: About myself first. I'm a 40 year old project manager and system administrator working in French National Aerospace Research Center. My best definition of my skills in computing is "Know more or less about a Lot of Things and be a Specialist of Nothing"...:-). I'm definitely not a programmer, nor a real system administrator, nor a RDBMS administrator, nor a personal workstation designer, though I do all of these daily. I think I'm perfect for finding the good person for having a defined job done. Besides this, I'm a genealogist for several years now. This is what finally decided me to apply for becoming a package maintainer : there are some quite good free genealogy software for Unix, though for various reasons they are not used very widely, even Unix geeks (my main software for genealogy still runs on Another Operatin System and is evertythig but free).I think that I can bring something here to the Free Software World, by helping some of these good programs in getting into the best Linux distribution I know.... For me, this is a mean for giving back to the free software movement what I gives to me since I discovered Linux 6-7 years ago. My very first intention as soon as I get my way into the Debian Developers Heaven is adopting the Geneweb package currently maintained by Brent Flugham. I'm in close contact with the author (who happens to be french, which helps) as well as a daily user of it. The current package which is in the distribution is already my work for a great part. I gave it to Brent, the current maintainer and we both agreed that it would be better for me to apply to becoming anofficial maintainer. I also contributed to the package for lifelines, another genealogy software. The last version of the package is also 80% my work, acknowledged by Javier, the official maintainer. Concerning that package, I do not have "plans" for adopting it (we didn't discussed of this with Javier, and I'm not sure I could bring him that much things). I came to Linux thanks to a great friend of mine, Ren Cougnenc. Ren opened my eyes to the free software world when I still thought that it was only a variant of free beers. I got really involved into Linux when I forced me to remove any other Operating System from my computer at work and tried to do my daily job with Linux. I have now succeeded at ONERA in getting free software to be accepted as a credible alternative for important projects. At this time, especially for server and network-related projects. I absolutely cannot tell why and how I came to be a Debian user. I simply don't remember. But I know why I am still a Debian user : this is a distribution which is controlled by only one organisation--->its users. And I want to be part of it. Finally, I did not mention above the somewhat "political" nature of my personal involvment into free software. Except for the physical appearence, I think I mimic RMS on several points (though he probably speaks better french than I try to speak english....which does not help for expressing complex ideas like the ones above!). As anyone can see, I was already very verbose when writing, sorry for this. Funnily Martin summed this up in one paragraph when he posted his AM report about my application. From what I see, also, my English didn't improve that much since then. It seems this is a desperatecause, I'm afraid. Anyway, all this was apparently OK for Martin and, on July 21st 2001, he wrote and posted his AM report and, on July 30th 2001, I got a mail by James Troup: An account has been created for you on developer-accessible machines with username 'bubulle'. bubulle@debian.org was born. Now I can more easily destro^W contribute to my favourite Linux distro. Indeed, I don't remember that much about the 2001-2003 years. I was probably not that active in Debian. Mostly, I was maintaining geneweb, for which I polished the package to have it reach a quite decent state, with elaborated debconf configuration. Indeed, at that time, I was still also deeply involved in genealogy research and still contributing to several mutual help groups for this. This is about the time where I did setup my web site (including pages to keep the link with our US family, which we visited in 2002). I think that the major turn in my Debian activities happened around september 2002 when Denis Barbier contacted me to add support in geneweb for a new feature he introduced in Debian : po-debconf. At that time, I knew nearly nothing about localization and internationalization. Denis was definitely one of the "leaders" in this effort in Debian. During these years, he did a tremendous job setting up tools and infrastructure to make the translation work easier. One of his achievements was "po-debconf", this set of tools and scripts that allows translation debconf "templates", the questions asked to users when configuring packages. All this lead me to discover an entire new world : the world of translating software. As often when I discover something I like, I jumped into it very deeply. Indeed, in early January 2003, I did my very first contributions to debian-l10n-french and began working on systematic translation of debconf templates. Guess what was the goal : 100%, of course! Have ALL packages that have debconf templates...translated to French. We reached that goal.....on June 2nd 2008 in unstable (indeed "virtually" : all packages were either 100% translated...or had a bug report with a complete translation) and on December 21st 2010 for testing. Squeeze was indeed the first Debian release with full 100% for French. Something to learn with localization work: it's never finished and you have to be patient. So, back in 2003, we were starting this effort. Indeed, debian-l10n-french was, at that time, an incredibly busy list and the translation rate was very high: I still remember spending my summer holidays translating 2-3 packages debconf templates every day for two weeks. Meanwhile, my packaging activities were low: only geneweb and lifelines, that was all. Something suddenly changed this and it has been the other "big turn" in my Debian life. After summer 2003, I suddenly started coming on some strange packages that were needing translation: they were popping up daily in lists with funny names like "languagechooser", "countrychooser", "choose-mirror", etc. I knew nothing about them and started "translating" their strings too, and sending bug reports after a decent review on debian-l10n-french. Then, Denis Barbier mailed me and explained me that these things were belonging to a new shiny project named Debian Installer and meant to replace the good old boot-floppies. Denis explained me that it would maybe be more efficient to work directly in the "D-I" team and "commit" my work instead of sending bug reports. Commit? What's that? You mean this wizard tool that only Real Power Developers use, named "CVS"? But this is an incredibly complicated tool, Denis. Do you really want me, the nerd DD, to play with it? Oh, and in this D-I development, I see people who are close to be semi-gods. Names I read in mailing lists and always impress me with their Knowledge and Cleverness: Martin Michlmayr (my AM, doh), Tollef Fog Heen, Petter Reinholdtsen and so many others and, doh, this impressive person named "Joey Hess" who seems to be so clever and knowledgeable, and able to write things I have no clue about. Joey Hess, really? But this guy has been in Debian forever. Me, really? Work with the Elite of Debian? Doh, doh, doh. Anyway, in about two months time, I switched from the clueless guy status to the status of "the guy who nags people about l10n in D-I", along with another fellow named Denny "seppy" Stampfer". And then we started helping Joey to release well localized D-I alphas and betas at the end of 2003 (the release rate at the time was incredible: Sarge installer beta1 in November 2003, beta2 in January 2004). I really remember spending my 2003 Christmas holidays hunting for....100% completion of languages we were supporting, and helping new translators to work on D-I translation. Yes, 8 years ago, I was already doing all this..:-)...painting the world in red. All this leads up to the year 2004. Certainly the most important year in my Debian life because it has been....the year of my first DebConf. But you'll learn about this....in another post (hopefully not in 2.5 months).

There is an interesting interview with Richard Wilkinson on ted.com about the damage to society that is caused by excessive inequality [1]. The conclusion is interesting, it seems that one part of the solution is to send the message that excessive greed is anti-social. The demonstrations against the greedy 1% seem likely to do some good in this regard. He also has a TED talk about this in which he shows that even the rich don t benefit from great inequality [2]. If nothing else the links between great inequality and high rates of mental illness and murder should convince people that they don t want to live in such a society. Buying Cameras Some of the radio news reports have claimed that some of the people in OWS camps in Australia are somehow unworthy because they have smart-phones and digital cameras. They seem to believe that people have to demonstrate great poverty to have standing to complain. The problem here is that owning a mobile phone is essential to getting employment in many industries, so the vast majority of people who are old enough to work but not near retirement age just have to own a mobile phone. Once you have decided to use a phone if you are going to use it a lot (which you probably will if living in a tent in a public place) then being on a contract usually makes economic sense. As the cheapest contracts include a free Android phone that means almost everyone who is old enough to be allowed out alone at night and young enough to be willing to sleep rough for a cause will have such a phone. A related complaint is about people owning good cameras. One reason for this is the fact that the huge number of cameras deters the police from using excessive force that s a good justification for spending money on a good camera. But then a good camera doesn t cost much nowadays, the specs on $100 cameras are quite impressive and a camera that costs $400 new will have features that are useful for professional photographers and cameras are even cheaper on ebay. In Australia social security payments for a single person who is out of work are as much as $486.80 per fortnight [3]. Therefore someone who is living on social security could buy a great camera if they saved up two weeks of social security payments or buy a similar camera on ebay for one week s worth of payments. When at a protest the widespread use of cameras is essential for protection against police brutality. It s worth saving up for a camera. But really they are missing the point, OWS is about representing ~99% of the population. Even people on the average income are suffering because of the greed of the rich. Is Australia such a Great Place? There have been claims that Australia is such a great place that OWS protests are not needed, supposedly we have a very egalitarian society. The ABS data shows that the level of inequality as expressed by numbers isn t that great when restricted to just income if you restrict the analysis to the top 20% [4]. The mean gross household income per week is $340 for the lowest quintile and $2,380 for the highest quintile giving a ratio of 1:7.0. But when you look at total household net worth it s $27,400 vs $1,720,700 a ratio of 1:62.8! The ratio for the richest 1% would surely be a lot greater but a quick search of abs.gov.au didn t turn up any statistics on them. Also Richard Wilkinson s analysis puts Australia quite close to the US. If the people who are in the top 1% earned their money, paid taxes, and didn t pervert the political process then there wouldn t be any OWS protests. The corruption in the political process and rent seeking by corporations isn t as bad here as it is in the US, but it s bad enough that we need some serious changes. Emily Manuel wrote an interesting article for Tiger Beatdown about the need for an Occupy movement in Australia [5]. Her description of the political problems in Australia is quite clear. But I wasn t convinced by her analysis which suggested that Australia is different from the US in any significant way. Really Comparing Income To properly compare income it doesn t make sense to compare a ratio of money earned, or disposable income which is often misleading due to disagreements about what is considered disposable. It s really about which of the things that you want to do can be achieved on your income. One possible way of comparing it is based on Maslow s hierarchy of human needs. The poorest 20% of households in Australia have a gross income of $340 per week. The ABS shows that the average of private rental prices in the 8 capital cities (where most of the population lives) is $218 per week [6]. Obviously the poorest households can t afford an average rent unless you have lots of people packed in one house. No matter how you look at the numbers it s going to be difficult for low income people to pay for rent and food. That puts them on the bottom level of Maslow s higherarchy. It seems to me that the benefits of increased income diminish and it becomes more of a contest to be richer than other people. Owning an old car is a significant benefit over having no car. Owning a new car has some real benefits over an old car. Luxury cars usually have safety features before they are introduced to cheaper cars, but apart from that the benefit of owning a luxury car is small. Owning multiple Rolls-Royces doesn t seem to provide any real benefit, someone who would want to do that would probably be better served by hiring a good psychologist. Update: In a comment Brendan Scott cited The Theory of the Leisure Class by Thorstein Veblen. That s a great point, and I ll have to read that book! I still maintain that owning two Rolls Royces is a symptom of psychological problems, people who can sort out such problems won t feel the need to try and prove that they have more money than others. Charles Stross has an interesting article about wealth disparity etc [7]. Being a sci-fi author he also explores what life might be like after Drexler boxes satisfy most of our current materiel needs. The Age has an informative article by Suzy Freeman-Greene contrasting the OWS protests in Melbourne which were broken up by police to the Catholic anti-abortion protests that have been going on for more than 20 years [8]. It seems that corporations aren t the only large organisations that are pwning democracy!

• [1] http://blog.ted.com/2011/10/26/we-quite-suddenly-realized-that-what-we-were-looking-at-was-a-general-pattern-qa-with-richard-wilkinson/
• [2] http://www.ted.com/talks/richard_wilkinson.html
• [3] http://www.centrelink.gov.au/internet/internet.nsf/payments/newstart_rates.htm
• [4] http://www.abs.gov.au/ausstats/abs@.nsf/0/4EABC33B47FEE100CA25773700169C75?opendocument
• [5] http://tigerbeatdown.com/2011/10/25/why-do-we-need-an-occupy-australia/
• [6] http://www.abs.gov.au/AUSSTATS/abs@.nsf/Lookup/1301.0Chapter10052009-10
• [7] http://www.antipope.org/charlie/blog-static/2011/10/a-cultural-experiment.html
• [8] http://www.theage.com.au/opinion/society-and-culture/some-occupy-to-protest-others-to-hamper-harangue-and-hurt-20111111-1nbn4.html

Long time has passed since last entry in this blog. Moderation panel is full of spam comments. It s still unclear if I will ever will continue it. However, given what is happening in my country these days, I *must* write at least one entry, just to put a number there. 632305222316434 Everyone who disagrees with criminal behaviour of Russian president, government and all those rascals, must do that.

It s been a couple days since I returned from this year s WebKitGTK+ hackfest in A Coru a, Spain. The weather was very nice, not too cold and not too rainy, we had great food, great drinks and I got to meet new people, and hang out with old friends, which is always great! I think this was a very productive hackfest, and as usual a very well organized one! Thanks to the GNOME Foundation for the travel sponsorship, to our friends at Igalia for doing an awesome job at making it happen, and to Collabora for sponsoring it and granting me the time to go there! We got a lot done, and although, as usual, our goals list had many items not crossed, we did cross a few very important ones. I took part in discussions about the new WebKit2 APIs, got to know the new design for GNOME s Web application, which looks great, discussed about Accelerated Compositing along with Joone, Alex, Nayan and Martin Robinson, hacked libsoup a bit to port the multipart/x-mixed-replace patch I wrote to the awesome gio-based infrastructure Dan Winship is building, and some random misc. The biggest chunk of time, though, ended up being devoted to a very uninteresting (to outsiders, at least), but very important task: making it possible to more easily reproduce our test results. TL;DR? We made our bots and development builds use jhbuild to automatically install dependencies; if you re using tarballs, don t worry, your usual autogen/configure/make/make install have not been touched. Now to the more verbose version! The need For a couple years now we have supported an increasingly complex and very demanding automated testing infrastructure. We have three buildbot slaves, one provided by Collabora (which I maintain), and two provided by Igalia (maintained by their WebKitGTK+ folks). Those bots build as many check ins as possible with 3 different configurations: 32 bits release, 64 bits release, and 64 bits debug. In addition to those, we have another bot called the EWS, or Early Warning System. There are two of those at this moment: one VM provided by Collabora and my desktop, provided by myself. These bots build every patch uploaded to the bugzilla, and report build failures or passes (you can see the green bubbles). They are very important to our development process because if the patch causes a build failure for our port people can often know that before landing, and try fixes by uploading them to bugzilla instead of doing additional commits. And people are usually very receptive to waiting for EWS output and acting on it, except when they take way too long. You can have an idea of what the life of an EWS bot looks like by looking at the recent status for the WebKitGTK+ bots. Maintaining all of those bots is at times a rather daunting task. The tests require a very specific set of packages, fonts, themes and icons to always report the same size for objects in a render. Upgrades, for instance, had to be synchronized, and usually involve generating new baselines for a large number of tests. You can see in these instructions, for instance, how strict the environment requirements are yes, we need specific versions of fonts, because they often cause layouts to change in size! At one point we had tests fail after a compiler upgrade, which made rounding act a bit different! So stability was a very important aspect of maintaining these bots. All of them have the same version of Debian, and most of the packages are pinned to the same version. On the other hand, and in direct contradition to the stability requirement, we often require bleeding edge versions of some libraries we rely on, such as libsoup. Since we started pushing WebKitGTK+ to be libsoup-only, its own progress has been pretty much driven by WebKitGTK+ s requirements, and Dan Winship has made it possible to make our soup backend much, much simpler and way more featureful. That meant, though, requiring very recent versions of soup. To top it off, for anyone not running Debian testing and tracking the exact same versions of packages as the bots it was virtually impossible to get the tests to pass, which made it very difficult for even ourselves to make sure all patches were still passing before committing something. Wow, what a mess. The explosion^Wsolution So a few weeks back Martin Robinson came up with a proposed solution, which, as he says, is the nuclear bomb solution. We would have a jhbuild environment which would build and install all of the dependencies necessary for reproducing the test expectations the bots have. So over the first three days of the hackfest Martin and myself hacked away in building scripts, buildmaster integration, a jhbuild configuration, a jhbuild modules file, setting up tarballs, and wiring it all in a way that makes it convenient for the contributors to get along with. You ll notice that our buildslaves now have a step just before compiling called updated gtk dependencies (gtk is the name we use for our port in the context of WebKit), which runs jhbuild to install any new dependencies or version bumps we added. You can also see that those instructions I mentioned above became a tad simpler. It took us way more time than we thought for the dust to settle, but it eventually began to. The great thing of doing it during the hackfest was that we could find and fix issues with weird configurations on the spot! Oh, you build with AR_FLAGS=cruT and something doesn t like it? OK, we fix it so that the jhbuild modules are not affected by that variable. Oh, turns out we missed a dependency, no problem, we add it to the modules file or install them on the bots, and then document the dependency. I set up a very clean chroot which we could use for trying out changes so as to not disrupt the tree too much for the other hackfest participants, and I think overall we did good. The aftermath By the time we were done our colleagues who ran other distributions such as Fedora were already being able to get a substantial improvements to the number of tests passing, and so did we! Also, the ability to seamlessly upgrade all the bots with a simple commit made it possible for us to very easily land a change that required a very recent (as in unreleased) version of soup which made our networking backend way simpler. All that red looks great, doesn t it? And we aren t done yet, we ll certainly be making more tweaks to this infrastructure to make it more transparent and more helpful to the users (contributors and other people interested in running the tests). If you ve been hit by the instability we caused, sorry about that, poke mrobinson or myself in the #webkitgtk+ IRC channel on FreeNode, and we ll help you out or fix any issues. If you haven t, we hope you enjoy all the goodness that a reproducible testing suite has to offer! That s it for now, folks, I ll have more to report on follow-up work started at the hackfest soon enough, hopefully =).

<object data="https://upload.wikimedia.org/wikipedia/commons/d/de/Aspect-ratio-4x3.svg" type="image/svg+xml"> https://upload.wikimedia.org/wikipedia/commons/d/de/Aspect-ratio-4x3.svg</object> <object data="https://upload.wikimedia.org/wikipedia/commons/f/f8/Aspect-ratio-16x9.svg" type="image/svg+xml"> https://upload.wikimedia.org/wikipedia/commons/f/f8/Aspect-ratio-16x9.svg</object> It seems that nearly all computer monitors have now switched from a 4:3 aspect ratio popular several years ago to a "wide screen" 16:10 and now mostly to an even wider 16:9. But screen sizes are usually measured by their diagonal length and those sizes have not changed. For example, before I had my Thinkpad X201, I had a X60 and a X35. They are similar laptops in the same product line with 12.1" screens. But 12.1" describes the size along the diagonal and the aspect ratio switched from 4:3 to 16:10 between the X60 and the X201. As the screen stretched out but maintained the same diagonal length, the area shrunk: from 453 square centimeters to 425. But screens are not only getting smaller, they are also getting less useful. The switch to wider aspect ratios is done so that people can watch wide screen movies while using a larger proportion of their screens. Of course, the vast majority of people's time on their laptops is not spent watching wide screen movies but in programs like browsers, word processors, and editors. Because most of our writing systems lay out documents from top to bottom, the tools we most frequently use to display (and then scroll through) the things we read primarily use vertical screen space -- the dimension that is shrinking. If you have a desktop monitor, you might rotate the whole thing 90 degrees and "solve" the problem. If you're on a laptop though (as I usually am) this is clearly not an option. I am not the first person to be annoyed by this trend. In fact, many recent desktop UI changes are designed to work around this issue. In the free software world, both Unity and GNOME 3 have made efforts to hide, merge, or otherwise get ride of title bars, menu bars, and panels that take up dwindling vertical space. I use Awesome which I've mostly set up to do two side-by-side terminals with very little in the way of menu bars. Applications are the worst offenders and the solutions for those things that won't run in a terminal (or people that don't want to live there) are still lacking. I have been using Firefox's Tree Style Tab extension to move tabs to the side and hand-customized toolbars that squeeze everything I need (i.e., back, forward, stop, refresh, and URL bar) onto a single menu bar. But the situation still drives me crazy. I'd love to hear what others are doing.

My earlier post on juju described a number of weird glitches I ran into. I got invited by hazmat on IRC (freenode #juju) to try to reproduce the problems so we could isolate the trouble. Fix #1: use the version from the PPA. The juju setup documentation doesn t mention this, but it seems that adding juju-origin: ppa to your ~/.juju/environment.yaml is a good idea. I suggest it be made the default, and to link to the full list of legal syntax for the environment.yaml file. I was not able to reproduce the missing-machines-at-startup problem after doing this, but perhaps it s a hard race to lose. Fix #2: don t use terminate-machine . :P There seems to be a problem around doing the following series of commands: juju remove-unit FOO/N; juju terminate-machine X; juju add-unit FOO . This makes the provisioner go crazy, and leaves all further attempts to add units stick in pending forever. Big thank you to hazmat and SpamapS for helping debug this.

2011, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.

Procps-ng, the debian, Fedora and OpenSuSE fork of procps had another release today. This is a bugfix release that fixes some important bugs that have cropped up in 3.3.0 pgrep crashes, pgrep -u not finding processes and a problem with top forest view have all been fixed. An important addition to this release is that test scripts have now been added using the Dejagnu framework. This framework tests most of the programs that ship with procps-ng. There is only 100 tests so far and they are only tested for Linux architecture, but we expect to increase this test count and sophistication with each release. The test scripts even found long-present but unknown bugs in the package. For example, running ps with output flags around the signal masks work as expected in Linux, but fail on kFreeBSD. This is due to the unusual output of the relevant lines on that architecture. This is not a new bug, bug has been around for quite some time; noone ever noticed (or reported) it. The Debian package has already been built and uploaded to the master FTP server. Oh, and it is the first package with my new GPG key!

Mika and I will be traveling this winter in the Seattle area and in Japan. The current plan is to be in Seattle December 19 through 28 and then in Japan from December 28 through January 12. After that, we will fly back to Boston for the MIT Mystery Hunt where, as punishment for winning last year, our team is running this year's hunt. We will be in Tokyo for New Years and then traveling around Japan for much of the rest of the time. We hope to visit Hokkaido and Aomori and to travel there from Tokyo along Japan's Western coast through Kanazawa and Niigata. We're still figuring out where we will visit and what we will do in both places. If you are interested in meeting up for dinner or drinks in either place (or in organizing a talk or meeting), please get in touch and let's try to figure something out.

At work we use .procmailrc files generated by CGIpaf to let non-technical users create forwards, out-of-office mails, etc. and any combination thereof. This also has the advantage that we can filter out double bounces and spam (which also prevents us from being listed in spammer blacklists). Unfortunately autofs (seems independent if autofs4 or autofs5 is used) seems to be unreliable if there are bursts of mount or umount requests, resulting either in File or directory not found error message while trying to access the home directory of a user, or Directory not empty error messages if the automounter tries to remove the mount point after unmounting. In that case a not mounted directory owned by root is left over. In the end both cases lead to procmail behaving as if that user does not have a .procmailrc which looks like sporadically lost mails to those who forward all mails. (The mails then can be found in the local default INBOX for that user.) Additionally there are similar issues when the NFS servers are not available. The most effective countermeasure we found so far was adding tests to the global /etc/procmailrc to check if the user s home directory exists and belongs to the correct user:

# -----------------
# Global procmailrc
# -----------------
# For debugging, turn off if everything works well
VERBOSE=1
LOGFILE=/var/log/procmail.log
# This only works with bourne shells, $SHELL defaults to the user's
# login shell. And by experience dash seems not work, so we use bash.
OLDSHELL=$SHELL
SHELL=/bin/bash
# temporary failure (see EX_TEMPFAIL in /usr/include/sysexits.h) if
# $LOGNAME is not set for some reason. (Just to be sure our paths
# later on are not senseless.
:0
* ? test -z "$LOGNAME"
 
    LOG="Expected variable LOGNAME not set. "
    EXITCODE=75
    :0
    /dev/null
 
# temporary failure (see EX_TEMPFAIL in /usr/include/sysexits.h) if
# $HOME is not readable. ~$LOGNAME does not seem to work, so this uses
# a hard wired /home/.
:0
* ? test ! -r /home/$LOGNAME
 
    LOG="Home of user $LOGNAME not readable: /home/$LOGNAME "
    EXITCODE=75
    :0
    /dev/null
 
# temporary failure (see EX_TEMPFAIL in /usr/include/sysexits.h) if
# $HOME has wrong owner. ~$LOGNAME does not seem to work, so this uses
# a hard wired /home/.
:0
* ? test ! -O /home/$LOGNAME
 
    LOG="Home of user $LOGNAME has wrong owner: /home/$LOGNAME "
    EXITCODE=75
    :0
    /dev/null
 
[ ]

If you want to store a copy of these mails for debugging purposes on every delivery attempt, replace /dev/null with some Maildir or mbox only accessible for root. One small but important part was to explicitly declare bash as shell for executing the tests, otherwise mails for users with tcsh or zsh as login shell filled up the mail queue and never get delivered (if the SHELL variable never gets fixed). Only drawback so far: This leads to more lagging e-mail on e-mail bursts also for those users who have no .procmailrc because procmail can t check if there s really no .procmailrc. Extensive procmail documentation can be found online at the Procmail Documentation Project as well as in the man pages procmail(1), procmailrc(5) and procmailex(5).

Today I was idly performing some maintainence upon one of my hosts, and it crossed my mind to look beneath /etc in there I found:

/etc/python
/etc/python2.4
/etc/python2.5
/etc/python2.6

That made me look more closely at the contents of /etc - the following command output was surprising:

steve@steve:~$ ls /etc   wc -l
187

Is that average? Heavy? Light? I have no idea, but I purged a hell of a lot of software today. Now I have only python v2.6 although for some reason I still have:

python
python-apt
python-apt-common
python-central
python-minimal
python-support
python2.6
python2.6-minimal

I suspect I could drop the pything2.6-minimal package, but for the moment I'm done. I have to make pretty people look exceptional with my magical camera. Anyway as part of this cleanup I ran a quick sanity-check on which processes are running and I think, short of kernel processes, I'm as minimal as I can be. I understand the purpose and reason for every running service:

UID        PID  CMD
root         1  init [2]
pdnsd    14091  /usr/sbin/pdnsd --daemon -p /var/run/pdnsd.pid
root     14199  /usr/sbin/monit -c /etc/monit/monitrc -s /var/lib/monit/monit.state
root     14206  /usr/sbin/syslog-ng -p /var/run/syslog-ng.pid
root     14234  /usr/sbin/cron
102      14595  /usr/sbin/exim4 -bd -q30m
redis    14627  /usr/bin/redis-server /etc/redis/redis.conf
root     14637  /usr/sbin/sshd

These are basic services; I use monit to ensure those essential daemons keep running. The only oddity there is probably the local DNS cache, but it is useful if you run any kind of DNS blacklist-using service, for example.

root     14794  /sbin/getty -L ttyS0 9600 vt100

I need a serial console login for emergencies.

root     14796  runsv node-reverse-proxy
root     14797  /bin/sh ./run
root     14799  /opt/node/bin/node node-reverse-proxy.js --config ./rewrites.js

These three processes combine to run my reverse proxy which routes incoming HTTP requests to a number of local thttpd instances.

qpsmtpd  27309    /usr/bin/perl -Tw /usr/bin/qpsmtpd-prefork --port 25 --user qpsmtpd --pid-file /var/run/qpsmtpd/qpsmtpd.pid --detach
..

The perl SMTP daemon which runs my incoming mail, passing it to exim4 which listens upon 127.0.0.1:2525. You can read about my setup in the out-of-date writeup Chris & I put together.

 /usr/bin/memcached -m 64 -p 11211 -u root -l 127.0.0.1

Memory cache for transient items.

s-blog    thttpd -C /etc/thttpd/sites.enabled/blog.steve.org.uk
1030      thttpd -C /etc/thttpd/sites.enabled/edinburgh-portraits.com
s-hg      thttpd -C /etc/thttpd/sites.enabled/hg.steve.org.uk
s-ipv4    thttpd -C /etc/thttpd/sites.enabled/ipv4.steve.org.uk
s-ipv6    thttpd -C /etc/thttpd/sites.enabled/ipv6.steve.org.uk
s-kvm     thttpd -C /etc/thttpd/sites.enabled/kvm-hosting.org
...

One thttpd instance is launched for each distinct HTTP site my server runs. Each site runs under its own UID, with its own chrooted directory tree. This is important for security. Each local instance listens upon 127.0.0.1 - and the reverse proxy previously mentioned rewrites connections to the appropriate one.

1016     28812     /usr/bin/perl -I./lib/ -I./ /usr/local/bin/blogspam

My anti-spam filter for blog comments.

Here is my christmas challenge. Can you identify each service upon your host? Do you know why you're running what you're running? Me? I had no idea I had a dbus deamon running. Now I've purged it. Ha! ObQuote - "I owe everything to George Bailey. Help him, dear Father." - It's a wonderful life.

This is my monthly summary of my Debian related activities. If you re among the people who made a donation to support my work (310.73 , thanks everybody!), then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. Dpkg: Multi-Arch Saga I know lots of people are waiting the landing of multiarch in Debian unstable, and so am I. Things are progressing, though not as quickly as I hoped. Guillem merged about half of the branch between the 24th October and the 6th of November. After that most of the work happened on his personal repository in his pu/multiarch/master branch. I verify this repository from time to time because Guillem does not inform me when he has made progress. I noticed changes on his repository on the 10th, 19th, 23th, 28th of November and on the 1th of December. He announced a long time ago that he had some interface changes and up to now only wrote about the switch from the command-line option --foreign-architecture (to put in /etc/dpkg/dpkg.cfg) to the explicit command dpkg --add-architecture that only needs to be called once (see mail here). As of today (December 2th), the promised email for the other interface changes is still not here. On November 23th, I reviewed Guillem s work and tried to run the code in his branch. I spent the whole day chasing up regressions and submitted lots of fixes to Guillem. Thanks to the extensive test-suite I wrote when I developed my branch, it has been fairly easy to track them all down. All the issues I reported have been fixed in the latest version of Guillem s branch although the fixes are often slightly different from those that I submitted. Dpkg: Squeeze Backport At the start of the month, I uploaded what I expected to be a fairly uncontroversial backport of dpkg 1.16.1.1. It turns out I was wrong. After some discussion, I think we came to an agreement that it was acceptable to backport dpkg-dev and libdpkg-perl only. My goal was not to bring the latest dpkg to users but to make it easier for package maintainers to backport packages using new features provided by dpkg-dev >= 1.16 (such as hardening build flags, the makefile snippets provided in /usr/share/dpkg/, or the improved dpkg-buildflags interface). Thus I modified the source package uploaded to squeeze-backports to build only dpkg-dev and libdpkg-perl. It has been uploaded on November 23th and it s waiting in the NEW queue for a backports admin to process it. Misc Dpkg Work I merged a patch of Colin Watson to be able to verify build-dependencies for a foreign architecture (taking into account the Multi-Arch status of each package listed). I released dpkg 1.16.1.2 with two minor fixes that were sitting in the sid branch. I wanted to get rid of this so that the path is clear for a 1.16.2 upload with multiarch. The package just migrated to testing so we re fine. I spent another day doing dpkg bug triaging on Launchpad, we re now down to 77 bugs with many of them tagged as incomplete and likely to expire in 2 months. The Debian Administrator s Handbook We released a sample chapter so that it s easier to have an idea of the quality of the book. The chapter covers the APT tools quite extensively. I bet that even you could learn something about apt-get/aptitude The crowfunding campaign on Ulule ended on November 28th.
With 675 supporters, we raised 24385 EUR. Of those, 14935 EUR have been put in the liberation fund and the rest corresponds to the various pre-orders and rewards offered. This means that the translation will happen (we just started) but that the book is currently not going to be released under a free license. Don t despair As planned, the liberation campaign is carried on until the 25 K target is reached! Instead of being hosted on Ulule, this permanent campaign is on the project website at debian-handbook.info/liberation/. Note that any contribution of 10 EUR or more means that you get a copy of the ebook as soon as it s available (even if the liberation target is not reached). Package Tracking System At the start of the month, I filed two ideas of improvements for the PTS in the bug tracking system: #647258 is about showing outstanding bugs that relate to a release goal and #647901 is about warning maintainers that the package is affected by a current transition. If you re a coder and want to start contributing to Debian and its QA team, those bugs could be interesting targets for a start. In both cases, I have been in contact with members of the release team because those ideas require some structured data from the release team as input. Thanks to Meddi Dohguy and Niels Thykier for their help. Later in the month, the topic of relocating the PTS once again came up. For historical reasons, the PTS was hosted on master.debian.org together with the BTS. Nowadays the BTS has its own host and it made no sense anymore to have the PTS separate from the rest of the QA services hosted on qa.debian.org (currently quantz.debian.org). So together with Martin Zobel Helas we took care to plan the migration and on November 19th we executed the plan. It worked like a charm and almost nobody noticed (only one undocumented dependency was missed, which broke the SOAP interface). Misc Packaging Work WordPress was broken in Ubuntu and it was also not properly synchronized with Debian due to an almost useless change on their side. Thus I requested a sync so that the working version from Debian gets imported in Ubuntu. I sponsored the docbook-xsl 1.76.1 upload that I needed for Publican. Then I updated Publican just to discover that the test-suite triggers a new bug in fop (filed as #649476). I disabled the test-suite temporarily and uploaded Publican 2.8 to unstable. BTW, I also filed 2 upstream bugs with patches for issues I discovered while trying to generate the sample chapter of my book (see here and here). I uploaded a version 0.7.1 of nautilus-dropbox and fixed #648215 at the same time. I made an NMU of bison to fix a long-standing release critical bug that hit me once more during an upgrade (see #645038). I uploaded to experimental a new version of gnome-shell-timer compatible with GNOME 3.2. I took the opportunity to install from experimental the few GNOME 3.2 packages which are not yet in unstable Thanks See you next month for a new summary of my activities.

7 comments Liked this article? Click here. My blog is Flattr-enabled.

(including English!) The string freeze of Debian Installer officially ended at 23:59 yesterday (Sept. 20th). Indeed, this was extended a bit to today, with agreement by Otavio Salvador who I thank for this. That allowed Zak to "save" Tagalog and also the Welsh and Latvian translators to polish their work. We now have to decide about some of these languages: those that failed to meet the release criteria but were formerly activated in D-I. There are four such languages: Amharic, Welsh, Estonian and Northern Sami. Please find below the mail I just sent to debian-i18n and debian-boot. I promised that this discussion would happen in public. It will (but it will be short as we can't delay the release of the installer for ages....and I think that my proposals are reasonable!)

First of all, the numbers as of Sunday Sept. 21st 09:32 UTC (date of
the last commit with an l10n update):
Languages meeting the release criteria: 59
------------------------------------------
Already activated and complete for level 1: 51
 Arabic, Belarusian, Bulgarian, Bosnian, Catalan, Czech, Danish,
 German, Dzongkha, Greek, Esperanto, Spanish, Basque, Finnish, French,
 Galician, Gujarati, Hebrew, Hindi, Croatian, Hungarian, Indonesian,
 Italian, Japanese, Georgian, Khmer, Korean, Lithuanian, Latvian,
 Macedonian, Malayalam, Marathi, Norwegian Bokm l, Nepali, Dutch,
 Norwegian Nynorsk, Punjabi, Polish, Portuguese, Brazilian Portuguese,
 Romanian, Russian, Slovak, Albabian, Swedish, Tamil, Thai, Turkish,
 Vietnamese, Simplified Chinese, Traditional Chinese
Already activated and complete for sublevels 1 and 2: 6
Bengali, Kurdish, Slovenian, Tagalog, Ukrainian, Wolof
Not yet activated languages complete for sublevels 1 and 2: 2
 (the mail in -i18n and -boot says 3 but this is an error by me)
Irish, Serbian
Languages failing to meet the release criteria: 15
--------------------------------------------------
Activated languages: 4
Amharic, Welsh, Estonian, Northern Sami
Not yet activated languages: 11
Afrikaans, Persian, Armenian, Icelandic, Kazakh, Kannada,
Malagasy, Malay, Telugu, Urdu, Xhosa
Discussion
----------
(careful people will notice that I moved Welsh down to "failed to meet
the release criteria" as this is what is technically correct)
Nothing to discuss for the 57 already activated languages that meet
the defined criteria. They'll be kept or first activated in the RC1
release of Debian Installer.
Similarly, nothing to discuss for the 11 languages that were not
activated and haven't made it. They will remain unactivated.
Two languages should be activated as they have met the release
criteria for the first time during the string freeze: Irish and Serbian.
This adds more load (and size changes) to D-I but I really don't see
any reason to not follow our own rules there.
The discussion comes for the 4 languages that fail to meet the release
criteria. Here are my proposals with some rationale:
Amharic: 
  I would really dislike deactivating Amharic because it's highly
  symbolic to have the language of Ethiopia activated. We have so few
  African languages. Also, the translation is nearly complete and the
  translator was well coping with updates until July. The missing
  stuff for Amharic in sublevels 1 and 2 are messages about loading
  drivers or firmware from removable media, the rescue mode stuff for
  the graphical installer and some messages that briefly appear during
  finish-install. A little bit more important is the message warning
  that the boot partition is not ext2 or ext3, added in August by
  tbm. I think this is not enough to drop out one year of efforts for
  the translator
  As a consequence, I propose to KEEP Amharic.
Welsh:
  Only five strings are missing in sublevels 1 and 2 because of the
  small experience of PO files by the person who completed the
  translation during last week. One will make the regular user login
  name screen to be in English and others will make the GRUB password
  screen to be in English as well, that's all.
  Additionnally, we can safely assume that all potential users of
  Welsh have good skills in English...and will therefore very easily
  cope with these screens.
  As a consequence, I propose to KEEP Welsh.
Estonian:
  The translation had NO update since Etch. The last update is dated
  back to Feb. 17th 2007. I haven't got any sign of life from the
  translator and no Estonian users have volunteered to maintain the
  translation.
  Missing strings are in many places, including several screens that
  appear in default installs. Even though one can assume that the
  skills of the average Linux user in Estonia is fairly good, I think
  this is not enough to throw users in a big mix of English and
  Estonian.
  As a consequence, I propose to DROP Estonian.
Northern Sami:
  The translation is very incomplete. With about any other language,
  that would be a reason to drop the translation.
  However, a few reasons make me suggest keeping it:
   - Northern Sami is mostly used in Norway and D-I will fall back
     to Norwegian Bokm l which is understood by all potentials users
     as it is teached in all Norwegian schools. 
   - Users will be warned, *in Sami*, about this situation
   - The choice of Sami will be kept in localechooser even if the
     translations are dropped. This is on request of Debian Edu
     developers to avoid them to develop a special boot floppy
     to offer the choice of Sami (a requirement for Norwegian
     schools). I personnally think this is a reward to Debian Edu and
     its ancestor Skolelinux for their initial involvement in the
     development of D-I
  As a consequence, I propose to KEEP Northern Sami.
I understand that these choices may be debatable and some may sound
slightly subjective. I however think this is the best way to be fair
with translators' efforts without compromising the quality of D-I.
Please note that the final word on this will be by D-I release
managers...but advices are very much welcomed.

uniq is a great tool, since it returns the unique (adjacent) lines of the given input. But it has a limitation: it can't check for uniqueness only the first N fields (while it allows to ignore them, weird).

So, what to do if you have a long file, and lines with several fields, but you're only interested in getting the line with the different first 2 field (but all the rest of the line content? awk to the rescue!

$ awk '!x[$1]++' file

will print the (complete) lines of file that has the first field unique. You can set $1$2 to have lines unique on the first 2 fields, and so on. Thanks to this forum post, but there's some other interesting articles.