I've been frustrated by my inability to schedule appointments directly from the org-agenda view, for quite some time, but I think I've found a way. If like me you're using org-mode to manage your appointments, you're probably using SCHEDULED TODO items that can be entered in your system using org-capture templates. A typical scenario is I'm asked by a colleague (face to face or on the phone) when I'm available to schedule a meeting or some other activity. I'm then firing an agenda view, and browse through the dates available... then agreeing on an empty slot, I'm capturing the meeting... but then I have to C-c C-s to add the SCHEDULED marker and set the correct date, although I was previously on that exact date in the org-agenda view The solution seems to be with the 'k c' command, i.e. the capture org-agenda-action in the agenda view. From the docs :

k runs the command org-agenda-action, which is an interactive compiled
c     Call  org-capture' with cursor date as the default date

Exactly what I need : it will prompt me for a capture template, which I just have to set to a template containing "SCHEDULED: %t". Excerpt from my .emacs :

(custom-set-variables
...
'(org-capture-templates (quote (("t" "Todo" entry (file+headline "~/org/newgtd.org" "TACHES") "* TODO %^ Brief description  %^g
 %?   
    Added: %U
%i
%a") ("n" "Notes" entry (file+datetree "~/org/journal.org") "* %^ topic  %T %^g
%i%?
%a") ("d" "Scheduled appointment" entry (file+headline "~/org/newgtd.org" "TACHES") "* TODO %^ Brief description  %^g
 %?   
    SCHEDULED: %t
%i
%a"))))

Tadaaa ! it works

I've got yet another question whether Weblate has any sort for ACL to limit access to project. As usual, my answer was no, but I started to think how I would implement such feature. After a little bit of thinking and playing with code, I've realized, that this is not that hard as I thought and implemented it in few minutes. So there is another ofter requested feature which will come in Weblate 1.4 - ACL. It provides simple way to limit access to some projects to some users. The default behavior is still that anybody logged in can do anything, but this can be changed per project by enabling ACL for it. More details are available in our documentation.

Filed under: English Weblate 0 comments Flattr this!

In order to move my blog to a free-as-in-freedom platform and support the great work that Joey (of git-annex fame) and Lars (of GTD for hackers fame) have put into their service, I decided to convert my Blogger blog to Ikiwiki and host it on Branchable. While the Ikiwiki tips page points to some old instructions, they weren't particularly useful to me. Here are the steps I followed.

Exporting posts and comments from Blogger Thanks to Google letting people export their own data from their services, I was able to get a full dump (posts, comments and metadata) of my blog in Atom format. To do this, go into "Settings Other" then look under "Blog tools" for the "Export blog" link.

Converting HTML posts to Markdown Converting posts from HTML to Markdown involved a few steps:

1. Converting the post content using a small conversion library to which I added a few hacks.
2. Creating the file hierarchy that ikiwiki requires.
3. Downloading images from Blogger and fixing their paths in the article text.
4. Extracting comments and linking them to the right posts.

The Python script I wrote to do all of the above will hopefully be a good starting point for anybody wanting to migrate to Ikiwiki.

Maintaining old URLs In order to make sure I wouldn't break any existing links pointing to my blog on Blogger, I got the above Python script to output a list of Apache redirect rules and then found out that I could simply email these rules to Joey and Lars to get them added to my blog. My rules look like this:

# Tagged feeds
Redirect permanent /feeds/posts/default/-/debian http://feeding.cloud.geek.nz/tags/debian/index.rss
Redirect permanent /search/label/debian http://feeding.cloud.geek.nz/tags/debian
# Main feed (needs to come after the tagged feeds)
Redirect permanent /feeds/posts/default http://feeding.cloud.geek.nz/index.rss
# Articles
Redirect permanent /2012/12/keeping-gmail-in-separate-browser.html http://feeding.cloud.geek.nz/posts/keeping-gmail-in-separate-browser/
Redirect permanent /2012/11/prefetching-resources-to-prime-browser.html http://feeding.cloud.geek.nz/posts/prefetching-resources-to-prime-browser/

Collecting analytics Since I am no longer using Google Analytics on my blog, I decided to take advantage of the access log download feature that Joey recently added to Branchable. Every night, I download my blog's access log and then process it using awstats. Here is the cron job I use:

#!/bin/bash
BASEDIR=/home/francois/documents/branchable-logs
LOGDIR=/var/log/feedingthecloud
# Download the current access log
LANG=C LC_PAPER= ssh -oIdentityFile=$BASEDIR/branchable-logbot b-feedingthecloud@feedingthecloud.branchable.com logdump > $LOGDIR/access.log

It uses a separate SSH key I added through the Branchable control panel and outputs to a file that gets overwritten every day. Next, I installed the awstats Debian package, and configured it like this:

$ cat /etc/awstats/awstats.conf.local
SiteDomain=feedingthecloud.branchable.com
LogType=W
LogFormat=1
LogFile="/var/log/feedingthecloud/access.log"

Even if you're not interested in analytics, I recommend you keep an eye on the 404 errors for a little while after the move. This has helped me catch a critical redirection I had forgotten.

Limiting Planet feeds One of the most common things that happen right after someone migrates to a new blogging platform is the flooding of any aggregator that subscribes to their blog. The usual cause being the change in post identifiers. Unsurprisingly, Ikiwiki already had a few ways to avoid this problem. I chose to simply modify each tagged feed and limit them to the posts added after the move to Branchable.

Switching DNS Having always hosted my blog on a domain I own, all I needed to do to move over to the new platform without an outage was to change my CNAME to point to feedingthecloud.branchable.com. I've kept the Blogger blog alive and listening on feeding.cloud.geek.nz to ensure that clients using a broken DNS resolver (which caches records for longer than requested via the record's TTL) continue to see the old posts.

The DEP-11 proposal to add AppStream information to the Debian archive, is a proposal to make it possible for a Desktop application to propose to the user some package to install to gain support for a given MIME type, font, library etc. that is currently missing. With such mechanism in place, it would be possible for the desktop to automatically propose and install leocad if some LDraw file is downloaded by the browser. To get some idea about the current content of the archive, I decided to write a simple program to extract all .desktop files from the Debian archive and look up the claimed MIME support there. The result can be found on the Skolelinux FTP site. Using the collected information, it become possible to answer the question in the title. Here are the 20 most supported MIME types in Debian stable (Squeeze), testing (Wheezy) and unstable (Sid). The complete list is available from the link above. Debian Stable:

  count MIME type
  ----- -----------------------
     32 text/plain
     30 audio/mpeg
     29 image/png
     28 image/jpeg
     27 application/ogg
     26 audio/x-mp3
     25 image/tiff
     25 image/gif
     22 image/bmp
     22 audio/x-wav
     20 audio/x-flac
     19 audio/x-mpegurl
     18 video/x-ms-asf
     18 audio/x-musepack
     18 audio/x-mpeg
     18 application/x-ogg
     17 video/mpeg
     17 audio/x-scpls
     17 audio/ogg
     16 video/x-ms-wmv

