Most packages contain files that you don t need: for example translations in languages that you don t understand, or documentation that you don t read. Wouldn t it be nice if you could get rid of them and save a few megabytes? Good news: since dpkg 1.15.8 you can! dpkg has two options --path-include=glob-pattern and --path-exclude=glob-pattern that control what files are installed or not. The pattern work the same than what you re used to on the shell (see the glob(7) manual page). Passing those options on the command-line would be impractical, so the best way to use them is to put them in a file in /etc/dpkg/dpkg.cfg.d/. Beware, the order of the options does matter: when a file matches several options, the last one makes the decision. A typical usage is to first exclude a directory and then to re-include parts of that directory that you want to keep. For example if you want to drop gettext translations and translated manual pages except French, you could put this in /etc/dpkg/dpkg.cfg.d/excludes:

# Drop locales except French
path-exclude=/usr/share/locale/*
path-include=/usr/share/locale/fr/*
path-include=/usr/share/locale/locale.alias
# Drop translated manual pages except French
path-exclude=/usr/share/man/*
path-include=/usr/share/man/man[1-9]/*
path-include=/usr/share/man/fr*/*

Note that the files will vanish progressively every time that a package is upgraded. If you want to save space immediately, you have to reinstall the packages present in your system. aptitude reinstall or apt-get --reinstall install might help. In theory with aptitude you can even do aptitude reinstall ~i but it tends to not work because one package is not available (either because it was installed manually or because the installed version has been superseded by a newer version on the mirror).

Found it useful? Click here to see how you can encourage me to provide more articles like this one.

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

The second alpha of Cupt2 is out at the same download place.

Changes since first alpha:

• documented library, except of cupt::system::Worker and cupt::system::Resolver
• added an example 'show-upgradeable'
• bug fixes

The library API is still a subject to change. If you care, please install the documentation package and mail me (see mail address in README) your thoughts and suggestions.

In the last years I noticed a growing trend of people pushing for "new" rules about what is appropriate or not for single developers or for the project as a whole. In too many cases even just considering these ideas to be an obvious fact... I prefer to not give specific examples because these would divert the attention from the main topic and would be affected by my own biases. At this point I believe it is useful to remember that all ethical issues which are not explicitly covered by the Social Contract are just the developers' own opinions. It may even be a good idea, but other developers are not and should not be compelled to agree with it no matter how good or important you believe it is. You are entitled to having your own ethics and even ranting about it on Planet Debian, but I am entitled to not caring at all without this making me a worse Debian Developer. Let's try to be grown ups and not be excessively annoyed by other people's choices. This is why I want to convey this simple message to the people who keep preaching about what is proper for me or for Debian: please fuck you. If I want to receive lectures about what is right or wrong then I surely know where I can find a priest. For some reason, now I see fit to mention that I have an Amazon wishlist...

