Koji/Utilisation
Généralités
Ajout d'un paquet au repository
Un admin du koji ajoute le paquet et le place sous la responsabilité d'un utilisateur Koji
koji add-pkg --owner didier centos-5 b2pweb
Koji permet de construire des paquets sans qu'il soit nécessaire de les ajouter au repository: scratch
La commande de construction devient donc
koji build --scratch centos-5 b2pweb-1.1.0-8.fc17.src.rpmToutefois cette méthode n'est pas recommandé si on cherche à construire un paquet pour notre repository.
Construction d'un paquet
Depuis un paquet source
koji build centos-5 b2pweb-1.1.0-8.fc17.src.rpm
Depuis un système de contrôle de version
Il faut tout d'abord autoriser le serveur et le dépôt sur tous les constructeurs koji ( kojid ).
Ici on déclare deux dépôts de sources:
- dépôt GIT: git://didier.b2pweb.com/rpm
- dépôt SVN: http://didier.b2pweb.com/svn/rpm
Celui-ci étant composé d'un arbre SVN standard, on déclare le répertoire trunk.
Extrait du fichier <path>/etc/kojid/kojid.conf</path>
; A space-separated list of hostname:repository[:use_common] tuples that kojid is authorized to checkout from (no quotes). ; Wildcards (as supported by fnmatch) are allowed. ; If use_common is specified and is one of "false", "no", "off", or "0" (without quotes), then kojid will not attempt to checkout ; a common/ dir when checking out sources from the source control system. Otherwise, it will attempt to checkout a common/ ; dir, and will raise an exception if it cannot. allowed_scms=didier.b2pweb.com:/rpm:no didier.b2pweb.com:/svn/rpm/trunk:yes
Il semble y avoir un bug avec le paramètre use_common et l'utilisation d'un dépôt git.
En effet quelque soit la valeur de ce paramètre, un dépôt common sera téléchargé.
Work-Around: Créer un dépôt common vide sur le serveur git.Le système doit fournir un Makefile qui contient une cible sources, dont la tâche est de fournir les sources via une commande de téléchargement. Si celles-ci sont incluses dans le SCM, la cible doit être vide.
# Common Makefile
sources:
Il ne reste plus qu'à lancer la construction depuis <app>koji</app>
avec SVN
koji build centos-5 svn+http://didier.b2pweb.com/svn/rpm/trunk?b2pweb-release#head
avec git
koji build centos-5 git://didier.b2pweb.com/rpm?b2pweb-release#5153396fc3bf204b74e745759eee33ed5dad0ffe
- Avec svn, le répertoire common sera téléchargé en plus de celui du paquet en cours
- Avec git c'est un dépôt common qui sera ajouté et l'intégralité du dépôt rpm sera téléchargé.
Interface Web
Dépôt B2PWeb
Importer des paquets sources et binaires
Il est impératif d'importer les paquets RPM pour chaque architecture gérée (intel 32/64 bits, etc ...). De plus le paquet RPM source devra être importer en premier. Il y a donc au minimum import de deux paquets RPM.
<package>Koji</package> n'accepte pas facilement l'import de paquet RPM binaire sans paquet RPM source correspondant.
Import standard
Sur le <package>Koji</package> B2PWeb, il n'y a que deux architectures définies :
- i386 ou i686 ( suivant la version de la distribution )
- x86_64
Afin de maintenir une certaine homogénéité dans le dépôt, il faudra importer les paquets RPM binaires pour les deux architectures.
Le SRPM est obligatoirement importé en premier.
- Import du paquet RPM source
koji add-pkg centos-5 foo.src.rpm
- Import des paquets RPM binaires
- Paquet 32 bits
koji add-pkg centos-5 foo.i386.rpm
- Paquet 64 bits
koji add-pkg centos-5 foo.x86_64.rpm
- Paquet 32 bits
Import sans SRPM
Ajout de paquets sources
Il faut tout d'abord avoir une copie de travail du dépôt des sources, accessible en lecture/écriture.
Pour cela il faut disposer d'un compte associé à une paire de clés ( publique et privée ) <app>ssh</app>.
- Génération de la paire de clé
- Sous GNU/Linux, il suffit de lancer la commande
ssh-keygen -t rsa
- Sous Windows il faut utiliser le programme <app>puttygen.exe</app> pour générer la paire de clé. La clé publique porte l'extension pub et la clé privé ppk.
Il faut ensuite utiliser un agent ( ex: <app>pageant.exe</app> )
- Sous GNU/Linux, il suffit de lancer la commande
- Puis il faut insérer le contenu de la clé publique ( à la suite des autres ) dans le fichier <path>/var/lib/git/.ssh/authorized_keys</path> sur le serveur.
Afin de tester avant le checkout, on doit pouvoir se connecter au serveur sans mot de passessh git@didier.b2pweb.com
- Si le login est possible, on peut alors obtenir une copie du dépôt
git clone git@didier.b2pweb.com/rpm
Ajout d'un paquet
Mise à jour d'un paquet
F.A.Q.
Comment supprimer un paquet sans aucun build associé
Pour un problème de nom incorrect de paquet ou pour d'autre raisons, il est nécessaire de modifier directement la base de données, car aucune commande existe.
Si aucun build n'est associé à ce paquet, il n'est référencé que dans deux tables:
- package
- tag_packages
On se place sur le serveur <package>Koji</package> et on se loggue avec l'utilisateur koji
# su - koji $ psql -U koji koji
Remplacer commit par rollback si quelque chose ne se passe pas bien, afin d'annuler la transaction.
begin;
delete from tag_packages where package_id = (select id from package where name = 'SOME-TYPO');
delete from package where name = 'SOME-TYPO';
commit;
BuildrootError: could not init mock buildroot, mock exited with status 30
Et dans le fichier <path>root.log</path> associé au build, on retrouve l'erreur: Package does not match intended download
Il faut lancer manuellement la régénération du dépôt
koji regen-repo centos-6-build
Construction du SRPM en erreur
- Il faut regarder que le répertoire ne contient pas de fichier nommé <path>sources</path>, car koji télécharge les sources en faisant
make sources
et la cible du Makefile est donc à jour. - Le paquet n'est pas inclus au dépôt. Il faut l'inclure comme expliquer précédemment #Ajout_d.27un_paquet_au_repository
Utilisation du repository
Il suffit de renseigné <package>yum</package> pour qu'il pointe sur le repository
http://koji.b2pweb.com/kojifiles/repos/centos-6-build/latest/$basearch
Skins
Modification à partir du thème osg[1]