OBSD4* : wiki

Version de traduction basée sur la 6.4 officielle (29/10/2018)


FAQ - Construire le système depuis les sources

Saveurs d'OpenBSD

Il y a trois saveurs d'OpenBSD :

  • -release: La version d'OpenBSD qui sort tous les 6 mois.
  • -current: La branche de développement. Tous les six mois, -current est marquée et devient le nouvelle -release.
  • -stable: La branche -release plus les correctifs trouvés sur la page errata. Quand des correctifs très importants sont créés pour la version -current, ils sont portés dans la branche -stable.

Seulement les deux plus récentes versions d'OpenBSD reçoivent les correctifs de sécurité et fiabilité pour le système de base. Les détails sur comment appliquer les correctifs de sécurité peuvent être trouvés dans le chapitre Gestion du Système.

Les nouveaux utilisateurs devraient faire fonctionner la version -stable ou -release. Ceci étant dit, beaucoup de personnes font fonctionner -current sur des systèmes en production, ce qui aide à identifier les bogues et tester les nouvelles fonctionnalités.

Développement d’instantanés

Les snapshots - instantanés en français - de la branche -current sont rendus disponibles entre les versions formelles d'OpenBSD. Ce sont des constructions de tout le code qui est dans l'arborescence à moment donné.

Un instantané récent est habituellement tout ce dont vous avez besoin pour faire fonctionner -current. Si vous désirez le construire depuis les sources, démarrer depuis le dernier instantané est requis. Vérifiez la page -current et utilisez les instantanés pour tout changement de configuration ou les étapes supplémentaires nécessaires pour construire -current depuis les sources.

Il est possible que vous découvriez des bogues dans les instantanés. C'est une des raisons pour lesquels ils sont construits et distribués. Si vous trouvez un bogue, veuillez le rapporter.

Construire OpenBSD depuis les sources

Construire OpenBSD depuis les sources nécessite un certain nombre d'étapes :

  • Mettre-à-jour vers les binaires les plus récents.
  • Récupérer le code source.
  • Construire un nouveau noyau et l'espace utilisateur, tels qu’expliqués dans les étapes 2 et 3 de release(8).

La FAQ a pour intention de vous aider avec la préparation nécessaire. La référence principale est release(8).

Mettre à jour vers les binaires les plus récents

N'essayez pas d'aller d'une version à l'autre en compilant depuis les sources.

Assurez vous d'avoir les binaires les plus récents installés. C'est soit la version OpenBSD x.y-release si vous voulez construire x.y-stable d’OpenBSD, soit le dernier instantané si vous souhaitez construire -current.

Récupérer le code source

OpenBSD utilise le système de contrôle de version CVS pour gérer ses sources. Le programme cvs(1) est utilisé pour obtenir une copie des sources désirées vers votre machine locale pour la compilation. Vous pouvez aussi maintenir un dépôt CVS local en utilisant le programme CVSync ou rsync, disponibles en tant que paquets. Une introduction à cvs(1) et des instructions détaillées pour récupérer l'arborescence des sources sont sur la page CVS anonyme. En premier, vous devez récupérer l'arborescence des sources avec la commande cvs checkout. Après cela, vous maintiendrez l'arborescence avec la commande cvs update pour obtenir les fichiers mises-à-jour depuis votre dépôt local.

Éviter les privilèges administrateur

Évitez d'utiliser cvs(1) en tant qu'administrateur. Le répertoire /usr/src (où sont typiquement les sources) est permis en écriture pour le groupe wsrc par défaut ; ajoutez donc les utilisateurs qui ont besoin d'utiliser cvs(1) à ce groupe.

  # user mod -G wsrc exampleuser

Les changements prennent effets pour l'utilisateur d'exemple au prochain login.

Si vous voulez récupérer xenocara ou les ports pour cet utilisateur, vous devez créer les répertoires et définir les permissions manuellement.

  # cd /usr
  # mkdir -p   xenocara ports
  # chgrp wsrc xenocara ports
  # chmod 775  xenocara ports