Debian Testing:

  count MIME type
  ----- -----------------------
     33 text/plain
     32 image/png
     32 image/jpeg
     29 audio/mpeg
     27 image/gif
     26 image/tiff
     26 application/ogg
     25 audio/x-mp3
     22 image/bmp
     21 audio/x-wav
     19 audio/x-mpegurl
     19 audio/x-mpeg
     18 video/mpeg
     18 audio/x-scpls
     18 audio/x-flac
     18 application/x-ogg
     17 video/x-ms-asf
     17 text/html
     17 audio/x-musepack
     16 image/x-xbitmap

Debian Unstable:

  count MIME type
  ----- -----------------------
     31 text/plain
     31 image/png
     31 image/jpeg
     29 audio/mpeg
     28 application/ogg
     27 image/gif
     26 image/tiff
     26 audio/x-mp3
     23 audio/x-wav
     22 image/bmp
     21 audio/x-flac
     20 audio/x-mpegurl
     19 audio/x-mpeg
     18 video/x-ms-asf
     18 video/mpeg
     18 audio/x-scpls
     18 application/x-ogg
     17 audio/x-musepack
     16 video/x-ms-wmv
     16 video/x-msvideo

I am told that PackageKit can provide an API to access the kind of information mentioned in DEP-11. I have not yet had time to look at it, but hope the PackageKit people in Debian are on top of these issues. Update 2013-01-16 13:35: Updated numbers after discovering a typo in my script.

Setting resource limits from a shell script is commonly done with the ulimit command.
Shells provide it as a built-in, if they provide it at all. As far as I know, there is no non-built-in ulimit command. One could be implemented with the Linux-specific prlimit system call, but even that requires a fairly "recent" kernel version (circa 2010).

Depending on the kind of resource you want to limit, you may get away with what some shells such as dash provide: CPU, FSIZE, DATA, STACK, CORE, RSS, MEMLOCK, NPROC, NOFILE, AS, LOCKS. I.e. options tfdscmlpnvw, plus H for the hard limit, S for the soft limit, and a for all. Bash allows other resources to be limited.

Remember, if you rely on any non-standard behaviour or feature make sure you document it and, if feasible, check for it at run-time. ulimit is not required by POSIX:2001 to be implemented for the shell.

For years, I've distributed the individual AFS administrative tools that we use at Stanford as separate software releases on my web site, but this has clearly been less and less efficient. We've needed to package them for use at Stanford and didn't want to create separate packages for each individual script, we've wanted to get them out of their current CVS repository, and they didn't support any unified configuration system or simple method for local site customization. I started trying to solve those problems over a year ago by converting all the scattered CVS files into a coherent Git repository and turning the collection of scripts into an actual distribution that I can version and release more like regular software packages. But other things kept coming up, and it's one of the yearly goals I had for last year that I didn't finish. Today, I finally took the time to finish this off. The scripts frak, fsr, lsmounts, mvto, partinfo, volcreate, volcreate-logs, and volnuke, which were previously distributed separately, are now collectively distributed as afs-admin-tools and all support a standard configuration file and location. I also rolled up some previously unreleased fixes and removed some remaining Stanford-specific behavior. I have not, with this release, incorporated any of the various changes that people have sent me to the individual scripts. That's next. They're also all still standalone scripts without any common code moved into a Perl module, but I may change that in the future. Note that some of these scripts refer to scripts that will be part of the afs-mountpoints package. Putting that together is my next task, but it's a bit trickier since we moved the mount point database into an actual database, so I need to put some work into the Perl modules that wrap that database. Hopefully I can get that released before too long as well. You can get the latest release from the (new! shiny!) afs-admin-tools distribution page.

phpMyAdmin just got a new theme. It's available for download on our themes page. New theme reflects look of new Windows and I have to admit it looks quite nice: As you can see, it also offers four color variants, configurable in it's layout.inc.php file. PS: More details on theme can be found on deviantART.

Filed under: English Phpmyadmin 0 comments Flattr this!

I was upset to learn about Aaron Swartz's death last week. I continue to be upset about his loss, and about our loss. He didn't just show promise of great things to come in the future -- he had already done more work for the public good than many of us will ever do. I'd only met him IRL a couple times, but (like many others) i had encountered him on the 'net in many places. He was a good person, someone i didn't need to always agree with to respect. I read Russ Allbery's posts about Aaron and "slacktivism" with much appreciation. I had been ambivalent about signing the whitehouse.gov petition asking for the removal of the prosecutor for overreach, because I generally distrust the effectiveness of online petitions (and offline petitions, for that matter). But Russ's analysis convinced me to go ahead and sign it. The petition is concrete, clear (despite wanting a grammatical proofread), and actionable. For people willing to go beyond petition signing to civil disobedience, The Aaron Swartz Memorial JSTOR Liberator is an option. It makes it straightforward to potentially violate the onerous JSTOR terms of service by re-publishing a public-domain article from JSTOR to archive.org, where it will be accessible to anyone directly. As someone who builds and maintains information/communications infrastructure, i have very mixed feelings about most online civil disobedience, since it often takes the form of a Distributed Denial of Service (DDoS) attack of some sort. DDoS attacks of public services are notoriously difficult to defend against without having huge resources to throw at the problem, so encouraging participation in a DDoS often feels a little bit like handing out cans of gasoline when you know that everyone is living in a house of straw. However, the JSTOR Liberator is not a DDoS at all -- it's simply a facilitation of people breaking the JSTOR Terms of Service (ToS), some of the same terms that Aaron was facing charges for violating. So it is a well-targeted way to demonstrate that the prosecutions were overreaching. I wanted to take issue with one of Russ' statements, though. In his second post about the situation, Russ wrote:

Social activism and political disobedience are important and often valuable things, but performing your social activism using other people's stuff is just rude. I think it can be a forgivable rudeness; people can get caught up in the moment and not realize what they're doing. But it's still rude, and it's still not the way to go about civil disobedience.

While i generally agree with Russ' thoughtful consideration of consent, I have to take issue with this elevation of some sort of hyper-extended property right over the moral agency that drives civil disobedience. To use someone else's property for the sake of a just cause without damaging the property or depriving the owner of its use is not "forgivable rudeness" -- it's forgivable, laudable even, because it is just. And the person using the property doesn't need to be "caught up in the moment and not realize what they're doing" for it to be acceptable. Civil disobedience often involves putting some level of inconvenience or discomfort on other people, including innocent people. It might be the friends and family of the activist who have to deal with the jail time; it might be the drivers stuck in a traffic jam caused by a demonstration; it might be the people forced to shop elsewhere because the store's doors are barricaded by protestors. All of these people could be troubled by the civil disobedience more than MIT's network users and admins were troubled by Aaron's protest, and that doesn't make the protests described worse or "not the way to go about civil disobedience." The trouble highlights a more significant injustice, and in its troubling way does what it can to help right it. Aaron was a troublemaker, and a good one. He will be missed. Tags: aaronsw