A while ago I wrote about the new distcheck tool upcoming in dose3. I've recently updated the proposal on the debian wiki to reflect recent changes in the yaml data structure. The idea was to remove redundant information, to make it easier to read and at the same time include enough details to make it easy to use from a script. I'll write down a small example to explain the format. A package can be broken because of a missing package or because of a conflict. For a missing package we'll have a stanza like this : The first part gives details about the package libgnuradio-dev, specifying its status, source and architecture. The second part is the reason of the problem. In this case it is a missing package that is essential to install libgnuradio-dev. missindep is the dependency that cannot be satisfied is the package libgruel0 , in this case: libboost-thread1.40.0 (>= 1.40.0-1). The paths component gives all possible depchains from the root package libgnuradio-dev to libgruel0 . Notice that we do not include the last node in the dependency chain to avoid a useless repetition. Of course there might be more then on path to reach libgruel0. Distcheck will unroll all of them. Because of the structure of debian dependencies usually there are not so many paths. The other possible cause of a problem is a conflict. Consider the following : This is the general case of a deep conflict. I use an artificial example here instead of a concrete one since this case is not very common and I was not able to find one. To put everything in context, this is the example I've used (it's in cudf format, but I think you get the gist of it): The first part of the distcheck report is as before with details about the broken package. Since this is a conflict, and all conflicts are binary, we give the two packages involved in the conflict first. Packages f and e are in conflict, but they are not direct dependency of package a . For this reason, we output the two paths that from a lead to f or e. All dependency chains for each conflict are together. Again, since there might be more than one way from a to reach the conflicting packages, we can have more then one depchain. Another important upcoming change is distcheck (to be implemented soon) it the ability to check if a package is in conflict with an Essential package. In the past edos-debcheck always check the installability of a package in the empty universe. This assumption is actually not true for debian as all essential packages should always be installed. For this reason, now distcheck will check the installability problem not in an empty universe, but in a universe with all essential packages installed. This check is not going to be fool proof though. Because of the semantic of essential packages, despite is not possible to remove a package toutcourt, an essential package can be replaced by a non essential package via the replace mechanism. For example, poking with this feature I noticed that the package upstart in sid replace sysinit and it is in conflict with it. This is perfectly fine as it gives a mechanism to upgrade and replace essential components of the system. At the same time this does not fit in the edos-debcheck philosophy of checking packages for installation problems in the empty universe (or in a universe with all essential packages installed). At the moment we are still thinking how to address this problem (the solution will be in the long term to add the replace semantic in distcheck), but for the moment we will just provide an option to check packages w.r.t essential packages conscious the this can lead to false positives. This work is of course done in collaboration with the mancoosi team in paris. Dose3 is still not ready for prime time. We are preparing debian packages and we plan to upload them in experimental in the near feature.

Just in passing, if anyone wants to support my work in Debian and/or Emdebian, there is a simple and free way to do it. Send me some patches, especially for documentation, translations and examples.

I have more than enough stuff that I could be doing and I do hear from users who want more stuff done to suit their particular requirements. Sorry, but time is finite and whilst a "thank you" is always appreciated, it doesn't actually generate a 25 hour day. So please don't just tell me what you want or why the current stuff doesn't do what you want it to do. The source code is all just "out-there" and you know more about what you actually want than I ever could.

If any of my code doesn't quite do what you want, please don't moan about it or file bugs that just moan about it, work out why and how and fix it - get involved. That way, the code will develop even if I don't always have time to work on it.

Tonight I was having some connectivity issues, so after much diagnostic time and pain I decided to reboot my router. At the moment my home router came back my (external) IP address changed, and suddenly I found I could no longer login to my main site. Happily however I have serial console access, and I updated things such that my new IP address was included in the hosts.allow file. [*] The next step was to push that change round my other boxes, and happily I have my own tool slaughter which allows me to make such global changes in a client-pulled fashion. 60 minutes later cron did its magic and I was back. This reminds me that I let the slaughter tool stagnate. Mostly because I only use it to cover my three remote boxes and my desktop, and although I received one bug report (+fix!) I never heard of anybody else using it. I continue to use and like CFEngine at work. Puppet & Chef have been well argued against elsewhere, and I'm still to investigate BFG2 + FAI. Mostly I'm happy with slaughter. My policies are simple, readable, and intuitive. Learn perl? Learn the "CopyFile" and you're done. For example. By contrast the notion of state machines, functional operations, and similar seem over-engineered in other tools. Perhaps thats my bug, perhaps that's just the way things are - but the rants linked to above makes sense to me and I find myself agreeing 100%. Anyway; slaughter? What I want to do is rework it such that all policies are served via rsync and not via HTTP. Other changes, such as the addition of new primitives, don't actually seem necessary. But serving content via rsync just seems like the right way to go. (The main benefit is recursive copies of files become trivial.) I'd also add the ability to mandate GPG-signatures on policies, but that's possible even now. The only step backwards I see is that currently I can serve content over SSL, but that should be fixable even if via stunnel.

---

*

My /etc/hosts.allow file contains this:

ALL: 127.0.0.1
ALL: /etc/hosts.allow.trusted
ALL: /etc/hosts.allow.trusted.apache

Then hosts.allow.trusted contains:

# www.steve.org.uk
80.68.85.46
# www.debian-administration.org
80.68.80.176
# my home.
82.41.x.x

I've never seen anybody describe something similar, though to be fair it is documented. To me it just seems clean to limit the IPs in a single place. To conclude hosts.allow.trusted.apache is owned by root.www-data, and can be updated via a simple CGI script - which allows me to add a single IP address on the fly for the next 60 minutes. Neat.

ObQuote: Tony is a little boy that lives in my mouth. - The Shining

I miss the days when Debian was about making software work well together. These days the user mailing lists are full of posts from users asking for help on Ubuntu [*1*], people suggesting that we copy what Ubuntu has done, and people asking for "howtos" because documentation is too scary or too absent for them to read. Yesterday the whole commercial spam on Planet debate started. Its yet another example of how in-fighting[*2*] seems to be the most fun part of Debian for too many. Me? I started and folded a company. I got Debian help and users. Some threw money at me. Joey Hess? Started making the nice-looking ikiwiki-powered branchable.com. Commercial? Yes. Spam? No. I guess there is little I can do. I could quit - as over time I've become less patient dealing with the project as a whole, but simultaneously more interested in dealing with a few specific people. But I suspect the net result would be no change. Either people would say "Ok , bye" or worse still offer my flttry: "Don't go - we lurve you". Meh. I shouldn't write when I'm annoyed, but living in a hotel will do that to you. Footy-Mc-Foot-notes. Cos HTML is hard. Lets go shopping Eat Cake.

1

The Ubuntu forums are largely full of the blind leading the blind. Or equally often the blind being ignored. I do believe that an Ubuntu stackoverflow site would be more useful than forums. But that's perhaps naive. People will still most often say "My computer doesn't work" missing all useful the details. The only obvious gain is you can avoid "me too!!!" comments, and "fix this now or I'm gonna go .. use gentoo?".

2

Back a few years when people were less civil some mailing lists and irc channesl were unpleasant places to be. These days we've solved half the problem: People mostly don't swear at each other. The distractions, the threads that don't die, even if you ignore them and don't join in the "hilarity" they still have a devisively negative effect.

State of X in experimental What happened since last month? The video drivers we were previously lacking were built against X Server 1.9, with a tiny exception: xserver-xorg-video-nouveau. This one is particularly annoying because the ABI is not stable, and it requires a particular version of the kernel to be usable. The same seems to happen with the nouveau part of the libdrm library. As a consequence, I ve demoted it from Depends to Recommends for the xserver-xorg-video-all metapackage. The same happened to the xserver-xorg-input-wacom driver (for the xserver-xorg-input-all metapackage this time), since it isn t maintained by debian-x@, and since it didn t look too bad to have it only recommended (after all, we re only targeting experimental right now). In addition, all drivers were updated to the last upstream releases. Bottom-line, the following is now possible on (at least) both amd64 and i386 architectures:

apt-get install -t experimental xserver-xorg

As a side note: Intel users probably want to upgrade their libdrm-intel1 package to 2.4.22-2 (in experimental as well), they could run into X.Org Bug #31443 otherwise. Dependency handling for X packages in Debian Previously, dependencies were quite fun:

• Drivers used to provide a given virtual package: xserver-xorg-input-$ABI and xserver-xorg-video-$ABI. One shall note that the ABI is evolving independently for input and video drivers, see SET_ABI_VERSION in server s hw/xfree86/common/xf86Module.h for curious people.
• The xserver-xorg metapackage depended on xserver-xorg-core (the server itself) with a minimal version, and on those virtual packages. More precisely, for example in the input case: xserver-xorg-input-all xserver-xorg-input-$ABI so that by default one gets everything for autodetection to work, but one can pick a specific driver instead.
• The drivers only depended on the server, with a minimal version as well.

So what did we do to ensure the server and drivers were all using the same ABI? When the server was updated to a new ABI, one had to add the previous virtual packages to Conflicts (and keep a list of all of them, yay!). Needless to say, asking a package manager to upgrade at a same time many packages (several dozens for all drivers) declaring conflicts, especially during a mass dist-upgrade from a stable release to the next stable was no fun. So what s the current situation now?

• xserver-xorg depends on a minimal server version, and on drivers. The alternatives are now written like this: xserver-xorg-input-all xorg-driver-input. Notice there s no ABI mentioned here anymore. It s just about having the server, at least an input driver, and at least a video driver.
• xserver-xorg-core now provides an input ABI and a video ABI. In experimental for example: xorg-input-abi-11.0, xorg-video-abi-8.0
• Drivers now depend on the ABI they were built against. For example, xserver-xorg-input-evdev in experimental depend on xorg-input-abi-11.0

So one might think everything is now fine, except there are some conflicts still declared, to ensure one can transition from packages using the former (bad) logic to the new state of affairs. And those conflicts were still causing headaches to package managers. Fortunately, David Kalnischkies came up with a proposal to replace Conflicts with Breaks, which turned out to ease things. Yatta! All of that is implemented in experimental. squeeze is the transition period where the metapackage stills the depends on xserver-xorg- input,video -$ABI virtual packages, but where drivers now depend on the appropriate server ABI. (Thanks to Alexander Kurtz for his feedback.)

I had been planning to write today about my great uncle Milt Goerzen. Milt passed away last Thursday after a long struggle with dementia, and his funeral was this morning. I was there, and was inspired by a few things I heard. But that will have to wait, because today brought one of those few moments in life that s a sense of an impending possible great loss. I can remember two others: one was when Terah passed out, and the other was when we heard that our place was on fire and our house had burned down (it turned out the house hadn t, but much of the rest had). I got a call during Milt s funeral. I didn t answer because I was, well, at a funeral, and the phone was on vibrate. When I had the chance to check the voicemail, it went something like this: I think we have an emergency with Jacob. He got run over by a tractor. He says he s OK, but I m taking him to the doctor right now. I tried to return the call, but cell phone reception wasn t cooperating. The most I got was he s OK . It s hard to describe how a moment like that feels. My mind jumped to telling Jacob I love you , and how lately when he hears that, he will snuggle in for a big hug, and say, Dad, I love you toooooooooo! On the one hand, I heard the he s OK part, and on the other hand I couldn t forget the tractor running over him part, and my mind leapt at the worst. It turns out that, while I was at the funeral, Jacob had been standing on his usual spot on the tractor, sort of to the side of the driver. He was enjoying himself like usual. The tractor hit a large hole that wasn t really visible. The combination of the jolt and the dip the tractor took towards Jacob s side knocked him off and he went directly under the big rear wheel before the tractor could be brought to a stop. I caught up with him and his grandpa after he had seen the doctor and just as he was being admitted to the hospital. He saw me and crawled over, making his sort of sad and scared sound he sometimes doesn t want to verbalize things when he s in that mood. I held him close and he seemed to appreciate it. He had to have blood drawn, and he was scared of that. I remembered his inquisitive mind, and reminded him how much he liked watching the tube fill up with blood last time he had a blood test (which he calls a blood shot ). That wasn t helping, until the actual blood test started. He cried when the needle went in, but then calmed down as the nurse, getting into the act, pointed out that there was blood filling up the tube. Hmmm! said Jacob. Then she gave him a band-aid. It has an airplane, said the nurse. Um-hmm! said Jacob. I pointed out that it looked like the airplane we were on when we flew home from New York. Jacob got a big smile and said, Yes, it IS that one! He got a sticker there too. Then it was off for an x-ray to check for broken bones and a CT scan to check for internal injuries the tractor had gone right over his abdomen. He had to get an IV at the CT scan, which he certainly didn t like. After it happened, however, he found it very interesting especially when the nurses explained that they would give him a drink through the hose attached to his hand. After that, we went to his room, with orders for him not to eat or drink anything until it was clear he didn t have digestive problems. While we waited at various steps along the way, Jacob wanted to sit on my lap and watch train videos on YouTube on my phone. He loves train videos, and brought my phone s battery nearly to depletion through the course of the afternoon. Jacob eventually seemed to get back to a bit of his usual self. At one point, while Terah had made a run home to pack an overnight bag and grandpa ran some errands of his own, Jacob wanted to leave the room. He had gone exploring in the hospital with me before: when Oliver was born, and when Terah had her thyroid surgery. So this was something he just associated with the hospital. That and lemonade, which is free any time of the day or night in the cafeteria. So we went exploring, even ventured outside into a courtyard for a bit. He was walking fast and seemed good. We had several visitors: grandparents and his aunt and uncle. Jacob got a stuffed rabbit and a colorful bug box with windows (for putting bugs inside for observation). Eventually the doctor came by and gave us the results: the x-rays showed no problems. The labs showed some elevated liver enzymes, which he expected, but no serious trouble. The CT showed contusions on his lung and bruising on his heart which would heal completely in time. He allowed Jacob to have a liquid supper (so I quickly got him the lemonade he had been wanting while the nurses got him some Jello). The doctor examined Jacob, pushing at various places, asking Does it hurt here? No. Does it hurt here? No. Here? No. Are you hungry? Yes. Does it hurt here? No. He gave me a look that said: really? It doesn t hurt ANYWHERE? What could I do but shrug my shoulders? Jacob has some abrasions on his face, arms, and back, which will probably eventually hurt (and sure enough, about 10 minutes later he started getting a little pain when he tried to move, which the doctor checked out) Then the doctor said, I hope you know you have a walking miracle today. This is just amazing. You have some thanking to whatever guardian angels you like tonight all I can say about this is that the Lord must have had some other plan for him. There s no way he could have survived that. Jacob s doctor is one that we really respect: he s scientific in his analysis, cites studies as a matter of routine, doesn t prescribe antibiotics for things that he knows they have a small chance of helping, is common-sense about not over-treating things and yet always engaged in an emergency. That little speech from him was something I d never expected to hear from him. He went on to add that I always visit my sickest patients first. You were my last visit this evening, so that should tell you something. Any other kid as healthy as he is, I might discharge already but I m just not justified doing that with a boy that s, well, been driven over by a tractor this morning. He also wanted to monitor Jacob s progress throughout the coming day, especially his digestive system. They wanted to measure his urine output, which he, predictably, found to be very interesting. Terah said I think it is about 150 ml. Jacob said, No mom, it is closer to the two hundred line. Me: Since when does Jacob know about the number 200? Terah: I don t know . he s 4, where would he have gotten it? Between that, and using every opportunity to tell people that there were not one but TWO red light switches in the x-ray room, Jacob s definitely himself in some ways already. So, that feeling of some impeding great loss is gone, replaced by being more than a bit overwhelmed by how fortunate we were today. We also appreciate all the help we ve had with Jacob and Oliver today.

Now that we have KMS, it happens things go bad enough that when X goes down, one can no longer access any console to see what happened. Mainly, one can distinguish between two cases.

• The good one: the machine is still accessible over the network. Unfortunately, that requires having a spare machine to ssh into the first machine, but that means one can run dmesg, look into X logs, possibly run X inside gdb and see where it breaks (because glibc s backtrace isn t exactly an excellent tool to get the idea of what s going on and that s the tool used in X to print a backtrace in the log through a signal handler).
• The bad one: the machine is no longer accessible over the network. Likely, the kernel is in such a bad shape that one is never going to know what happened. Usually, writing logs to disc didn t happen, so logs won t magically show up at next reboot.

I m going to discuss the second case. There s a nice tool in the kernel which makes it possible to send kernel logs over the network. It s called netconsole. As far as limitations are concerned, one shall note that it s UDP only, and over Ethernet (in other words: no wireless). The good news is that it can usually make the last crucial lines available. Let s call the crashy machine a patient and the logging machine a doctor. One should keep in mind that if something goes wrong while configuring the netconsole module, it can be unloaded at anytime through:

sudo modprobe -r netconsole

Easy case: on a local network Here s an example: Patient s IP is 192.168.0.1, doctor's IP is 192.168.0.2. Doctor setup What one needs on the receiving side: only netcat. A tiny warning, there are several implementations. Here s the appropriate syntax:

# netcat-traditional:
nc -l -u -p 6666   tee ~/netconsole.log
# netcat-openbsd:
nc -l -u 6666   tee ~/netconsole.log

The nc command is handled through the alternatives system, one can use update-alternative --config nc to pick the appropriate one if several netcat-* packages are installed. To list the current one, an easy way is readlink -f $(which nc). Using tee means that incoming messages are going to be printed, both to the standard output and to the specified file. Running as non-privileged user is sufficient. Patient setup Now, to have the patient send stuff to the doctor, a simple modprobe is needed:

sudo modprobe netconsole netconsole=@/,6666@192.168.0.2/

What happens here? One requests the netconsole module to be loaded, and one specifies the parameters. Details can be read in the Linux kernel documentation (Documentation/networking/netconsole.txt), but concentrating on the points of interest here:

• 192.168.0.2: The doctor s IP.
• 6666: The UDP port to which packets are sent. 6666 is the default and can be omitted.

That s all! On the doctor side, one should see something along those lines:

[2920549.188090] console [netcon0] enabled
[2920549.188102] netconsole: network logging started

Slightly harder case: over internet Because one might not have a second machine handy, it s also possible to go through a router and send stuff across the internet. Here s an example: Patient s IP is 192.168.0.1, connecting to internet through a router, which IP is 192.168.0.254. The doctor, available over the internet, is 192.0.32.10. Doctor setup Exactly the same as in the previous case. The main issue one can run into is firewalls at this point. That s why one may want to switch from the default 6666 port to another one which wouldn t be filtered. One can think of 53 (DNS), but that means running nc as root since it s a privileged port (below 1024). Patient setup Routing is also possible, but that requires an extra parameter: the MAC address of the router. To obtain it, one can use the arp command:

/usr/sbin/arp 192.168.0.254

Supposing it returned the 01:02:03:04:05:06 address, loading the module becomes:

sudo modprobe netconsole netconsole=@/,6666@192.0.32.10/01:02:03:04:05:06

Now, if you re running into firewall-related issues, you can change the source for the UDP packets. The default is 6665, but assuming you want to send from an unfiltered 1234 port, that becomes:

sudo modprobe netconsole netconsole=1234@/,6666@192.0.32.10/01:02:03:04:05:06

On the drive back home from BelHac I thought about the configuration problem in Haskell: The issue is finding a convenient way to work with values that are initialized once and used in many places all over the code. Assume you have a large module of pure code that, using many custom functions and combinators, parses some data structure. Later you noticed that somewhere far down in the parser, you need to react differently depending on some user preferences say, his preferred language. The usual solution is to add a new parameter to that function and, in consequence, to each and every function that calls or might call directly or indirectly this function. This is often very inconvenient. Other solutions include:

• Using mutable references and some hacking with unsafePerformIO, which always gives the programmer a bad conscience.
• Using a Reader monad, requiring a rewrite of the whole program in monadic style.
• Using implicit parameters which is ok if you did not write type signatures, but if you did, you still have to modify them a lot.
• Some advanced type hackery.

The solution I thought of and implemented uses Template Haskell, the Haskell library to modify code at compile time, to turn the style you prefer to write in (pure code that uses configuration values as if they were global constants) into the style that is semantically correct (pure code with configuration values as an additional parameter). I uploaded the resulting code as seal-module to hackage and added plenty of comments and examples to the SealModule module ( are comments according to ohcount). I refrain from copying that into this blog post, so if you are curious, please continue reading there.

My recent experience with Mozilla ThuderBird, IceDove. With KDE 4.x, the KDE team took a radical step of ripping apart most of the stuff and rethinking many of the designs. Quite a bold move. Many people appreciated KDE's efforts to start afresh while others moved away from KDE. For some reasons, I decided to stick to KDE. Maybe it was because of the awesome flexibility KDE provided provides to customize the DE to one's personal taste. Or maybe because I was too used to the KDE way of doing things. I stayed with KDE while 4.0 was released and stayed with it up till very recently. I started to lose my patience with the PIM Suite. I know the PIM team is also going to some very radical changes which will bring very innovative stuff later. But, at the moment, the KDE PIM suite is very broken. Broken not in the first impress, but broken when you regularly use it. It leaks memory like anything and keeps doing lots and lots of I/O. I hope some day the KDE team decides that they do need a core team, a core team that could take care of important tasks, making sure that the imporatant tasks are Continuously Usable. It takes time to earn the reputation but it takes a lot lesser time to lose it. Anyways, having been a KDE (PIM) user for long, I had been bearing the PIM torments up until, I recently saw a colleague using IceDove. There was a time when the Mozilla suite was in itself terribly slow. But things seem to have changed a lot. Both, the browser and the PIM suite, have improved a lot lot in terms of functionality and performance. Performance is very important. What good is a feature if its performance is terrible and it hinders the usability. Some of the things that really impressed me were:

• Indexing
• Organization

Indexing: Nepomuk might be good one day but that day is yet to be seen. I patiently wait for that day to come. Well, don't have much choice. Have been patiently waiting for it since KDE 4.0 was released. KDE has great ideas with Nepomuk which is good. But realisticly, what all do you want to see indexed ? There has to be a realistic line drawn. The browsers already have indexing for the history. Amarok, the player, also does indexing. It can tell you when your last favorite song was played. For pictures, I have the awesome KPhotoAlbum that cannot be beaten by anything. But above all, the most important thing to index is your conversation. Those emails that you send daily. And indexing is no good if you can't find the information you need, later. IceDove has filled that place. It does an excellent indexing (in terms of performance) and presents a very user intuitive way to narrowing it down to, when looking for a particular information. Organization: The other great thing about KDE PIM is its ability to break down its applications into small parts and glue them together into a new, well integrated application. Yes, Kontact. It is used to be the best PIM application. Used common libraries to make the suite more efficient than the rest. But all this was used to be. Today, kpart itself might be Kontact's problem. We have different applications glued together that if built with a common design, could have benefited a lot more. Take for example: kmail, knode and akregator. They are all very important parts of the PIM suite. Yet all three are different. The only thing common amonst them is is that they are available from the same Kontact shell. kmail has a different navigation. akregator has very nice aggregated folders but the same cannot be available in knode and kmail. knode, while still okay, has been rotting for some time. So it was time to see how IceDove performed when testing it up against this Use Case. The good thing about IceDove is is that it has one single uniform interface to most of the PIM needs. I can use the same window and the same interface for all my rss feeds, my emails and my leafnode newsgroups. That has a big benefit in itself. I have only 1 integrated interface to look at and only 1 interactive method to learn. There aren't different keystrokes for different applications. All is one in IceDove. And I think one of the main reasons for Mozilla's success is its plugin architecture. It is very difficult to satisfy everyone's needs. In the same way, it is very difficult for one group of developer's to be able to innovate differently. This is where Mozilla rocked. They provided a solid foundation with basic standard interface and let new fresh minds to do the rest of the innovation. Turns out it has worked well. So, with my PIM needs satisfied, I thought KDE was serving as nothing but just a mere shell. So, now was the right time to do the thing I always thought of doing. Switch to GNOME. GNOME looks elegant at first look but that is it. I wanted to take a screenshot of an application to report a bug. I fired up PrntSc key to let the screen capture utility pop-up. It did not have the opiton to select just the application window. Hmmm! Time to return back to KDE and use the Mozilla PIM suite and hope the KDE PIM team learns and does the right thing.

I ve just read the Wikipedia page about Unparliamentary Language [1]. I recommend that everyone read it, if only for the amusement value, among other things it links to incidents where elected representatives acted in a way that would be expected of primary school children. The general concept of having rules about Unparliamentary Language is that MPs are permitted to say anything in Parliament without the risk of being sued or prosecuted, but certain things are inappropriate the most common example is directly accusing another MP of lying. One of the main aims of rules against Unparliamentary Language is to prevent attacks on the honor of another member. Having just witnessed a mailing list discussion go widely off track when a free software project was denigrated, it seems to me that we could do with some similar guidelines for mailing list discussions. The aim would be not to just prevent excessive attacks on the honor of other members but to also protect the honor of the free software projects. So for example one might recommend not using a particular program because of design decisions which seem dubious or a bad security history, but saying it s crap would be considered to be inappropriate. Not that rejecting a program based on design decisions or a history of security flaws would be uncontroversial, but at least that gives objective issues to discuss so if there is a debate it will educate some of the lurkers. Note that I m not claiming to be better than other people in this regard, I ve described software as crap on more than a few occasions. But I will try to avoid such things in future. Finally does anyone have a good suggestion for a Free Software equivalent to the term Unparliamentary Language ? It seems that to a large extent the support of certain ideas depends on having a catchy name and I can t think of one.

• [1] http://en.wikipedia.org/wiki/Unparliamentary_language

In the comments of the article explaining how to generate different dependencies on Debian and Ubuntu with a common source package, I got asked if it was possible to apply a patch only in some distribution. And indeed it is. The source package format 3.0 (quilt) has a neat feature for this. Instead of unconditionally using debian/patches/series to look up patches, dpkg-source first tries to use debian/patches/vendor.series (where vendor is ubuntu, debian, etc.). Note that dpkg-source does not stack patches from multiple series file, it uses a single series file, the first that exists. So what s the best way to use this? Debian should always provide debian/patches/series, they are supposed to provide the default set of patches to use. Any derivative cooperating with Debian can maintain their own series files within the common VCS repository used for package maintenance. They can drop Debian-specific patches (say branding patches for example), and they can add their own on top of the remaining Debian patches. It s worth noting that it s the job of the maintainers to keep both series files in sync when needed. dpkg-source offers no way to have stacked series files (or dependencies between them). If you want to use quilt to edit an alternate series file, you can temporarily set the QUILT_SERIES environment variable to vendor.series . Just make sure to start from a clean state, i.e. no patches applied. Otherwise quilt will be confused by the sudden mismatch between the series file and its internal data (stored in the .pc directory).

Found it useful? Click here to see how you can encourage me to provide more articles like this one.

No comment Support my work

Using the apt-xapian-index catalogedtime plugin apt-xapian-index has recently gained a catalogedtime plugin, which stores the timestamp of when the package was first cataloged. At first glance this does not mean much, so I'll explain with an example. aptitude can show a list of "New Packages": those packages that it sees now for the first time. It is a very useful feature, but you cannot ask it "what packages became available during last week?" With the catalogedtime plugin, the apt xapian index can now answer that question. You can also sort package results by "newness", or implement a user interface with some sort of "newness timeline" package filter option. Of course you will find documentation about it in /var/lib/apt-xapian-index/README, since the index is self-documenting. As usual in my apt-xapian-index posts, here is a code example:

#!/usr/bin/python
# coding: utf-8
# Show packages that were NEW in the last N days
# (C) 2010 Enrico Zini <enrico@enricozini.org>
# License: WTFPL version 2 (http://sam.zoy.org/wtfpl/)
import axi
import xapian
import time
import sys
class App:
    def __init__(self, days):
        self.db = xapian.Database(axi.XAPIANINDEX)
        # Read the contents of /var/lib/apt-xapian-index/values
        self.values, self.descs = axi.readValueDB()
        # Find the value ID for the catalogedtime timestamps
        self.cattime_vid = self.values["catalogedtime"]
        # Filter packages first seen more than than X days ago
        self.query = xapian.Query(xapian.Query.OP_VALUE_GE, self.cattime_vid,
                    xapian.sortable_serialise(time.time() - 86400*days))
    def main(self):
        # Perform the query
        self.enquire = xapian.Enquire(self.db)
        self.enquire.set_query(self.query)
        # Sort by cataloged time
        self.enquire.set_sort_by_value(self.cattime_vid, True)
        # Print the first 200
        matches = self.enquire.get_mset(0, 200)
        for m in matches:
            name = m.document.get_data()
            val = m.document.get_value(self.cattime_vid)
            fval = xapian.sortable_unserialise(val)
            tm = time.localtime(fval)
            timestr = time.strftime("%c", tm)
            print "%s %s" % (timestr, name)
if __name__ == "__main__":
    try:
        days = int(sys.argv[1])
    except:
        print >>sys.stderr, "Usage: %s days" % sys.argv[0]
        sys.exit(1)
    app = App(days)
    app.main()
    sys.exit(0)

Enjoy!

Story I bought Xperia X10i this summer during DebConf10 in NYC, I loved this phone from very beginning however what bothered me was that it was still stuck on outdated Android 1.6. To get your own custom Android on it, wasn t quite possible because no one managed to hack bootloader even though some of the guys at XDA where getting pretty close. Long story made short, Sony Ericsson has finally release their Android 2.1 update, but made it available only for Nordic region, they explained it all on their blog where they also sent a message for paranoid users as they called them. I thought, if I gave it all this time I can wait a little bit longer, but then one of my friends (@sahinovic) gave me a good pointer to go in right direction with using custom ROM, Nordic for example? So this is where I got my idea. I want 2.1 update now! Please note steps below will get you Android 2.1 update, but AFAIK you ll also lose your warranty 1. Root your phone If you don t have your phone rooted, this can now be done in single click. Get X10 Root and follow instructions on screen. 2. Edit system/default.prop Get Root Explorer, mount r/w (upper right corner), edit system/default.prop Lines you re concentrating on are 1 and 3 Let s say they are:

ro.semc.version.cust=1237-0333
ro.product.name=X10_1237-0333

Edit them to look like:

ro.semc.version.cust=1234-8465
ro.product.name=X10_1234-8465

Save the file and it s gonna create automatic backup of original file. 3. Get the updates using SEUS Turn off your phone, launch SEUS, plugin in the USB cable while holding back button, SEUS is going to tell you have updates for your phone Follow on screen instructions. Enjoy the update Conclusion X10 is a pretty sweet phone, but with it being so closed, it also closes a lot of doors to hacking it and playing with it, great example would be this update itself, since right now Android 2.1 update is an outdated one. However 2.1 update brings new life into it, just as it s a brand new phone, it s more responsive and much much faster. And do take a backup before this update, because I lost everything from my contacts to internet settings, but all files on my sd card remained intact. If you want to discuss anything regarding this topic please do so in comment area below or find me on Twitter.

So, I m (almost) back from the first edition of MiniDebConf Paris, which was a success thanks to the great organizing skills in panic mode of Carl Chenet and Mehdi Dogguy. I think that everybody is already looking forward to the next edition. I met lots of people, and it was great to be able to finally put faces on names from the french free software community. I gave two talk there, the first one on Debian and Ubuntu (slides), the second one on Debian Quality Assurance (slides), which both went well (I think). I also hacked a bit:

• I added tags and claimed by to UDD Bugs Search.
• I worked on my piuparts replacement (which really needs a sexy name ; I m open to suggestions), processing the results, making some improvements to the script, and filing 16 RC bugs.

If you want to help me, here are some easy tasks that need takers (it s unlikely that I ll be able to tackle them anytime soon):

• One missing thing in UDD Bugs Search is information about the deferred/delayed queue. Unfortunately, the ftp-masters status information is not available in a machine-parseable format.
  • Improve dak code to also export the data in a machine-parseable format (JSON, YAML). I was told the changes are to be done in dak/show_deferred.py.
  • Write the corresponding UDD importer (actually, that s a 30 mins job for me, so I could easily find time to do it if the data was available).
  Update: done!
• Another missing thing is comments (as on bts.turzimmer.net). I don t really have good ideas about how to implement them, so if you want to tackle that with your own idea, go ahead. (It s probably easy to setup a copy of bugs.cgi on alioth if you are not a DD). The CGI is in Ruby.
• Help me process the logs of my piuparts replacement, and file the bugs. I don t have any good scripts to automate bug filings yet. You need a good understanding of packages dependencies and maintainers scripts, but it s a good way to learn, too. (I would need to regenerate the full results first, so talk to me if you are interested)

One of the other things I d like to do is discuss ways to improve the synchronization of UDD (currently, it s synchronized at arbitrary times, while we could sync Sources+Packages just after dinstall, for example).

There is something fishy with the latest "printer bomb" reports. One one hand, they claim the parcels were adressed to "jewish synagogues in Chicago". On the other hand, they claim they were meant to explode in the air. So: why would you address them to a synagogue then? Sending a parcel from Jemen to a synagogue probably is a sure thing to have it thoroughly checked? I don't trust any of their reports. Don't get me wrong; for example I do not believe the WTC was blown up using explosives like most of the conspiration theorists out there do. But they are not telling the truth with these parcels, either. Also given that they claimed there were way over 20 parcels sent, and the security was that weak, how come all of them were found? When they decide to make up a story for us (either for having a reason to kill more people in Jemen or just for election reasons) they should at least bother to make up a consistent story ...

I switched to git from mercurial about two years ago. See here why I switched and here my experience after 4 months. Back then I was unsure, whether git will win, but I thought it has a bigger momentum. Well, I think that now it's quite clear that git has already won. Pretty much everybody that I collaborate with is using git now.

I use github everyday, and now thanks to github pull requests, I think it's the best collaboration platform out there (compared to Google Code, Sourceforge, Bitbucket or Launchpad).

I think it's partly because the github guys have a clear vision of what has to be done in order to make collaboration more easier and they do it, but more importantly that git branches is the way to go, as well as other git features, that are "right" from the beginning (branches, interactive rebase, and so on), while other VCS like bzr and mercurial simply either don't have them, or are getting them, but it's hard to get used to it (for example mercurial uses the "mercurial queues", and I think that is the totally wrong approach to things).

Anyway, this is just my own personal opinion. I'll be happy to discuss it in the comments, if you disagree.

Today I forgetfully left my USB drive at home when I took off for a night at the yurt. This has happened before and generally involves staring at an scp for rather too long, probably getting low on battery power in the process, and is followed by not quite having files in the places I expect and forgetting to delete them from my small laptop SSD later. With git-annex those annoyances can go away. So I wanted a couple of gigabytes of files that were left at home behind a slightly slow link. Rather than scp them to my laptop for several hours, I just did a quick ssh into a server, and browsed through my stuff there, running git annex get $foo & on files and directories I wanted. Then went to eat dinner and play board games while the content was scped across the slow link from home. Now I can quickly download it all to my laptop from that fast server (named "finch"), like this:

git pull
git annex move . --from finch

That removes the data from the server too, freeing its space back up for next time. And the files are in their regular places on my laptop, automatically. And I can simply git annex drop . when I need that space back without worrying about losing any data. (Hmm, this feels a little bit like it did to switch from doing everything by hand with dpkg to using apt-get..)