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.

The bug webinterface of the Universal Debian Database currently knows about the following release critical bugs:

In Total:	679
Affecting Squeeze:	261
Squeeze only:	56
Remaining to be fixed in Squeeze:	205

Of these 205 bugs, the following tags are set:

Pending in Squeeze:	17
Patched in Squeeze:	41
Duplicates in Squeeze:	23
Can be fixed in a security Update:	12
Contrib or non-free in Squeeze:	6
Otherwise fixed in Squeeze:	21

Ignoring all the above (multiple tags possible), 126 bugs need to be fixed by Debian Contributors to get Debian 6.0 Squeeze released. However, with the view of the Release Managers, 165 need to be dealt with for the release to happen. Please see Interpreting the release critical bug statistics for an explanation of the different numbers.

In my professional role as Ubuntu CTO, I take on a number of different perspectives, which sometimes compete for my attention, including:

• Inward supporting the people in my department, alignment with other departments in Canonical and reporting upward
• Outward connecting with customers, partners and the free software community, including Debian
• Forward considering the future of the Ubuntu platform and products, based on the needs of their users, our customers and business stakeholders within Canonical
• Outside-in taking off my Canonical hat and putting on an Ubuntu hat, and looking at what we re doing from an outside perspective

My recent work, as Canonical has gone through a period of organizational growth and change, has prioritized the inward perspective. I took on a six-month project which was inwardly focused, temporarily handing off many of my day-to-day responsibilities (well done, Robbie!). I ve grappled with an assortment of growing pains as many new people joined Canonical over the past year. With that work behind me, it s time to rebalance myself and focus more outside of Canonical again. It s good to be back! In my outward facing capacity, I ll shortly be attending Web 2.0 Summit in San Francisco. I attend several free software conferences each year, but this is a different crowd. I hope to renew some old ties, form some new ones, and generally derive inspiration from the people and organizations represented there. Being in the San Francisco Bay area will also give me an opportunity to meet with some of Canonical s partners there, as well as friends and acquaintances from the free software community. With my head down, working hard to make things happen, it s easy to lose perspective on how that work fits into the outside world. Spending more time with people outside of Canonical and Ubuntu is an important way of balancing that effect. Looking forward, I ll be thinking about the longer term direction for the Ubuntu platform. The platform is the layer of Ubuntu which makes everything else possible: it s how we weave together products like Desktop Edition and Server Edition, and it s what developers target when they write applications. Behind the user interfaces and applications, there is a rich platform of tools and services which link it all together. It s in this aspect of Ubuntu that I ll be investing my time in research, experimentation and imagination. This includes considering how we package and distribute software, how we adapt to technological shifts, and highlighting opportunities to cooperate with other open source projects. My primary outside-in role is as chair of the Ubuntu Technical Board. In this capacity, I m accountable to the Ubuntu project, the interests of its members, and the people who use the software we provide. Originally, the TB was closely involved with a range of front-line technical decisions in Ubuntu, but today, there are strong, autonomous teams in place for the most active parts of the project, so we only get involved when there is a problem, or if a technical question comes up which doesn t fit the charter of an established team. It s something of a catch-all. I d like to re-establish the TB in a more central role in Ubuntu, looking after concerns which affect the project as a whole, such as transparency and development processes. I m also re-joining Debian as a non-uploading contributor, to work on stimulating and coordinating cooperation between Debian and Ubuntu. I m looking forward to working more with Zack on joint projects in this area. This change will help me to support Canonical and Ubuntu more effectively as they continue to grow and change. I look forward to exercising some mental muscles I haven t used very much lately, and facing some new challenges as well.

