DAVROMANIAK
Le site de Cyril "Davromaniak" Lavier, sysadmin ascendant geek
If you're watching this, it means I'm dead now.

Keyword - Planet-Libre

Fil des billets - Fil des commentaires

mardi 12 juillet 2011

Pbuilder et tmpfs peuvent être bons amis

Ou comment accélérer de façon non négligeable les compiles de paquets sous Debian/Ubuntu.

Lire la suite...

mardi 21 juin 2011

Quelques news

Bonjour.

Après quelques mois d'inactivité, voici les dernières nouvelles.

Déjà, comme vous pouvez le voir, la nouvelle apparence du blog, plus sobre, et plus lisible.

Ensuite, les deux dépôts Debian que je maintiens (qui sont maintenant dans le menu principal).

Le dépôt OWFS est toujours là, et mis à jour régulièrement, avec la dernière version (2.8p9 sortie fin Mai), je prépare doucement le passage à Ubuntu Oneiric, ça devrait arriver dans les prochaines semaines.

Le nouvel arrivant, DDB (pour Davromaniak's Debian Backports), qui est un dépôt contenant les backports de paquets Debian que je réalise. Sachant qu'ils ont tous vocation à être proposés pour une inclusion dans les backports debian officiels. C'est un dépôt relativement stable, mais comme tout backports, il peut y avoir des risques.

Pour l'instant, j'ai mis à dispo les backports de nginx 1.0.4, chromium 11.0.696.71 et audacious 2.4.4. Le tout accompagnées de leurs dépendances de fonctionnement et de compilation.

D'ailleurs, concernant nginx 1.0.4, il a été récemment accepté dans les backports officiels, son inclusion est en cours là. Le paquet disponible (pour la version 1.0.4) sur DDB est donc le même que celui qui arrive sur les dépôts officiels, seul la version change (j'utilise "davrobpo60+1" au lieu de "bpo60+1" pour différencier mes paquets des paquets officiels).

Pour chromium, c'est un backport assez complexe (entre 20 et 30h de travail pour arriver à un fonctionnement correct), cependant, il n'est pas très propre, car j'ai préféré backporter les binutils, afin de ne pas trop altérer le paquet officiel.

Concernant audacious, il fonctionne, mais le travail est toujours en cours, surtout au niveau de la quantité de dépendances à backporter.

J'essaie de proposer les paquets dans le plus grand nombre d'architectures matérielles, et cela dépend de la taille des paquets. Pour l'instant, seulement OWFS et nginx sont proposés en 5 architectures différentes (amd64, armel, i386, mips et powerpc), car leur compilation n'est pas très longue. Concernant audacious, le nombre de dépendances le rendent pas facile à compiler sous autre architecture que amd64 et i386. Pour chromium, il n'est compatible que amd64, i386 et armel, cependant, sa compilation seule dure environ 25 minutes sur ma machine de compilation (8 cœurs, 16Go de ram), ma machine armel étant totalement l'inverse au niveau puissance, la compilation risque de durer des jours entiers.

Voila, c'est tout.

lundi 7 mars 2011

OWFS : Paquets Debian et Ubuntu

Bonjour.

OWFS est une suite logicielle libre (sous GPL) qui permet d'utiliser facilement le système 1-wire de maxim, permettant d'exploiter divers capteurs (température, humidité, luminosité, ouverture/fermeture de portes, etc...).

Dans mon entreprise actuelle, ça fait environ 1 an et demi qu'on utilise le 1-wire, et à ce moment là, j'avais réalisé des paquets pour OWFS.

Ces paquets étaient plutôt bruts et relativement peu en accord avec la Debian Policy, mais ils fonctionnaient, et ça suffisait pour le moment.

Cependant, il y a quelques temps, il a été décider de publier ces paquets, afin d'aider la communauté qui existe autour d'OWFS, et plus généralement de la domotique.

Pour cela, j'ai donc travailler à mettre à jour et à rendre les paquets plus propres, et donc publiables.

Ce midi, par un mail (en anglais) sur la liste de diffusion, la diffusion des paquets pour OWFS a été officialisée et rendue publique.

Le mail étant en anglais, je ne vais pas le traduire dans son intégralité, vu que l'introduction de ce billet reprend en partie l'introduction du mail, je vais plutôt transcrire la suite du mail.

