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.


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…

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.

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.

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

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

Dpkg “triggers” soon in Debian's policy manual.

Dpkg provides a mechanism to execute again the postint script of a package in some conditions triggered by the installation of another package. The description of this mechanism is scattered between two manual pages, dpkg-trigger (1) and deb-triggers (5), and the file /usr/share/doc/dpkg-dev/triggers.txt.gz.

To provide a broader overview and to promote the use of triggers, we will add a section for them in the Debian Policy. The work is well advanced and tracked in the bug number 582109. The most recent version of the patch is available following this link.

There needs only one more seconding opinion for this patch to be accepted. Seconds are not personal opinions, but are given when one thinks that a proposal reflects the consensus in Debian (see the process to change the Policy). If after inspecting this patch you feel qualified to second it, this will be welcome. Of course, other comments to improve or amend the patch are also welcome.

Do we really need “contrib”?

The Debian project distributes software packages via its archive, propagated through a network of mirrors. This archive is organised in three areas, main, that contains the Debian system, and contrib and non-free, that contain accessory packages that are not Free. The packages in non-free contain files that have a proprietary license. The source packages in contrib contain only Free files, but produce binary packages that are either useless without the access to remote services, or contain non-Free files, or cause the installation of non-Free materials.

The contrib area is an endless source of discussions, as it is not always easy to draw the line between what is usable and what is useless without remote services. I wonder if it would be better to replace the contrib area by a new priority level, “remote”, lower than extra. Packages that are entirely Free (source and binary) and that do not cause the installation of proprietary software would be fit for main. For the packages that can not function without non-Free software, given that the work to be done to free them is the same regardless whether the proprietary code is included in the source package (in non-free) or not (in contrib), I think that in both cases the package should be in non-free as it is not Free in practice.

This would allow for a simple criterion: does the selection of a binary package trigger the installation of non-Free files? If yes, the package and its source belong to non-free. If not, they belong to main. Then, if they need to access a remote service that would not be possible to set up on a network where only Debian is available, their priority would be remote.

Debian-Installer in a Cloud, part 2.

I finally manage to create an image of the Debian Installer automatically, with no key or password transiting on the Cloud or the network, and without using the ec2-api-tools, which are non-Free. Thanks to Eucalyptus for implementing the attribute InstanceInitiatedShutdownBehavior in euca2ools 2.1.2.

In brief, I start a micro-instance with an additional volume, and I pass it a script for cloud-init, which will download the Installer on the volume and shut down the instance. Then, I register the volume as a machine image.

Those machine images of the Installer are to be preseeded via instance metadata to install Debian on another volume. I am still struggling with the pre-configuration. More details will follow in the next article. In the meantime, here are the commands I a using.

On the local computer, start an instance on the Cloud. Until #696595 is fixed and cloud-init is installed by default, I use a Ubuntu image.

HELPER_AMI=ami-7609bb77 # Ubuntu 12.04 LTS Precise amd64 EBS (Asia North-East)

Start the instance with an extra volume of 1 GiB, which will persist after termination (/dev/sdb=:1:false). Pass the script debigen-install-installer-cloud (see below).

HELPER_INSTANCE=$( euca-run-instances \
        --instance-initiated-shutdown-behavior terminate \
        --instance-type t1.micro \
        --block-device-mapping /dev/sdb=:1:false \
        --user-data-file debigen-install-installer-cloud \
        $HELPER_AMI |
        tee /dev/stderr | grep INSTANCE | awk '{print $2}')

Wait that the boot finished.

while [ ! $(euca-describe-instances $HELPER_INSTANCE | grep INSTANCE | cut -f 6 | tee /dev/stderr) = "running" ]
    do sleep 30

Get the volume's identifier

TARGET_VOLUME=$( euca-describe-volumes |
        grep $HELPER_INSTANCE | grep '/dev/sdb' |
        tee /dev/stderr | awk '{print $2}')

Wait that the scripts shuts down the instance.

while [ ! $(euca-describe-instances $HELPER_INSTANCE | grep INSTANCE | cut -f 6 | tee /dev/stderr) = "terminated" ]
    do sleep 30

Snapshot the volume and register it as a machine image.

PV_KERNEL=aki-44992845 # Boot PV-Grub on hd0 (Asia North-East)

TARGET_SNAPSHOT=$( euca-create-snapshot $TARGET_VOLUME |
        tee /dev/stderr | awk '{print $2}')

while euca-describe-snapshots $TARGET_SNAPSHOT | grep -q pending ; do sleep 30 ; done

euca-register \
    --name test_di \
    --description test_of_debian_installer \
    --snapshot $TARGET_SNAPSHOT \
    --kernel $PV_KERNEL \
    --architecture x86_64

Here is the script called debigen-install-installer-cloud, used above.

#!/bin/sh -ex    
mke2fs -L debian-installer /dev/xvdb -F
mount LABEL=debian-installer /mnt/

cd /mnt    

wget $BASEURL/initrd.gz $BASEURL/vmlinuz    
mkdir -p boot/grub    
cat > boot/grub/menu.lst <<__END__
default 0
timeout 3

title  Debian Installer ($DI_VERSION $ARCH)
root   (hd0)
kernel /vmlinuz root=LABEL=debian-installer ro console=hvc0 auto=true priority=critical url= DEBIAN_FRONTEND=text
initrd /initrd.gz

sleep 30