Yesterday, I wrote about the modalias values provided by the Linux kernel following my hope for better dongle support in Debian. Using this knowledge, I have tested how modalias values attached to package names can be used to map packages to hardware. This allow the system to look up and suggest relevant packages when I plug in some new hardware into my machine, and replace discover and discover-data as the database used to map hardware to packages. I create a modaliases file with entries like the following, containing package name, kernel module name (if relevant, otherwise the package name) and globs matching the relevant hardware modalias.

Package: package-name
Modaliases: module(modaliasglob, modaliasglob, modaliasglob)

It is fairly trivial to write code to find the relevant packages for a given modalias value using this file. An entry like this would suggest the video and picture application cheese for many USB web cameras (interface bus class 0E01):

Package: cheese
Modaliases: cheese(usb:v*p*d*dc*dsc*dp*ic0Eisc01ip*)

An entry like this would suggest the pcmciautils package when a CardBus bridge (bus class 0607) PCI device is present:

Package: pcmciautils
Modaliases: pcmciautils(pci:v*d*sv*sd*bc06sc07i*)

An entry like this would suggest the package colorhug-client when plugging in a ColorHug with USB IDs 04D8:F8DA:

Package: colorhug-client
Modaliases: colorhug-client(usb:v04D8pF8DAd*)

I believe the format is compatible with the format of the Packages file in the Debian archive. Ubuntu already uses their Packages file to store their mappings from packages to hardware. By adding a XB-Modaliases: header in debian/control, any .deb can announce the hardware it support in a way my prototype understand. This allow those publishing packages in an APT source outside the Debian archive as well as those backporting packages to make sure the hardware mapping are included in the package meta information. I've tested such header in the pymissile package, and its modalias mapping is working as it should with my prototype. It even made it to Ubuntu Raring. To test if it was possible to look up supported hardware using only the shell tools available in the Debian installer, I wrote a shell implementation of the lookup code. The idea is to create files for each modalias and let the shell do the matching. Please check out and try the hw-support-lookup shell script. It run without any extra dependencies and fetch the hardware mappings from the Debian archive and the subversion repository where I currently work on my prototype. When I use it on a machine with a yubikey inserted, it suggest to install yubikey-personalization:

% ./hw-support-lookup
yubikey-personalization
%

When I run it on my Thinkpad X40 with a PCMCIA/CardBus slot, it propose to install the pcmciautils package:

% ./hw-support-lookup
pcmciautils
%

If you know of any hardware-package mapping that should be added to my database, please tell me about it. It could be possible to generate several of the mappings between packages and hardware. One source would be to look at packages with kernel modules, ie packages with *.ko files in /lib/modules/, and extract their modalias information. Another would be to look at packages with udev rules, ie packages with files in /lib/udev/rules.d/, and extract their vendor/model information to generate a modalias matching rule. I have not tested any of these to see if it work. If you want to help implementing a system to let us propose what packages to install when new hardware is plugged into a Debian machine, please send me an email or talk to me on #debian-devel.