I decided recently to publish interviews from Debian contributors and I picked Joey Hess as my first target. He s one of the few who have heavily influenced Debian by creating software that have become building blocks of the project, like the debian-installer (Joey uses the shorthand d-i to refer to it). My questions are in bold, the rest is by Joey (except for the additional information that I inserted in italics). Who are you? Hello, I m Joey Hess. I m one of the oldtimers in Debian. Actually, I just checked, and there are still up to nineteen active Debian Developers who joined the project before I did, in 1996. I got started fairly young, and am just 34 years old. I spend part of my time working with Lars Wirzenius, another Debian oldtimer, on Branchable. It makes it dead-easy for anyone to make a website that is built from Git, using my Ikiwiki engine to do wiki and blog style things. These days I spend the rest of my time working on free software, when I should really be looking for work to pay the bills. What s your biggest achievement within Debian or Ubuntu? I guess I m mostly known by Debian developers for writing debhelper and perhaps debconf. Probably founding the Debian Installer project has been a bigger impact for users. I m fairly equally proud of all three projects. But while it might sound corny, I am more proud of the accumulation of all the smaller things done in the context of Debian. It s more of a deep connection to the project. All the bugs fixed, and filed, and packages uploaded, and late night discussions, and just being a part of the larger project. What are your plans for Debian Wheezy? Hmm, I stopped thinking of Debian releases by code names back around Slink. So, few specific plans for Wheezy. The main thing I would like to help make happen in Debian next is Constantly Usable Testing, and it transcends releases anyway. The only specific plans I have for Wheezy are that there will probably be a new debhelper compat level, and I hope d-i will finally switch to using git. RH: You can learn more about Constantly Usable Testing in my article Can Debian offer a Constantly Usable Testing distribution?. If you could spend all your time on Debian, what would you work on? Getting Debian on all these computers that we carry around in our pockets and can t easily run apt-get on and hack on. Phones that is. It s a bigger problem than just Debian, but I think Debian needs to find a way to be part of the eventual solution. The FreedomBox concept at least hints at a way around the current situation with embedded computers in general. What s the biggest problem of Debian? I believe that the biggest problem is institutional, social and technological inertia. Every specific case of something that frustrates me about Debian today can be traced back to that. You contribute regularly to Debian mailing lists, yet I don t remember any aggressive/frustrated mail of you. How do you manage that? Are you avoiding heated discussions? Rats, sounds like all my wonderful flames of years past have been forgotten! Seriously though, after I noticed thread patterns, I started trying to avoid participating in the bad patterns myself. Now I limit myself to one expression of an opinion, and I don t care who gets the last word. If people can t be convinced, it s time to find another approach to the problem. Also, code talks. Most of the programs you wrote for Debian are in Perl. Do you regret this choice? I love that question! No, no regrets. My only concern is whether the language limits contributors or users. I have not seen Perl significantly limiting the use of anything except for debconf (we had to rewrite it in C for d-i). And I do not notice fewer contributions to my Perl-based code than to other code. I do sometimes regret when someone tells me they had to learn or re-learn Perl to work on something I wrote. But while I m enjoying writing new things in Haskell now, and while I hope it will mean less maintenance burden later, I don t think using Haskell will make it easier for others to contribute to my programs. Anyway, for me the interesting thing about writing a program is the problem it solves and the decisions made doing it. Choice of language is one of the less interesting decisions. Is there someone in Debian that you admire for his contributions? Well, lots. You re tempting me to throw a dart at a map. So arbitrarily, I ll say Anthony Towns. We could all learn something from how he s approached making big, fundamental changes, like introducing Testing, and making Debian Maintainers happen.

---

Thank you to Joey for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Subscribe to my newsletter and don t miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook. PS: If you want to suggest me someone to interview, leave a comment or mail me.

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

It seems like VServer is not something for long run because it does not seem to want to be upstream and there is also no good future for having it as patch in Debian for long run. So I should look for alternatives and probably migrate to some other solution while upgrading my server to Squeeze (once it is released or really close to the release). There are various options, starting with OpenVZ, through Linux Containers (LXC) up to full virtualization (probably KVM based). With OpenVZ the situation won't be much better, so it is not a real option. For various reasons I don't want to go to full virtualization, I simply thing containers are good enough and avoid too much overhead in some situations. So the only remaining solution seems to be LXC. There even seem to be some people who managed to migrate from VServer, which is good and will be definitely helpful. Now it's time to play with lxc a bit before I will try to implement it for real.

Filed under: Linux 4 comments Flattr this!

If you want to see a really big Google Calendar, check out this calendar. Essentially, it is all the events from over 100 other calendars (all containing swing dancing events) merged into one, resulting in often more than 50 events every day, occasionally over 20 at the same time). The data is approximately the same that can be seen on this map; in fact I'm trying to move the data keeping from a custom database (which has superior filtering capabilities such as synonyms in text search) to just having Google keep the data for me (meaning it will eventually not require me to have an own web server for this). I'm doing some filtering such as removing events that don't have parseable geo information (I'm adding GeoRSS:where elements, in fact), some text to html conversion of the entry contents and filtering out inappropriate events via some regular expressions (e.g. only including "Swing" not "Ballroom" events from a calendar) There are still a couple of things to resolve. I'm not sure that recurrence exceptions are propagated properly to the combined calendar; the updates could work more incrementally, and I have to resolve some timezone issues due to the global nature of the calendar: I need to make sure the timezone information is preserved, since usually it makes more sense to give the events in local (to the event) time. P.S. sorry, the code is too specialized and needs cleanup, I won't share it yet.

