Revenir au contenu principal.

Suivre NetBSD-current

Foire aux Questions

Foire aux Questions

Pourquoi suivre NetBSD-current (top)

Les développeurs NetBSD ont rendus les sources de développement disponibles au public pour plusieurs raisons. L'une d'elles était d'aider les développeurs à concevoir un système plus stable, plus accessible.

L'idée était de permettre aux personnes de s'impliquer davantage au développement de NetBSD. En distribuant le code source en phase de développement, n'importe qui pouvait avoir accès aux évolutions du système de manière simple et être séduit par les nouvelles fonctionnalités, voire pourquoi pas d'être impliquer au projet.

NetBSD-current permet également de rendre tous changements de la part des utilisateurs faciles à intégrer. Si des utilisateurs effectuent des changements à l'encontre du développement actuel, alors quasiment aucune tâche d'intégration ne sera nécessaire pour obtenir ces activités dans l'arborescence principale.

NetBSD-current permet également de tester les programmes en cours de développement grandeur nature. Les utilisateurs de NetBSD-current sont d'ailleurs encouragés à envoyer des rapports de bogue au sujet des sources actuelles, afin de nous aider à trouver et corriger des bogues. C'est justement parce que les gens font des tests après le développement d'un programme que les bogues peuvent être trouvés et éliminés.

Ce que vous devez retenir (top)

  • Les personnes utilisant NetBSD-current sont fortement encouragés à souscrire à la liste de diffusion current-users. La liste de diffusion source-changes peut également être un plus.

  • Lors de la mise à jour vers une version plus récente de -current, vous devez toujours installer et démarrer un nouveau noyau avant l'installation de toutes nouvelles bibliothèques (*). Avant toute autre chose, la meilleure approche consiste à essayer le nouveau noyau. Si vous rencontrez des problèmes, consultez la FAQ du noyau.

  • Lors de la compilation d'un noyau -current, n'omettez pas l'option COMPAT_<lastrelease> (par exemple, COMPAT_16). Comme current diverge de la dernière version stable, le code de compatibilité sera ajouté, mais il sera activé uniquement si l'option est présente. Au minimum, vous aurez besoin de ce code de compatibilité au moment de l'exécution du nouveau noyau jusqu'à la fin de la construction via build.sh.

*: A moins que vous soyez certain qu'aucun nouveaux appels système aient été ajouté, il est important de le faire : c'est plus sûr.

Mettre à jour un système à partir d'un cliché instantané current (top)

Veuillez consulter src/UPDATING sur le comportement autour de certains changements spécifiques.