I got some feedback that the analogy I used in my last post was a bit confusing, and indeed I blew the phrasing of the analogy (also now corrected). So let me try this again, since I think there's a subtlety here that may be missed. I should note for the record that my understanding of what Swartz did that started the process is apparently somewhat based on the description from the prosecution, so it may not be the complete or accurate facts. Since there will now be no trial, we may never find out what the defense was, and whether those facts would be challenged. So it may be best to think of this as a hypothetical. We never established, or will establish, in court exactly what happened. Swartz was, generally speaking, charged with two things that I consider quite distinct, at least from an ethical perspective. Most of the focus is on the copyright part: downloading JSTOR articles with an intent (never acted upon) to distribute them to the world. There are a bunch of reasons why this may or may not be justified, which are tied into the origin of those articles (many of them were publicly funded) and the legitimacy of copyright licensing agreements. I think there is significant room to hold a variety of opinions on this, although I don't believe that "crime worth 35 years in prison" is even remotely close to justifiable under any interpretation. However, there is a second part of what he was charged with, and that's primarily what I was commenting on, not the copyright part. He allegedly hooked up a laptop in an unlocked MIT wiring closet without permission and then used MIT's network and JSTOR license to download information. This is, to me, a subtlely but entirely distinct act from the question of whether taking JSTOR's data was ethically or legally wrong. Whether or not one believes that JSTOR's copyrights are not legitimate, it's still not okay to use someone else's network and license or to trespass in their wiring closets without permission. (I work in central IT for a university, so this strikes closer to home.) And this is where the analogy came in, which I flubbed. I had originally said that this was akin to "traipsing into someone's barn or backyard shed without their permission and taking some of their tools because you want to use them." The word "taking" was wrong; it falsely implies that you weren't going to return the tools. I had been thinking "taking and then returning" when I wrote that, and the important second part didn't make it into the post. So let's try this again: Swartz's actions at MIT, as I understand them (and many things could change this, such as a revelation that he had MIT's prior permission), are akin to going onto someone's property and into their barn without permission, borrowing their hedge trimmer for a while because you want to use it, and returning the hedge trimmer without any damage when you're done (and without them noticing it was gone). I'm quite fond of this analogy, since I think it clearly establishes two things:

1. Most people are going to be unhappy about this happening and will intuitively feel like it should probably be illegal. Not everyone; there are folks who don't believe in personal property, or at least wouldn't extend it to tools in a barn. But most people will feel that someone should ask first before they come borrow your tools. Even if they don't damage them, even if they return them before you notice they're gone, you might have wanted to use the tool at the same time or they might have damaged them without intending to, and they should just ask first. It's common politeness, and depending on the circumstances, someone who doesn't ask and is covert about borrowing tools might be worth calling the police over.
2. There is absolutely no way in any reasonable moral system that doing this should result in 35 years in prison. Or even 10, or even 1. Yes, most people would consider this a crime, but most people would consider it a minor crime. It's the sort of thing where you might have to impose some consequences just to make sure the message of "knock it off" is delivered firmly, but someone doing this is rude and inconsiderate, not evil.

The JSTOR copyright stuff is more complex to analyze and is more politically divisive, but for me the key points are (a) Swartz never released the data, and (b) JSTOR declined to press charges. To me, that means the deeper copyright questions, which are quite interesting, were never actually reached in this particular case. The crime that did apparently happen was the trespass at MIT, for which I think the above analogy is the right way to think about it. The point I do want people to take away from this is that one should not overlook the trespass at MIT even if one wants to celebrate the undermining of the copyright regime and doesn't believe JSTOR's data should be considered their private property. Social activism and political disobedience are important and often valuable things, but performing your social activism using other people's stuff is just rude. I think it can be a forgivable rudeness; people can get caught up in the moment and not realize what they're doing. But it's still rude, and it's still not the way to go about civil disobedience. For both ethical and tactical reasons, involving bystanders in your act of social activism without their consent is a bad approach. ETA: The problem, of course, with discussing all of this is that while it's relevant and possibly even somewhat important in the broader sense of how our community acts going forward, it also doesn't capture the fact that this was only one incident in a remarkable life. One of the worst problems with the abusive prosecution of Swartz is that it blew this incident completely out of proportion. A moment of arguable judgement should not dominate one's life or cast a shadow over all of one's other accomplishments; the prosecution tried to make it do just that. That's part of what I'm arguing, but ironically that partly feeds into the lack of proportionality in the discussion. I've gotten kind of far afield here, so let me go back and say explicitly: Swartz was a remarkable person who did much to admire and respect, and the world is a worse place without him.

Rusty wrote an insightful post titled What Can I Do To Help? about reactions to new ideas [1]. He suggests that people make an effort to have a positive approach when someone talks about a new idea, it s quite common for people to point out reasons why the new idea might not work out which is discouraging for the person who had the idea. I think that is a really good point. I probably haven t done too well in that regard in the past and will try to do better in future. Code Written by Assholes Rusty previously wrote a post titled If you didn t run code written by assholes, your machine wouldn t boot which implies that we should just let assholes be assholes [2]. That doesn t go well with his What Can I Do To Help? post. Note that I m not accusing Rusty of hypocrisy here, giving advice to help people who want to get along well with others is not in contradiction with refraining from giving unsolicited advice and encouragement to difficult people who have expressed no interest in improving their behavior. A comment on the latter post by Doctor Whom says If I had seen this kind of talk when I was a teenager, I would have thought twice about picking up coding , presumably given the number of people who read Rusty s blog there are some teenagers who experienced some discouragement towards a career in computers (or a hobby in FOSS) from Rusty s post. I ve already written a response to the If you didn t run code written by assholes post, among other things I suggested that people who are minor assholes should be assisted to be less difficult and major assholes should be excluded [3]. In that post I was working on the assumption that for every significant task that needs to be completed (such as making a popular OS bootable) someone will do it, if the person working on it disappears then someone else will take over there is a community of programmers who will work on whatever needs to be done. The Importance of Individuals But in terms of new ideas it really comes down to individuals. Most projects which are significant and important now probably started out as one person or a small group who had an idea that seemed unlikely to succeed at the time. So while any big and successful project can have people replaced (which is among other things a requirement of long-term success) there are situations in which individuals with ideas matter. Another important factor is that even ideas which turn out to be impractical are still useful. Someone who has an impractical idea about a technical issue and investigates it fully will learn a lot and may end up working on the less radical ways of solving similar problems this is good for the individual and the community. Another Way of Promoting Enthusiasm In terms of promoting enthusiasm it seems that one thing that can be done by high profile people is to avoid writing posts like If you didn t run code written by assholes, your machine wouldn t boot . When people in positions of power and influence appear to have no interest in promoting good behavior it really discourages people who are vulnerable to the assholes which among other things means most members of minority groups. Obviously Rusty could t stamp out all asshole behavior, but if he announced a plan to try and make things better in that regard then it would help. It s difficult to be enthusiastic when faced with discrimination from a minority and disinterest from the majority. Of course with the way the Internet works I m sure someone will say what about the assholes who have great ideas, shouldn t we nurture their enthusiasm by letting them keep doing asshole things? . I think that for the major assholes this won t be a problem, for example anyone who s racist will be well aware that many people disagree strongly with them and thus won t be particularly discouraged when they meet more people who disagree. For the minor assholes (people who don t want to be assholes) it will be somewhat discouraging to be corrected, but that could be a learning experience for them that s worth more than support in implementing their latest technical idea. Update: Why Rusty is Important In response to a comment by private mail I ve added this section after publication. Firstly I think that the opinions of all members of the community matter as they all affect the social environment which determines what types of behavior are encouraged and discouraged. But Rusty is more important than most people. Firstly Rusty has a Wikipedia page [4], that alone is an objective criteria indicating his importance. But in terms of influencing people in the FOSS community the most important things are that he s a high profile Linux kernel programmer (which alone gives significant status and influence) and that he s the founder of the first Linux conference in Australia (which is now known as Linux.conf.au AKA LCA). When issues such as the anti-harassment policy for LCA are being discussed any opinion that Rusty offered would be taken very seriously. But so far he doesn t seem to be involved in any of the public discussions.

• [1] http://rusty.ozlabs.org/?p=282
• [2] http://rusty.ozlabs.org/?p=196
• [3] http://etbe.coker.com.au/2011/05/25/are-assholes-essential/
• [4] http://en.wikipedia.org/wiki/Rusty_Russell

While looking into how to look up Debian packages based on hardware information, to find the packages that support a given piece of hardware, I refreshed my memory regarding modalias values, and decided to document the details. Here are my findings so far, also available in the Debian Edu subversion repository: Modalias decoded This document try to explain what the different types of modalias values stands for. It is in part based on information from <URL: https://wiki.archlinux.org/index.php/Modalias >, <URL: http://unix.stackexchange.com/questions/26132/how-to-assign-usb-driver-to-device >, <URL: http://code.metager.de/source/history/linux/stable/scripts/mod/file2alias.c > and <URL: http://cvs.savannah.gnu.org/viewvc/dmidecode/dmidecode.c?root=dmidecode&view=markup >. The modalias entries for a given Linux machine can be found using this shell script:

find /sys -name modalias -print0   xargs -0 cat   sort -u

The supported modalias globs for a given kernel module can be found using modinfo:

% /sbin/modinfo psmouse   grep alias:
alias:          serio:ty05pr*id*ex*
alias:          serio:ty01pr*id*ex*
%

PCI subtype A typical PCI entry can look like this. This is an Intel Host Bridge memory controller:

pci:v00008086d00002770sv00001028sd000001ADbc06sc00i00

This represent these values:

 v   00008086  (vendor)
 d   00002770  (device)
 sv  00001028  (subvendor)
 sd  000001AD  (subdevice)
 bc  06        (bus class)
 sc  00        (bus subclass)
 i   00        (interface)

The vendor/device values are the same values outputted from 'lspci -n' as 8086:2770. The bus class/subclass is also shown by lspci as 0600. The 0600 class is a host bridge. Other useful bus values are 0300 (VGA compatible card) and 0200 (Ethernet controller). Not sure how to figure out the interface value, nor what it means. USB subtype Some typical USB entries can look like this. This is an internal USB hub in a laptop:

usb:v1D6Bp0001d0206dc09dsc00dp00ic09isc00ip00

Here is the values included in this alias:

 v    1D6B  (device vendor)
 p    0001  (device product)
 d    0206  (bcddevice)
 dc     09  (device class)
 dsc    00  (device subclass)
 dp     00  (device protocol)
 ic     09  (interface class)
 isc    00  (interface subclass)
 ip     00  (interface protocol)

The 0900 device class/subclass means hub. Some times the relevant class is in the interface class section. For a simple USB web camera, these alias entries show up:

usb:v0AC8p3420d5000dcEFdsc02dp01ic01isc01ip00
usb:v0AC8p3420d5000dcEFdsc02dp01ic01isc02ip00
usb:v0AC8p3420d5000dcEFdsc02dp01ic0Eisc01ip00
usb:v0AC8p3420d5000dcEFdsc02dp01ic0Eisc02ip00

Interface class 0E01 is video control, 0E02 is video streaming (aka camera), 0101 is audio control device and 0102 is audio streaming (aka microphone). Thus this is a camera with microphone included. ACPI subtype The ACPI type is used for several non-PCI/USB stuff. This is an IR receiver in a Thinkpad X40:

acpi:IBM0071:PNP0511:

The values between the colons are IDs. DMI subtype The DMI table contain lots of information about the computer case and model. This is an entry for a IBM Thinkpad X40, fetched from /sys/devices/virtual/dmi/id/modalias:

dmi:bvnIBM:bvr1UETB6WW(1.66):bd06/15/2005:svnIBM:pn2371H4G:pvrThinkPadX40:rvnIBM:rn2371H4G:rvrNotAvailable:cvnIBM:ct10:cvrNotAvailable:

The values present are

 bvn  IBM            (BIOS vendor)
 bvr  1UETB6WW(1.66) (BIOS version)
 bd   06/15/2005     (BIOS date)
 svn  IBM            (system vendor)
 pn   2371H4G        (product name)
 pvr  ThinkPadX40    (product version)
 rvn  IBM            (board vendor)
 rn   2371H4G        (board name)
 rvr  NotAvailable   (board version)
 cvn  IBM            (chassis vendor)
 ct   10             (chassis type)
 cvr  NotAvailable   (chassis version)

The chassis type 10 is Notebook. Other interesting values can be found in the dmidecode source:

  3 Desktop
  4 Low Profile Desktop
  5 Pizza Box
  6 Mini Tower
  7 Tower
  8 Portable
  9 Laptop
 10 Notebook
 11 Hand Held
 12 Docking Station
 13 All In One
 14 Sub Notebook
 15 Space-saving
 16 Lunch Box
 17 Main Server Chassis
 18 Expansion Chassis
 19 Sub Chassis
 20 Bus Expansion Chassis
 21 Peripheral Chassis
 22 RAID Chassis
 23 Rack Mount Chassis
 24 Sealed-case PC
 25 Multi-system
 26 CompactPCI
 27 AdvancedTCA
 28 Blade
 29 Blade Enclosing

The chassis type values are not always accurately set in the DMI table. For example my home server is a tower, but the DMI modalias claim it is a desktop. SerIO subtype This type is used for PS/2 mouse plugs. One example is from my test machine:

serio:ty01pr00id00ex00

The values present are

  ty  01  (type)
  pr  00  (prototype)
  id  00  (id)
  ex  00  (extra)

This type is supported by the psmouse driver. I am not sure what the valid values are. Other subtypes There are heaps of other modalias subtypes according to file2alias.c. There is the rest of the list from that source: amba, ap, bcma, ccw, css, eisa, hid, i2c, ieee1394, input, ipack, isapnp, mdio, of, parisc, pcmcia, platform, scsi, sdio, spi, ssb, vio, virtio, vmbus, x86cpu and zorro. I did not spend time documenting all of these, as they do not seem relevant for my intended use with mapping hardware to packages when new stuff is inserted during run time. Looking up kernel modules using modalias values To check which kernel modules provide support for a given modalias, one can use the following shell script:

  for id in $(find /sys -name modalias -print0   xargs -0 cat   sort -u); do \
    echo "$id" ; \
    /sbin/modprobe --show-depends "$id" sed 's/^/  /' ; \
  done

The output can look like this (only the first few entries as the list is very long on my test machine):

  acpi:ACPI0003:
    insmod /lib/modules/2.6.32-5-686/kernel/drivers/acpi/ac.ko 
  acpi:device:
  FATAL: Module acpi:device: not found.
  acpi:IBM0068:
    insmod /lib/modules/2.6.32-5-686/kernel/drivers/char/nvram.ko 
    insmod /lib/modules/2.6.32-5-686/kernel/drivers/leds/led-class.ko 
    insmod /lib/modules/2.6.32-5-686/kernel/net/rfkill/rfkill.ko 
    insmod /lib/modules/2.6.32-5-686/kernel/drivers/platform/x86/thinkpad_acpi.ko 
  acpi:IBM0071:PNP0511:
    insmod /lib/modules/2.6.32-5-686/kernel/lib/crc-ccitt.ko 
    insmod /lib/modules/2.6.32-5-686/kernel/net/irda/irda.ko 
    insmod /lib/modules/2.6.32-5-686/kernel/drivers/net/irda/nsc-ircc.ko 
  [...]

If you want to help implementing a system to let us propose what packages to install when new hardware is plugged into a Debian machine, please send me an email or talk to me on #debian-devel. Update 2013-01-15: Rewrite "cat $(find ...)" to "find ... -print0 xargs -0 cat" to make sure it handle directories in /sys/ with space in them.

The Debian package of the Linux kernel has some additional features not present in mainline Linux 3.2. This continues from part 1 and part 2. Real-time scheduling The 'PREEMPT_RT' aka 'linux-rt' patchset provides true real-time scheduling under Linux. This can allow applications to respond to I/O with very low latency and jitter, although the results depend on application design and on the hardware and firmware used. Real-time scheduling is commonly used in industrial control, live audio/video applications, and high-frequency trading systems; it can also be useful for tightly-coupled cluster computing. However, most applications will run more slowly under these kernels, and may not be any more responsive. The Linux 3.2-rt stable series maintained by Steven Rostedt is used to build alternate kernels for amd64 and i386. You can install these using the metapackage linux-image-rt-amd64 or linux-image-rt-686-pae. Hyper-V guest drivers Like most VM hypervisors, Microsoft Hyper-V supports paravirtualised drivers which can provide much better performance than emulation of old hardware devices. Linux 3.2 had quite early versions of these drivers that were relegated to the 'staging' area, but we've updated them to the much improved versions found in Linux 3.4. I hoped we would also be able to package the userland daemon that supports management of Hyper-V guests, but this also needed many fixes and wasn't ready in time.

I recently added a formal interface to testrepository to enable cross-machine scaling of test runs. As testrepository is still a static scheduler, this isn t perfect, but its quite a minimal interface, which makes it easy to implement. I will likely evolve it in reaction to feedback and experience. In the long term I d love to have a super generic tool that matches that interface, so the project VCS copy of .testr.conf can just call out to it. However I don t yet have that, but I do have a simple by-hand implementation that I use to run nova s tests across my personal laptop, desktop and work laptop. Testr models this by assuming each test running process can be mapped to a single instance id (which could be a chroot, vm, cloud instances, ) and then running one or more commands in the instance, before disposing of it. This by hand implementation consists of 4 things:

1. A tiny script to rsync my source directory to the relevant places before I run tests. (This takes <2seconds on my home wifi).
2. A script to allocate instance ids (I just use ints)
3. A script to discard them
4. And a script to copy tempfiles onto the target machine and run a given command.

I do my testing in lxc containers, because I like my primary environment to be free of project-specific quirks and workarounds. lxc is not needed though, if you don t want it. So, to set this up for yourself:

1. on each host, make an lxc container (e.g. following) http://wiki.openstack.org/DependsOnUbuntu
2. start them all (lxc-start -n nova -d)
3. Make SSH config entries for the lxc containers, so you can get at them remotely. (make sure your host * rules are at the end of the file otherwise the master overrides won t work [and you might not notice for some time...]):

   Host desktop-nova.lxc
   # lxc addresses may be present on localhost too, so namespace the control
   # path to avoid connecting to the wrong container.
     ControlPath ~/.ssh/master-lxc-%r@%h:%p
     hostname 10.0.3.19
     ProxyCommand ssh 192.168.1.106 nc -q0 %h %p
   Host hplaptop-nova.lxc
   # lxc addresses may be present on localhost too, so namespace the control
   # path to avoid connecting to the wrong container.
     ControlPath ~/.ssh/master-lxc-%r@%h:%p
     hostname 10.0.3.244
     ProxyCommand ssh 192.168.1.116 nc -q0 %h %p

4. make a script to copy your nova source tree to each test location. I called mine sync

   #!/bin/bash           
   cd $(dirname $0)
   echo syncing in $(pwd) 
   (rsync -a . desktop-nova.lxc:source/openstack/nova --delete-after && echo dell done) &
   (rsync -a . hplaptop-nova.lxc:source/openstack/nova --delete-after && echo hp done)

5. Make sure you have the base directory on each location

   ssh desktop-nova.lxc mkdir -p source/openstack
   ssh hplaptop-nova.lxc mkdir -p source/openstack

6. Sync your code over.

   ./sync

7. And check tests run by running a few.

   ssh hplaptop-nova.lxc "cd source/openstack/nova && ./run_tests.sh compute"
   ssh hplaptop-nova.lxc "cd source/openstack/nova && ./run_tests.sh compute"

   This will check the test environment: we re not going to be running tests on each node via run-tests or even testr (because it gets immediately meta), but if this fails, later attempts won t work. Your test virtualenv is inside the source tree, so it is copied implicitly by the sync.
8. Decide what concurrency you want. For me, I picked 12: I have a desktop i7 with 4 cores, and two laptops with 2 cores each, and hyperthreads are on on all of them I m going to set a concurrency figure of 12 between the cores (8) and threads (16) counts, and possibly balance it more in future. A higher number assumes less contention between ALU s and other elements of the core pipeline, and I expect quite some contention because most of nova s unittests are CPU bound not I/O. If the test servers are not busy, I can always raise it later.
9. Create scripts to create / dispose / execute logical worker threads.
10. Creation. I call this instance-provision and all it does is find the lowest ints not currently allocated and return them.

    #!/usr/bin/env python
    import os.path
    import sys
    if not os.path.isdir('.instances'):
        os.mkdir('.instances')
    running_ids = os.listdir('.instances')
    count = int(sys.argv[1])
    top = count + len(running_ids)
    ids = [str(i) for i in range(top)]
    new = set(ids) - set(running_ids)
    for id in new:
        file('.instances/%s' % id, 'w').close()
    print(' '.join(new))

11. Disposal is easy: remove the file marking the instance as in-use.

    #!/bin/bash
    echo freeing $@
    cd .instances
    rm $@

12. Execution is a little trickier. We need to run some commands locally, and other ones by copying in temp files that testr has setup to the machine sshing to the remote machine, cd ing to the right directory, sourcing the virtual env, and finally running the command.

    #!/bin/bash
    instance="$(($1 % 4))"
    case $instance in
    [0]) node=
         local="true"
         ;;
    [1]) node=hplaptop-nova.lxc
         local=""
         ;;
    [2-3]) node=desktop-nova.lxc
         local=""
         ;;
    *)   echo "Unknown instance $instance" >&2
         exit 1
         ;;
    esac
    shift
    files=
    # accumulate files to copy
    while [ "--" != "$1" ]; do 
    files="$files $1"
    shift ; done 
    shift   
    if [ -n "$files" -a -z "$local" ]; then
        echo copying $files to node.
        for f in $files; do
            rsync $f $node:$(dirname $f) ;
        done
    fi  
    if [ -n "$local" ]; then
        eval $@
    else
        echo ssh to $node
        ssh $node "cd source/openstack/nova && . .venv/bin/activate && $@"
    fi

