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

Construction d'un paquet scratch
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.rpm

Toutefois 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

Paramètre use_common
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

Différence entre les SCM

• 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

Import
Il est impératif d'importer les paquets RPM pour chaque architecture gérée. De plus le paquet RPM source devra être importer en premier. Il y a donc au minimum import de deux paquets RPM.

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

<package>Koji</package> n'accepte pas l'import de paquet RPM binaire sans paquet RPM source correspondant.

Afin de maintenir une certaine homogénéité dans le dépôt, il faudra importer les paquets RPM binaires pour les deux architectures.

Import du paquet RPM source

koji add-pkg centos-5 foo.src.rpm

Import du paquet RPM binaire

koji add-pkg centos-5 foo.rpm

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>.

1. 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> )
2. 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 passe

    ssh git@didier.b2pweb.com

3. 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

TODO

Mise à jour d'un paquet

TODO

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

Utilisation du repository

Il suffit de renseigné <package>yum</package> pour qu'il pointe sur le repository

http://didier.b2pweb.com/kojifiles/repos/centos-5-build/latest/$arch

Skins

Modification à partir du thème osg