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...

Posted
nodejs-legacy

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

Posted
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
Posted
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...

Posted
European consultation on copyrights.

I eventually answered to the Public Consultation on the review of the EU copyright rules. As a coincidence, the radio was playing European Super State, from Killing Joke.

One can see in the consultation the picture of an Internet shaped to better control the diffusion and copy of non-free works, and monitor for possible infractions. It is therefore important to answer and remind primacy of the presumption of innocence, and the importance of the respect of privacy.

Nevertheless, I also asked for reducing exceptions of copyrights, because to give a temporary access to non-free works at zero cost has the consequence of reducing the incentive for creating alternatives that can be copied, modified and redistributed freely.

Posted
Tired

This morning when preparing the update of a package, and I saw a PNG file in its documentation. Even before opening it, I felt old, tired, distressed and unable to escape the situation. Inspecting the file confirmed that the image was not hand made. The source file is missing. The proof: anther image in the same directory has the same style and a SVG source. To make things worse, there are no instructions on how to generate the PNG from the SVG. More and more in these cases, I give up and abandon the package. I lost time and energy make Upstream some requirements for which I personally have no concrete interest. SVG in addition to PNG is better, but PNG alone for the documentation of a Free software is Free enough for me. However, the points of view expressed on debian-devel give me the impression that it is not good enough for Debian, so I just give up…

Posted
The source of a package developed in a Git repository is that repository.

In his blog, Lars puts words on my feelings of weariness in these situations where we are asked much efforts to make our packages modifiable by contributors who can not or want not to use Git.

Most of the core Debian tools, dpkg, debhelper, litnian, debian-installer and many others are developed in Git repositories. Somebody serious about contributing to Debian can hardly avoid Git.

It is time for our tools and methods to evolve and take advantage of Git. This requires to say “no thank you” to contributions based on source packages downloaded from our FTP server, instead of being cloned from the Git repository where the package is actually developed, and this calls the question of what is the real source of the binary packages, but this is a question that is becoming unavoidable.

Posted
Debian-Installer in the Amazon cloud.

I prepared machine images of the Debian Installer in each region of the Amazon Elastic Computing Cloud, following the method that I described earlier, and that I updated and documented in Debian's wiki.

Started with a preseed file, these images install Debian à la carte on a storage volume that can then be registered as a new machine image. This is not yet automatic, but I am working on it. In the meantime, it is possible to install Debian interactively using the network console.

Posted
Update of EMBOSS explorer in Wheezy.

EMBOSS explorer was broken in Debian 7 (Wheezy) because of an incompatibly with EMBOSS 6.4. The package was repaired with the second update (7.2). The development and maintenance of EMBOSS explorer have stopped for many years. If a new serious bug surfaces, we may need to remove the package rather than repair it. In consequence, do not hesitate to suggest us an alternative, or if you are developer and need EMBOSS explorer, to see how you can reinvigorate this project (currently on SourceForge).

Posted
“triggers” in Dpkg and RPM: a comparaison.

Dpkg and RPM provide a mechanism called triggers. But are they doing the same thing?

There are two different types of triggers for Dpkg: explicit and file. In the case of explicit triggers, the script of a package A will activate a package B. The file type is more frequently used. In that case, the creation, modification or deletion of a file in a path declared by a package B will activate the package B. The triggers are often used when a package A has to register an information to a package B. For instance, when a graphical application is installed, its package will add its description in the /usr/share/applications directory, which will trigger the desktop-file-utils package, which will do what is necessary to add a new menu entry in the window manager.

RPM's triggers function differently. The installation, update or removal of a package A will activate a package B if this package B declares its interest for the package A in its SPEC file (with possible restrictions on package A's version). The documentation of RPM and Fedora gives a few examples of use, like the update of symbolic links when one mail server is replaced by another.

Altogether, despite both mechanisms have the same name, they do not have the same goal. In the case of Dpkg, the triggers are especially useful to group similar actions. For instance, to update the list of manual pages once after installing a hundred of packages, instead of a hundred of times, after installing each package. They are also useful to transfer commands from a large number of packages to a central one, thus easing the evolution of the system. In the case of RPM, the triggers seem more specialised, as they always are about the relationship between a pair of packages.

Posted