I wrote yesterday about our scare with Jacob. It s been quite the day. Before I go into it, I want to say thank you to all the many of you that have sent comments and support our way. Terah and I haven t had the chance to reply to many of them, but we have read every one, and very much appreciate it! Terah spent the night with Jacob, and I spent the day with him today (others were present for parts of it too). Jacob was mostly in good spirits. He was up and around, pushed his IV around himself in the room and to the bathroom. He called it my VI machine (not a typo take that, Emacs, eh?) He continued to enjoy measuring his trips to the bathroom. We went exploring a few times. He would walk or run down one of the long corridors in the hospital, holding my hand, while I pulled the IV along. We often went by the cafeteria, which he called the kitchen. One time he insisted that I get a cup of coffee from the free coffee dispenser. I insisted that I didn t want to, but eventually asked, Shall I get a pretend cup of coffee? Yeah! So he watched me get a pretend cup, pretend to fill it, and pretend to drink it and smiled and clapped for me after. He spent hours watching videos of trains on YouTube. This is a favorite activity at home too, but we obviously limit the amount of time he can spend doing it. I had to limit the amount of time he spent with it today too, of course, but he got rather more time with it than usual. Jacob had his usual books, but I thought we might try something new today. This morning, I loaded The Tale of Peter Rabbit (with illustrations) onto my Kindle. Jacob loved it, and enjoyed pressing the Next Page button in the Kindle. We read it twice, and he is interested by the promise of other stories about rabbits. It also probably didn t hurt that his grandma had given him a rabbit in the hospital yesterday. As we got on towards evening, I told him that tomorrow could be a normal day. His response: enthusiastic applause and a big grin, plus YAY! Jacob loved eating today. He wolfed down breakfast and lunch. He enjoyed the lemonade I brought for him again, and played with some toys, and yes, watched some more train videos in the afternoon. He also pretended to ignore the visitors he got as much as possible (pretty typical for him actually). The doctor came by at about 6:00PM and again was just stunned at how well he s doing. Jacob neither complained of any pain nor acted like he had any even when the nurses would rub neosporin on his wounds. The doctor was still just stunned at how well he was doing. He told us his last tractor accident resulted in a death before LifeWatch could arrive, and the one before that turned a good student and a promising athlete into a wheelchair-bound person with a vocabulary of 20 words. I can t believe I m discharging him today, but try as I might, as I go over all the details, there s no reason for him to stay. I thanked him for all his help, and he said, I didn t do anything for him. All I did was figure out what had happened to him . I guess we have the CT to prove that something really did happen, but the fact that he showed up at my office in the first place was stunning enough. Jacob started to get more excited after the IV was unhooked from him. He didn t particularly like having the needle removed, due to the pain of taking off the tape, but was happy to have it gone. He was making plans: will we stop by the train station on the way home? It s the middle of the night maybe a train will be there! (If it s dark outside, it s middle of the night to him) We agreed to stop by the cafeteria to pick him up one last lemonade, than stop at the train station. The nurses offered a wheelchair to take him out to the car with. I said I didn t think he d want it. One of them said, Wouldn t you like a FUN ride in a WHEELCHAIR? Jacob: No. Me: I suspect he will want to run out of here. Nurse: OK then. We walked, or half ran, to the cafeteria to get his lemonade. Then we went out to the car. He was excitedly jabbering about everything: the car, my radio, and especially the train station. We did drive by, and at least got to see a freight engine go past. He noticed the Christmas lights starting to be set out along Main Street, and said, Dad, it s CHRISTMAS! Well, almost Then he got quiet, and eventually fell asleep in the car. He had almost fallen asleep while eating his lunch, but stayed awake, and then got interested in other things so he had no nap today. When we got home, I unbuckled him and pulled him out of his seat. He opened his eyes for just a second, wrapped his arms tightly around my neck, put his head on my shoulder, and fell back asleep while I carried him up to his room. I put him down on his own bed. He had a contented sigh, pulled his favorite blanket up to his neck like he loves to do, and was back asleep in no time. Our little boy is home, safe and sound. It s a happy day.

A few months after starting the NM process, I have just been accepted as a Debian Developer. My account name is simply: julien I have been a Debian user for about 10 years now, and have begun contributing to Debian in 2005. I have then been accepted as a Debian Maintainer in 2007. This post is mainly to thank:

• all my sponsors: Christoph Haas (haas) , Lo c Minier (lool), Free Ekanayaka (freee), Maximiliano Curia (maxy) and Micah Anderson (micah),
• my advocate: Matthijs M hlman (matthijs)
• my AM (who actually make it happen in a really short time frame, thanks a lot to him): Xavier Oswald (xoswald)
• all people who helped me during the process, to name a few: Christoph Berg (myon), Enrio Zini (enrico), Peter Palfrader (weasel)