Récupérer l'arborescence -stable

Pour récupérer l'arborescence -stable src, spécifiez la branche que vous voulez avec le drapeau -r :

  $ cd /usr
  $ cvs -qd anoncvs@anoncvs.example.org:/cvs checkout -rOPENBSD_6_4 -P src

Une fois que vous avez récupéré l'arborescence, vous pouvez mettre à jour avec :

  $ cd /usr/src
  $ cvs -q up -Pd -rOPENBSD_6_4

Remplacez src par xenocara ou ports, au besoin. Comme toutes les parties d'OpenBSD doivent être gardés synchrones, tous les arborescences que vous utilisez devront être vérifiés et mis à jour en même temps.

Récupérer l'arborescence -current

Pour récupérer les sources de l'arborescence -current, vous pouvez faire ce qui suit :

  $ cd /usr
  $ cvs -qd anoncvs@anoncvs.example.org:/cvs checkout -P src

Mettez-à-jour l'arborescence avec :

  $ cd /usr/src
  $ cvs -q up -Pd -A

Remplacez src par le nom du module que vous voulez, tel que xenocara ou ports.

Construire OpenBSD

À ce point vous êtes prêt à construire OpenBSD depuis les sources.

Si vous construisez -current, revoyez les changements et les instructions spécifiques de construction listés sur la page current.html.

Suivez les instructions détaillées des étapes 2 et 3 de release(8).

D’autres lectures sur le processus de construction

Faire une release

Une release est un jeu complet de fichiers qui peut être utilisé pour installer ou mettre à niveau OpenBSD sur un autre système. Un exemple d'utilisation serait de construire -stable sur une machine puissante, puis de faire une version à installer sur toutes vos autres machines. Si vous avez un seul ordinateur faisant fonctionner OpenBSD, vous n'avez pas réellement de raisons de faire une release, le processus de construction ci-dessus fera tout ce dont vous avez besoin.

Les instructions pour faire une release sont dans release(8). Le processus utilise les binaires créés dans le répertoire /usr/obj du processus de construction ci-dessus.

Note : si vous souhaitez distribuer le résultat de votre jeu de fichiers par HTTP(s) pour l'utiliser à travers les scripts d'installation ou de mise-à-niveau, vous aurez besoin d'ajouter un fichier index.txt qui contient la liste de tous les fichiers de votre release nouvellement créée.

  # ls -nT > index.txt

Si vous voulez ajouter la signature cryptographique des jeux de fichiers que vous avez créés, la page de manuel signify(1) détaille comment faire.

Paramétrer votre système

Créer une release requiert la permission noperm sur la partition. Cela permet à l'infrastructure de construction d'utiliser l'utilisateur build non-privilégié pour la majeure partie du processus.

Créez un système de fichier sur /dest ayant l’option noperm de mount(8). La ligne correspondante de fstab(5) ressemble à celle-ci :

c73d2198f83ef845.m /dest ffs rw,nosuid,noperm 1 2

La racine du système de fichier doit appartenir à build avec des permissions à 700 :

# chown build /dest
# chmod 700   /dest

Créer les répertoires DESTDIR pour base et xenocara :

# mkdir /dest/{,x}base

Votre RELEASEDIR n’a pas besoin de se trouver sur un système de fichiers noperm. Assurez vous qu’il appartienne à build:wobj et qu’il ait au moins les permissions u=rwx.

Utilisez une partition mfs noperm

Il se peut que vous souhaitiez utiliser une partition mfs au lieu d’un disque physique. Ajoutez une ligne similaire à celle-ci dans votre /etc/fstab :

swap /dest mfs rw,nosuid,noperm,-P/var/dest,-s1.5G,noauto 0 0

Créer le prototype de répertoires DESTDIR :

# mkdir -p /var/dest/{,x}base
# chown -R build /var/dest
# chmod -R 700   /var/dest

Maintenant, vous pouvez monter /dest avant de créer une release :

# mount /dest

Construire X

À partir de la v7 de X.Org, X est passé à un système modulaire de construction, fractionnant l'arborescence des sources de X.Org en plus de trois cent paquets plus ou moins indépendants.

Pour simplifier la vie des utilisateurs d'OpenBSD, un meta paquet appelé Xenocara a été développé. Le système convertit X en un seul grand arborescence à construire par un seul processus. En prime, le processus de construction est bien plus similaire au processus de construction utilisé par le reste d'OpenBSD que les anciennes versions.

Les instructions officielles pour construire X existent dans le fichier xenocara/README et à l'étape 5 de release(8).

Problèmes communs durant la compilation

La plupart du temps, les problèmes dans le processus de construction sont causés par le fait de ne pas suivre attentivement les directives. Ce sont occasionnellement de réels problèmes avec la construction de la -current depuis les plus récents instantanés, mais les échecs lors de la construction de la -release ou -stable sont pour la plupart toujours des erreurs dues à l'utilisateur.

La plupart de problèmes sont habituellement l’un des suivants :

J'ai oublié de faire ''make obj'' avant de faire ''make build''

En faisant un make build avant de faire un make obj, vous vous retrouverez avec les fichiers objet éparpillés dans le repertoire usr/src. C'est une mauvaise chose. Si vous souhaitez éviter d'avoir à récupérer à nouveau l'arborescence des sources, vous pouvez essayer les commandes suivantes pour nettoyer les fichiers objet :

  $ cd /usr/src
  $ find . -type l -name obj | xargs rm
  $ make cleandir
  $ rm -rf /usr/obj/*
  $ make obj

La construction s'est arrêtée avec l'erreur "Signal 11"

Construire OpenBSD et d'autres programmes depuis les sources est une tâche qui demande de la puissance bien plus que d'autres, l'utilisation intensive du CPU, du disque dur et de la mémoire. Les erreurs “Signal 11” sont typiquement causées par des problèmes d'ordre matériel.

Trouvez le meilleur moyen de réparer ou remplacer de tels composants fautifs ; ces problèmes se répéteront à nouveau dans le futur, d'une manière ou d'une autre.

Pour plus d'informations à ce propos, lisez la FAQ Sig11.

Questions et astuces diverses

Ajouter votre utilisateur au groupe ''wobj''

Si vous avez l’intention de compiler des programmes individuels dans l’arborescence des sources – par exemple, pour faire du développement – vous devriez ajouter votre utilisateur au groupe wobj. Ceci vous permettra d’écrire dans /usr/obj.

Étiqueter des fichiers

Étant des éditeurs pour les développeurs, mg(1) et vi(1) ont un support intégré pour les fichiers ctags(1), ce qui vous permet de naviguer rapidement dans l’arborescence des sources.

Dans la plupart des répertoires sources de bibliothèques ou de programmes, vous devrez créer un fichier ./tags, en exécutant :

$ make tags

Quand vous construisez et installez libc, un fichier /var/db/libc.tags est aussi créé.

Par défaut, les étiquettes du noyau pour chaque architecture sont localisés dans /sys/arch/$(machine)/. Ces fichiers peuvent être créés par make tags depuis /sys/kern. Vous devriez faire fonctionner make links en tant qu’administrateur afin de placer un raccourci du fichier tags de votre architecture noyau dans chaque répertoire et dans /var/db/.

Comment puis-je sauter des parties durant la compilation de l'arborescence ?

Utilisez l'option SKIPDIR de mk.conf(5).

Puis-je cross-compiler ?

Les outils de cross-compilation sont dans le système, pour l'usage des développeurs afin de gérer une nouvelle plate-forme. Toutefois, ils ne sont pas maintenus pour un usage général.

Quand les développeurs ajoutent le support d'une nouvelle plate-forme, l'un des premiers gros tests est la compilation native. Construire le système depuis les sources peut imposer une charge considérable sur l'OS et la machine, et est très efficace pour tester le comportement du système en situation réelle. Pour cette raison, OpenBSD effectue tout le processus de construction sur la même plate-forme que celle pour laquelle la construction est destinée.

Noyaux personnalisés

Il y a trois manières de personnaliser un noyau :

  • Configuration du temps de démarrage en utilisant boot_config(8)
  • Modification permanente d'un noyau compilé en utilisant config(8)
  • Compilation d'un noyau personnalisé

Il est recommandé de lire en premier config(8).

Configuration du temps de démarrage

Parfois lors du démarrage de votre système, vous pouvez avoir des notes d'informations à-propos du fait que le noyau trouve un périphérique mais ayant une mauvaise adresse IRQ. Sans reconstruire le noyau, vous pouvez configurer de la phase de démarrage du noyau d'OpenBSD grâce à boot_config(8).

Toutefois, ceci corrigera votre problème une seule fois. Si vous redémarrez, vous devrez répéter la procédure. Ainsi, c'est seulement temporaire et vous devrez corriger le problème en utilisant config(8).

Pour démarrer dans le mode 'User Kernel Config', ou 'UKC' utilisez l'option -c au démarrage.

  boot> boot hd0a:/bsd -c

Faire cela aura pour résultat d'afficher une invite de commande UKC. Tapez help pour obtenir la liste des commandes disponibles.

Utilisez config(8) pour changer votre noyau

Les options -e et -u de config(8) sont extrêmement utiles et permettent de gagner du temps lors de la compilation de votre noyau. Le drapeau -e vous permet d'entrer dans l'invite 'UKC' ou 'User Kernel Config' lors du fonctionnement système. Ces changements seront effectifs lors de votre prochain redémarrage. Le drapeau -u permettra de voir si les changements sont apportés au noyau lors du démarrage, ce qui signifie que vous avez utilisé boot -c pour entrer dans l'invite 'UKC' durant le démarrage de votre système.

Pour des raisons de sécurité, utilisez l'option -o qui écrit les changements sur le fichier spécifié. Par exemple : config -e -o bsd.new /bsd écrit les changements sur le noyau bsd.new. Des exemples de modification du noyau sont donnés dans la page de manuel de config(8).

Construire un noyau personnalisé

Seuls les noyaux GENERIC et GENERIC.MP sont supportés par l'équipe d'OpenBSD. La configuration du noyau GENERIC est la combinaison d'options dans les fichiers /usr/src/sys/arch/$(machine)/conf/GENERIC et /usr/src/sys/conf/GENERIC. Rapporter un problème sur un noyau personnalisé aura quasiment toujours pour résultat que quelqu'un vous invite à reproduire le problème avec un noyau GENERIC.

Lisez en premier les pages de manuels config(8) et options(4). Les étapes suivantes sont une part de la compilation d'un noyau personnalisé :

  $ cd /usr/src/sys/arch/$(machine)/conf
  $ cp GENERIC CUSTOM
  $ vi CUSTOM    # make your changes
  $ config CUSTOM
  $ cd ../compile/CUSTOM
  $ make

Préparer un diff

Si vous avez fait des changements au code source que vous désirez partager avec des développeurs, suivez les conventions :

  • Basez votre diff sur une sortie -current.
  • Utilisez cvs diff -uNp pour générer le diff.
  • Envoyez votre diff à l’intérieur d’un courriel à la liste de mails @tech. Assurez que votre client mail ne détruisent pas les espaces blancs.

Si vous utilisez un dépôt git des arborescences sources d’OpenBSD, paramétrez :

$ git config diff.noprefix true

dans votre dépôt et générez votre diff tel que :

$ git diff --relative .

Cette page est la traduction officieuse de la page “Building the system from the source” de la FAQ officielle d'OpenBSD.
En cas de doute, merci de vous y référer !

Si vous voulez participer à l'effort de traduction, merci de lire ce topic.