Il y a trois saveurs d'OpenBSD :

• -release: La version d'OpenBSD qui sort tous les six 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.

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 à un 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 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).
• En option, créer une release et construire X.

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

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.

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. 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 mis à jour depuis votre dépôt local. Vous pouvez aussi maintenir un dépôt CVS local en utilisant le programme CVSync ou rsync, disponibles en tant que paquets. La configuration d'un miroir du dépôt est également expliquée sur la page CVS anonyme.

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

# usermod -G wsrc exampleuser

Les changements prennent effet 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

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

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

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.

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

• mk.conf(5)
• src/Makefile
• /usr/src/share/mk/bsd.README
• config(8)
• options(4)

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.

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.

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

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

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 :

• Échec de démarrage depuis les binaires appropriés.
• Récupérer le code source depuis la mauvaise branche de l'arborescence.
• Oublier de lire la page suivre -current avant de construire -current.
• Sauter l'étape de redémarrage après la construction et l'installation du nouveau noyau.

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 -delete
$ make cleandir
$ rm -rf /usr/obj/*
$ make obj

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.

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.

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

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

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.

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

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.

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

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

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

Contribut(rice|eur)s :