27 fév. 2017

pbulk : compilation massive de paquets pkgsrc

Je continue dans ma série de billets sur pkgsrc, mais cette fois-ci on retourne sous NetBSD. L'objectif aujourd'hui est de construire de nombreux paquets (idéalement tous, ou alors une liste précise) binaires et de créer un dépôt pour ceux-ci. On appelle cela un bulk build lorsqu'on tente de construire tous les paquets disponibles, et un partial bulk build lorsqu'on décide de n'en construire qu'une partie, en inscrivant ceux-ci dans un fichier de liste.

Précisons que ce contenu est en partie basé sur le tutoriel du wiki officiel : Using pbulk to create a pkgsrc binary repository. Si vous préférez la langue de Shakespeare, cela peut s'avérer un bon point de départ.

Préparation

Effectuer ce genre d'opérations requiert idéalement un système dédié, matériel ou virtuel. Dans mon cas, j'ai opté un Raspberry Pi 2B.

braverthanithought.jpg

Bon, on va pas se faire d'illusion, c'est juste pour du bulk build partiel, n'imaginons même pas tenter de construire tous les paquets disponibles sans une cinquantaine de ces trucs.

Côté ressources, il est donc préférable d'avoir plusieurs coeurs, 1 giga-octet de mémoire vive minimum, et quelques dizaines de giga-octets d'espace disque. Au niveau du partitionnement, c'est un peu comme on veut tant que l'endroit où on crée la sandbox (et les paquets) est assez grand. Dans mon cas, j'ai fait un choix très simpliste, vu que le Pi ne sert qu'à cela : un / sur une carte SD de 32 giga-octets. Le répertoire pour créer les sandbox est tout simplement /srv/sandbox.

Concernant l'installation de l'OS, là aussi on va se faciliter l'existence, il suffit d'installer tous les sets, sauf les codes sources du noyau et du système (encore moins de la partie graphique). Exemple sur le Pi, la liste des sets installés :

$ ls -hl /etc/mtree/
total 5.7M
-r--r--r--  1 root  wheel   57K Sep 25  2015 NetBSD.dist
-r--r--r--  1 root  wheel  749K Sep 25  2015 set.base
-r--r--r--  1 root  wheel  2.4M Sep 25  2015 set.comp
-r--r--r--  1 root  wheel   43K Sep 25  2015 set.etc
-r--r--r--  1 root  wheel   43K Sep 25  2015 set.games
-r--r--r--  1 root  wheel  815K Sep 25  2015 set.man
-r--r--r--  1 root  wheel   96K Sep 25  2015 set.misc
-r--r--r--  1 root  wheel   26K Sep 25  2015 set.modules
-r--r--r--  1 root  wheel   90K Sep 25  2015 set.text
-r--r--r--  1 root  wheel  193K Sep 25  2015 set.xbase
-r--r--r--  1 root  wheel  473K Sep 25  2015 set.xcomp
-r--r--r--  1 root  wheel   11K Sep 25  2015 set.xetc
-r--r--r--  1 root  wheel  761K Sep 25  2015 set.xfont
-r--r--r--  1 root  wheel   17K Sep 25  2015 set.xserver
-r--r--r--  1 root  wheel   18K Sep 25  2015 special

Par contre, dans certains cas, l'absence de /usr/src ou de /usr/xsrc peut arrêter net certaines manipulations. IL faut donc penser à les créer (en tant que root) : mkdir /usr/src && mkdir /usr/xsrc. Il n'est pas nécessaire d'installer pkgsrc, mais disposer au moins d'un dépôt de paquets binaires peut être une bonne idée (la dernière version stable suffira). Il s'agit plus d'une question de préférence ici.

Création et configuration de la sandbox

Nous allons donc créer une sandbox qui va contenir l'installation de l'outil pbulk. Cela a plusieurs avantages :

  • on peut créer plusieurs sandbox pour tester différents cas, comme une version différente de pkgsrc ou des options de compilation ;
  • si une sandbox ne fonctionne plus, il est possible d'en créer une autre, voire même de scripter son installation pour aller plus vite ;
  • on pourra installer son petit confort sur le système hébergeant la sandbox (qui a dit bash, vim et git ?), et aussi installer des outils de supervision ou de métrologie.

