My Debian contributions in January 2014

Follow me on  or Twitter 

One of my resolutions for 2014 is to keep trying harder to talk about my Debian contributions. So here it is, on a monthly basis this time I hope, quite short this month because I’m leaving for holidays at the end of the week and I think I won’t have time to contribute more this month.

Debian packages

Below are some packages I updated recently:

1. Brebis, the fully automated backup checker

I successively packaged Brebis, the fully automated backup checker, versions 0.6 to 0.9 (the latter is today in Debian Sid and Jessie) since my last Debian activities blog posts (in french).


Anisette, the mascot of the Brebis Project

2. Pycallgraph, a Python library that creates call graphs for Python programs

Pycallgraph is one of the first Debian packages I have been maintaining. So when I noticed it was upgraded after so much time I was really eager to package the new version 1.0.1. Now available in Debian Sid! Just belown an example of the generated graph for the application Belier, a sysadmin tool.


3. Belier, the SSH connection generation tool

Nothing really new for Belier, the SSH connection generation tool but I updated the package in order to update the configuration of the Debian package and get rid of some warning messages. Kind of maintenance job I kept avoiding and avoiding, until now.

Bug report

I’d like to take a few seconds to talk about an interesting bug report about the need for a nagios3-dev package I created asking for a new nagios3-dev or nagios3-headers package to offer a simple access to the headers of Nagios for the developers of Nagios external modules.

In Nagios, some headers are generated after the ./configure, meaning it may be platform dependent. I (and not only me, the same request was active already by someone other Nagios module developers) thought it was simple to ask the Nagios3 Debian package maintainer to offer these files in a dedicated package.

It seems until now people just add the missing files in tarball of their app or in their Debian packages, even if these Nagios headers are not really part of this application. In my opinion, that’s why Build-Depends packages are for, don’t you think?


It seems it is not so simple. I could not understand why it was more important to prevent Debian users who need these files to access these files in a convenient way than letting them to put theses files in there own source tarball/repository. The maintainer told me it could break things. Sure. But we all know an external module of any app often relies on a really specific version of this app. That’s nothing new, thats how external modules work. That’s not every apps in the world which could provide a stable API to ease the development of external modules. But at least they give access to their dev files or headers when they are FOSS. But feel free to explain to me. After all, the bug reports are still not tagged as "won’t fix" ;)

Your turn now :)  I’d be delighted to have your opinions in the comments of this blog post.

Virtual environments with Python 3.3

Follow me on  or Twitter 

One of the major features of Python 3.3 is the new venv module, allowing the creation of Python virtual environments on your system.

1. What is a virtual environment?

A virtual environment is a directory dedicated to the execution of your Python applications. Activating your virtual environment will force Python to execute in this directory as the top level of this directory was the root of your file system.

The virtual environments are interesting because of the independence they have toward the host they run on, especially when you want to install several versions of Python or if you want to install lots of dependencies without being the system administrator of the host.


If you are a Python developer, you must know virtualenv. This really nice application offers a nice way to create Python virtual environment. Moreover it comes with pip already installed in your virtual environment, in order to install other dependencies you need in a really convenience way.

Starting from Python 3.3, the module venv of the Python standard library offers the users to create virtual environments. This new feature will encourage all users to create virtual environments to develop their own Python applications, which is a good practice. Thanks to the experiences of several applications being used in the Python community, the module venv was written to be really efficient and widely available.

The Python Enhancement Proposal 405 (PEP405) offers a really interesting reading if you wish to find more information about this topic.

2. Creating a virtual environment with Python 3.3

With Python 3.3 comes pyvenv-3.3, allowing to create Python virtual environment:

$ pyvenv-3.3 myvirtualenv
$ cd myvirtualenv/
$ tree .
├── bin
│   ├── activate
│   ├── pydoc
│   ├── python -> python3.3
│   ├── python3 -> python3.3
│   └── python3.3 -> /usr/bin/python3.3
├── include
├── lib
│   └── python3.3
│       └── site-packages
└── pyvenv.cfg

As we can see, three directories were created.

  • bin/ offers the activate script and different links to the executable python3.3
  • lib/ offers a tree of directories where the libraries and packages you install in your virtual environment will be stored
  • include/ is by default empty
  • pyvenv.cfg offers different configuration options
