Continuing my earlier musings about test driven distro development, and the tools that would require. I imagine something like this:

• create a virtual machine with a particular configuration of stable
• run a test suite verifying the VM works
• upgrade the VM to testing and reboot
• re-run test suite, verifying things work in testing

We might also want this scenario:

• install testing directly in a VM (instead of upgrading from stable)
• run test suite

There might be other scenarios that would be useful to test as well. Even from these two, it's clear there's a need for at least three separate tools:

• create a machine image with a particular configuration
  • might be based on stable or testing or unstable
  • might also be using some other package sources
  • might want particular packages installed
  • might want particular configuration settings
• run a suite of tests against the running image
  • which tests to run will depend on the scenario
• run various scenarios using the above two tools
  • needs reasonably easy ways to specify scenarios
  • needs to support tests specific to scenarios

I've written a rudimentary version of the first tool: vmdebootstrap. I've since learned there's a bunch of others that might also work. There's room for more: someone should write (or find) a tool to make a snapshot of a real system and create a VM image that mimicks it, for example. Anyway, for now, I'll assume that one of the existing tools is good enough to get started. For the second tool, I wrote a quick-and-dirty proof-of-concept thing, see systest.py. Here's a sample of how it might be used:

liw@havelock$ ./systest -v --target 192.168.122.139 --user tomjon
test 1/6: cat
test 2/6: only-ssh-port
ERROR: Assertion failed: ['22/tcp', '139/tcp', '445/tcp'] != ['22/tcp']
[status 1]
liw@havelock$ ./systest -v --target 192.168.122.139 --user tomjon \
    cat ping6-localhost ping-localhost simple-dns-lookup ssh-login
test 1/5: cat
test 2/5: ping6-localhost
test 3/5: ping-localhost
test 4/5: simple-dns-lookup
test 5/5: ssh-login
liw@havelock$ 

The first run failed, because the VM I'm testing against has some extra ports open. Some of the tests will require logging into the machine, via ssh, and for that one needs to specify the user to use. systool may overlap heavily on system monitoring tools, and possibly the production implementation should be based on those. I think it's best to design such a tool for the more general purpose of testing whether a system currently works rather than as an integrated part of a more specific larger tool. This lets the tool be useful for other things than just testing specific things about Debian. (The production implementation would then need to not have all the tests hardcoded, of course. SMOP.) The third tool I have not spent a lot of time on yet. One thing at a time. Given these tools, one would then need to decide how to use them. The easiest way would be to use them like lintian and piuparts: run them frequently on whatever packages happen to be in testing or unstable or experimental, and put links to the test reports to the PTS, and hope that people fix things. That is the easiest way to start things. Once there's a nice set of test cases and scenarios, it may be interesting to think about more aggressive ways: for example, preventing packages from migrating to testing unless the test suite passes with them. If the tests do not pass, one of four things is broken:

• the package or packages in question
• other packages already in testing
• the tests themselves
• the test environment

If things are set up properly, the last one should be rare. The other three always require manual inspection: it is not possible to automatically know whether the test itself, or the code it tests, is at fault. it is, however, enough to know that something is wrong. If the tests are written well, they should be robust enough to not be the culprits very often. (Someone wanting to make a rolling distrbution, or even better, making a monthly mini-release, might benefit from this sort of automated testing.)

As usual many people requested travel sponsorship to attend DebConf 11 and are now waiting eagerly on the outcome of their request. We are sorry, that we can t give you much details yet. To give you an idea of the time line, here is a small explanation of the process. About 100 people requested travel sponsorship. In total that would about 50 000 Euro. Problem is currently we don t exactly know, how much money we may spend on travel sponsorship ourselves (By the way: If a potential sponsor is reading this, please contact us; DebConf also accepts donations). So, we formed a team of 13 persons (the mail only lists twelve, one was added later). The team members will start to rate each and every single request in two criteria: Contributor Level and sponsorship amount. With limited amounts we obviously want to sponsor those first, who contribute a lot to Debian, preferably if they don t travel first class. After that s done, we ll have a long, but ordered list, but the team still needs to meet and discuss different cases and similar. Our team isn t really small and consists of people living all over the world, it s quite hard to actually schedule a meeting everyone can attend. (Which is not a bug, but a feature: More people from more countries should in the end result in a fair rating of the sponsorship requests.) So, in the end, we ll meet on 19th of June. Sounds late, please keep in mind, that every team member has to rate all sponsorship requests (including some research) and all of them are volunteers with actual daytime jobs. But even if you don t hear anything from us short after that date, don t panic! As said we really don t know, yet, how much money we can spend on travel sponsorship. Our sponsor-hunting-team is constantly working on the acquisition of more money, so every now and then the budget for travel sponsorship gets increased, meaning that we can mail a couple of more people on our ordered list. So it might take a while, till we get to all, but we try very hard to do so.