Ne soyons pas non plus trop optimistes sur la pérennité du système, dans le cas du Pi, j'en suis à la troisième réinstallation (une carte SD n'est pas un disque dur, une clé USB non plus).

Pour créer la sandbox, installons mksandbox. Cet outil est en fait un script shell qui va utiliser des points de montage de type null mountpoint pour faciliter la création de nos espaces de création de paquet et éviter de recopier tout le contenu du système hôte. Au moment de l'écriture de ce billet, la version en date est la 1.7, disponible dans pkgsrc-2016Q4. Au choix, on peut pkgin in mksandbox, pkg_add -v mksandbox, ou bien cd /usr/pkgsrc/pkgtools/mksandbox && make install clean clean-depends.

Une fois mksandbox installé, créons notre premier bac à sable (en tant que root) :

# mksandbox --without-pkgsrc /srv/sandbox/pkgsrc-2016q4
Make and populate /srv/sandbox/pkgsrc-2016q4/dev
Make and populate /srv/sandbox/pkgsrc-2016q4/etc
Make empty dirs upon which to mount the null mounts
Making /tmp in /srv/sandbox/pkgsrc-2016q4
Making /var/games in /srv/sandbox/pkgsrc-2016q4
Making /var/run in /srv/sandbox/pkgsrc-2016q4
Making /var/log in /srv/sandbox/pkgsrc-2016q4
Making /var/spool/lock in /srv/sandbox/pkgsrc-2016q4
Making /var/run/utmp in /srv/sandbox/pkgsrc-2016q4
Making /var/run/utmpx in /srv/sandbox/pkgsrc-2016q4
Making /var/log/wtmp in /srv/sandbox/pkgsrc-2016q4
Making /var/log/wtmpx in /srv/sandbox/pkgsrc-2016q4
Making /var/log/lastlog in /srv/sandbox/pkgsrc-2016q4
Making /var/log/lastlogx in /srv/sandbox/pkgsrc-2016q4
Mount /usr/src from /srv/sandbox/pkgsrc-2016q4
Mount /usr/xsrc from /srv/sandbox/pkgsrc-2016q4
Sandbox creation is now complete

La sandbox est d'ailleurs déjà montée à l'issue de sa création :

# mount | grep 2016q4
/bin on /srv/sandbox/pkgsrc-2016q4/bin type null (read-only, local)
/sbin on /srv/sandbox/pkgsrc-2016q4/sbin type null (read-only, local)
/lib on /srv/sandbox/pkgsrc-2016q4/lib type null (read-only, local)
/libexec on /srv/sandbox/pkgsrc-2016q4/libexec type null (read-only, local)
/usr/X11R7 on /srv/sandbox/pkgsrc-2016q4/usr/X11R7 type null (read-only, local)
/usr/bin on /srv/sandbox/pkgsrc-2016q4/usr/bin type null (read-only, local)
/usr/games on /srv/sandbox/pkgsrc-2016q4/usr/games type null (read-only, local)
/usr/include on /srv/sandbox/pkgsrc-2016q4/usr/include type null (read-only, local)
/usr/lib on /srv/sandbox/pkgsrc-2016q4/usr/lib type null (read-only, local)
/usr/libdata on /srv/sandbox/pkgsrc-2016q4/usr/libdata type null (read-only, local)
/usr/libexec on /srv/sandbox/pkgsrc-2016q4/usr/libexec type null (read-only, local)
/usr/share on /srv/sandbox/pkgsrc-2016q4/usr/share type null (read-only, local)
/usr/sbin on /srv/sandbox/pkgsrc-2016q4/usr/sbin type null (read-only, local)
/var/mail on /srv/sandbox/pkgsrc-2016q4/var/mail type null (read-only, local)
/usr/src on /srv/sandbox/pkgsrc-2016q4/usr/src type null (read-only, local)
/usr/xsrc on /srv/sandbox/pkgsrc-2016q4/usr/xsrc type null (read-only, local)

Profitons-en pour découvrir le script de montage, démontage, et d'entrée dans la sandbox, qui se nomme sandbox et se trouve à la racine de celle-ci. Dans mon cas c'est donc /srv/sandbox/pkgsrc-2016q4.

Pour démonter la sandbox, c'est donc :

# /srv/sandbox/pkgsrc-2016q4/sandbox umount

Pour monter la sandbox, c'est :

# /srv/sandbox/pkgsrc-2016q4/sandbox umount

