Didier : Page créée avec « droite == Généralités == === Ajout d'un paquet au repository === Un admin du koji ajoute le paquet et le place sous la responsabil... »

2017-04-20T10:20:01Z

Page créée avec « sans_cadre|droite == Généralités == === Ajout d'un paquet au repository === Un admin du koji ajoute le paquet et le place sous la responsabil... »

Nouvelle page

[[Fichier:LogoKoji.svg|sans_cadre|droite]]

== 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
{{Admon/tip|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
<pre>koji build --scratch centos-5 didier-release-1.0.0-1.fc17.src.rpm</pre>
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''': ''<nowiki>http://didier.tartarefr.eu/svn/rpm</nowiki>''<br>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
{{Admon/warning|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.

<syntaxhighlight lang="make">
# Common Makefile
sources:
</syntaxhighlight>

Il ne reste plus qu'à lancer la construction depuis <app>koji</app>

avec SVN
koji build centos-5 <nowiki>svn+http://didier.tartarefr.eu/svn/rpm/trunk?didier-release#head</nowiki>

avec git
koji build centos-5 git://didier.tartarefr.eu/rpm?didier-release#5153396fc3bf204b74e745759eee33ed5dad0ffe
{{Admon/important|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 ==
[[Fichier:KojiwebScreenshot.png||800px]]

== Dépôt B2PWeb ==

=== Importer des paquets sources et binaires ===
{{Admon/warning|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.

# Import du paquet RPM source<pre>koji add-pkg centos-5 foo.src.rpm</pre>
# Import des paquets RPM binaires
#* Paquet 32 bits<pre>koji add-pkg centos-5 foo.i386.rpm</pre>
#* Paquet 64 bits<pre>koji add-pkg centos-5 foo.x86_64.rpm</pre>

==== Import sans SRPM ====

Exemple en intégrant les paquets pour une base Oracle.
# 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
# Ajout des paquets au {{package|Koji}}
#* <pre>koji add-pkg centos-6 --owner didier oracle-instantclient12.1-basic</pre>
#* <pre>koji add-pkg centos-6 --owner didier oracle-instantclient12.1-devel</pre>
#* <pre>koji add-pkg centos-6 --owner didier oracle-instantclient12.1-sqlplus</pre>
# Import des paquets dans le {{package|Koji}}<pre>koji import --create-build /mnt/koji/externals/oracle*.rpm</pre>
# Comme les paquets sont juste importés, il est nécessaire de les taggués. On commmence par visualiser les paquets non taggués<pre>koji list-untagged</pre>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
# Tag des paquets précédemment importés en centos-6-build
#* <pre>koji tag-pkg centos-6 oracle-instantclient12.1-basic-12.1.0.1.0-1</pre>
#* <pre>koji tag-pkg centos-6 oracle-instantclient12.1-devel-12.1.0.1.0-1</pre>
#* <pre>koji tag-pkg centos-6 oracle-instantclient12.1-sqlplus-12.1.0.1.0-1</pre>
# Régénération du dépôt<pre>koji regen-repo centos-6-build</pre>

=== 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<pre> ssh-keygen -t rsa</pre>
#* 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'''.<br>Il faut ensuite utiliser un agent ( ex: <app>pageant.exe</app> )
#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.<br>Afin de tester avant le checkout, on doit pouvoir se connecter au serveur sans mot de passe<pre> ssh git@didier.tartarefr.eu</pre>
# Si le login est possible, on peut alors obtenir une copie du dépôt<pre>git clone git@didier.tartarefr.eu/rpm</pre>

=== Ajout d'un paquet ===
{{Admon/todo}}
=== Mise à jour d'un paquet ===
{{Admon/todo}}

== 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.
<syntaxhighlight lang="sql">
begin;
delete from tag_packages where package_id = (select id from package where name = 'SOME-TYPO');
delete from package where name = 'SOME-TYPO';
commit;
</syntaxhighlight>

=== 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 <pre>make sources</pre>et la cible du Makefile est donc à jour.
* Le paquet n'est pas inclus au dépôt. Il faut l'inclure comme ceci<pre>koji add-pkg centos-6 --owner didier <MON PAQUET></pre>

== Utilisation du repository ==

Il suffit de renseigné <package>yum</package> pour qu'il pointe sur le repository
<nowiki>http://koji.tartarefr.eu/kojifiles/repos/centos-6-build/latest/$basearch</nowiki>

== Skins ==
Modification à partir du thème osg<ref>https://github.com/djw8605/osg-koji-theme</ref>

== Références ==
<references/>

Koji/Utilisation - Historique des versions

Didier : Page créée avec « droite == Généralités == === Ajout d'un paquet au repository === Un admin du koji ajoute le paquet et le place sous la responsabil... »

Didier : Page créée avec « droite == Généralités == === Ajout d'un paquet au repository === Un admin du koji ajoute le paquet et le place sous la responsabil... »