I m just back from spending a few days volunteering with the tornado recovery effort in Joplin, MO. The biggest image that remains in my mind is of the first time I saw a person picking through a large pile of rubble. The person was standing on top of what used to be a house. Now it was a pile of wood, glass, carpet, siding, and roofing material. I m sure there was hope for finding some treasure or other maybe a photo album or videos of children. In any case, it made me feel so lucky, even unfairly lucky, to have not had to go through that. This scene was repeated several times, but mostly the houses that devastated appeared abandoned by the time we were there, now two weeks after the event. But I heard stories, and lots of them. The victims of the storm, who were perhaps trying to rebuild that part of their house that got smashed by a tree or a pickup, or trying to get their intact belongings out before abandoning the house, or whatever, were mostly surprisingly upbeat. They were working out in 95-degree heat, many without electricity, running water, or sewer service. Almost every person I met that suffered a loss from the tornado wanted to tell their story. Many also told of their plans for the future, which were full of hope and even upbeat. These were people doing a hard job in terrible conditions and still showing hope. Another testament to the disaster was the most unusual set of vehicles you ve ever seen parked at any hotel you can care to think of, for at least an hour-and-a-half radius in the direction I came from. Besides the usual cars and minivans, there might be FEMA vehicles, electric company trucks, Red Cross vans, construction trucks of every kind, police and law enforcement from all over, etc. There was quite obviously an influx of people helping out in Joplin. My primary task there was to provide communications support for the effort as an amateur radio operator. Amateurs (or hams ) are something of a volunteer first responder of sorts during times of crisis; most of us own and are very familiar with operating equipment that can communicate over very long distances without the need for any on-site infrastructure. Amateur radio was the only method of communication for some Joplin hospitals in the immediate aftermath. The communications emergency is over, but the response isn t. I was assigned to work with the Salvation Army. They were doing a lot of things in Joplin, and had hundreds of volunteers working with them. I don t think I even know what many of them were doing I do know they had set up several warehouses across the city working with donating clothing, food, etc. The part I was involved with was primarily the canteen operation. The SA sent in food service trucks from several parts of the country. These trucks would roam up and down the streets in the damaged area, trying to get past every single street several times a day. Anybody that we could see would be offered food and water. No strings attached, no questions asked. This included homeowners, electric line workers, construction crews, sanitation workers, and quite a few nonprofit groups that sent well-meaning and useful volunteers into the area but didn t think to provide them with a large supply of water due to sending them into an area without any. Oops. In any case, with extreme heat and no running water, conditions were dangerous. The canteens also knew of certain at-risk families that were living in homes that were mostly intact in the disaster areas, and made a special point to check in on them. They also generally looked to make sure that people looked like they were healthy. Each canteen also had a counselor on board that would visit with people while we quickly prepared their meal they all seemed to welcome that. Amateur Radio s Role The operation of this size had quite a logistics challenge. I d hear of things like an unexpected need of 70 lunches, or a semi showing up with donations before there was space, or an unexpected but very welcome donation of a large quantity of ice cream without a place to store it (so the canteen trucks, which have freezers, needed to pick it up quickly). That s where us hams came in. Each canteen had an amateur radio operator on board. Each major location also had a ham stationed there, and the head of operations also often had a shadow a ham that would follow him around wherever he went to relay messages back and forth. We also had hams with pickups (with radios in them, of course) that could transport things around the city to places that needed them, hams at headquarters managing all the communication and generally investigating questions that didn t have immediately obvious answers, etc. Radios were used instead of cellphones for a few reasons. One big one is that everybody on the operation can hear what everyone else s needs are, since it s a group communications situation rather than one-to-one. It s easy to give a general alert to everyone ( come get your ice cream now please! ) and people that have suggestions can chime in. This came in extremely handy more than once. Also, it frees the people doing other jobs from having to spend time chasing someone s voicemail, finding phone numbers, etc; that gets delegated to us in some cases. I heard from the head of canteen operations, for whom this was the first disaster he d worked that had amateur radio support, how wonderful it was to have this going on. I also heard a secondhand report that some police officers that were also amateurs had listened to our operation and reported that we sound more professional than 911 dispatch and do a better job. On Sunday I was assigned to a canteen. This meant I didn t have a lot of radio traffic to pass, so although I had it in my ear all day, I wasn t actively talking on the radio very much. So I rode in back, helping hand out water, carry meals to people, and so forth. On Saturday, I was the shadow for the head of operations. That was a difficult task, because he barely ever moved at a pace slower than a run, sometimes would abruptly zip out somewhere, etc. But it was also enlightening and vital. He was a real get it done sort of guy, and was the key to quite a few things. Having someone available to relay questions to and from him was a good thing. And today I worked as a transport person and at headquarters. Due to not having a pickup there, I didn t actually get called on much to transport things, but in general between jobs the whole time I d act as a runner if needed, or simply try to figure out the details of how things were run for next time. I wound up taking net control (being the control operator at headquarters, and generally managing communications so that people don t talk over each other and such) for about an hour. So I got to do a little of just about every amateur radio task. Thoughts I am thankful for the opportunity to go, and the good feeling of helping people in need the first I ve ever had the chance to do that in a disaster. It s a good feeling to have a skill that is useful and appreciated. Sometimes it felt like handing out food and water is something pretty small in the scheme of things. But on the other hand, it gives people a chance to have contact with someone that cares, an opportunity to have people that can notice problems drive by a few times a day, and an opportunity to help meet people s basic needs. And sometimes in a fluid situation, there might be more volunteers than are needed, so I did spend some time sitting waiting for the next task. But overall, I m convinced that the work I helped facilitate was a good thing and provided a good and needed service in Joplin. This has been quite the experience and I m sure it s changed me too, though I don t yet know how.

and it starts with f While looking at the future of the KDE Platform Frameworks here in Randa, Switzerland, a lot of interesting things has been found in kdelibs and kdepimlibs

• KSortableList
• KTypeList
• KAscii

that no one knew what was there for. On the good side, there is also lots of cool stuff, that of course most people knows about and uses

• A real nice job based api
• Nice library for figuring out when there is holidays and special dates in different countries
• IMAP library
• Compression library
• Hardware access library

And a lot of great larger solutions for solving different real life problems

• Akonadi
• KIO
• KParts

And lots of other cool stuff

• I really like the KDE plugin framework
• KIO slaves are great
• Kontact master is great
• Aaron is wearing pink
• Plasma Active seems cool
• The chefs are making good food, even though sometimes lacking a bit of meat

And we have currently nice things in the required runtime components for every app built using kdelibs

• Finger KIO slave
• Floppy KIO slave
• Weird cornercase user tools, some of them broken