Also thanks to all people who have already sent their congratulations, it makes me very proud!

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.

Last week, I worked on my Google Maps for Emacs extension. I've introduced a new format handling for locations which include the longitude and latitude. The initial format was just a string describing the location, which was obviously too limited. It now prints coordinates of the different elements when the mouse is over the map, with other information. It also center the map on M-x google-maps and set a default zoom level. This is something which was not set because it's not a good idea to set center coordinates in order to see all points on the map automatically. But you can still remove the centering by pressing "C". On the other hand, setting it automatically allows to move the map easily, and I think that what most users want to do. I've also added a "place my home on the map" feature, accessible by pressing "h" on any map. That adds a marker according to the location set in Emacs using the calendar- variables. This feature is also available under Org by pressing C-u C-c M-l, which shows the location of your appointment with your home on the map too. Finally, you also get caching so it does not request images you already seen, which makes the moving nicer and faster to use, and prompt history.

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.

You re probably manipulating Debian packages everyday, but do you know what those files are? This article will show you their bowels Surely they are more than file archives otherwise we would just use TAR archives (you know those files ending with .tar.gz). Let s have a look! 1. It s two TAR file archives in an AR file archive! A .deb file is actually an archive using the AR format, you can manipulate it with the ar command. This archive contains 3 files, you can check it yourself, download any .deb file and run ar t on it:

$ ar t gwibber_2.31.91-1_all.deb
debian-binary
control.tar.gz
data.tar.gz

debian-binary is a text file indicating the version of the format of the .deb file, the current version is 2.0 .

$ ar p gwibber_2.31.91-1_all.deb debian-binary
2.0

data.tar.gz contains the real files of the package, the content of that archive gets installed in your root directory when you run dpkg --unpack . But the most interesting part which truly makes .deb files more than a file archive is the last file. control.tar.gz contains meta-information used by the package manager. What are they?

$ ar p gwibber_2.31.91-1_all.deb control.tar.gz   tar tzf -
./
./postinst
./prerm
./preinst
./postrm
./conffiles
./md5sums
./control

2. It contains meta-information defining the package and its relationships The control file within the control.tar.gz archive is the most fundamental file. It contains basic information about the package like its name, its version, its description, the architecture it runs on, who is maintaining it and so on. It also contains dependency fields so that the package manager can ensure that everything needed by the package is installed before-hand. If you want to learn more about those fields, you can check Binary control files in the Debian Policy. Those information end up in /var/lib/dpkg/status once the package is installed. 3. It contains maintainer scripts so that everything can just work out of the box At various steps of the installation/upgrade/removal process, dpkg is executing the maintainer scripts provided by the package:

• postinst: after installation
• preinst: before installation
• postrm: after removal
• prerm: before removal

Note that this description is largely simplified. In fact the scripts are executed on many other occasions with different parameters. There s an entire chapter of the Debian Policy dedicated to this topic. But you might find this wiki page easier to grasp: http://wiki.debian.org/MaintainerScripts. While this looks scary, it s a very important feature. It s required to cope with non-backwards compatible upgrades, to provide automatic configuration, to create system users on the fly, etc. 4. Configuration files are special files Unpacking a file archive overwrites the previous version of the files. This is the desired behavior when you upgrade a package, except for configuration files. You prefer not to loose your customizations, don t you? That s why packages can list configuration files in the conffiles file provided by control.tar.gz. That way dpkg will deal with them in a special way. 5. You can always add new meta-information And in fact many tools already exploit the possibility to provide supplementary files in control.tar.gz:

• debsums use the md5sums file to ensure no files were accidentally modified
• dpkg-shlibdeps uses shlibs and symbols files to generate dependencies on libraries
• debconf uses config scripts to collect configuration information from the user

Once installed, those files are kept by dpkg in /var/lib/dpkg/info/package.* along with maintainer scripts.

If you want to read more articles like this one, click here to subscribe to my free newsletter. You can also follow me on Identi.ca, Twitter and Facebook.

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

When doing porter uploads, one must not forget to pass -m"My Name <my@email.addr>" to dpkg-buildpackage, e.g. with --debbuildopts for cowbuilder. Thanks Aur lien and sorry to everyone who got the upload mails. (How are the rules for sponsored uploads? I get conflicting info on these, and indeed, the one I sponsored never showed up on my QA DDPO page )