13. Finally, tell testr how to use this. (Don t commit this change to nova, as it would break other people). Add this to your .testr.conf.

    test_run_concurrency=echo 12
    instance_provision=./instance-provision $INSTANCE_COUNT
    instance_execute=./instance-execute $INSTANCE_ID $FILES -- $COMMAND
    instance_dispose=./instance-dispose $INSTANCE_IDS

Now, when you run testr run parallel, it will run across your machines. Just do a ./sync before running tests to get the code out there. It is possible to wrap all of this up via automation (or to include just-in-time provisioned cloud instances), but I like the results of still rough scripts here it strikes a good balance between effort, reliability and performance.

the count of RC bugs is rather constant, & my impact on it during this week was rather negligible again:

• #671690 libgamin0: "libgamin0 breaks courier-imap/courier-imap-ssl (Sudden termination of connection)"
  add some info to the bugreport, do a manual versioned close after confirmation from bug submitter
• #690152 src:bsaf: "bsaf: FTBFS: Test org.jdesktop.application.TaskMonitorTest failed"
  add some info to the bugreport
• #697892 src:virtualbox: "src:virtualbox: FTBFS in sid and experimental: /usr/bin/kmk_sed: file /tmp/buildd/virtualbox-4.1.18-dfsg/src/VBox/Runtime/common/err/errmsg.sed line 31: Unmatched [ or [^"
  report new RC bug