My last update about running activities is dated back to Paris Marathon (April 10th). Time for a new update, then. After a very busy end March-early April, with that crazy succession of 55km Ecotrail and 42km Paris marathon with only two weeks between both, I needed a kind of "break". Moreover, I had another goal set with the 35m trail race named "Trail des Cerfs", on May 15th, in my neighbourhood. So, end of April was a little bit quieter. Still, one week after Paris marathon, I completed a very hard trail run in Seine Valley: only 18km, but about 600-700m positive slope. That was indeed a good moutain-style run (yes, in Seine valley....) and a good way to check that I recovered quite well. Later on, I slowed down a little with even a Sunday (24th) where I *didn't run at all*..:-).. Just a few short uns during the week and a short Saturday run. Well, that was indeed Easter Sunday and Monday is a holiday in France, so I ran an half-marathon on 25th...:-)...on a loop where I already have some references, the fastest being 1h46. This time it was 1h52'...but, well, that was two weeks after a marathon... Still, a small pain at the back of my ankle decided me to stop running long distances until May 15th. So, I only did short trainings up to no more than 12km, even during my stay in Germany for SambaXP. As a consequence, I was very well for the 35km (600m positive slope) Trail des Cerfs, which I completed in 3h31', 168th out of 328 runners. More interestingly, I completed it in negative split with a much faster second half, ending up at about 12km/h. For seomthing that (given the slope and the nature of the paths) is comparable to a marathon, that's very promising. The rest of May was spent quietly with a standard training and progressively resuming longer distances. I originally planned to do my spring solo marathon on May 28th in Versailles Castle park, but I stopped at km28 and completed the distance two days after with a 14km run..:-)... Stopping was wiser as I was feeling that the last loop would have been a great pain. That was indeed the first time I give up on a marathon. I prefer this to happen for a non official race, after all! June will not see any "big goal". I might be running one race somewhere in my neighbourhood but the point will mostly be accumulating kilometers before summer. Summer (which includes DebConf that makes training a little bit more hectic) will not see any race, probably (unless I find one in banja Luka!) but more some specific preparation for Berlin marathon. Here, the "safe" target for me is, first, breaking my record. I'm probably not ready for 3h30 and even 3h35 might be difficult. It seems that I'm now reaching a barrier where progress becomes harder. Before Berlin, I'll run the Bois d'Arcy half-marathon, two weeks before. Last year, I managed to set a very good mark, there, with 1h37. Not sure that i'll try to break this only two weeks before Berlin. After Berlin? We'll see, but my last big goal of the year will be the 67km "Le Puy-Firminy" night race, in November (no web site, this is indeed a "small" local race). Yet another adventure beyond marathon distances, in the unknown...

DECLARATIVE DIVERSIONS ====================== Introduction A diversion is when it is possible to have dpkg not overwrite a file when it reinstalls the package it belongs to, and to have it put the file from the package somewhere else instead. Declarative diversions involves a new control file with a declarative syntax which dpkg will parse and process directly as part of the package unpack and removal phases, eliminating the problems resulting from non-atomic handling of diversions. Topics There are a number of topics involved in implementing this kind of project * What syntax do we use for the new control file? * What dpkg does with the control file * How do we handle diversions to a non-existant directory? * How do we order unpacking a new package which adds a diversion? * How do we order unpacking a new package that removes a diversion? * How do we order removing a package which had a diversion? * How do we handle errors? * What happens to dpkg-divert? - Details - Control File Syntax - It will conform to RFC2822 style with the following format: * Divert-From: * Divert-To: * Blank lines and lines beginning with # will be comments Divert-To will be optional and if it is ommitted then files being diverted will have their filename changed to file.distrib The above style has it s advantages, one of the main ones being that there is no need to escape whitespace within filenames. - Details - Control File Handling - Within control.tar.gz the file should be named diversions This file is then copied to /var/lib/info/$package.diversions This is ensuring we have a copy of the control file just in case it is needed. Any input on this subject would be appreciated. - Details - Handling Diversions to non-existant directories - Diverting files to directories that don t exist can cause a number of problems. If the package does not own the directory it may be left orphaned on removal of the package The package is responsible for ensuring the availability of the target directory in the unpack phase. - Details - Ordering Requirements - =>Unpacking a new package that adds a diversion *1. Unpack folders *2. Add diversions *3. Unpack files ==Notes== Performing diversions this way avoids trouble with creating folders and accidentally overwrtiting the wrong version of files. If we don t use this method the problems that can occur include creating folders before the package itself would create them which may cause permission errors. Another major problem would be extracting a new version of the file and overwriting the old one. This might cause the wrong version of the file to be diverted and the package to break. =>Unpacking a new package that removes a diversion *1. Unpack folders *2. Add diversions *3. Unpack files ==Notes== =>Removing a package which had a diversion *1. Remove files *2. Remove diversions *3. Remove folders ==Notes== This ensures that all files, diversions and folders are removed correctly Details - Error handling Errors in diversions will have to handled with a great deal of care due to the fact that if they are not the package could be broken. This means that a great deal of checks must be done to ensure that all the files can be diverted properly before any actual diverting takes place. If they can t the package installation/update must be stopped and rolled back to avoid the package being installed incorrectly or broken. - Details - dpkg-divert - When we impliment the new diversion method we should keep the current dpkg-divert. This allows maintainers to catch up with the new method without breaking their packages. It also allows maintainers to perform some operations that aren t support by the new method. Example Usage #1 The file to be diverted is /usr/share/foo It needs to be moved to /usr/share/bar The syntax of the control file would be: #Start File Divert-From: /usr/share/foo Divert-To: /usr/share/bar #End File Example Usage #2 In this example the maintainer doesn t want to move the file to any specific folder The syntax of the control file would be: #Start File Divert-From: /usr/share/foo #End File This would divert the file to /usr/share/foo.distrib - Footnotes - RFC2822 Guide: * http://www.faqs.org/rfcs/rfc2822.html First Email Thread on Declarative Diversions (First Message in Thread): * http://lists.debian.org/debian-dpkg/2011/05/msg00102.html Declarative Diversions Wiki: * http://wiki.debian.org/SummerOfCode2011/DeclarativeDiversions My Blog for this Project: * http://blog.sam-dunne.com

