Who finished DEP 5?

Many people worked on finishing DEP 5. I think that the blog of Lars does not show enough how collective the effort was.

Looking in the specification's text, one finds:

The following alphabetical list is incomplete; please suggest missing people:
Russ Allbery, Ben Finney, Sam Hocevar, Steve Langasek, Charles Plessy, Noah
Slater, Jonas Smedegaard, Lars Wirzenius.

The Policy's changelog mentions:

  * Include the new (optional) copyright format that was drafted as
    DEP-5.  This is not yet a final version; that's expected to come in
    the release.  Thanks to all the DEP-5 contributors and to
    Lars Wirzenius and Charles Plessy for the integration into the
    Policy package.  (Closes: #609160)

 -- Russ Allbery <rra@debian.org>  Wed, 06 Apr 2011 22:48:55 -0700


debian-policy ( unstable; urgency=low

  [ Russ Allbery ]
  * Update the copyright format document to the version of DEP-5 from the
    DEP web site and apply additional changes from subsequent discussion
    in debian-devel and debian-project.  Revise for clarity, to add more
    examples, and to update the GFDL license versions.  Thanks, Steve
    Langasek, Charles Plessy, Justin B Rye, and Jonathan Nieder.
    (Closes: #658209, #648387)

On my side, I am very grateful to Bill Alombert for having committed the document in the Git repository, which ended the debates.

Amazon cloud: refreshing my skills.

For a few years I did not attempt any serious task on the Amazon cloud. It took me a bit of time to get back my automatisms and adapt myself to the changes. In particular, the cheapest instances, t2.nano, are only accessible via virtual private clouds (VPC), and it was a bit difficult for me to find how to create a simple one. Perhaps this is because all AWS accounts created after March 18, 2013, automatically have a default VPC, and everybody else who needed their own simple VPC have created it a long time ago already. In the end, this was not complicated at all. This is probably why I could not find a tutorial.

In brief, one needs first to create a VPC. If it is just for spawning an instance from time to time, the IP range does not matter much. Default VPCs are using, so let's do the same.

aws ec2 create-vpc --cidr-block $CIDR_BLOCK

In the command's output, there is the VPC's identifier, that I paste by hand in a variable called VPC. The same pattern will be repeated for each command creating something. One can also find the VPC's identifier with the command aws ec2 describe-vpcs.


Then, create a subnet. Again, no need for complications, in our simple case one can give the full IP range. I cut and paste the returned identifier in the variable SUBNET. In order that the instances receive a public IP address like in default VPCs and like in the usual behaviour of the VPC-less Cloud, one needs to set the attribute MapPublicIpOnLaunch.

aws ec2 create-subnet --vpc-id $VPC --cidr-block $CIDR_BLOCK
aws ec2 modify-subnet-attribute --subnet-id $SUBNET --map-public-ip-on-launch 

Then, create a gateway (paste the identifier in GATEWAY) and attach it to the VPC.

aws ec2 create-internet-gateway
aws ec2 attach-internet-gateway --internet-gateway-id $GATEWAY --vpc-id $VPC

A routing table was created automatically, and one can find its identifier via the command describe-route-tables. Then, create a default route to the gateway.

aws ec2 describe-route-tables
aws ec2 create-route --route-table-id $ROUTETABLE --destination-cidr-block --gateway-id $GATEWAY

Of course, if one does not open the traffic, no instance can be contacted from outside... Here I open port 22 for SSH.

aws ec2 describe-security-groups
aws ec2 authorize-security-group-ingress --group-id $SECURITY_GROUP --protocol tcp --port 22 --cidr

Other novelty, now Amazon distributes some Free tools for the command line, that are more comprehensive than euca2ools.

Next, I will try again the Debian Installer in the Cloud.

The slippery slope.

Step by step, one slips towards the bottom:

  1. One should be blunt with those who are wrong.
  2. One is blunt when one is right.
  3. When one thinks to be right, one is blunt.
  4. One is wrong and blunt.

Let's note anyway that one can slip to the bottom without being vulgar or insulting. In any large project like Debian, one can find people who know how to be very oppressive, while keeping a very “correct” communication style. Debian is a broad project, and it is easy to avoid them, unless one tries make contributions that can be related to keywords like “committee”, “code”, “policy”, “delegation”, etc. In that case, it is better to retrieve the good old thick skin from the cupboard where we stored it after our code of conduct was adopted...

Long life to Jessie!

Debian published Jessie last month. Big congratulations to the release team and all the contributors; quality is again at the rendez-vous!

This time, I could not contribute much, being busy with parental activities (hello my son, if you read me), apart from making sure that my packages are ready for the D Day. This work was made easy by the automated removals of buggy packages set up by the release team. Many thanks for that development.

I hope to use Jessie for a long time without the need of upgrading to Testing. At the moment, it provides everything I need, including the input of Japanese characters together with the possibility to switch between Japanese (or American) and multilingual Canadian keyboard layouts, which was not easy to do anymore in Wheezy.

Many thanks again.

News of the package mime-support.

The package mime-support is installed by default on Debian systems. It has two roles: first to provide the file /etc/mime.types that associates media types (formerly called MIME types) to suffixes of file names, and second to provide the mailcap system that associates media types with programs. I adopted this package at the end of the development cycle of Wheezy.

Changes since Wheezy.

The version distributed in Jessie brings a few additions in /etc/mime.types. Among them, application/vnd.debian.binary-package and text/vnd.debian.copyright, which as their name suggest describe two file formats designed by Debian. I registered these types to the IANA, which is more open to the addition of new types since the RFC 6838.

The biggest change is the automatic extraction of the associations between programs and media types that are declared in the menu files in FreeDesktop format. Before, it was the maintainer of the Debian package who had to extract this information and translate it in mailcap format by hand. The automation is done via dpkg triggers.

A big thank you to Kevin Ryde who gave me a precious help for the developments and corrections to the run-mailcap program, and to all the other contributors. Your help is always welcome!

Security updates.

In December, Debian has been contacted by Timothy D. Morgan, who found that an attacker could get run-mailcap to execute commands by inserting them in file names (CVE-2014-7209). This first security update for me went well, thanks to the help and instructions of Salvatore Bonaccorso from the Security team. The problem is solved in Wheezy, Jessie and Sid, as well as in Squeeze through its long term support.

One of the consequences of this security update is that run-mailcap will systematically use the absolute path to the files to open. For harmless files, this is a bit ugly. This will perhaps be improved after Jessie is released.

Future projects

The file /etc/mime.types is kept up to date by hand; this is slow and inefficient. The package shared-mime-info contains similar information, that could be used to autogenerate this file, but that would require to parse a XML source that is quite complex. For the moment, I am considering to import Fedora's mailcap package, where the file /etc/mime.types is very well kept up to date. I have not yet decided how to do it, but maybe just by moving that file from one package to the other. In that case, we would have the mime-support package that would provide mailcap support, and the package whose source is Fedora's mailcap package who would provide /etc/mime.types. Perhaps it will be better to use clearer names, such as mailcap-support for the first and media-types for the second?

Separating the two main functionalities of mime-support would have an interesting consequence: the possibility of not installing the support for the mailcap system, or to make it optional, and instead to use the FreeDesktop sytem (xdg-open), from the package xdg-utils. Something to keep in mind...


apt install nodejs-legacy if you want npm install to work.

Browsing debian-private via SSH

I recently realised that one can browse the archives of debian-private via SSH. I find this a good compromise between subscription and ignorance. Here is for instance the command for November.

ssh -t master.debian.org mutt -f /home/debian/archive/debian-private/debian-private.201411
Did we need a general resolution?

In 2009 I called for a general resolution regarding membership procedures in Debian, to block a change that, in my opinion, was going against our values. Results, even if they satisfied the majority came with a bitter feeling and it became questioned whether a better solution could have been reached without using a constraining procedure. I did not think so, but not to the point of not having doubts about it, and therefore, regrets.

This year, we are again having a vote related to a change that some people think it goes against our values, and again the existence of this vote makes it hard to find compromises. Bitterness will win whatever the result is. For the avoidance of doubt, I have proposed the amendment number 3, stating that this general resolution should not have been started.

I hope that this amendment will defeat the original proposition and will make people think twice before pressing Debian's alarm button next time.

PS: amendment 3, that is amendment C, that is choice 4. If there was a need for an example that the procedure is complex, here it is...