Modifications entre les versions 5 et 30 (s'étendant sur 25 versions)
⇤ ← Version 5 à la date du 2008-01-15 22:26:10 →
Taille: 7004
Éditeur: ThomasNoël
Commentaire: désolé JC, j'ai tout repris en retirant (archivant) ce que tu avais écrit pour plus de clareté... (?)
← Version 30 à la date du 2011-03-11 03:14:48 → ⇥
Taille: 4766
Éditeur: JeanChristopheAndré
Commentaire: adél réelle mais masquée
Texte supprimé. Texte ajouté.
Ligne 1: Ligne 1:
Cette page présente le dépôt de paquets Debian/Ubuntu spécifiques à l'AUF. = Que peut-on proposer ? Qui peut ? =
Ligne 3: Ligne 3:
 ||<#ffaa00> Il s'agit d'un système en cours de mise en place, ne pas utiliser pour l'instant merci !|| Si vous savez fabriquer des paquets Debian ou Ubuntu, vous pouvez les mettre à disposition sur le dépôt AUF. Pour cela, il faut :
 * savoir faire des paquets Debian corrects : `dh-make`, `debuild`, retro-portages, ...
 * savoir à quelle distribution sont destinés les paquets :
  * Debian lenny ou squeeze
  * Ubuntu lucid, maverick, natty, etc
 * avoir un accès au réseau privé de l'AUF (aucun autre accès spécifique n'est nécessaire, ni mot de passe, ni clé ssh, rien).
Ligne 5: Ligne 10:
= Accès aux paquets disponibles = Tout le monde peut envoyer des paquets selon deux niveaux :
 * '''niveau experimental''' : paquets destinés à expérimenter de nouvelles idées, de nouvelles façons de faire
 * '''niveau test''' : paquets qui demandent à être testés et qui sont des candidats pour devenir des paquets « officiels » de l'AUF.
Ligne 7: Ligne 14:
D'abord installer la clé publique GPG qui signe certains fichiers du dépôt : Une fois qu'un paquet est correctement testé, il est validé : il faut alors demander son inclusion dans le '''niveau stable'''. Il suffit d'envoyer votre demande sur la liste de discussion technique de l'AUF, un des « ftp-masters » se fera un plaisir d'y répondre.

= Concrétement =

Pour envoyer un paquet, on utilise '''dput''' : `aptitude install dput`.

Voici une configuration typique, à placer dans `$HOME/.dput.cf` :
Ligne 9: Ligne 22:
$ wget -qO - http://apt.auf.org/B7520EF5BF4CCF4D.asc | sudo apt-key add - # Exemple de configuration de "dput" pour envoyer des paquets
# pour Ubuntu "Hardy" (8.04) dans les sections "test" et "experimental".
[DEFAULT]
hash = md5
allow_unsigned_uploads = 1
run_dinstall = 0
scp_compress = 1
default_host_main = precisez-la-section
fqdn = apt.auf
method = ftp
login = anonymous

# paquets pour "lucid-tests auf"
[lucid-test]
incoming = test/lucid