The Event I just attended a lecture by Dr Ziggy Switkowski (see the above picture) on the topic of nuclear power, for a long time Ziggy has been the most prominent advocate of nuclear power in Australia, so naturally the talk was pro-nuclear. The lecture was free for alumni of Swinburne University and introduced by Swinburne s Chancellor who described Ziggy as a friend. Before the lecture started I handed out flyers for Beyond Zero Emissions [1] with a plan for zero carbon use in Australia by 2020. That was more difficult than handing out Greens polling cards on election day. The people who attended were there for a purpose and they could see the free food and wine on offer inside the building so getting them to stop and take a brochure wasn t easy. There were also people from Friends of the Earth [2] and some other anti-nuclear organisations giving out brochures. There were also some anti-nuclear protesters dressed as Uranium miners and the specter of nuclear contamination, they made for an interesting picture (which is amazingly good for a phone camera 20 minutes after sunset), but got in the way when I was handing out brochures. There were a few university security people at the door trying to keep the opposition away who were a bit annoying. There was also one policeman in attendance who was quite friendly, he asked whether there was a competition between the different groups as there is when handing out how-to-vote cards on election day. 15 minutes before the lecture was due to start I quit handing out the brochures and went inside for free food and drink (food always tastes better when the other team pays the bill). The Lecture I felt that Ziggy did a poor job of advocating nuclear power. There were a number of gaping flaws in his argument, but I have to commend him for his honesty in his appraisal of how hard it would be to develop a nuclear industry in Australia. Most nuclear advocates are a lot more optimistic about the process of building nuclear power plants and training all the people to run them. I will write a post tomorrow rebutting some of Ziggy s arguments. After the Lecture Immediately after the lecture the vice-chancellor stated that 500 people registered which made it the best attended such lecture that they have held. I don t know how many of the 500 attended, but I did notice that about 1/4 of the seats in the lecture hall were empty. It s rather sad that they can t get more people to such lectures, is TED.com stealing the audience? When I got out of the building I started handing out brochures to people as they left. I noticed that they were a lot friendlier than they were on the way in. I believe that people who left the lecture had greater interest in renewable energy because Ziggy just failed to make a good case for nuclear power. I expect that anyone who hadn t already made up their mind would immediately want to research the alternatives after watching Ziggy s lecture.

• [1] http://beyondzeroemissions.org/
• [2] http://www.foe.org.au/