Normally, I'm not that much of a fan of the slacktivist trend of signing pre-canned petitions, signing things that political organizations send in the mail, and so forth. It takes very little effort and therefore carries very little weight. A lot of those efforts are more exercises in helping the signers feel better about themselves. But there is the occasional exception. Most of you probably already know about the death of Aaron Swartz. For those who aren't familiar, see Larry Lessig's article. Swartz suffered from depression (and, seriously, fuck depression it's an awful, horrible disease), but there's little doubt that the ongoing federal prosecution using the full weight of the US district attorney's office to hound him for what amounts to political trespassing was part of what led to his suicide. As it happens, I personally believe that Swartz committed a crime, and probably should have paid some consequence for it (on the order of a fine or some community service). Hooking your devices up to someone else's network without their permission and messing around in their wiring closets (locked or not) is, for me, akin to traipsing into someone's barn or backyard shed without their permission and using some of their tools because you want to use them. And whether or not one likes the current copyright regime (and I don't like it at all), MIT is still in the awkward position of having to work with it. Abusing their license for your political goals is effectively recruiting them into your activism without their permission, and as I've mentioned before, I have a mild obsession with consent. It was a crime. However, it was a minor crime, and that's where this whole situation went completely off the rails. One aspect of a justice system is fairness: uniform application of the laws to everyone. However, another aspect of a justice system is proportionality: punishments that fit the crime. Without ever having been convicted, Swartz was already punished completely out of proportion to what he actually did, both financially and emotionally, by prosecution by the US attorney that went far, far beyond zealous into actively abusive. This despite the fact that the owner of the academic papers that he was downloading as an act of open access activism stated they did not want the case to proceed and asked the US government to drop the charges. I don't think what Swartz did was right, or legal. However, the correct reaction was "look, involuntarily recruiting MIT as an accomplice to your act of civil disobedience is not okay don't ever do that again." Not "you are evil and should be locked up in prison for 35 years." And I'm completely fed up with the disproportionality of our justice system and the practice of ridiculous over-charging of crimes in an attempt to terrify people into bad plea bargains. Which brings me to the slacktivism. This is exactly the sort of situation where popular opinion matters. US attorneys who have lost the faith and support of the population they serve won't keep their jobs. And no one in government particularly wants this case to be splashed across the front pages, or to have to answer questions about the appropriateness or proportionality of the prosecution while people are mourning a dead young man. If we make it clear enough to the Obama administration that people are watching, that this matters, and that we're angry about it, not only is it quite likely there will be consequences for this prosecutor, but it may serve as a deterrant for other prosecutors in the future. There is a petition on WhiteHouse.Gov to remove the district attorney for prosecutorial overreach, and for once taking five minutes to create an account and clicking on a petition may be both useful and appropriate. Taking disciplinary action here is, unlike with a lot of petitions, something that the Obama administration can actually do, directly, without involving the rest of the dysfunctional US government, and without making new law. If you are a US citizen, please consider going to this site and signing it to say that this matters to you and you believe this prosecution was excessive and inappropriate. Please note: you do not have to believe that Swartz died solely or even primarily because of this prosecution to do this. We'll never really know the complex factors behind his death. But this was a burden that he shouldn't have had to deal with. Please also note that you do not have to think he was justified in his behavior to sign this petition. This is not a question of whether what he did should be legal or was ethical. Rather, even assuming it was illegal, it's a question of appropriate punishment and proportionality of response. Whether or not you agree with his political cause, there simply was not enough damage done, to anyone, to warrant this kind of aggressive prosecution. And the direct victims agreed, which was the point at which the district attorney should have scaled way back on their actions or dropped the matter entirely. Not doing so was an abuse of office and position, and that should have consequences. ETA: Corrected "taking" to "using" in the analogy about tools. I was actually thinking "taking and then returning" when I wrote that, but only the first word made it into the post, and ended up creating a confusing parallel with theft that wasn't intended.

The Debian package has some additional features not present in mainline Linux 3.2. Some of these were described in part 1, and this continues the list. CPU devices CPUs are exposed in the device model as normal devices, not 'sysdevs'. For x86 CPUs, model and feature information is included in the uevent for the CPU device. This results in automatic loading of appropriate device drivers with the help of udev, rather than specialised init scripts:

• CPU frequency scaling drivers
• The intel_idle driver
• CPU temperature monitoring drivers
• Crypto drivers that use extensions such as SSE or VIA Padlock

Control groups Most control groups (cgroups) features are included, but some are disabled by default at run-time:

• The memory controller is disabled and can be enabled using the kernel parameter cgroup_enable=memory.
• Scheduler auto-grouping is disabled and can be enabled through the sysctl kernel.sched_autogroup_enabled.

EFI stub On x86 architectures the kernel is built as an EFI executable which can be directly loaded from an EFI shell, e.g.:

Shell> vmlinuz-3.2.0-4-amd64 root=/dev/sda2 initrd=initrd.img-3.2.0-4-amd64

Debian will usually boot on an EFI system via grub-efi, but this can be useful for some unusual configurations and some of the simple EFI boot loaders that are currently being developed. Linux Security Modules The kernel side of AppArmor has some extensions for backward compatibility with AppArmor userland versions 2.4-2.7, matching wheezy userland. Debian appears to be the only major distribution to provide a choice of LSMs: AppArmor, SELinux or TOMOYO. Use the security= boot parameter to enable any of them. CPU microcode updates for Xen Like all hardware, CPUs have bugs, which can sometimes be fixed in microcode. x86 microcode updates may be applied by either the BIOS or operating system, but it's easier to upgrade packages than to upgrade the BIOS. Xen 4.1 can apply microcode updates but relies on the dom0 kernel to load them, and the mainline Linux kernel does not do this. We include an extension of the microcode loader that does so.

As I couldn t retain my curiosity for Ubuntu s Raring Ringtail release, I ended up having a dual boot with Ubuntu 13.04 and Debian Sid. Even thought at the moment 13.04 is only 24% complete, it s already a pretty promising release. However, one thing that heavily annoyed me is that global menu and HUD (still) don t work out of box with Eclipse IDE. Being part of Debian Java team (working on Eclipse) I had to do something about it. To make it as simple as possible for you, I made a package which enables mentioned features. Package is made for/tested and working on 32/64 bit architectures on 12.04/12.10/13.04 Ubuntu.

• sudo add-apt-repository ppa:absinthesyringe/eclipse
• sudo apt-get update && sudo apt-get install eclipse-enable.appmenu

In following days I ll push a Eclipse patch which will enable global menu and HUD support out of box, thus eliminating need to install this package in future.

PSA: Referring to Unicode codepoints. If your Unicode codepoint is, numerically, between 0 and 65533, inclusive, convert it to hexadecimal and zero-pad it to four nibbles. For example, the Euro sign is Unicode codepoint #8364 which is 20AC hex; the Eszett is 223 which is DF hex, padded 00DF.
Then write an uppercase U , a plus sign + , and the four nibbles: U+20AC U+00DF
In mksh, JSON, etc. it s a backslash \ , a lower-case u and four nibbles. Otherwise, your Unicode codepoint will be, numerically, between 65536 and 1114111, inclusive, that is hex 10000 to 10FFFF. (There s nothing on 65534 and 65535, nor above these figures.) In this case, convert it to hex, zero-pad it to eight nibbles and write it as an uppercase U , a hyphen-minus - and the eight nibbles. In C-like escapes for environments supporting the Unicode SMP, that s a backslash \ , an upper-case U and eight nibbles. Do not, in either case, use less (or more) hex digits than specified here. For example, there s a famous Unicode codepoint U-0001F4A9 PILE OF POO . That s not the same as U+1F4A9. The latter reads as U+1F4A GREEK CAPITAL LETTER OMICRON WITH PSILI AND VARIA and a digit 9 ( 9). Be educated.

While almost everyone has already worked with cryptographic signatures, they are usually only used as black boxes, without taking a closer look. This article intends to shed some lights behind the scenes. Let's take a look at some signature. In ascii-armoured form or behind a clearsigned message one often does only see something like this:

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJQ8qxQAAoJEH8RcgMj+wLc1QwP+gLQFEvNSwVonSwSCq/Dn2Zy
fHofviINC1z2d/voYea3YFENNqFE+Vw/KMEBw+l4kIdJ7rii1DqRegsWQ2ftpno4
BFhXo74vzkFkTVjo1s05Hmj+kGy+v9aofnX7CA9D/x4RRImzkYzqWKQPLrAEUxpa
xWIije/XlD/INuhmx71xdj954MHjDSCI+9yqfl64xK00+8NFUqEh5oYmOC24NjO1
qqyMXvUO1Thkt6pLKYUtDrnA2GurttK2maodWpNBUHfx9MIMGwOa66U7CbMHReY8
nkLa/1SMp0fHCjpzjvOs95LJv2nlS3xhgw+40LtxJBW6xI3JvMbrNYlVrMhC/p6U
AL+ZcJprcUlVi/LCVWuSYLvUdNQOhv/Z+ZYLDGNROmuciKnvqHb7n/Jai9D89HM7
NUXu4CLdpEEwpzclMG1qwHuywLpDLAgfAGp6+0OJS5hUYCAZiE0Gst0sEvg2OyL5
dq/ggUS6GDxI0qUJisBpR2Wct64r7fyvEoT2Asb8zQ+0gQvOvikBxPej2WhwWxqC
FBYLuz+ToVxdVBgCvIfMi/2JEE3x8MaGzqnBicxNPycTZqIXjiPAGkODkiQ6lMbK
bXnR+mPGInAAbelQKmfsNQQN5DZ5fLu+kQRd1HJ7zNyUmzutpjqJ7nynHr7OAeqa
ybdIb5QeGDP+CTyNbsPa
=kHtn
-----END PGP SIGNATURE-----

This is actually only a form of base64 encoded data stream. It can be translated to the actual byte stream using gpg's --enarmor and --dearmour commands (Can be quite useful if some tool only expects one BEGIN SIGNATURE/END SIGNATURE block but you want to include multiple signatures but cannot generate them with a single gpg invocation because the keys are stored too securely in different places). Reading byte streams manually is not much fun, so I wrote gpg2txt some years ago, which can give you some more information. Above signature looks like the following:

89 02 1C -- packet type 2 (signature) length 540
        04 00 -- version 4 sigclass 0
        01 -- pubkey 1 (RSA)
        02 -- digest 2 (SHA1)
        00 06 -- hashed data of 6 bytes
                05 02 -- subpacket type 2 (signature creation time) length 4
                        50 F2 AC 50 -- created 1358081104 (2013-01-13 12:45:04)
        00 0A -- unhashed data of 10 bytes
                09 10 -- subpacket type 16 (issuer key ID) length 8
                        7F 11 72 03 23 FB 02 DC -- issuer 7F11720323FB02DC
        D5 0C -- digeststart 213,12
        0F FA -- integer with 4090 bits
                02 D0 [....]

Now, what does this mean. First all gpg data (signatures, keyrings, ...) is stored as a series of blocks (which makes it trivial to concatenate public keys, keyrings or signatures). Each block has a type and a length. A single signature is a single block. If you create multiple signatures at once (by giving multiple -u to gpg) there are simple multiple blocks one after the other. Then there is a version and a signature class. Version 4 is the current format, some really old stuff (or things wanting to be compatible with very old stuff) sometimes still have version 3. The signature class means what kind of signature it is. There are roughly two signature classes: A verbatim signature (like this one), or a signature of a clearsigned signature. With a clearsigned signature not the file itself is hashed, but instead a normalized form that is supposed to be invariant under usual modifications by mailers. (This is done so people can still read the text of a mail but the recipient can still verify it even if there were some slight distortions on the way.) Then the type of the key used and the digest algorithm used for creating this signature. The digest algorithm (together with the signclass, see above) describes which hashing algorithm is used. (You never sign a message, you only sign a hashsum. (Otherwise your signature would be as big as your message and it would take ages to create a signature, as asymetric keys are necessarily very slow)). This example uses SHA1, which is no longer recommended: As SHA1 has shown some weaknesses, it may get broken in the not too distant future. And then it might be possible to take this signature and claim it is the signature of something else. (If your signatures are still using SHA1, you might want to edit your key preferences and/or set a digest algorithm to use in your ~/.gnupg/gpg.conf. Then there are some more information about this signature: the time it was generated on and the key it was generated with. Then, after the first 2 bytes of the message digest (I suppose it was added in cleartext to allow checking if the message is OK before starting with expensive cryptograhic stuff, but it might not checked anywhere at all), there is the actual signature. Format-wise the signature itself is the most boring stuff. It's simply one big number for RSA or two smaller numbers for DSA. Some little detail is still missing: What is this "hashed data" and "unhashed data" about? If the signed digest would only be a digest of the message text, then having a timestamp in the signature would not make much sense, as anyone could edit it without making the signature invalid. That's why the digest is not only signed message, but also parts of the information about the signature (those are the hashed parts) but not everything (not the unhashed parts).