Et pour entrer dans la sandbox, c'est :

# /srv/sandbox/pkgsrc-2016q4/sandbox chroot

Démontons-donc la sandbox, et avant de la remonter, éditons le script de sandbox. Les lignes 16 à 33 montrent la liste des répertoires à monter, et nous allons en ajouter une, qui permettra à la sandbox d'envoyer des mails (c'est donc optionnel mais pratique parfois). Il s'agit du répertoire /var/spool. Dans mon cas, le résultat est donc :

fses="\
/bin /bin ro \
/sbin /sbin ro \
/lib /lib ro \
/libexec /libexec ro \
/usr/X11R7 /usr/X11R7 ro \
/usr/bin /usr/bin ro \
/usr/games /usr/games ro \
/usr/include /usr/include ro \
/usr/lib /usr/lib ro \
/usr/libdata /usr/libdata ro \
/usr/libexec /usr/libexec ro \
/usr/share /usr/share ro \
/usr/sbin /usr/sbin ro \
/var/mail /var/mail ro \
/usr/src /usr/src ro \
/usr/xsrc /usr/xsrc ro \
/var/spool /var/spool rw \
"

Notons qu'il s'agit du seul répertoire accessible en écriture. Nous pouvons alors monter la sandbox, et y entrer.

Notre sandbox est crée, mais il nous faut ajouter quelques éléments avant d'installer pbulk. Par exemple, il nous manque pkgsrc. Installons donc ce dernier :

netpi2# mkdir -p /root/.ssh
netpi2# cd /usr                                                                                              
netpi2# cvs -d anoncvs@anoncvs.netbsd.org:/cvsroot co -rpkgsrc-2016Q4 pkgsrc

Dans le cas d'une installation de pkgsrc-current, il suffit de retirer la partie -rpkgsrc-2016Q4 de la commande précédente. Sauf que, dans mon cas, le Raspberry Pi (ou bien sa carte SD) ne tient pas le coup et abandonne avant la fin du checkout. Procédons à l'alternative :

netpi2# mkdir -p /root/.ssh
netpi2# cd /usr
netpi2# ftp http://cdn.netbsd.org/pub/pkgsrc/pkgsrc-2016Q4/pkgsrc-2016Q4.tar.xz 
Trying 2a04:4e42:4::262:80 ...
ftp: Can't connect to `2a04:4e42:4::262:80': No route to host
Trying 151.101.61.6:80 ...
Requesting http://cdn.netbsd.org/pub/pkgsrc/pkgsrc-2016Q4/pkgsrc-2016Q4.tar.xz
100% |*************************************************************************************************************************************************************************************************| 37422 KiB    2.65 MiB/s    00:00 ETA
38320872 bytes retrieved in 00:13 (2.65 MiB/s)
netpi2# unxz -v pkgsrc-2016Q4.tar.xz                                                                                                                                                                                                         
pkgsrc-2016Q4.tar.xz (1/1)
  100 %        36.5 MiB / 437.1 MiB = 0.084   8.8 MiB/s       0:49   
netpi2# tar -xvpf pkgsrc-2016Q4.tar
# non, je ne copierai pas la sortie d'un tar verbose de pkgsrc.
netpi2# cd pkgsrc && cvs update -dP

Note pour plus tard : bsdtar ne prend pas en compte nativement le format xz. En attendant, les archives au format bzip2 c'est pas mal.

Installation et configuration de pbulk

Avant d'installer pbulk, il convient de comprendre certains détails. Pbulk s'installe via pkgsrc, mais tous les paquets qui vont être créés par la suite le seront aussi, et probablement désinstallés. Cela risque donc d'influer sur les dépendances de pbulk. L'idée est donc d'installer pbulk non pas dans l'emplacement habituel des paquets /usr/pkg/ mais dans un autre endroit, qui se trouve être /usr/pbulk.

En préalable à l'installation de pbulk, initialisons un fichier d'options de compilation, nommé mk.conf.frag :

PKG_DEVELOPER=yes

MAKE_JOBS=3
SKIP_LICENSE_CHECK=yes
PKG_COMPILER=ccache gcc
PKG_RCD_SCRIPTS=yes
ALLOW_VULNERABLE_PACKAGES=YES
PKG_DEFAULT_OPTIONS+=
KRB5_ACCEPTED=heimdal mit-krb5
USE_CWRAPPERS=yes
PKG_OPTIONS.irssi+= ssl perl inet6