$ cat pyvenv.cfg 
home = /usr/bin
include-system-site-packages = false
version = 3.3.2

Just before moving on, if you want to use the existing modules in your global site-packages directory on your system, the option –system-site-packages is available.

3. Activate the virtual environment

Lets activate our virtual environment. We need to use the bin/activate file in this environment:

$ source bin/activate 
(myvirtualenv) $

A change in our prompt indicated the good activation of the virtual environment.

4. Installing applications in the virtual environment

But playing around with only the default Python interpreter is not really funny. Lets download pip, the Python installer, but before that we need a dependency setuptools:

(myvirtualenv) $ curl -o
 % Total % Received % Xferd Average Speed Time Time Time Current
 Dload Upload Total Spent Left Speed
 100 11356 100 11356 0 0 18507 0 --:--:-- --:--:-- --:--:-- 18495
(myvirtualenv) $ curl -o
 % Total % Received % Xferd Average Speed Time Time Time Current
 Dload Upload Total Spent Left Speed
 100 543k 100 543k 0 0 685k 0 --:--:-- --:--:-- --:--:-- 685k

Now lets install Setuptools and Pip:

(myvirtualenv) $ python3.3
 Extracting in /tmp/tmpxlrv7q
 Now working in /tmp/tmpxlrv7q/setuptools-2.0
 Installing Setuptools
... (lots of lines)...
Installed /tmp/myvirtualenv/lib/python3.3/site-packages/setuptools-2.0-py3.3.egg
 Processing dependencies for setuptools==2.0
 Finished processing dependencies for setuptools==2.0
(myvirtualenv) $ python3.3
 Downloading/unpacking pip
 Downloading pip-1.4.1.tar.gz (445kB): 445kB downloaded
 Running egg_info for package pip
 ... (lots of lines)...
 Successfully installed pip
 Cleaning up...

Ok now we’re ready to use pip to install anything we need in our virtual environment. Lets think one more second about what we did: we install the Setuptools and the Pip application inside our virtual environment, with nothing written on our main system. Now lets try to install Brebis, the fully automated backup checker, and run it in this environment:

(myvirtualenv) $ pip-3.3 install brebis
 Downloading/unpacking brebis
 Downloading brebis-0.8.tar.gz
 Running egg_info for package brebis
Installing collected packages: brebis
 Running install for brebis
 changing mode of build/scripts-3.3/brebis from 644 to 755
changing mode of /tmp/myvirtualenv/bin/brebis to 755
 Successfully installed brebis
 Cleaning up...

We’re now ready to launch Brebis, executing in our virtual environment:

(myvirtualenv) $ brebis -h
usage: brebis [-h] [-c DIR] [-C DIR] [-d DELIMITER] [-g] [-G] [-l FILE]
 [-L DIR] [-O DIR] [-v] 
Fully automated backup checker
positional arguments:
 archives archives to check
optional arguments:
 -h, --help show this help message and exit
 -c DIR, --configpath DIR
 the path to the configurations
 -C DIR, --output-conf-dir DIR
 the directory to store the configuration file
 -d DELIMITER, --delimiter DELIMITER
 delimiter of the fields for the list of files
 -g, --gen-list generate a list of files inside a backup
 -G, --gen-full generate the configuration file and the list of files
 for the backup
 -l FILE, --log FILE the log file
 -L DIR, --output-list-dir DIR
 the directory to store the list of files inside an
 archive or tree
 -O DIR, --output-list-and-conf-dir DIR
 the directory to store the configuration file and the
 list of files inside an archive or tree
 -v, --version print the version of this program and exit
For more information:

So we get an execution of the Brebis application inside our virtual environment, installed from our virtual environment with tools installed only in the virtual environment.

That’s a big step that such a feature is now included in the standard library. In the future, you will enjoy the possibility to create new virtual environments for each Python version right out of the box. Moreover, using the –upgrade option of the pyvenv command, you will upgrade, if needed, your virtual environment in a really easy and straightforward way, making environments adaptable in time.