Debian mailing lists' standard policy is to allow posts from unsubscribed users. That of course fits our standards for opened development but has the drawback of allowing a lot of spam to reach our mailing lists. This spam also clutters the mailing lists archives. However, 1.5 years ago, listmasters established a well-working system to clean out spam from the mailing lists. It basically works in four steps:

1. first, spam can be "reported" by anyone meeting it. While you are reading the mailing lists, reporting spam is as simple as bouncing the offending mail to a dedicated address: report-listspam@lists.debian.org. I, for instance, use a mutt macro to set ESC-L as a "report spam" hotkey. Spam can also be reported when browsing the mailing lists archives and clicking on the "Report as spam" button;
2. when a given mail has been reported as spam more than five times, it is then "nominated" for review;
3. nominated mails must the be reviewed by volunteers in order to confirm they really are spam. The review algorithm is complex but, in short, when a mail has been confirmed as spam by 3 reviewers without being qualified as "ham" by anyone else, then it is considered spam;
4. such mails are then removed from the mailing lists archives.

Steps 2 and 4 are performed by a weekly script that runs on Sunday mornings (5:00 UTC, IIRC) How can you help? Process nominated spam We need more reviewers for step 3. At this moment 2 people are doing this on a regular basis (every Sunday with the morning coffee). Some others are working on this in a less frequent way. It seems that 1 or 2 more regulars reviewers would guarantee that we can cope with the nominated spam incoming flow. Only Debian developers can do that step. They should read instructions, ask for a password, then start reviewing. The first 1 or 2 people joining this will have a quite big amount of nominated spam to process, for their first effort. However, as most of these have been classified as spam by at least the two people doing this for months....the amount will slowly decrease. I, for instance, now only spend 5-10 minutes reviewing the nominated mails every week. Report spam Everybody can work on reporting spam. You can start by doing this on mailing lists you read by just bouncing spams to the spam report address; If you want to do more, you can join existing spam cleaning efforts, such as the one running for debian-boot or the one running in debian-l10n-french (the latter probably more for French speakers). Or you can of course start a similar effort for your pet list. To be efficient, this effort needs to gather 5-6 people who will process the mailing lists archives systematically. Let's clean out these archives!

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.

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

The bug webinterface of the Universal Debian Database currently knows about the following release critical bugs:

In Total:	664
Affecting Squeeze:	261
Squeeze only:	60
Remaining to be fixed in Squeeze:	201

Of these 201 bugs, the following tags are set:

Pending in Squeeze:	8
Patched in Squeeze:	34
Duplicates in Squeeze:	22
Can be fixed in a security Update:	12
Contrib or non-free in Squeeze:	8
Otherwise fixed in Squeeze:	21

Ignoring all the above (multiple tags possible), 127 bugs need to be fixed by Debian Contributors to get Debian 6.0 Squeeze released. However, with the view of the Release Managers, 160 need to be dealt with for the release to happen. Please see Interpreting the release critical bug statistics for an explanation of the different numbers.

My latest patch for Org mode has been accepted by Carsten today. It adds support for custom category icons in all views, like agenda or todo. You just need to configure org-agenda-category-icon-alist and it will work out of the box.

Today, Zoe is six months old. The last three months certainly feel like they've taken their time, but a lot has happened. Developmentally, she's doing great. She's now in the 70th percentile for height (up from around the 25th percentile), and 31st percentile for weight (up from the 25th percentile). She cut her bottom front teeth a few days ago. Crawling is imminent, I'd say. She can already scoot around in reverse, and by a combination of shuffling and rolling, doesn't seem to be having problems moving around the floor. We started her on solids at five months, and she's taken like a duck to water to pureed pumpkin, sweet potato, beans, zucchini, apple, pear, banana and avocado. Speaking of water, she's also decided she likes to drink water from our glasses whenever she sees us doing it. Hilarity usually ensues, closely followed by a change of outfit. She's sleeping well, only waking up once a night under normal circumstances, and that wake-up is getting later and later. She loves her baths. She usually lets out a series of loud sighs as soon as we put her in the bath. She got her first cold a couple of weeks ago. It coincided with her first day in ad hoc daycare, but Sarah and I were both sick as well, so I think it's more likely that she caught the cold from us than from daycare. She's still battling it, but it hasn't really bothered her all that much. She's just a bit snotty. The NoseFrida has been very handy for dealing with this. She had her six month shots today, and seems to be tolerating them fairly well. Sarah says she hardly even cried when she got them. She continues to be a remarkably happy baby. She always wakes up with a smile, she really only fusses if we keep here away for more than a couple of hours, or haven't fed her on time. Even with this current cold she has, she's still stayed very happy. We feel incredibly lucky to have such a wonderful baby. The next big adventure is to try a babysitter.