PKGCHK_CONF?=   /etc/pkgchk.conf
DEPENDS_TARGET= bulk-install
BATCH=          yes
BULK_PREREQ+=   pkgtools/lintpkgsrc
BULK_PREREQ+=   pkgtools/pkg_install
BULK_PREREQ+=   devel/ccache

# http://wiki.netbsd.org/tutorials/pkgsrc/cross_compile_distcc/
.for DISTCCDEPS in devel/ccache sysutils/checkperms pkgtools/digest devel/distcc devel/popt devel/libtool-base lang/f2c devel/gmake
.  if "${PKGPATH}" == "${DISTCCDEPS}"
IGNORE_DISTCC=  yes
IGNORE_CCACHE=  yes
.  endif
.endfor

WRKOBJDIR=              /tmp
PACKAGES=               /srv/packages
DISTDIR=                /srv/distfiles

L'idée est d'indiquer ici des options de personnalisation de compilation. Il est possible de comprendre à quoi correspondent ces options en allant jeter un œil dans le répertoire /usr/pkgsrc/mk/defaults/, mais je vais malgré tout m'attarder sur l'une d'entre elles : MAKE_JOBS. Cette directive permet d'utiliser plusieurs commandes make en parallèle, et il convient de l'ajuster selon le nombre de cœurs ou de threads de votre ordinateurs. Généralement une règle simple serait au minimum "nombre de processeurs +1". Mais, le Raspberry PI, malgré ses 4 cœurs, ne tient pas le coup, j'ai donc abaissé la valeurs à 3. A noter que le contenu de ce mk.conf.frag sera copié lors de l'installation de pbulk dans le fichier /etc/mk.conf. On pourra le modifier entre deux builds, pas besoin de relancer l'installation. Tiens, d'ailleurs, lançons-là :

sh /usr/pkgsrc/mk/pbulk/pbulk.sh -n -c mk.conf.frag

Une fois pbulk installé, configurons son fichier principal : /usr/pbulk/etc/pbulk.conf. Je ne vais pas détailler toutes les options, mais juste celles que je modifie. Commençons d'ailleurs par ajouter les deux lignes suivantes juste après la première :

ulimit -t 3600 # set the limit on CPU time (in seconds)
ulimit -v 2097152 # limits process address space

Comme l'indiquent les commentaires en anglais (recopiés textuellement depuis la page wiki du début du billet), ils servent à limiter la consommation CPU de nos builds, au cas où. Je choisis ensuite l'URL du rapport de bulk build :

base_url=http://pkg.anotherhomepage.org/pub/pkgsrc/reports/NetBSD/earmv6hf/7.0_2016Q

Ce rapport va me permettre de voir quels paquets n'ont pu être construits, et surtout de comprendre pourquoi grâce aux fichiers de log.

Avant la construction des paquets, une phase permet de lister ceux-ci et de déterminer l'ordre dans lequel les construire. Cette étape se nomme le "scan". Pour accélérer cette étape, nous pouvons conserver le résultat du scan d'un build précédent. Pour cela :

reuse_scan_results=yes

Il est possible d'utiliser plusieurs machines avec pbulk. Ce n'est pas notre cas ici :

master_mode=no

On passe alors aux options de publication des paquets, via rsync :

pkg_rsync_args="-rltoDPq"
pkg_rsync_target="user@host:/chemin/vers/les/paquets/"
report_rsync_args="-rltoDPq"
report_rsync_target="user@host:/chemin/vers/les/rapports/"

Le build est long, c'est pratique d'avoir un mail quand c'est fini, et qui contient le rapport :

report_subject_prefix="pkgsrc-2016Q4"
report_recipients="adresse@domaine.valide"

C'est d'ailleurs l'occasion de parler du BulkTracker, qui permet de suivre différents bulk builds. Pour y participer, il suffit d'ajouter dans dans report_recipients l'adresse pkgsrc-bulk chez NetBSD point org.

On parlait de bulk buid partiel, on peut spécifier un fichier contenant une liste de paquets pour ne pas avoir à compiler tous les paquets :

limited_list=/etc/pkgchk.conf

Dans ce fichier, chaque paquet est sur sa propre ligne. Pour le moment, on peut démarrer avec juste pkgtools/pkgin dedans.

Je choisis ensuite de modifier certains répertoires, celui qui contient les logs de construction des paquets, et celui qui contient les paquets :

bulklog=/srv/bulklog
packages=/srv/packages

Ne pas oublier aussi, surtout pour NetBSD, de bien positionner la variable make :

make=/usr/bin/make

Dernier détail, la fin du fichier contient quelques redéfinitions de variables, donc attention de les mettre en commentaire !

Et tu bulk, et tu bulk, et tu bulk (mais sans t-shirt jaune ni planche de surf)

Avant de lancer la construction à proprement parler, petit avertissement : il est plus que recommandé d'utiliser screen ou tmux, car cela prend énormément de temps !

Lançons pbulk :

/usr/pbulk/bin/bulkbuild
Warning: All log files of the previous pbulk run will be
removed in 5 seconds. If you want to abort, press Ctrl-C.
Removing old scan results

Si jamais un paquet ne fonctionne pas, mais qu'après mise à jour, il peut compiler, il est possible de ne pas tout recompiler :

/usr/pbulk/bin/bulkbuild-rebuild category/pkgname

Il est aussi possible de reprendre un build arrêté inopinément :

/usr/pbulk/bin/bulkbuild-restart

J'espère que malgré la longueur, ce billet saura se montrer utile et intéressant. Comme toujours, les commentaires sont là pour accueillir remarques, questions et compléments !

30 janv. 2017

pkgsrc : installer un gestionnaire de paquets pour plus de logiciels sur macOS

Disclaimer : mon installation de pkgsrc étant bien entendu faite depuis quelques temps, une partie de ce billet est écrite grâce aux documentations suivies à l'époque et un peu de mémoire, je n'ai pas pu tout re-tester. Si des passages sont erronés ou que vous éprouvez des difficultés, n'hésitez pas à m'en faire part dans les commentaires, je corrigerai dès que possible.

L'une des forces de macOS (anciennement OSX, anciennement Mac OS X, Apple pourrait quand même arrêter sa frénésie de renommage) est sa base héritée d'Unix. Sans rentrer dans les détails, j'apprécie de pouvoir lancer un terminal et disposer d'un interpréteur de commandes (Bash) et de certains logiciels "classiques", comme Vim, wget, curl, sed ou awk. J'apprécie aussi de pouvoir installer certains logiciels très facilement via le terminal, ce qui est le cas sur un système GNU/Linux ou BSD. Bien que cela ne soit pas disponible pour macOS, plusieurs projets viennent combler ce manque :



J'ai par le passé utilisé MacPorts, mais aujourd'hui j'utilise pkgsrc. Les raisons qui m'ont fait passer de l'un à l'autre sont surtout liées à mes contributions au dernier : au-delà de la réutilisation de connaissances liées à NetBSD/pkgsrc, je peux aussi tester certains paquets pkgsrc sous macOS. Quelque chose que j'ai apprécié aussi est la disponibilité de paquets binaires pré-compilés grâce à Joyent, tout en conservant la possibilité de compiler soi-même de manière rapide et simple ces propres paquets.

Installation de pkgsrc pour les paquets binaires

L'installation de pkgsrc sur macOS est assez simple si on souhaite juste utiliser les paquets binaires, et un peu plus longue si on souhaite aussi compiler ses propres paquets, qu'on verra dans un second temps. Une manière plus rapide d'installer pkgsrc consiste à utiliser Save mac OS, un script shell de boostrap qui effectuera ces opérations pour vous. Néanmoins, il me semble pertinent de comprendre un peu le pourquoi des choses, et c'est l'objectif de cette partie.

Démarrons par le bootstrap, qui consiste à installer l'arborescence de base permettant d'obtenir les paquets binaires. Je pars ici du principe qu'on dispose d'une machine au moins sous 10.9. Si vous avez une version plus ancienne, suivez ce qui est indiqué pour 10.6 chez Joyent. On commence par télécharger l'archive contenant cette arborescence :

BOOTSTRAP_TAR="bootstrap-trunk-x86_64-20161011.tar.gz"
curl -O https://pkgsrc.joyent.com/packages/Darwin/bootstrap/${BOOTSTRAP_TAR}

Par principe, vérifions aussi que le téléchargement de pkgsrc s'est bien déroulé :

BOOTSTRAP_SHA="09d6649027ce12cadf35a47fcc5ce1192f40e3b2"
echo "${BOOTSTRAP_SHA}  ${BOOTSTRAP_TAR}" >check-shasum
shasum -c check-shasum

Tant qu'on y est dans les vérifications, on peut s'occuper de la signature GPG, si celui-ci est installé (c'est optionnel, vous pouvez l'installer sur le site de GPGTools) :

curl -O https://pkgsrc.joyent.com/packages/Darwin/bootstrap/${BOOTSTRAP_TAR}.asc
gpg --recv-keys 0x1F32A9AD
gpg --verify ${BOOTSTRAP_TAR}{.asc,}

Passons à l'installation de pkgsrc à proprement parler, c'est maintenant qu'on a besoin de droits administrateur :

sudo tar -zxpf ${BOOTSTRAP_TAR} -C /

Enfin, on prend en compte les chemins additionnels dans le $PATH, car les paquets s'installent dans l'arborescence /opt/pkg/ (les exécutables sont dans /opt/pkg/bin ou /opt/pkg/sbin) :

eval $(/usr/libexec/path_helper)

Pour ce qui est des pages de manuel, on peut ajouter la ligne suivante dans son fichier .profile :

export MANPATH=$MANPATH:/opt/pkg/share/man/

Une fois que cela est fait, on peut vérifier que pkgin est bien installé, et mettre à jour la liste des paquets depuis le dépôt :

sudo pkgin -f up
sudo pkgin fug

On peut alors utiliser pkgin pour lister, installer, mettre à jour ou désinstaller des logiciels. Attention, il est préférable de l'utiliser avec sudo, surtout pour les actions d'installation, de désinstallation ou de mise à jour.

Installation de pkgsrc pour compiler depuis les sources

La partie binaire mise en place, passons aux sources. Dans cette optique, il faut commencer par installer les command-line tools de Xcode. Cette partie peut nécessiter de créer un compte développeur chez Apple. L'installation se fait de la manière suivante :

xcode-select --install

Bien qu'un miroir Github de pkgsrc existe, nous allons préférer utiliser CVS pour récupérer l'arbre des paquets :

sudo pkgin -y in cvs
cd /opt
sudo mkdir pkgsrc
sudo chown $(whoami):wheel pkgsrc
cvs -danoncvs@anoncvs.netbsd.org:/cvsroot checkout pkgsrc

Optionnellement, on peut ajouter pkgsrc-wip, un arbre supplémentaire de paquets, qui permet entre autres aux débutants de se faire la main dans le domaine de l'empaquetage logiciel pour pkgsrc. Ici, pas besoin d'installer CVS, git est le gestionnaire de version de ce projet (et inclus de base dans macOS) :

cd /opt/pkgsrc
git clone git://wip.pkgsrc.org/pkgsrc-wip.git wip

Pour mettre à jour les arborescences :

cd /opt/pkgsrc
cvs update -dP
cd wip
git pull -r

Pour installer un paquet, par exemple figlet, on utilise la commande bmake (il s'agit du bsd make, disponible sous NetBSD directement via la commande make) :

cd /opt/pkgsrc/misc/figlet
bmake install

On pourra ensuite faire le nettoyage dans l'arborescence via :

bmake clean clean-depends

Avant de terminer, un petit mot sur le paramétrage du bootstrap et de son impact sur l'installation de logiciels via les sources : le boostrap de Joyent active la vérification par clé GPG des paquets binaires, afind de s'assurer de l'intégrité de ceux-ci. Or, cela peut perturber l'installation de paquets via les sources, car le paquet créé ne sera pas signé par Joyent. Il est possible de signer tous les paquets qu'on crée, mais cela peut devenir vite rébarbatif si le processus de compilation n'est pas automatisé. Dans le cas où l'installation d'un paquet par les sources échouerait, il est possible de modifier le niveau de confiance, en demandant de manière interactive si le paquet doit être installé ou non. Il suffit alors de positionner la variable VERIFIED_INSTALLATION à "trusted" dans le fichier /opt/pkg/etc/pkg_install.conf.

J'espère que ce billet aura plus et poussera plus d'utilisateurs de macOS à mieux maîtriser les possibilités de leur machine. Des remarques, des propositions d'améliorations ? Les commentaires sont là pour ça !

Propulsé par Dotclear