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 didier-release

Construction d'un paquet scratch
Koji permet de construire des paquets sans qu'il soit nécessaire de les ajouter au repository: c'est le scratch build

La commande de construction devient donc

koji build --scratch centos-5 didier-release-1.0.0-1.fc17.src.rpm

Toutefois cette méthode n'est pas recommandé si on cherche à construire un paquet pour notre dépôt (hors test).

Construction d'un paquet

Depuis un paquet source

koji build centos-5 didier-release-1.0.0-1.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.tartarefr.eu/rpm
• dépôt SVN: http://didier.tartarefr.eu/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.tartarefr.eu:/rpm:no didier.tartarefr.eu:/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.tartarefr.eu/svn/rpm/trunk?didier-release#head

avec git

koji build centos-5 git://didier.tartarefr.eu/rpm?didier-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 (intel 32/64 bits, etc ...). De plus le paquet SRPM (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

Comme nous n'avons 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.

1. Import du paquet RPM source

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

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

Import sans SRPM

Exemple en intégrant les paquets pour une base Oracle.

1. Téléchargement des RPM depuis le site Oracle dans le dossier <path>/mnt/koji/externals</path>
   • oracle-instantclient12.1-basic-12.1.0.1.0-1.i386.rpm
   • oracle-instantclient12.1-devel-12.1.0.1.0-1.i386.rpm
   • oracle-instantclient12.1-sqlplus-12.1.0.1.0-1.i386.rpm
   • oracle-instantclient12.1-basic-12.1.0.1.0-1.x86_64.rpm
   • oracle-instantclient12.1-devel-12.1.0.1.0-1.x86_64.rpm
   • oracle-instantclient12.1-sqlplus-12.1.0.1.0-1.x86_64.rpm
2. Ajout des paquets au Koji

   • koji add-pkg centos-6 --owner didier oracle-instantclient12.1-basic

   • koji add-pkg centos-6 --owner didier oracle-instantclient12.1-devel

   • koji add-pkg centos-6 --owner didier oracle-instantclient12.1-sqlplus

3. Import des paquets dans le Koji

   koji import --create-build /mnt/koji/externals/oracle*.rpm

4. Comme les paquets sont juste importés, il est nécessaire de les taggués. On commmence par visualiser les paquets non taggués

   koji list-untagged

   Comme on s'y attend, trois paquets ne sont pas taggués
   • oracle-instantclient12.1-basic-12.1.0.1.0-1
   • oracle-instantclient12.1-devel-12.1.0.1.0-1
   • oracle-instantclient12.1-sqlplus-12.1.0.1.0-1
5. Tag des paquets précédemment importés en centos-6-build

   • koji tag-pkg centos-6 oracle-instantclient12.1-basic-12.1.0.1.0-1

   • koji tag-pkg centos-6 oracle-instantclient12.1-devel-12.1.0.1.0-1

   • koji tag-pkg centos-6 oracle-instantclient12.1-sqlplus-12.1.0.1.0-1

6. Régénération du dépôt

   koji regen-repo centos-6-build

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

3. Si le login est possible, on peut alors obtenir une copie du dépôt

   git clone git@didier.tartarefr.eu/rpm

Ajout d'un paquet

TODO

• étape #1
• étape #2

Mise à jour d'un paquet

TODO

• étape #1
• étape #2

Mise à jour du koji

La mise à jour du koji est sensible. En effet, les versions doivent correspondre entre le hub, le web, et même les builders.

Si les composants sont sur des machines virtuelles, il est préférable de sauvegarder la vm (a minima de faire un snapshot, ou bien un export) avant de lancer la mise à jour.

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 ceci

  koji add-pkg centos-6 --owner didier <MON PAQUET>

Utilisation du repository

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

http://koji.tartarefr.eu/kojifiles/repos/centos-6-build/latest/$basearch

Skins

Modification à partir du thème osg