What about you? What do you think about the Python 3 virtual environments and their features, given your own needs? Feel free to use the comments section of this post.

X-mas present: Brebis 0.9, the fully automated backup checker, released

Follow me also on Twitter 

Just in time for this 2013 Christmas, the Brebis Project released Brebis "Bouddhinette" 0.9. Hope you’ll enjoy our X-mas present ;)

Reminder: Brebis is the fully automated backup checker, a CLI software developed in Python, allowing users to verify the integrity of archives (tar,gz,bz2,lzma,zip) and the state of the files inside the archives. You will find more information about Brebis features on the Brebis Project homepage.

What’s new?

The major features for this release are:

  • support of the apk archive
  • the cli offers new options to store the configuration file (-C), the list of files (-L) or both (-O) in custom locations

Anisette, the proud mascot of the Brebis Project

The extensive list of the supported features is available on the Brebis Project homepage.

Get Brebis

The official archive of Brebis 0.9 is available here.

Feedback about Brebis

What do you think about the Brebis project ? We at the Brebis Project welcome any feedback about Brebis. Feel free to comment on this blog,  to subscribe to the Brebis-users mailing listby Twitter or email me directly at

Official website:

Cadeau de Noël : Publication de Brebis 0.9, le vérificateur automatisé de sauvegarde

Suivez-moi aussi sur ou sur Twitter 

Peu de temps avant ce Noël, l’équipe du projet Brebis a publié la version "Bouddhinette" 0.9 du vérificateur automatisé de sauvegardes. Pour rappel, Brebis est un programme en ligne de commande codé en Python permettant le contrôle automatisé de l’intégrité d’archives (tar, gz, bzip2, lzma, zip) et de la cohérence des fichiers à l’intérieur des archives. Au menu de cette version :

  • Support des archives apk
  • Nouvelles options de la ligne de commandes pour écrire le fichier de configuration (-C), la liste des fichiers dans l’archive (-L) ou les deux (-O) dans un répertoire défini par l’utilisateur (où précédemment ces fichiers étaient écrits par défaut dans le même répertoire que l’archive elle-même).

Anisette, la fière nouvelle mascotte et nouveau logo du projet Brebis généreusement contribué par Antoine Millet

Comme annoncé aux JM2L, Brebis continue d’intégrer des nouveaux types d’archives , mais aussi rend sa manipulation plus flexible afin d’être intégré plus simplement pour répondre aux besoins de ses utilisateurs en s’adaptant plus simplement aux différentes situations existantes..

Feedback sur Brebis

Et vous ? Que pensez-vous de Brebis ? N’hésitez pas à vous abonner à la liste de diffusion de Brebis,  à laisser un commentaire ici ou  un message sur le forum ou à me contacter directement, tous les retours seront appréciés.

Retour sur Brebis, le vérificateur automatisé de sauvegarde, aux JM2L

Suivez-moi aussi sur ou sur Twitter 

Comme chaque année avait lieu à Sophia Antipolis les Journées Méditerrannéennes du Logiciel Libre, organisées par l’association Linux Azur. J’avais proposé pour cette année une présentation du projet  Brebis, le vérificateur automatisé de sauvegarde. C’était pour moi l’occasion de réaliser quelques slides parlant du projet (désormais disponible en ligne – CC by SA) et de recueillir les réactions du public.


L’accueil est chaleureux, comma d’habitude et le public est présent. On m’avait accordé un créneau d’une bonne heure. j’ai donc essayé de captiver mon public pendant 50 minutes avant la séance de questions. La présentation se découpe en deux phases, une introduction au domaine de la sauvegarde et à la nécessité de vérifier les sauvegardes régulièrement, puis une seconde partie plus technique sur les fonctionnalités du logiciel Brebis lui-même.


Anisette, la fière nouvelle mascotte et nouveau logo du projet Brebis généreusement contribué par Antoine Millet

La conférence a été filmée, je pourrai donc vérifier ce qu’il en est une fois que les vidéos seront en ligne.

Niveau stand, les exposants sont accueillants et disponibles et je suis content de voir cet événement du Logiciel Libre toujours aussi fréquenté. Trois fois que je fais le déplacement et je repasse sans faute l’année prochaine !