# paquets pour "lucid-experimental auf"
[lucid-experimental]
incoming = experimental/lucid
Ligne 12: Ligne 43:
Ensuite ajouter les sources qui vous conviennent en fonction de ce que vous avez à mettre en place. Les lignes à ajouter dans le `sources.list` sont de la forme : Pour envoyer un paquet en mode experimental il suffit alors de faire :
Ligne 14: Ligne 45:
deb http://apt.auf.org/ distribution composant
}}}
Exemples (non fonctionnels à l'heure de la rédaction) :
 {{{
# paquets pour la mise en place d'un serveur VoIP Asterisk AUF :
deb http://apt.auf.org/ etch voip
# paquets spécifiques à Dakar pour les postes clients Ubuntu Feisty :
deb http://apt.auf.org/ feisty sn		 $ dput lucid-experimental le-nom-du-paquet.changes
Ligne 24: Ligne 48:
= Pour ajouter ses petits paquets = Si tout va bien le paquet sera ajouté dans le dépôt 5 minutes plus tard (par cron). Vous pourrez voir le résultat de votre demande en suivant [[http://apt.auf.org/rss.xml|le flux RSS de apt.auf.org]]. Si la version expérimentale fonctionne chez vous, envoyez dans `lucid-test` et demandez à des collègues de tester.
Ligne 26: Ligne 50:
Il faut :
 * savoir faire des beaux paquets Debian : `dpkg-buildpackage`, `dh-make`, retroportages, ...
 * savoir à quelle distribution sont destinés les paquets : etch, lenny, feisty, gutsy, hardy, ...
 * trouver un nom pour le composant : voip, rpv2, auf-desktop, votre-iso-pays, votre-nom, ...
 * avoir un compte ''ssh'' sur la machine `apt.auf.org` (demander à Moussa)
 * avoir un répertoire (''incoming'' ou tout autre nom poétique) configuré pour recevoir les paquets (fichiers changes, deb, dsc et sources)
Ligne 33: Ligne 51:
Pour envoyer un paquet, on utilise '''dput''' (`aptitude install dput`) que l'on configure ainsi dans son ~/.dput.cf :
 {{{
# extrait de ~/.dput.cf (inspiré de /etc/dput.cf) :
[DEFAULT]
method = rsync
hash = md5
allow_unsigned_uploads = 0
run_lintian = 0
run_dinstall = 0
check_version = 0
default_host_main = voip
fqdn = apt.auf.org		 == Annexe : proposer un paquet binaire pour plusieurs architecture (i386 et amd64) ==
Ligne 46: Ligne 53:
# par défaut on envoie ici :
[voip]
incoming = ~/incoming/voip		 Pour proposer un paquet binaires dans plusieurs architectures (typiquement i386 et amd64) :
  * il faut compiler d'abord une architecture classiquement et inclure les sources dans l'upload (donc `dpkg-buildpackage` avec l'option `-sa`)
  * envoyer par `dput` le `...changes`
  * puis compiler la ou les autres architectures avec l'option `-b` qui ne construit ''que'' le paquet binaire...
  * envoyer par `dput` le ou les `...changes` obtenus
Ligne 50: Ligne 59:
# mais on peut aussi envoyer ici (en ajoutant voip-test après dput) :
[voip-test]
incoming = ~/incoming/voip-test
}}}		 = Pour les curieux : comment ça marche à l'intérieur =
Ligne 55: Ligne 61:
Pour envoyer un paquet il suffit de faire :
 {{{$ dput nom-du-paquet.changes
}}}		 {{attachment:reprepro-apt-auf-org.png}}
Ligne 59: Ligne 63:
Si tout va bien le paquet sera ajouté dans le dépôt 5 minutes plus tard. Sinon un courriel sera envoyé à qui de droit, qui vous informera de la fin de votre contrat à l'AUF. Le système est basé sur [[http://mirrorer.alioth.debian.org/|reprepro]] ([[http://packages.debian.org/etch/reprepro|version etch]]). C'est ce logiciel qui gère le dépot : on lui dit quel paquet ajouter à quel composant de quelle distribution, et il gère le pool, les fichiers Release, Packages, Sources, etc. A côté, un serveur ''apache2'' propose le dépôt en HTTP.
Ligne 61: Ligne 65:
= Comment ça marche à l'intérieur =

Le système est basé sur [http://mirrorer.alioth.debian.org/ reprepro] ([http://packages.debian.org/etch/reprepro version etch]). C'est ce logiciel qui gère le dépot, un serveur ''apache2'' le propose en HTTP. Notez que la version etch de reprepro ne gère pas la notion de répertoires "incoming", j'ai donc écrit cette partie. Une version plus récente semble savoir le faire, je l'étudierais plus tard.

Le principe : il y a un utilisateur virtuel "reprepro" sur le système, qui gère le dépôts. C'est cet utilisateur qui va lancer le logiciel "reprepro" avec les bons arguments, régulièrement (via cron).		 Le principe : il y a un utilisateur virtuel "reprepro" sur le système, qui gère le dépôts. C'est cet utilisateur qui va lancer le logiciel "reprepro" avec les bons arguments. Il est le seul à avoir accès en écriture sur le dépôt.
Ligne 71: Ligne 71:
Un script lance le logiciel reprepro en lui disant d'aller chercher les paquets de tel composant pour telle distribution dans tel répertoire. La liste de ces triplets est dans `~reprepro/incomings` : Un script shell appelé `reprepro-incoming` lance le logiciel reprepro en lui disant d'aller chercher les paquets de tel composant pour telle distribution dans tel répertoire. La liste de ces paramètres est dans `~reprepro/incomings` :
Ligne 73: Ligne 73:
# (... extrait de ~reprepro/incomings ...)
# voip : la config AUF d'asterisk 1.2 pour etch
etch voip /home/thomas/voip
# voip-test : backport de asterisk 1.4 en cours
etch voip-test /home/thomas/voip-test		 # Fichier ~reprepro/incomings

# Format d'une ligne :
# distrib composant repertoire email-pour-rapport

squeeze-test auf /home/ftp/test/squeeze root+aptauf_À_auf.org
squeeze-experimental auf /home/ftp/experimental/squeeze root+aptauf_À_auf.org
Ligne 80: Ligne 82:
Le script (version du 15 janvier 22h TU) :
 {{{$ cat ~reprepro/reprepro-incoming
#!/bin/bash		 Le script `reprepro-incoming` gère l'envoie de rapport par mail (dernier paramètre de chaque ligne d'appel). Il est lancé par '''cron toutes les 5 minutes'''.
Ligne 84: Ligne 84:
# reprepro-incoming <dist> <component> [<repertoire>]
# - se place dans le repertoire indiqué, y regarde les fichiers .changes
# - pour chaque fichier .change, analyse si les fichiers correspondants sont présents
# (pour le cas d'un upload en cours)
# - si oui, envoie les paquets dans le dépot, sur la distrib et selon le composant indiqué
# La configuration est dans /etc/reprepro/options et /etc/reprepro/distributions (cf man reprepro)
# Exemple :
# $ reprepro-incoming etch voip /home/thomas/voip/		 Pour info, le script dans sa version du 11 février 15h TU : [[attachment:reprepro-incoming]]
Ligne 93: Ligne 86:
# Note : reprepro-incoming est destiné à tourner en cron, il ne dit rien s'il
# n'a rien à faire. Exemple de configuration en cron :
# */5 * * * * reprepro cd /home/reprepro && ./reprepro-incoming
# Attention, reprepro ne gère sans doute pas les accès concurrents à un même dépôt !		 = Il reste à faire =
Ligne 98: Ligne 88:
# Note : si on lance "reprepro-incoming" sans argument, il va lire le fichier ~/incomings
# qui contient un triplet "<dist> <component> [<repertoire>]" par ligne. r-i se lance
# alors autant de fois que de ligne, avec ces arguments à chaque fois... Ces lancements
# séquentiels évitent d'avoir à ce soucier des accès concurrents...
if [ $# -eq 0 -a -r ~/incomings ]; then
        sed '/^\s*#/d;/^\s*$/d' ~/incomings | while read ARGS; do
                ~/reprepro-incoming $ARGS # le script s'appelle lui-même ici
                if [ $? -ne 0 ]; then
                        echo " ^^ erreur lors de $0 $ARGS ^^ "
                        echo ""
                fi
        done
        exit 0
fi

if [ $# -lt 2 ]; then
        echo "syntaxe: $0 distribution component [repertoire]" >&2
        exit 1
fi
DISTRIB=${1}
COMPONENT=${2}

# s'il existe un 3ème argument c'est un repertoire, on va dedans
if [ -n "${3}" ]; then
        cd "${3}" || exit 2
fi

# pas de fichier .changes : on s'arrete ici (silencieusement car ça peut être normal)
ls *.changes > /dev/null 2>&1 || exit 0

export REPREPRO_CONFIG_DIR=${REPREPRO_CONFIG_DIR:-~/conf}

# on analyse chaque fichier changes
for fc in *.changes; do
        # les md5sum sont-ils ok ?
        sed '0,/^Files:\s*$/d' ${fc} | while read MD5 SIZE SECT PRIO FILE; do
                echo $MD5" "$FILE
        done | md5sum --check --status > /dev/null 2>&1
        if [ $? -ne 0 ]; then
                echo "warn: fichier ${fc}, echec de la verification des sommes md5"
                sed '0,/^Files:\s*$/d' ${fc} | while read MD5 SIZE SECT PRIO FILE; do
                        echo $MD5" "$FILE
                done | md5sum --check
                # md5 pas bon : on passe au .change suivant
                continue
        fi
        echo "traitement de ${fc} :"
        echo "$ reprepro --component $COMPONENT include $DISTRIB $fc"
        # on envoie dans le dépôt (et si ça passe pas, on va pas plus loin !)
        reprepro -V --component $COMPONENT include $DISTRIB $fc || exit 3
        # et on efface les fichiers, ils sont dans le pool maintenant
        sed '0,/^Files:\s*$/d' ${fc} | while read MD5 SIZE SECT PRIO FILE; do
                rm -f $FILE
        done
        rm -f ${fc}
        echo ""
done
}}}		  * regarder le [[http://packages.debian.org/etch-backports/reprepro|backport de reprepro]] et notamment son "processincoming"
 * mettre tout le code sur git.auf.org

Que peut-on proposer ? Qui peut ?

Si vous savez fabriquer des paquets Debian ou Ubuntu, vous pouvez les mettre à disposition sur le dépôt AUF. Pour cela, il faut :

  • savoir faire des paquets Debian corrects : dh-make, debuild, retro-portages, ...

  • savoir à quelle distribution sont destinés les paquets :
    • Debian lenny ou squeeze
    • Ubuntu lucid, maverick, natty, etc
  • avoir un accès au réseau privé de l'AUF (aucun autre accès spécifique n'est nécessaire, ni mot de passe, ni clé ssh, rien).

Tout le monde peut envoyer des paquets selon deux niveaux :

  • niveau experimental : paquets destinés à expérimenter de nouvelles idées, de nouvelles façons de faire

  • niveau test : paquets qui demandent à être testés et qui sont des candidats pour devenir des paquets « officiels » de l'AUF.

Une fois qu'un paquet est correctement testé, il est validé : il faut alors demander son inclusion dans le niveau stable. Il suffit d'envoyer votre demande sur la liste de discussion technique de l'AUF, un des « ftp-masters » se fera un plaisir d'y répondre.

Concrétement

Pour envoyer un paquet, on utilise dput : aptitude install dput.

Voici une configuration typique, à placer dans $HOME/.dput.cf : 

  • # Exemple de configuration de "dput" pour envoyer des paquets
# pour Ubuntu "Hardy" (8.04) dans les sections "test" et "experimental".
[DEFAULT]
hash                    = md5
allow_unsigned_uploads  = 1
run_dinstall            = 0
scp_compress            = 1
default_host_main       = precisez-la-section
fqdn                    = apt.auf
method                  = ftp
login                   = anonymous

# paquets pour "lucid-tests auf"
[lucid-test]
incoming                = test/lucid

# paquets pour "lucid-experimental auf"
[lucid-experimental]
incoming                = experimental/lucid

Pour envoyer un paquet en mode experimental il suffit alors de faire : 

  • $ dput lucid-experimental le-nom-du-paquet.changes

Si tout va bien le paquet sera ajouté dans le dépôt 5 minutes plus tard (par cron). Vous pourrez voir le résultat de votre demande en suivant le flux RSS de apt.auf.org. Si la version expérimentale fonctionne chez vous, envoyez dans lucid-test et demandez à des collègues de tester.

Annexe : proposer un paquet binaire pour plusieurs architecture (i386 et amd64)

Pour proposer un paquet binaires dans plusieurs architectures (typiquement i386 et amd64) :

  • il faut compiler d'abord une architecture classiquement et inclure les sources dans l'upload (donc dpkg-buildpackage avec l'option -sa)

  • envoyer par dput le ...changes

  • puis compiler la ou les autres architectures avec l'option -b qui ne construit que le paquet binaire...

  • envoyer par dput le ou les ...changes obtenus

Pour les curieux : comment ça marche à l'intérieur

reprepro-apt-auf-org.png

Le système est basé sur reprepro (version etch). C'est ce logiciel qui gère le dépot : on lui dit quel paquet ajouter à quel composant de quelle distribution, et il gère le pool, les fichiers Release, Packages, Sources, etc. A côté, un serveur apache2 propose le dépôt en HTTP.

Le principe : il y a un utilisateur virtuel "reprepro" sur le système, qui gère le dépôts. C'est cet utilisateur qui va lancer le logiciel "reprepro" avec les bons arguments. Il est le seul à avoir accès en écriture sur le dépôt.

  • /srv/www/apt.auf.org/pool et .../dists : le dépôt lui-même

  • ~reprepro/conf/ : configuration de reprepro, voir man reprepro pour explication :

  • ~reprepro/db/ : contient les bases de données internes de reprepro

Un script shell appelé reprepro-incoming lance le logiciel reprepro en lui disant d'aller chercher les paquets de tel composant pour telle distribution dans tel répertoire. La liste de ces paramètres est dans ~reprepro/incomings : 

  • # Fichier ~reprepro/incomings

# Format d'une ligne :
# distrib composant repertoire email-pour-rapport

squeeze-test           auf     /home/ftp/test/squeeze              root+aptauf_À_auf.org
squeeze-experimental   auf     /home/ftp/experimental/squeeze      root+aptauf_À_auf.org

Le script reprepro-incoming gère l'envoie de rapport par mail (dernier paramètre de chaque ligne d'appel). Il est lancé par cron toutes les 5 minutes.

Pour info, le script dans sa version du 11 février 15h TU : reprepro-incoming

Il reste à faire

  • regarder le backport de reprepro et notamment son "processincoming"

  • mettre tout le code sur git.auf.org

DépôtAPT/EnvoyerSesPaquets (dernière édition le 2011-03-11 03:14:48 par JeanChristopheAndré)