Network effects are such a pernicious thing. They give us the internet, but they also give us an internet full of monopolistic worse-is-better players that use network effects to stifle improvements and competition. Sometimes the best you can manage is to be a parasite. facebook So I'm back on facebook ... sort of. My strategy for facebook is to be as near to a featureless datapoint as I can. I won't post anything. I entered as bad quality information as I could get away with. I turned all privacy controls off, on the theory that this way I don't have to worry about facebook eroding privacy since everything about me on facebook is aggressively public. By never posting anything to facebook, I am trying to fight the network effect; trying to avoid increasing the value of facebook due to me being on it. I've adblocked the text entry field on facebook just to avoid the temptation. I want to erase the Like buttons too. Technologically, I think a good approach would be a browser plugin that does these things while extracting all available content and optionally sending it to a RECAP-type system. I only friend people who I need to keep up with and who have little or no other internet presence. This is because I am aware that each person I friend still propels facebook's network effect a little bit; even though they'll never see any useful information from me, they will know that they are able to talk to me via facebook. I only log into facebook once a week or so (this is easy when you're not interacting with it anyway), and read whatever sample of farmville and other posts facebook selects as "important" (worse than usual probably since I never give it feedback). So people I friend can't rely on me reading everything they do, which reduces the value a little more. I will probably delete this account occasionally, and then re-add it later. Just often enough to be really annoying. twitter Similarly, I no longer gate my identi.ca account to twitter, and have deleted as many tweets as I could stand to (one click and one keypress per tweet; no mass-delete; ugh!), and protected my account to avoid accidential new tweets leaking out. Since twitter is not quite as evil as facebook I feel slightly less bad about exposing more of my social graph there. Only the folks who are too lame to get on an OpenMicroBlogging site like identi.ca. phone Of course there was a network effect with the telephone as well, and while it got deregulated it's still pretty bad, and also a technology that I mostly dislike using. Oddly my phone behavior is backwards to the other two networks; I only make outgoing phone calls, never answering the phone (unless real life intervenes very severely). I listen to some random fraction of my voice mail and read whatever ones manage to get machine-transcribed.

When I installed my new laptop, I decided to switch from sleepd to GNOME Power Manager (GPM). The rationale behind this decision was to get screen dimming for free while keeping other features because GPM uses UPower which uses pm-suspend and pm-powersave behind the scene. This means that it is easy to execute scripts on suspend or when the AC is unplugged by putting them in /etc/pm. I don t use a full GNOME desktop. My desktop is running FVWM which is just a window manager. However, I already use some parts of the GNOME environment:

• GDM as a display manager because it is the only one that is able to handle ConsoleKit correctly. This means that GDM is able to register your session to ConsoleKit and make it active. Without that, you won t be considered as the user sitting in front of the screen and DBus won t allow you to interact with most of your hardware unless you add yourself to a lot of groups. ConsoleKit enables the at_console property used by most policies.
• Network Manager to handle both wired and wireless connections. Connecting to some random AP using only command line tools is rather cumbersome (assume that the AP is using WPA). Connecting to a broadband network with a 3G dongle is even more cumbersome.
• GNOME bluetooth applet because interacting with BlueZ bluetooth stack is now done with DBus only and the command line tools have been removed. Therefore, you need to write your own tools or use this small applet that do most of the work for you.

What s working It happens that most of the features just do not work. However, suspend when closing the lid works fine. The icon in the systray works fine too (but there is a small bug). The screen dimming feature on idle also works (but there are annoying bugs with it). The visual feedback when pressing brightness keys works too.

What s not working It seems that I am not the only one to have problem with GPM: there are currently 115 bugs opened in the Debian BTS. If you want to get some debug output from gnome-power-manager, run it with --verbose flag. --debug flag does nothing (and supersedes --verbose).

Nothing happens when pressing the power button I have configured GPM to ask me what to do when I press the power button. But when I press the button, nothing happens. Looking at the source, here is the snippet of code that is executed:

1 2 3 4 5 6 7

if (policy == GPM_ACTION_POLICY_INTERACTIVE) GpmSession *session; egg_debug ("logout, reason: %s", reason); session = gpm_session_new (); gpm_session_logout (session); g_object_unref (session);

In fact, this is not GPM that will ask you the question, but GNOME session manager because GPM triggers logout. If you don t run a full GNOME session, nothing will happen. My workaround is just to set the action to Suspend .

Does not sleep when idle GPM is configured to go to sleep after 2 hours on AC or 30 minutes on battery. This does not work for me because idle detection is delegated to external programs. There are four variables used by GPM to determine if we are idle:

• session_idle which is the idle hint from ConsoleKit,
• idle_inhibited which is set when another program asks to disable idle detection (a video player which does not want the screen to be dimmed),
• suspend_inhibited which means a program do not want we going to sleep (a music player for example)
• x_idle which tells if X is idle or not (someone is moving the mouse or typing on the keyboard).

To allow GPM to suspend when we are idle, x_idle and session_idle must be true while suspend_inhibited and idle_inhibited must be false. For screen dimming purpose, you just need to have x_idle set to true and idle_inhibited set to false. Currently, only GNOME Screensaver seems to tell ConsoleKit if the session is idle or not. XScreenSaver does not contain anything about this. I am using xautolock with xlock and I am pretty sure they won t tell GPM if I am idle. You can use dbus-send to circumvent this problem:

1 2 3 4 5 6 7 8 9 10 11

$ dbus-send --system --dest=org.freedesktop.ConsoleKit \ > --type=method_call --print-reply --reply-timeout=2000 \ > /org/freedesktop/ConsoleKit/Manager \ > org.freedesktop.ConsoleKit.Manager.GetCurrentSession method return sender=:1.6 -> dest=:1.106 reply_serial=2 object path "/org/freedesktop/ConsoleKit/Session1" $ dbus-send --system --dest=org.freedesktop.ConsoleKit \ > --type=method_call --print-reply --reply-timeout=2000 \ > /org/freedesktop/ConsoleKit/Session1 \ > org.freedesktop.ConsoleKit.Session.SetIdleHint boolean:true method return sender=:1.6 -> dest=:1.108 reply_serial=2

While I understand what is the rationale behind those choices (no code duplicate and allowing external programs to hinder power management), it lacks some fallback in case you don t use GNOME Screensaver (which is the key component here). I first though this was bug #594706 but this is not the case. I have opened (and closed) bug #628755. UPDATED: Jump to the conclusion for an updated solution for this problem.

Brightness is not restored to the previous value after idle When GPM undims the screen, it does not restore the previous value. It seems to be bug #617310 which is marked as fixed in upstream. I did not investigate it.

Wrong number of batteries reported I only have one battery but after one suspend/resume cycle, GPM thinks I have two. Maybe this is a bug of UPower. Maybe this is bug #606434. I did not investigate it. Maybe there is an happy interaction with bug #456280.

Inability to set configure actions when the UPS runs out of battery This is bug #390602. In addition to laptop batteries, UPower also supports UPS. In this case, GPM displays a special icon to tell if the UPS is fully charged. However, there is no possibility to execute special actions when the UPS is unplugged, like hibernate after 10 minutes or something like this. This seems to be a problem with the interface because looking with gconftool-2, we can spot variables like low_ups or critical_ups which allow to set actions when the UPS is almost out of battery. Moreover, the UPS icon only displays after one suspend/resume cycle but I am too lazy to report and debug this issue. Since, the icon disappear if I restart GPM, I am confident that the bug is in GPM.

Conclusion The conclusion is that GPM is not really that buggy but it really needs to be run in a full-blown GNOME desktop. The main problem is not really GPM. New technologies like UPower and ConsoleKit get pushed by freedesktop.org initiative, they get implemented by GNOME (and, I suppose, KDE) because they have tons of people following the appropriate mailing lists and any alternative just gets crushed by all those unpublicized changes. UPDATED: I got several helpful comments about this problem. There are two possible solutions:

1. Use xfce4-power-manager. It handles brightness control in a better way and don t need an external program to tell when the current session is idle. It still needs a session manager to ask what to do when using the power button. The drawback to this solution is that you start to pull another desktop environment into your environment. You had some parts of GNOME and now you have some parts of XFCE. This solution was proposed by Sylvain Collilieux.
2. Use gnome-session, gnome-screensaver and keep gnome-power-manager. As pointed by Julien Valroff, gnome-screensaver needs gnome-session to detect idleness. However, gnome-session starts a whole GNOME desktop. Again, there are two solutions. The first one is to replace gnome-session by something lighter implementing the bare minimum to make gnome-screensaver happy. Another suggestion is to configure gnome-session to start your favorite environment.

I start mine from ~/.xsession and here is what I have added at the top of it:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

# If not done, restart ourself with gnome-session if [ -z "$SESSION_MANAGER" ]; then [ -d ~/.config/autostart ] mkdir ~/.config/autostart rm -f ~/.config/autostart/* cat <<EOF > ~/.config/autostart/xsession.desktop [Desktop Entry] Name=Xsession Comment=Start .xsession Exec=$(readlink -f $0) Type=Application X-GNOME-Autostart-enabled=true EOF exec gnome-session --autostart=$HOME/.config/autostart fi # Otherwise, keep starting stuff # [...] exec fvwm-crystal

As you all probably know by know, DNSSEC has been enabled on the root ('.') since July 2010. And on most TLDs like .com shortly thereafter (in the specific case of .com, since March 2011). The Debian guide to turning on DNSSEC is useful but some things you need to know (after using it for a week or so).

BIND loves IPv6.

If you have 'listen-on-v6', set to yes and you roam to a non-IPv6 network. Your name resolutions can take 30+ seconds.Since I roam from a some networks they do have IP6 and some that do not, I have had to turn this setting off to achieve reasonable performance

Each new network requires manual intervention

Just like Andrew Cowie, I'm trying to get new features in NetworkManager. by blogging.My use case is simple if a bit geeky use the local resolver on my system irregardless of what I get dynamically (via DHCP) or automagically (via SLAAC).I can do this manually for each network I connect to, but it quickly looses its appeal.

Very little software takes advantage of DNSSEC (yet).

Apart from the happy DNSSEC campers, very little takes advantage of DNSSEC yet.Kind of like the early days of IP6. It would be nicer if websites stored the fingerprint of the SSL website in DNS and it could be cross-checked against what was sent.The effort to do so is underway at the IETF by the name of DANE.In fact publishing SSH key fingerprints via DNS is already possible RFC4255 but I am unaware of deployed support.

Things are progressing, and I suspect now is a great moment to get involved if you have spare time, in making it significantly harder for 3rd-parties to censor the Internet for everyone.

I was invited to be part of one of the panels to be present this Thursday (June 2) in a forum that promises to be interesting. The forum is organized by the Science and Technology comission of the Senate of the Republic (of Mexico ;-) ), Universidad Aut noma Metropolitana and Mozilla M xico. The day will be opened by Sen. Francisco Javier Castell n Fonseca and Richard Stallman; starting at 10:00, we will have thematic panels on:

• Education
• Government
• Industry
• Civil society

The full program (as well as details of interest of those that can physically attend) is attached to this post. I am looking forward to this forum. Not only it is a good opportunity to get our work known in one of those places where it matters, but it's also being organized by several interesting people I'm sure will have something interesting to contribute. And of course, we lacked time to build a better, more complete and more coherent proposal but there is a good probability we will have further such contacts. You might find interesting to read on the list we have been discussing; subscription seems to be open (although access to the archives is not Maybe it will be later on? In any case, I'm saving a mbox ;-) )

Attachment	Size
Activity program	352.37 KB

Most of us developers use metaphors to help convey an understanding of how our software works. Sadly, many developers choose the "master" and "slave" metaphor. Why would we voluntarily choose such an ugly human human interaction with a real and present history in many of our lives to describe software that we've written? I wouldn't rule out the possibility that someone will (or already has) invented software for which the master/slave metaphor aptly conveys its function, however, I'd prefer not to use it. Also, many people intentionally play with master/slave relationships because of the history and connotations it provokes. However, use of this metaphor in software like MySQL databases or Bind Name servers seems pointless, offensive and mis-leading. I've never seen the use of the master/slave metaphor in software that conveyed more than the idea that one piece of the software essentially controls, wholly or in part, another piece of software. So, why master/slave? There are many metaphors to choose from - parent/infant, boss/worker, guard/prisoner, king/subject, landowner/serf, top/bottom, etc. What does master/slave convey that the others don't convey? Or, maybe they all convey the same thing, so it doesn't make a difference which one you choose (after all, it's just a metaphor). In that case, how about replacing master/slave with the metaphor husband/wife? Whoops. Now that's offensive (if you don't think that's offensive you can stop reading here and please don't post any comments - I won't change your mind). But, that's different right? At one point in history, the role of the wife was to do as her husband says, but it's 2011, and we've evolved beyond that, so by using husband/wife we'd be re-enforcing that ugly, sexist stereotype. However, how is that different from master/slave? It is 2011 after all. Isn't the role of the master to abdicate and the role of the slave to revolt? Maybe that's why Bind has so many security problems...

So earlier on I posted about my work on declarative diversions . I felt I needed to clarify a few things as a few people asked me different questions and I don t think I made the post clear enough and I also left out an important piece of information. The new control file will be located in control.tar.gz and it s syntax will be

One diversion per line Blank lines and lines with # are comments Two fields per diversion seperated by whitespace (SOURCE DESTINATION)

Now people have asked be about updating and removing diversions and how that will be accomplished. All diversions will be listed in this control file. If a diversion isn t listed in the control file on upgrade dpkg will automatically remove the diversion because it will see it is no longer needed. The same goes for changing diversions, i.i. list them just as though they re new and it will update them. This project will infer add, remove and package and will not allow you to specify them. The same is goes for rename, it is being made default and not optional (for now, I am aware of some special cases). *Removed, slight mistake here* Now, there are a number of things still left to do this week before a full draft is prepared. There is an email here by Ian Jackson which talks about ordering unpack in such a way to delay the the actual renaming of the file. If anyone has any suggestions for this process it would be greatly appreciated. Another two things that need to be done is the proper handling of diversions to non-existant directories and also escaping spaces within filenames for the control file. I should have another update tomorrow evening. Until then, ~Sam

Lately I have been working on the triggers feature of dpkg. I would like to share my plan and what I have done so far. I ll first explain what triggers are, the current problems, and the work I did to try to improve the situation. Introduction Dpkg triggers are a neat feature of dpkg that package can use to send/receive notifications to/from other installed packages. Those notifications take the form a simple string. This feature is heavily used to track changes of packaged files in a list of predefined directories, and to update other files based on this. For instance, man-db is watching the directories containing manual pages so that it can update its cache (in /var/cache/man/). install-info is updating the index of info pages when there have been changes in /usr/share/info. gnome-menus is updating its own copy of the menu hierarchy (with entries from /etc/gnome/menus.blacklist blacklisted) every time that a .desktop file is installed/updated/removed. From a user s perspective You see triggers in action very often during upgrades (in fact too often as we ll see it later):

Preparing to replace zim 0.52-1 (using .../archives/zim_0.52-1_all.deb) ...
Unpacking replacement zim ...
Processing triggers for shared-mime-info ...
Processing triggers for menu ...
Processing triggers for desktop-file-utils ...
Processing triggers for man-db ...
Processing triggers for hicolor-icon-theme ...
Processing triggers for python-support ...
Processing triggers for gnome-menus ...
Setting up zim (0.52-1) ...
Processing triggers for python-support ...
Processing triggers for menu ...

As you guessed it, those Processing triggers lines correspond to the packages which received (one or more) trigger notifications and which are doing the corresponding task. By default the triggers are processed at the end of the dpkg --unpack invocation which is often too soon because APT will often call dpkg --unpack repeatedly during important upgrades. There are some options to ask APT to use dpkg s --no-triggers option in order to defer the trigger processing at the end of the APT run. You can put this in /etc/apt/apt.conf.d/triggers:

// Trigger deferred
DPkg::NoTriggers "true";
PackageManager::Configure "smart";
DPkg::ConfigurePending "true";
DPkg::TriggersPending "true";

I have now asked APT maintainers to use those options by default, I filed bug #626599 to track this. At the same time I fixed bug #526774 reported by APT maintainers. This bug forced them to put a work-around in APT which resulted in running triggers sooner than expected. (And while writing this article I filed bug #628564 and #628574 because it was clearly not normal that the menu triggers was executed twice for the installation of a single package) From a packager s perspective The implementation of triggers has several consequences on the status that packages can have. Let s assume that the package A installs a file in a directory that is watched by package B (and that B is currently in the installed state). When A is unpacked, dpkg adds B to its Triggers-Awaited field and lists the activated trigger in B s Triggers-Pending field. Package A is in unpacked state, but B has been changed to triggers-pending . When A is configured, instead of going to the installed state, it will go to the triggers-awaited state. In that state the package is assumed to NOT fulfill dependencies. However, B which is still in triggers-pending state does fulfill dependencies. A and B will switch to installed at the same time when the trigger has been processed. The fact that the triggers-awaited status does not fulfill dependencies means that some common triggers like man-db have to be processed regularly just to be able to ensure dependencies are satisfied before running the postinst of other installed packages. But a package which ships a manual page can certainly be considered as configured when its postinst has been run even if man-db has not yet updated its cache to know about the new/updated manual page. When you activate a trigger with the dpkg-trigger command you have an option --no-await to avoid awaiting the trigger processing (and thus to go directly to installed state after the postinst has been run). But with file triggers or activate trigger directives, you do not have this option. My proposal to improve the situation This is the problem that I tried to solve during my last vacation. But before changing the inner working of triggers, I wrote a non-regression test suite for that feature (commit here) so I could hack with some confidence that I did not break everything. The result has been presented on the debian-dpkg mailling list: see the discussion here. I added new directives that can be used in triggers files that work exactly like the current triggers except that they do not put triggering packages in trigger-awaited status. I believe the code to be mostly ready, but in its current form the patch brings zero benefits until all packages have been converted to use the trigger variants that do not require awaiting trigger processing (and the change requires a pre-dependency on dpkg to ensure we have the required dpkg that understands the new kind of trigger directives). Remaining question Thus I wonder if I should not change the default semantic of triggers. The packages which really provide crucial functionality to awaiting packages through triggers would then have to be updated to switch to the new directives. If you re a packager using triggers, you can thus help me by answering this question: do you know some triggers where it s important that the awaiting packages are not considered as configured before the trigger processing? In most of the cases I checked, it s important for the triggered package rather than for the triggering package. In truth, a package in triggers-awaited status is usually in a good enough shape to be able to satisfy dependencies (i.e. requirements that other packages can have), but it would still be worth to record the fact that it s not entirely configured yet because it might be true from the user s point of view: for example if the menu trigger has not yet been processed, the software might not yet be visible in the application menu.

If you appreciate this kind of groundwork that benefits to the whole Debian ecosystem, please consider supporting my work. Click here and give it a look, there are many ways to contribute and to make a difference for me.

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

At April 30, I took over maintenance of of Debian's kFreeBSD autobuilders. Means getting something like 4,5k e-Mails this month (gladly no need to sign all those 4k successful builds any more!), filling nearly 30 RC Bugs (quite a lot of which got fixed just within hours after filling, wow!), investigating some of the more strange build failures and such stuff. In general it turned out to be quite some fun. Quite interesting which libraries turn out to be rather central to the Archive. I wouldn't have guessed that a uninstallable libmtp would prevent a reasonable fraction of the builds to fail -- including packages like subversion. Packages builds failing because the disk space is exhausted may be something most of us have already witnessed, especially those here that use one of these small notebook hard drives. Build failures caused by a lack of RAM might certainly be imaginable as well, especially on highly parallel builds. But have you ever seen gcc fail because the virtual address space was exhausted on 32 bit architectures? Also there's a interesting lot of packages with misspelled build dependencies which sbuild can't find and therefore can't build the package. Maybe having a lintian check for some of these problems would be a good idea? I'm also regularly seeing build failures that look easy enough to fix -- like some glob in a *.install for some python package matching lib.linux*. I try to fix some of these as I see them but my time is unfortunately limited as well. Someone interested in quick&easy noticed about these kind of issues? I could put URLs to build-logs on identi.ca or somewhere on IRC. There are also some really strange failures like llvm, which builds flawlessly on my local kFreeBSD boxes all the time, inside and outside schroot but hangs all the time in the same testcase when building on any of the autobuilders (any hints welcome!) or perl failing on kfreebsd-amd64 selectively but all the time.

I've got a few projects which are hosted in mercurial repositories. To deploy them I manually checkout the repository, create symlinks by hand, then update apache thttpd to make them work. When I want to update my applications I manually become the correct user, find the repository and run "hg pull --update". I think it is about time that I sat down and started doing things neatly. I made a start at this by writing a shell script for each site called .deploy then I drive it like so:

#!/bin/sh
#
# ~/bin/deploy  execute the .deploy file associated with this project.
#
while true; do
    #
    #  If we're at the root directory we're done.
    #
    if [ $PWD = "/" ]; then
        echo "Reached /"
        exit
    fi
    # found our file?
    #
    if [ -x ".deploy" ]; then
       ./.deploy
       exit
    fi
    cd ..
done

It seems the main candidate is capistrano, which was previously very Ruby on Rails centric, but these days seems to be divorced from it. Alternatively there is the python-based fabric project which has been stalled for two years, vlad the deployer (great name!) which is another Rake-based and thus Ruby-loving system, and finally whiskey disk which is limited to Git-based projects as far as I can tell. In short each of these projects is very similar, and each relies upon being able to do two things:

• SSH to remote machine(s) and run a command.
• Copy files to the remote command / pull a repository from a known location.

I've automated SSH before, and I've automed SCP/rsync. The hard part is doing both "copy" and "command" over one SSH channel - such that you don't get prompted for passwords multiple times - and handling the case of runnign sudo where appropriate. Still most of the initial stages are trivial. I wonder what project I should be using:

• I like perl. Perl is good.
• I use mercurial. Mercurial is good.
• Rake is perhaps permissable, but too ruby-centric == not for me.

Anything I've missed? Or pointers to good documentation? ObQuote: "We need to be a little more constructive here, okay? " - Terminator 2

It's 2011. Computers are here for a couple of decades now, but they still don't help me with the most simple problems. I've been asked once again about a recommendation for a GroupWare and still don't know what to say. This are the simple requirements:

Manage my Mails, Calendar, Contacts, Files, Knowledge (Wiki) and ToDos (including IssueTracker). Let me synchronize these informations with mobile devices and for offline work. Allow collaboration and sharing.

I started professional programming in 2006 with the eGroupWare project, which provides the above functionality more or less, but I still can't recommend it. Neither could I recommend any other system I know of (Tine 2.0, OpenGroupWare, OpenExchange, Horde, Kolab, ...?) since they violate one or more of my secondary requirements:

• a maintainable code base (this rules out PHP IMHO)
• free software (there's certainly enough to earn with support/service for such a system!)
• no relational database! they're just not made for this kind of data or why do you think system X allows only for N numbers of mails/addresses/phone numbers per contact?
• reusable components / libraries
• no dependency on antique technology (yes, I mean Kolab depending on Cyrus)
• and as the cream: easy installation at least for test setups

This kind of software is on the top position on my Things-To-Do-When-I-Have-Time. But on the other hand I know that many have already started such projects and either they did not deliver sufficient functionality or there code base is a PITA.

Yes, I'm ranting once again. But please show me a decent GroupWare and I'll praise you on any occassion!

Or should I make this my project for my bachelor thesis: A Contacts+Mail server/web frontend in Scala using CouchDB, Dovecot? What do you think?

Whenever you download some software from the Apache Software Foundation, there is a small .asc file besides every software release. This tiny file is a cryptographic signature to protect you from accidentally downloading and running malware.

However this signature is only as good as the web-of-trust between you and the Release Manager of the Software project.
At BerlinBuzzWords many developers and users will gather at one place. This is a unique occasion to strengthen the web-of-trust. Therefor we want to encourage and remind you to use the occassion for keysigning! For lack of time there won't be an official keysigning party, but you have occassion during lunch, coffee break or the barbecue to do quick one-to-one keysignings.
You should bring print-outs of your key fingerprints and identification documents. If you put the fingerprints in your batch (see picture) everyone can easily see
them and ask you for a quick trust exchange. We may also mark a "keysigning corner" somewhere where people can go and meet others for key signing.

Hints:

• under Debian (and Ubuntu) you can get a PDF to print out your fingerprints many times via:
  CODE:
  sudo aptitude install signing-party ghostscript gpg-key2ps KEYID ps2pdf - fingerprints.pdf
• the signing-party package also contains the tool "caff" to batch process the signing of keys after the event
• please only use keys with at least 2024 bits!
• please make sure that you've uploaded your key to a public keyserver
• I'm happy to answer all remaining questions at the BarCamp on Sunday or during the event

The problem Some programs require root privileges for part of their work: most notably Debian building tools such as dpkg-buildpackage or pdebuild. So, several command can be used to obtain real or fake root privileges: su, sudo, fakeroot, etc. Among them, su is quite distinct, because it only takes a quoted command to pass it to a shell. That is why its interface is completely incompatible with the others':

$ su -c "pbuilder --build package.dsc"
$ sudo pbuild --build package.dsc

This is annoying when real root privileges are needed, for instance by pbuilder, a tool to build Debian packages inside a minimal chroot. Indeed, in such a case I only know one command to obtain the root privileges, sudo, and some people (read: me) prefer using su.A wrapper Long story short: as I saw no existing tool to do that (but I would be glad to hear if there was already one), I wrote a wrapper that emulates a (very basic) sudo-like interface by using su, and vice-versa. It is available from my Git repository:

$ git clone git://git.ortolo.eu/sudo-su.git

It is polymorphic, BusyBox-style: call it sudo-su and it will emulate sudo with su; call it su-sudo and it will emulate su with sudo. For instance:

$ pdebuild --pbuilderroot /usr/local/bin/sudo-su

It is WTFPL-licensed, it implements no options from sudo and su (except sudo's -c, of course), but I can do something better if it may be useful to other people.

This week I finally used my packaging tutorial slides myself, a few days after Phil Hands used them at a UKUUG event. The tutorial is now available as a Debian package (in Debian unstable) named packaging-tutorial, and I ve talked to debian-doc@ about linking it from appropriate places. It s also hosted on collab-maint now, so don t hesitate to contribute. Links :

• Latest version (PDF)
• Git repo