Étiez-vous aux JM2L aussi ? Qu’en avez-vous pensé ? N’hésitez pas à réagir dans les commentaires de ce billet.

Yarn: a scenario testing tool

Follow me also on Twitter  

Those who follow me on Twitter may have read my recent tweet about Yarn, a really nice software by Lars Wirzenius I discovered the last week-end while attending the Mini-Debconf UK in Cambridge.

To make a long story short, Yarn allows the user to write scenarios of the executions of softwares. This scenario will be automatically played by Yarn which also returns the overview of the execution, with the goal to test the behaviour of these softwares.

1. Small example of how to use Yarn

Let’s have a look of how to use Yarn with a real example. The scenario will test if the software Brebis, a fully automatized backup checker, executes in an expected way. We can proceed as follow :

  1. set up the test environment
  2. launch a command with the software under test in the test environment
  3. verify the execution of the test

This is an example of a Yarn scenario file, the file is formatted using the Markdown syntax:

    SCENARIO basic brebis execution
    GIVEN setting up brebis
    AND generating backup configuration with brebis
    WHEN brebis verifies a backup
    THEN verify brebis output

    IMPLEMENTS GIVEN setting up brebis
    hg clone $DATADIR/brebis
    mkdir -p $DATADIR/brebis/yarn-test
    cp $DATADIR/brebis/functional-tests/expected-generated-list-for-tar-archive/expected-generated-list-for-tar-archive.tar.gz $DATADIR/brebis/yarn-test

    IMPLEMENTS GIVEN generating backup configuration with brebis
    $DATADIR/brebis/ -G $DATADIR/brebis/yarn-test/expected-generated-list-for-tar-archive.tar.gz

    IMPLEMENTS WHEN brebis verifies a backup
    $DATADIR/brebis/ -c $DATADIR/brebis/yarn-test -l $DATADIR/brebis/yarn-test/brebis.log

    IMPLEMENTS THEN verify brebis output
    if [ -s $DATADIR/brebis/yarn-test/brebis.log ]; then return 1; else return 0; fi

2. Result of the execution of the Yarn scenario

Yarn provides at the end of the scenario an overview of the execution, as show below:

$ yarn brebis-scenario
Scenario test suite PASS, with 1 scenarios (4 total steps), in 16.4 seconds

3. Details of the Yarn scenarios

The five first lines are basically your scenario. Each step takes a keyword and a sentence to identify a step. You define a name with the SCENARIO keyword. The next step, GIVEN, allows generally the setup of the test environment. It is possible of course to define different steps with the keywork AND.

Once the environment setup has been completed, we launch the test with the keyword WHEN. At last we check the result of the execution with THEN. It is worth noting that if you need further steps after checking the result of the execution, you can use FINALLY.

Very helpful while setting up the test environment is the variable $DATADIR, automatically initialized by Yarn. It provides the path to a temporary directory where you can store files during the execution of your scenario. This directory is by default removed at the end of the scenario.

Now the real trick: at each step I described above is associated shell commands to execute thanks to the IMPLEMENTS keyword.It’s in my opinion a great way to increase the understanding of what the scenario really does. In a short glance of the first lines, if the names of the steps are carefully chosen, you will understand what the scenario does without needing to read the actual shell code. Simple and efficient.

4. More about Yarn

Yarn is written in Python and now available in Debian in the package cmdtest. The sources are available here. In my opinion, if you were looking for this kind of tool, Yarn is in a really good direction. This project is still young but the core features do the job and the upstream is eager to receive feedbacks (and patches) :)

Some links:

Interested in Yarn? What do you think about it? Let us know in the comments of this post. 

Yarn : Scénarios d’exécutions de programmes en ligne de commandes

Suivez-moi aussi sur ou sur Twitter 

Ceux qui me suivent sur Twitter auront peut-être vu passer un tweet au sujet de Yarn, logiciel fort sympathique que j’ai vraiment découvert le week-end dernier à la Mini-Debconf UK à Cambridge.

Yarn permet de définir des scénarios d’exécutions de programmes en ligne de commande. Le scénario ainsi écrit sera ensuite joué et le résultat de l’exécution présenté de manière synthétique.