Pour commencer rapidement à utiliser current, utilisez un cliché instantané généré par l'équipe de publication. Le status current de chaque plateforme peut être vu à partir de NetBSD Autobuild ou bien à partir des versions trouvées dans http://nyftp.NetBSD.org/pub/NetBSD-daily/HEAD/, triées par date et par plateforme.

  1. Allez dans le répertoire binary/sets désiré et récupérez les fichiers mget *.tgz dans votre répertoire local (par exemple, $HOME/current); si vous êtes limités par l'espace disque et/ou par le temps, seul kern-GENERIC, etc, base, et comp (si vous souhaitez un compilateur) sont essentiels.
  2. Extrayez le noyau désiré (généralement GENERIC) et copiez le dans le répertoire racine /. 
        $ su
    # cd /root
    # tar -zxpf ~/kern-GENERIC.tgz
    # ln -fh /netbsd /netbsd.old
    # cp netbsd /netbsd

    Avertissement: n'extrayez pas tous les outils d'installation avant de redémarrer votre machine avec le nouveau noyau. Les nouveaux programmes peuvent utiliser de nouveaux appels systèmes qu'un noyau ancien ne supportera pas.

  3. Vérifiez si d'autres fichiers peuvent également être demandé par un nouveau noyau. De nouveau, src/UPDATING peut mentionner des possibles défauts au niveau des changements journaliers.

    Les éléments suivants sont des fichiers typiques devant être éventuellement mis à jour :

    1. le chargeur de démarrage

      Généralement le chargeur de démarrage d'une machine spécifique passe plusieurs paramètres au noyau chargé. Si certains nouveaux paramètres ont été ajoutés ou certains APIs existantes entre le chargeur de démarrage et le noyau ont changés, il faudra également installer les nouveaux fichiers du chargeur de démarrage pour un nouveau noyau pour gérer les nouvelles fonctionnalités. Les moyens pour mettre à jour les fichiers du chargeur sont dépendants de la machine alors vérifiez les pages du manuel boot(8) et installboot(8) pour plus de détails.

      Sur i386 et amd64, si vous utilisez FFSv1 pour le système de fichiers de la racine sur wd0a (par exemple, le premier disque ATA), les commandes typiques pour mettre à jour les chargeurs de démarrage sont : 

          # tar -C /tmp -zxf ~/base.tgz ./usr/mdec
    # cp /tmp/usr/mdec/boot /
    # installboot -v /dev/rwd0a /tmp/usr/mdec/bootxx_ffsv1

      Si vous utilisez FFSv2 pour le système de fichiers de la racine, utilisez plutôt les commandes suivantes: 

          # tar -C /tmp -zxf ~/base.tgz ./usr/mdec
    # cp /tmp/usr/mdec/boot /
    # installboot -v /dev/rwd0a /tmp/usr/mdec/bootxx_ffsv2

      Remarquez que /usr/mdec/bootxx_ffsv1 et /usr/mdec/bootxx_ffsv2 sont des chargeurs de démarrage primaires qui sont dépendants du système de fichiers. /usr/mdec/boot est un chargeur secondaire et il est indépendant du système de fichiers.

      Si vous ne vous souvenez plus du type de partition de la racine (FFSv1 ou FFSv2), vous pouvez toujours utiliser la commande dumpfs(8) : 

          # dumpfs /dev/rwd0a | head -3
    file system: /dev/rwd0a
    format  FFSv2
    endian  little-endian
    #
    2. les modules noyau

      Un nouveau framework de “modules noyau” a été introduit après la sortie de la branche netbsd-5 et le noyau GENERIC sur le port i386 a basculé vers l'utilisation de modules noyau depuis novembre 2008. Les modules noyau seront chargés dynamiquement et à la demande par le noyau afin de soutenir différentes options de ce dernier (y compris les systèmes de fichiers), plutôt que de tout lier aux fichiers objets (et peut-être des fichiers objets inutilisé) dans le binaire noyau. Cela signifie que si vous essayez de démarrer un noyau GENERIC, vous devrez également préparer de nouveaux modules noyau pour ce noyau.

      Pour préparer les modules du noyau, vous pouvez simplement utiliser un nouveau jeu de modules qui a été préparé depuis septembre 2009. 

          # cd /
    # tar -zxpf ~/modules.tgz

      Remarquez que le port i386 fournit également un exécutable du noyau MONOLITHIC dans l'outil d'installation kern-MONOLITHIC.tgz depuis octobre 2009. Le noyau MONOLITHIC inclut toutes les options nécessaires en lui, que ce soit le noyau 5.0 aussi bien que les noyaux antérieurs.

      C'est également une bonne idée de mettre un ancien noyau MONOLITHIC dans le répertoire racine / en cas d'urgence ou de récupération parce que si les nouveaux modules ont certains problèmes, il ne sera pas facile d'indiquer un chemin alternatif des anciens modules au noyau modularisé (et vous ne pouvez pas renommer les répertoires sans un noyau fonctionnel).

      Avertissement: l'infrastructure des modules noyau mentionnée ici est encore en discussion sur la branche -current. Il se pourrait qu'il y ait du changement sur certain point avant l'arrivé de NetBSD 6.0 et dans ce cas, la description de cette section sera obsolète. De nouveau, consultez src/UPDATING et le liste de diffusion current-users pour obtenir des informations à jour.

      En mai 2009, il a été proposé une possible alternative de la structure des modules noyau dont la conclusion n'a pas encore été faite. Celle-ci devrait l'être car la plupart des utilisateurs de -current construisent leurs propres noyaux personnalisés à partir des sources, bien que les modules noyaux peuvent être plutôt utiles pour les utilisateurs qui ne veulent pas à la fois compiler leurs propres noyaux à partir des sources et juste essayez d'utiliser de nouvelles fonctionnalités optimales. Bien sûr, tout retour sur les modules noyau est apprécié.

  4. Redémarrez la machine avec le nouveau noyau : 
        # shutdown -r now
  5. Assurez-vous que le nouveau noyau démarre et que tout fonctionne correctement. Si votre nouveau noyau contient des problèmes, vous pourrez le récupérer en chargeant l'ancien noyau renommé. Si vous utilisez un noyau modularisé GENERIC mentionné ci-dessus, vous devrez également restaurer les anciens modules noyau.
  6. Extrayez l'outil d'installation de base et tous les autres outils désirés sauf etc: 
        $ su
    # cd /
    # tar -zxpf ~/base.tgz
    # tar -zxpf ~/comp.tgz
    # ...
    N'oubliez pas de spécifier l'option "p" (préservation des permissions) avec la commande tar(1) car autrement les commandes setuid'és (comme su(1)) ne fonctionneront pas.

    Avertissement: extraire etc.tgz sur un système installé écrasera vos paramètres locaux.

  7. Mettez à jour /etc comme à la dernière étape: postinstall(8) vérifiera en premier et corrigera la plupart des choses qui peuvent être automatisé, et etcupdate(8) dans un second temps vous demandera ce qu'il faudra incorporer : 
        # /usr/sbin/postinstall -s ~/etc.tgz check
    # /usr/sbin/postinstall -s ~/etc.tgz fix
    # /usr/sbin/etcupdate -s ~/etc.tgz
    # shutdown -r now
    Si vous avec les outils d'installation X installés (xbase, ...), vous pouvez répéter l'étape concernant postinstall et etcupdate avec xetc.tgz comme argument avant de redémarrer.

A ce stade, vous êtes relativement prêt à construire votre propre source current.

Télécharger les sources en current (top)

Voir la section Obtenir les sources dans le Guide NetBSD.

Construction d'une version à partir du code source (top)

Voir la section Crosscompilation sous NetBSD dans le Guide NetBSD.

Mettre à jour un système déjà existant à partir du code source (top)

Voir la section Mettre à jour un système déjà existant à partir du code source dans le Guide NetBSD.

Mettre à jour les fichiers de configuration et de démarrage (top)

Voir la section Plus de détails sur la mise à jour des fichiers de configuration et de démarrage dans le Guide NetBSD.

Que faire si j'obtiens une erreur ? (top)

Si vous essayez de construire -current, soit par un cliché instantané ou par une version journalière, et que cela ne fonctionne pas, gardez votre calme. Essayez ces étapes :

  1. Lisez le fichier src/UPDATING à partir de la version que vous êtes en train de construire.
  2. Lisez l'archive current-users pour plus de conseils.
  3. Remettez à jour. Vous pouvez avoir pris le dépot en plein milieu d'une propagation de plusieurs fichiers liés, ou le problème pourrait avoir été déjà corrigé.
  4. Si après moults recherches, le problème est toujours présent, envoyez un email à current-users en expliquant le problème. Mettez-y la date, l'heure et la méthode que vous avez utiliser pour obtenir vos sources -current, aussi bien que tout changement locaux effectué. Ensuite mettez dans un court script qui inclus les messages d'erreurs que vous obtenez. Quelqu'un corrigera probablement le problème.

Suivre NetBSD-current avec anoncvs (top)

Voir la section Récupérer par CVS dans le Guide NetBSD.

Pour reprendre le code source à partir d'une certaine date
$ cvs checkout -D 20020501-UTC src
Pour reprendre le code source à partir d'une certaine branche
$ cvs checkout -rnetbsd-5-0 src
Voir src/doc/BRANCHES pour une description des branches dans le dépôt CVS.
Conseils utiles
  • N'utilisez pas le flag cvs '-z'. Le flux de donnée sera trop grand, ce qui amenera à la corruption de donnée sur la machine cliente, ou bien causera un freeze total. La charge additionnelle sera également lourde sur le serveur cvs.
  • Si vous souhaitez récupérer une certaine branche de l'arborescence, vous devrez pendre des précautions sur l'écrasement des répertoires déjà existants en créant un nouveau répertoire pour cette branche : 
    $ cd /parent/dir/to/checkout/into
$ mkdir NewName-temp
$ cd NewName-temp
$ cvs checkout ... src
$ mv src ../NewName
$ cd ..
$ rmdir NewName-temp
  • Vous aurez besoin d'utiliser objdirs dans l'ordre pour que cvs update fonctionne correctement. Si vous obtenez des erreurs de cvs du type : 
       cvs [update aborted]: could not chdir to gnu/usr.bin/gdb/gdb: Not a directory
    vous devrez faire un make cleandir et ré-essayer. Assurez vous de faire un make obj après le cvs update.

  • Vous pouvez émettre les commandes spécifiées dans un fichier .cvsrc qui doit être situé dans le répertoire home, et il sera automatiquement utilisé. Un exemple d'un fichier .cvsrc : 

     update -dP
   checkout -P
   diff -u

Importer et incorporer le code source. (top)

Le sources sont importées de la manière suivante :

$ cvs -d /misc/cvsrep import -I ! -I CVS netbsd netbsd current-date

date est remplacé par la date SUP du suivi proposé. Les options -I ! -I CVS assure qu'aucun fichier dans l'arborescence des sources ne soit ignoré sauf les répertoires 'CVS'. Ceci est dû à certains fichiers sources NetBSD qui ont des extensions qui sont normalement ignorées par CVS. Si il y a des conflits avec les correctifs locaux, la commande import les rapportera et informera d'une commande pour mêler les conflits : 

$ cvs checkout -jnetbsd:yesterday -jnetbsd netbsd

Cette commande merge fusionne correctement les sources NetBSD importées mais ne gérera pas la suppression des fichiers localement qui ont déjà été enlevés par le processus SUP. Pour arriver à cela, la commande merge devrait être : 

$ cvs update -jprevious import tag -j current-date

previous import tag devrait être remplacé avec le nom de l'étiquette utilisée pour le précédent import cvs. date devrait être remplacé avec la date actuelle pour livrer la même étiquette utilisée au niveau de l'importation de current qui vient juste d'être fusionné.

Les conflits rapportés par la commande import sont des conflits potentiels. Généralement, ils sont incorporés par la commande update mais dans certains cas un réel conflit se produit. Dans ces cas, une fusion manuelle des lignes en conflit devrait être demandés. Un réel conflit sera rapporté dans la sortie du cvs update avec le code C suivi du nom du fichier.

La fusion des conflits manuellement n'est pas un processus simple mais est néanmoins résolvable en enlevant les modifications locales et en récupérant le fichier original du code source NetBSD.

Les marques de conflits CVS sont les suivantes : 

<<<<<<
  code from local file
======
  code from imported file
>>>>>> local revision number of newly imported revision

Si l'imporation ne rapporte aucun conflit, la copie de l'arborescence devrait être mise à jour de la même manière que dans les cas à conflits.

Toutes les commandes 'update' et 'checkout' devraient être faites dans le répertoire où les sources ont été récupérés. Sur mon système, il s'agit de /usr/src/netbsd.

Si c'est la première importation alors il n'y aura pas de sources à récupérer. Supposons que vous souhaitez créer l'arborescence dans '/usr/src/netbsd'. Les commandes suivantes vérifieront que les sources et qu'aucune étape d'incorporation n'aient été demandés. 

$ cd /usr/src
$ cvs -d /misc/cvsrep checkout netbsd

Etiquetter une construction réussie (top)

Si la construction est complètement réussis et produit un jeu fonctionnel d'exécutables, il peut être utile d'étiquetter les sources fonctionnelles. Cela permet de revenir à une arborescence de construction qui fonctionne avec une simple commande CVS dans le cas où l'arbre current devient inconstructible. Cette opération peut être exécutée en lançant la commande suivante : 

$ cvs tag successful-build-build date
Notes
  • Si la version CVS personnalisée de NetBSD, qui reconnaît les marqueurs $NetBSD$ dans les fichiers, n'est pas utilisée, le nombre de révision NetBSD du fichier est disponible pour un usage de référence lorsque que des problèmes de construction se produisent.
  • La séquence sup/import/merge décrite ci-dessus est facilement automatisable. Le script Perl suivant automatise ces processus. 
    #!/usr/pkg/bin/perl
#
# Script to SUP NetBSD-current, import it into CVS and merge it with
# any local changes.
#
# NOTES:
# This script does no error handling so is not really suitable for 
# non-interactive use.
#
# This script has only been test with cvs-1.10.1 and cvs-1.9.18.
#
$SRCROOT="/usr/src/netbsd";
$IMPORTROOT="/misc/import";
$CVSROOT="/misc/cvsrep";
#run the sup into a perl stream
system "/usr/sbin/sup -zsv" ; # This may need to change for none
                              # current systems

# now import the new files into CVS 

chdir $IMPORTROOT or die "Could not cd to $IMPORTROOT\n";

($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime;
$date = localtime;
$shortdate = sprintf "%02d%02d%04d",$mday,$mon+1,1900+$year;
system "/usr/local/bin/cvs -d$CVSROOT import -I ! -m\"SUP Import $date\" netbsd netbsd current-$shortdate ";

# make the working directory the local NetBSD Tree
chdir $SRCROOT or die "Could not change to $SRCROOT directory\n";

# Now do the import.
$lastimport = `cat /usr/src/netbsd/.tag`; # `s are backquotes
$lastimport =~ s/\n//; # strip off any trailing newline in the string
system "/usr/local/bin/cvs update -j $lastimport  -j
current-$shortdate ";
# Now write the current file into tag save file
open TAG,">$SRCROOT/.tag" or die "Could not open new tag file";
 print TAG "current-$shortdate";
close TAG;

    Ce script a été écrit en Perl car il est l'outil de script dont l'auteur a le plus d'expérience. Cela devrait être assez facile de le réécrire en un script shell pour exécuter la même tâche.

  • Les techniques pour suivre une current avec CVS ont été discutés plusieurs fois sur la liste de diffusion current-users NetBSD. Pour les techniques alternatives, essayez de rechercher dans les listes de diffusion NetBSD.

Si vous avez des commentaires ou des suggestions, merci de les envoyer à Mike Pumford (qui maintient cette entrée) ou .

Obtenir le dépôt entier (top)

Toutes les procédures décrites ci-dessus vous permette de garder vos propres changements dans votre dépôt, ce qui a ses avantages si vous développez votre propre logiciel basé sur NetBSD. Si vous ne voulez pas maintenir votre propre dépôt CVS, mais que vous voulez juste faire un miroir du dépôt CVS de NetBSD, il y a trois possiblités pour arriver à ceci.

Chacune des méthodes décrites brievement ci-dessous vous permetteront d'avoir une copie du dépôt CVS NetBSD (par exemple, les RCS, fichiers v, pas les fichiers récupérés). Vous pouvez ensuite installer votre propre serveur anoncvs ou récupérer en local sur un disque dur. Il est également utile pour un accès rapide à l'historique des informations stockées dans le dépôt.

Les méthodes pour récupérer un dépôt en entier sont :

sup

Si vous utiliser sup pour faire un miroir des autres parties des sources de NetBSD, vous voudrez également ajouter les lignes suivantes à votre fichier de configuration sup : 

anoncvs release=all  host=sup.NetBSD.org hostbase=/ftp/pub \
base=/usr prefix=/usr backup use-rel-suffix compress

Après cela, exécutez "sup /path/to/supfile anoncvs" pour récupérer les fichiers.

Quelques fichiers exemples sup sont disponibles dans /usr/share/examples/supfiles. Vérifiez également notre liste de serveurs miroirs SUP afin de trouver le serveur le plus proche de l'endroit où vous êtes.

rsync

Notez que rsync demande une charge importante à notre serveur rsync et que le nombre d'utilisateurs de rsync est restreint. Si vous voulez malgré cela essayer rsync, la commande pour récupérer le dépôt est celle-ci : 

rsync -v -a rsync://anoncvs.NetBSD.org/cvsroot/src .

Veuillez consulter notre liste de serveurs miroirs rsync.

cvsup

CVSup n'est pas actuellement disponible pour toutes les architectures NetBSD, puisque le compilateur M3 n'a pas été porté. Sur i386, vous pouvez faire un miroir du dépôt depuis cvsup.de.NetBSD.org avec le paquet devel/cvsup et le fichier de configuration suivant : 

*default host=cvsup.de.NetBSD.org
*default base=/usr
*default prefix=/local/NetBSD-cvs
*default release=cvs
*default delete use-rel-suffix
*default compress

netbsd

Veuillez consulter notre liste de serveurs miroirs CVSup.