Les paquets sont disponibles pour les versions suivantes de Debian et Ubuntu :

  • Debian 5.0 "Lenny" (oldstable)
  • Debian 6.0 "Squeeze" (stable)
  • Debian 7.0 "Wheezy" (testing)
  • Debian Sid (unstable)
  • Ubuntu 8.04 "Hardy" (LTS)
  • Ubuntu 9.04 "Jaunty"
  • Ubuntu 9.10 "Karmic"
  • Ubuntu 10.04 "Lucid" (LTS)
  • Ubuntu 10.10 "Maverick"
  • Ubuntu 11.04 "Natty" (testing)

Maintenant, parlons des paquets.

Pour l'instant, je n'ai pas créé de paquets pour owperl, owmon, owtap, owphp, owcapi, owpython, owtcl, owftpd et owhttpd

Pour owftpd et owhttpd, je pense créer des paquets dans un futur pas trop lointain, sûrement pour une version 2.8p8 ou 2.8p9.

Pour les autres paquets, je n'ai, à l'heure ou j'écris ces lignes, aucune idée de quand je le ferai, mais ce n'est pas un abandon, plus une volonté de réaliser des paquets propres et fiables pour les composants essentiels d'OWFS, pour ensuite m'atteler aux autres composants.

Voici la liste des paquets (en versions 2.8p6 et 2.8p7, sauf indication) :

  • owfs-common : contient le fichier de configuration et la page de manuel.
  • owfs-server : contient le serveur owfs (/usr/sbin/owserver, il était placé dans /usr/bin, mais je l'ai déplacé dans /usr/sbin pour coller au mieux à la Debian Policy), sa page de manuel et son script de lancement.
  • owfs (2.8p7 seulement) : contient le serveur qui gère le système de fichiers 1-wire (/usr/sbin/owfs, il était placé dans /usr/bin, mais comme pour owserver, je l'ai déplacé dans /usr/sbin), sa page de manuel et son script de lancement.
  • owfs-client : contient les clients (owdir, owpresent, owread, owwrite and owread), et leurs pages de manuel.
  • libow-2.8-7 (2.8p7 seulement) : contient la libow en version 2.8p7
  • libow-2.8-6 (2.8p6 seulement) : contient la libow en version 2.8p6
  • owfs-dev : contient le fichier /usr/include/owfs_config.h
  • owfs-doc : contient toutes les pages de manuel restantes (notament celles sur les capteurs)
  • owfs-dbg : contient les symboles de débogage.

Pour l'installer le serveur et les clients, installez les paquets owfs-server et owfs-client. Pour utiliser directement le système de fichiers 1-wire, installez le paquet owfs.

Voici l'adresse du dépôt : http://owfs.davromaniak.eu

Voila, vous avez toutes les informations.

Je remercie Paul Alfille et les contributeurs du projet OWFS pour tout leur travail.

Là, j'ai réalisé quelques patchs qui sont inclus dans les paquets, je vais m'occuper aussi de leur diffusion.

De plus, il n'est pas impossible que je travaille à faire inclure ces paquets dans Debian (et aussi Ubuntu par la suite). Je vous tiendrai au courant pour tout ça.

@+

jeudi 3 mars 2011

La machine ultime pour compiler ses paquets debian.

Voici un "petit" billet qui est à la frontière entre le perso et le boulot, mais qui risque d'être utile pour beaucoup de gens.

Dans le cadre de mon emploi actuel, je passe un certain temps à faire des paquets Debian, mais aussi Ubuntu.

Au début, j'utilisais 2 machines virtuelles, avec un petit pbuilderrc, cependant, ayant eu l'opportunité d'utiliser une machine plus puissante (4 coeurs et 4Go de ram), je me suis dis qu'il serait plutôt pratique de fusionner les 2 machines, et d'avoir qu'une machine de build.

Ma machine de build tourne sous Debian sid, même si j'ai longtemps été fidèle à Ubuntu, maintenant, je suis passé du coté de Debian (y compris pour mon poste de travail).

Pourquoi Debian sid ?, juste pour avoir les dernières versions des outils de build, surtout pour debootstrap.

Ça peut marcher aussi sous Debian stable, et même Ubuntu (mais quelques petites choses sont différentes).

Bon, commençons.

Les commandes précédées d'un "#" sont à exécuter en root, les commandes précédées d'un "$" sont à exécuter en utilisateur normal, non privilégié.

Précision, ma machine étant en 64 bits, j'ai la possibilité de compiler des paquets 32 et 64 bits.

En premier, il faut installer sudo, car avec le temps, j'ai appris (à mes dépends) qu'il ne faut jamais bidouiller ses paquets source en root, car ce n'est pas nécessaire, et que de plus, après quelques heures de tapotage de clavier, la fatigue faisant, on peut faire des actes regrétables et se transformer en Rage Guy pendant 5 minutes.

# aptitude install sudo

Ensuite, il faut adapter la configuration de sudo à ce qu'on fera avec pbuilder.

# visudo

Voici mon fichier de configuration de sudo :

#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults	env_reset,env_keep="DIST ARCH CONCURRENCY_LEVEL"

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root	ALL=(ALL:ALL) ALL

# Allow members of group sudo to execute any command
%sudo	ALL=(ALL:ALL) ALL

#includedir /etc/sudoers.d

# Members of the admin group may gain root privileges
%adm ALL=(ALL:ALL) ALL

Remarquez surtout la ligne Defaults qui contient les instructions pour garder le contenu des variables DIST, ARCH et CONCURRENCY_LEVEL. Gardez les noms de ces variables dans la tête, on les utilisera après.

Après avoir installé sudo, on va s'occuper de la partie concrète de la compilation, avec l'installation des outils de compilation.

# aptitude install debhelper build-essential dpkg-dev pbuilder devscripts debootstrap

Parmis ces paquets, les plus remarquables sont pbuilder et debootstrap

  • pbuilder permet de construire ses paquets dans un chroot de la distribution que l'on veut utiliser.
  • debootstrap permet de créer ce chroot (il est appelé par pbuilder lors de la création d'un pbuilder)

Le paquet Lintian est aussi utile, car il permet de tester la conformité des paquets avec la Debian Policy.

Après avoir installé tout ça, il faut encore configurer le pbuilder, avec le fichier pbuilderrc. Vu que je n'aime pas trop aller modifier la configuration par défaut (placée dans /etc/pbuilderrc), je préfére créer le fichier /root/.pbuilderrc). Dont voici le mien.

# Codenames for Debian suites according to their alias. Update these when
# needed.
UNSTABLE_CODENAME="sid"
TESTING_CODENAME="wheezy"
STABLE_CODENAME="squeeze"
STABLE_BACKPORTS_SUITE="$STABLE_CODENAME-backports"
OLD_STABLE_CODENAME="lenny"
OLD_STABLE_BACKPORTS_SUITE="$OLD_STABLE_CODENAME-backports"

# List of Debian suites.
DEBIAN_SUITES=($UNSTABLE_CODENAME $TESTING_CODENAME $STABLE_CODENAME $OLD_STABLE_CODENAME "unstable" "testing" "stable" "experimental")

# List of Ubuntu suites. Update these when needed.
UBUNTU_SUITES=("natty" "maverick" "lucid" "karmic" "jaunty" "intrepid" "hardy" "gutsy")

# Mirrors to use. Update these to your preferred mirror.
DEBIAN_MIRROR="ftp.fr.debian.org/"
UBUNTU_MIRROR="fr.archive.ubuntu.com"

# Use old-releases mirrors for EOL versions
if [ "${DIST}" == "gutsy" ]; then
	UBUNTU_MIRROR="old-releases.ubuntu.com"
fi
if [ "${DIST}" == "intrepid" ]; then
	UBUNTU_MIRROR="old-releases.ubuntu.com"
fi
# Optionally use the changelog of a package to determine the suite to use if
# none set.
if [ -z "${DIST}" ] && [ -r "debian/changelog" ]; then
    DIST=$(dpkg-parsechangelog | awk '/^Distribution: / {print $2}')
    # Use the unstable suite for Debian experimental packages.
    if [ "${DIST}" == "experimental" ]; then
        DIST="unstable"
    fi
fi

# Optionally set a default distribution if none is used. Note that you can set
# your own default (i.e. ${DIST:="unstable"}).
: ${DIST:="$(lsb_release --short --codename)"}

# Optionally set the architecture to the host architecture if none set. Note
# that you can set your own default (i.e. ${ARCH:="i386"}).
: ${ARCH:="$(dpkg --print-architecture)"}

NAME="$DIST"
if [ -n "${ARCH}" ]; then
    NAME="$NAME-$ARCH"
    DEBOOTSTRAPOPTS=("--arch" "$ARCH" "${DEBOOTSTRAPOPTS[@]}")
fi
BASETGZ="/var/cache/pbuilder/$NAME-base.tgz"
DISTRIBUTION="$DIST"
BUILDRESULT="/var/cache/pbuilder/$NAME/result/"
APTCACHE="/var/cache/pbuilder/$NAME/aptcache/"
BUILDPLACE="/var/cache/pbuilder/build/"

if $(echo ${DEBIAN_SUITES[@]} | grep -q $DIST); then
    # Debian configuration
    MIRRORSITE="http://$DEBIAN_MIRROR/debian/"
    COMPONENTS="main contrib non-free"
    if $(echo "$STABLE_CODENAME stable" | grep -q $DIST); then
        EXTRAPACKAGES="$EXTRAPACKAGES debian-backports-keyring"
        OTHERMIRROR="$OTHERMIRROR | deb http://backports.debian.org/debian-backports $STABLE_BACKPORTS_SUITE $COMPONENTS"
    elif $(echo "$OLD_STABLE_CODENAME stable" | grep -q $DIST); then
        EXTRAPACKAGES="$EXTRAPACKAGES debian-backports-keyring"
        OTHERMIRROR="$OTHERMIRROR | deb http://backports.debian.org/debian-backports $OLD_STABLE_BACKPORTS_SUITE $COMPONENTS"
    elif $(echo "unstable" | grep -q $DIST); then
	DIST="$UNSTABLE_CODENAME"
	OTHERMIRROR="$OTHERMIRROR | deb http://ftp.fr.debian.org/debian/ experimental main"
    fi
elif $(echo ${UBUNTU_SUITES[@]} | grep -q $DIST); then
    # Ubuntu configuration
    MIRRORSITE="http://$UBUNTU_MIRROR/ubuntu/"
    COMPONENTS="main restricted universe multiverse"
     v=0
     n=0
     for i in ${DEBOOTSTRAPOPTS[@]}; do
	if [ $v -ne 0 ]; then
		DEBOOTSTRAPOPTS[$n]="/usr/share/keyrings/ubuntu-archive-keyring.gpg"
	fi
	if [ $i == "--keyring" ]; then
		v=1;
	fi
	n=$((n+1))
     done
else
    echo "Unknown distribution: $DIST"
    exit 1
fi

Afin de faciliter son téléchargement, vous pouvez le télécharger ici

Cependant, avant de vous jeter à corps perdu à créer les pbuilder des différentes versions de Ubuntu, il y a un petit truc à faire si vous êtes sous debian.

Dans les paquets debootstrap de Debian et Ubuntu, Il s'avère que les fichiers /usr/share/debootstrap/scripts/gutsy sont légèrement différents (une ligne), mais ça suffit pour causer des soucis, surtout sous Ubuntu 11.04 "Natty".

Donc sous Debian, à la ligne 72 du fichier /usr/share/debootstrap/gutsy, ajoutez la ligne suivante :

ln -nsf . "$TARGET/var/lib/dpkg/info/$ARCH"

Là, nous sommes enfin prets.

Avec ce beau .pbuilderrc, vous n'aurez qu'à taper la commande suivante pour créer un pbuilder Debian Squeeze en 64 bits :

$ DIST=squeeze ARCH=amd64 sudo pbuilder create

Ou un pbuilder Ubuntu Natty en 32 bits :

$ DIST=natty ARCH=i386 sudo pbuilder create

Mais là, vous vous demandez "Pourquoi nous a-t-il parlés de la variable CONCURRENCY_LEVEL ?".

Voici la réponse.

La variable CONCURRENCY_LEVEL permet de lancer plusieurs processus pour une compilation, en d'autres termes, pour ceux qui connaissent make, ça correspond à l'option "-j".

Pour compiler un paquet source avec 4 processus sous Debian Squeeze 64 bits voici comment faire :

$ CONCURRENCY_LEVEL=4 DIST=squeeze ARCH=amd64 sudo pbuilder build paquet.dsc

Pour compiler un paquet source avec 2 processus sous Ubuntu Natty 32 bits voici comment faire :

$ CONCURRENCY_LEVEL=2 DIST=natty ARCH=i386 sudo pbuilder build paquet.dsc

Voila, la machine de build est prête et fonctionnelle.

Mais sachant que j'aime bien avoir mes propres fonctions qui peuvent m'aider à automatiser certaines tâches, j'ai créé dans le dossier personnel de mon utilisateur non privilégié un dossier .scripts avec un fichier nommé pbuilder_utils dont voici le contenu :

function update_pbuilder() {
	nprocs=$(grep -cE "^processor" /proc/cpuinfo)
	dists=$@
	for i in $dists; do
		CONCURRENCY_LEVEL=$nprocs DIST=$i ARCH=i386 sudo pbuilder update
		CONCURRENCY_LEVEL=$nprocs DIST=$i ARCH=amd64 sudo pbuilder update
	done
}
function create_pbuilder() {
	nprocs=$(grep -cE "^processor" /proc/cpuinfo)
	dists=$@
	for i in $dists; do
		CONCURRENCY_LEVEL=$nprocs DIST=$i ARCH=i386 sudo pbuilder create
		CONCURRENCY_LEVEL=$nprocs DIST=$i ARCH=amd64 sudo pbuilder create
	done
}
function clean_pbuilder() {
	nprocs=$(grep -cE "^processor" /proc/cpuinfo)
	dists=$@
	for i in $dists; do
		CONCURRENCY_LEVEL=$nprocs DIST=$i ARCH=i386 sudo pbuilder --clean
		CONCURRENCY_LEVEL=$nprocs DIST=$i ARCH=amd64 sudo pbuilder --clean
	done
}
function build_pbuilder() {
	nprocs=$(grep -cE "^processor" /proc/cpuinfo)
	dsc=$1
	shift
	dists=$@
	for i in $dists; do
		CONCURRENCY_LEVEL=$nprocs DIST=$i ARCH=i386 sudo pbuilder build $dsc
		CONCURRENCY_LEVEL=$nprocs DIST=$i ARCH=amd64 sudo pbuilder build $dsc
	done
}

Dans le fichier .bashrc, j'ai ajouté la ligne source ~/.scripts/pbuilder_utils.

Vu comme ça, c'est un peu bourrin, mais voici les explications :

  • update_pbuilder : Permet de faire une mise à jour des pbuilders voulus, dans les 2 architectures, exemple : update_pbuilder squeeze natty
  • create_pbuilder : Permet de créer les pbuilders voulus, dans les 2 architectures, exemple : create_pbuilder squeeze natty
  • clean_pbuilder : Permet de nettoyer les pbuilders voulus, dans les 2 architectures, exemple : clean_pbuilder squeeze natty
  • build_pbuilder : Permet de compiler un paquet pour les distributions voulues et dans les 2 architectures, exemple : build_pbuilder paquet.dsc natty lenny squeeze

Voila, c'est à peu près tout.

Pour le pbuilderrc fourni ici, j'ai pris comme base celui fourni sur le wiki de ubuntu.com à l'adresse suivante : https://wiki.ubuntu.com/PbuilderHowto#Multiple%20pbuilders

Pour le reste, ben c'est de l'arrachage de cheveux, de la bidouille et de multiples essais infructueux.

Sur ce, bonne lecture.

mercredi 24 mars 2010

SFS Update 0.3pre : un aperçu de la 0.3

Bonjour.

Il y a quelques semaines, la version 0.2 sortait, avec plein de promesses pour la version 0.3.

Afin de contenir votre impatience et de pouvoir montrer à quoi ressemblera la 0.3, j'ai décidé de sortir une version préliminaire de la 0.3, qui gère une partie des moteurs de forums listés lors du dernier billet.

Voici donc les moteurs maintenant gérés dans cette version :

  • PHPBB2
  • PHPBB3
  • Fluxbb 1.2 (experimental)
  • Beehive 0.9 (experimental)
  • FUDForum 3 (experimental)
  • IceBB (experimental)
  • MyBB (experimental)

J'ai dû abandonner l'idée d'implémenter le support pour les moteurs suivants :

  • bbPress : Aucune gestion des bannissements n'est géré.
  • kusaba : Projet plus maintenu
  • MercuryBoard : Projet plus maintenu
  • MiniBB support : Gestion des bannissements trop peu complète

Pour rappel, la version 0.3 supportera aussi les forums suivants (sous réserve de compatibilité) :

  • NextBBS
  • NinkoBB
  • Quicksilver Forums
  • UseBB
  • Vanilla
  • XMB

La sortie de la version 0.3 marquera aussi la mise en place d'un GIT public pour ce projet, afin que chacun puisse y apporter des améliorations.

Voici les liens pour le télécharger la version 0.3pre : sfs_update-0.3pre.tar.bz2
sfs_update-0.3pre.tar.gz

Si vous remarquez des bugs, ou des imperfections, n'hésitez pas à me contacter.

@+

samedi 6 mars 2010

SFS Update arrive en version 0.2

Et la version 0.3 fait parler d'elle

Lire la suite...

lundi 22 février 2010

SFS Update 0.1.4

Une nouvelle version pleine d'évolutions.

Lire la suite...

lundi 15 février 2010

SFS Update 0.1.3

2 nouvelles fonctionnalités

Lire la suite...

lundi 23 novembre 2009

Ubuntu Party Karmic Koala parisienne le 28 et 29 novembre

Le retour de la 4K Team

Lire la suite...

jeudi 15 octobre 2009

L'absurdité de la volonté d'interdire les liens HTML

Bonjour.

Récemment, je suis tombé sur un article du blog Formats Ouverts, qui traite de la volonté de certains webmasters et sociétés à ne pas autoriser librement la création de liens HTML vers leurs sites.

Une liste est même disponible sur ce même blog

Une partie de l'article a attiré mon attention :

___

Si votre site Web mentionne dans ses Mentions légales ou dans ses Conditions générales d'utilisation qu'il faut « une autorisation préalable pour établir un lien hypertexte vers lui », alors voici les 10 questions et problèmes qui se posent à vous :

1. Google a-t-il votre autorisation ? Sinon, vous devrez l'attaquer, ou lui demander de vous retirer de sa base de liens.
2. Supprimez vos flux RSS ? C'est obligatoire, car ces flux sont des liens que vous demandez de faire vers vous : contradictoire.
3. Tous les auteurs de courriels (lettres d'informations, listes de diffusion) qui indiquent votre site ont-ils une autorisation ? Sinon, interdit de mentionner votre site.
4. Peut-on vous citer sur Twitter ? Non si Twitter n'a pas eu l'autorisation de faire des liens vers vous : attaquer Twitter ?
5. Revoir le contrat de travail de vos employés ? Ils mettent votre site en signature de leurs courriers électroniques : ont-ils par écrit le droit de faire ce lien ?
6. Et tous les auteurs de tous documents ? Mentionner votre site dans n'importe quel document (texte, présentation, tableur), c'est faire un lien : ils doivent avoir votre autorisation.
7. MSN ou Yahoo Messenger ? Ces outils de messagerie instantanée font des liens quand on écrit votre site : ont-ils une autorisation ?
8. Interdisez d'être enregistré dans les favoris ou les signets ? C'est indispensable, ce sont des liens.
9. Les forum et les commentaires des blogs ? Les auteurs de ces commentaires (et les sites) ne peuvent faire de lien sans votre autorisation.
10. Les adresses compactées ? Elles sont systématiques sur Twitter : les sites qui les créent ont-ils votre autorisation ?
___

Pour ma part, je trouve cette volonté de contrôle totalement inutile.

Le lien hypertexte étant un des symboles de la toile internet, vouloir le contrôler serait une démonstration de l'orgueil de certaines personnes qui croient pouvoir contrôler le monde.

Pour répondre à ces absurdités, autant utiliser l'absurde.

Je vous propose d'envoyer à chaque site qui n'autorise pas les liens HTML sans autorisation écrite un mail faisant part de votre volonté d'ajouter le site en question dans vos marque-pages, :). Voici un exemple ci-dessous :

___

Bonjour

Dans les conditions générales d'utilisation de votre site, j'ai lu qu'il est obligatoire d'avoir une autorisation écrite afin de créer un lien pointant vers votre site.

Voulant ajouter votre site dans les signets de mon navigateur internet, je vous demande donc cette autorisation, par retour de mail.

Cordialement
___

C'est une action sûrement débile, mais au moins, vous respecterez les CGU du site concerné.

@+

- page 2 de 6 -