1. Syntaxe d’un scénario à travers un exemple

Petit exemple avec un scénario permettant de vérifier la bonne exécution de Brebis, le logiciel de vérification de sauvegarde. Le but est de :

  1. mettre en place un environnement de test
  2. exécuter le test
  3. vérifier l’exécution du test

Voici comment se présente le fichier de scénario de Brebis, ce dernier suit la syntaxe Markdown :

    SCENARIO basic brebis execution
    GIVEN setting up brebis
    AND generating with brebis
    WHEN brebis is ready
    THEN verify brebis job

    IMPLEMENTS GIVEN setting up brebis
    hg clone $DATADIR/brebis
    mkdir -p $DATADIR/brebis/yarn-test
    cp $DATADIR/brebis/functional-tests/expected-generated-list-for-tar-archive/expected-generated-list-for-tar-archive.tar.gz $DATADIR/brebis/yarn-test

    IMPLEMENTS GIVEN generating with brebis
    $DATADIR/brebis/ -G $DATADIR/brebis/yarn-test/expected-generated-list-for-tar-archive.tar.gz

    IMPLEMENTS WHEN brebis is ready
    $DATADIR/brebis/ -c $DATADIR/brebis/yarn-test -l $DATADIR/brebis/yarn-test/brebis.log

    IMPLEMENTS THEN verify brebis job
    if [ -s $DATADIR/brebis/yarn-test/brebis.log ]; then return 1; else return 0; fi

2. Résultat de l’exécution du scénario

Le résultat de l’exécution du scénario est synthétique et précise les conditions d’exécution du scénario :

$ yarn brebis-scenario
Scenario test suite PASS, with 1 scenarios (4 total steps), in 16.4 seconds

3. Détails de l’implémentation du scénario

Les 5 premières lignes représentent votre scénario. Il porte avant tout un nom défini par le mot-clé SCENARIO, l’étape suivante GIVEN est en général à consacrer à la mise en place de votre environnement de test. Il est possible d’enchaîner ici plusieurs groupes d’instructions à l’aide de AND.
Une fois notre environnement de test mis en place, nous lançons le test à l’aide de WHEN. Enfin nous vérifions le résultat de notre exécution lors de l’étape THEN.Il est à noter que si des opérations sont à réaliser après le test, vous pouvez utiliser le mot-clé FINALLY.

On remarque également l’utilisation de la variable $DATADIR, initialisé par Yarn qui fournit le chemin vers un répertoire temporaire qui par défaut sera supprimé à la fin de votre scénario.

À chaque étape précédemment citée, nous associons des commandes shell à l’aide du mot-clé IMPLEMENTS. Nous faisons ainsi la correspondance entre les titres de nos étapes et les commandes exécutées. Il s’agit dans l’exemple des lignes qui commencent juste après la ligne contenant le THEN.

On voit que la première partie du fichier définie des étapes, avec une syntaxe qui permet d’obtenir des ordres proches du langage naturel. La seconde partie du fichier fournit la correspondance entre ces ordres et leur implémentation concrète en commandes shell. C’est simple et efficace.

4. Encore quelques mots sur un projet prometteur

Yarn est codé en Python et déjà disponible dans Debian dans le paquet cmdtest. Les sources sont facilement accessibles. Je pense que si vous êtes à la recherche de ce type d’outil, Yarn a pris d’emblée les bonnes directions. Le projet est encore jeune (documentation à améliorer, de nombreus points à faire évoluer) mais la base est là et son upstream est à l’écoute des suggestions (et des patchs) :)

Quelques liens pour la route :

Et vous ? Que pensez-vous de Yarn ? N’hésitez pas à réagir comme d’habitude dans les commentaires.

À propos de l’auteur

Carl Chenet, architecte système et expert GNU/Linux indépendant. N'hésitez pas à faire appel à mes services.
>>> Mon offre de services

Soutenir l’auteur

Soutenir les activités Debian de l'auteur Faire un don Pourquoi faire un don ?

Faire un don en bitcoins

Adresse pour les dons en bitcoins :


Suivez-moi aussi sur !



Recevez les nouvelles publications par mail.

Joignez-vous à 29 followers

%d bloggers like this: