Skip to main content.
Google custom search

NetBSD-currentの追跡

よくある質問

特定の問題

よくある質問

なぜ NetBSD-current を追跡するのか? (トップ)

NetBSDの開発者はそのときどきの開発中のソースをいくつかの理由から一般に 公開してきました。まず、NetBSD-currentを用意することで、より安定した、 利用しやすいシステムを作ることができます。

これにより、NetBSDの開発に熱中するのが容易になります。最新の開発中ソー スを配布することで、システムが今どうなっているのかが多くの人に明らかに なりますし、新機能が実装されればすぐにそれを試してみることができます。

また、利用者からの変更を統合するのも楽になります。もし利用者が最新の開 発中ソースに対して変更を加えたならば、その変更をマスターソースツリーに 取り込むための作業は事実上要らなくなります。

また、そうすることでソフトウェアが開発されてすぐに広い範囲のテストをす ることができます。NetBSD-currentの利用者は最新のソースについてのバグレポートを出すことが奨励されます。 これはバグを見つけたり修正したりする助けになります。ソフトウェアが書か れてからすぐに多くの人がそれをテストするために、より多くのバグを見つけ 出して退治することができます。

current スナップショットを使って、既存システムを更新する (トップ)

src/UPDATING を見て、個々の変更点に関する問題などを確認するのを忘れないようにしてください。

current を手っ取り早く使い始めるには、 リリースエンジニアリングサーバーで作られるスナップショットから始めます。 各プラットフォームの最新の構築状況は、 NetBSD Autobuild で見ることができ、実際に構築されたものは、日付およびプラットフォーム別に http://nyftp.NetBSD.org/pub/NetBSD-daily/HEAD/ 以下に置かれています。

  1. 必要な binary/sets ディレクトリーを探し、 ファイルを mget *.tgz して、ローカルの管理用ディレクトリー (たとえば $HOME/current ) に置きます。 ディスクスペースや時間が足りない場合は、 必要不可欠なのは kern-GENERIC, etc, base, comp (コンパイラーが必要な場合) だけです。
  2. 適切なカーネル (通常は GENERIC) を展開して / にコピーし、そのカーネルでマシンを再起動します。 
        $ su
    # cd /root
    # tar -zxpf ~/kern-GENERIC.tgz
    # ln -fh /netbsd /netbsd.old
    # cp netbsd /netbsd
    # shutdown -r now

    注意: 新しいカーネルでマシンを再起動するまでは、 ユーザーランドのバイナリーは一切展開してはいけません。 新しいバイナリーでは、新しいシステムコール (動作中の古いカーネルでは非対応) を使っているかもしれないからです。

  3. 新しいカーネルが、問題なく起動して動作することを確認します。 新しいカーネルに問題がある場合は、名前を変えた古いカーネルをロードして、 元に戻すことができます。
  4. base ほか一連の必要なもの (etc は除く) を展開し、 配置します。 
        $ su
    # cd /
    # tar -zxpf ~/base.tgz
    # tar -zxpf ~/comp.tgz
    # ...
    tar(1) コマンドの "p" オプション (許可属性の保持) を忘れずに指定してください。そうしないと、setuid されたコマンド (su(1) など) が動作しません。

    注意: 既存のシステムに対して etc.tgz を展開すると、独自におこなった設定が上書きされてしまいます。

  5. 最後に、 /etc を 更新 します。 postinstall(8) は、最初の検査をし、自動的に修正できることはほとんど修正してくれます。 その次にある etcupdate(8) は、どのようにマージするかたずねてきます。 
        # /usr/sbin/postinstall -s ~/etc.tgz check
    # /usr/sbin/postinstall -s ~/etc.tgz fix
    # /usr/sbin/etcupdate -s ~/etc.tgz
    # shutdown -r now
    X 配布セット (xbase など) をインストールしている場合は、 リブートする前に、postinstall と etcupdate の引数を xetc.tgz にして、 同様の手順を繰り返します。

以上で、 current に近い状態になり、 current のソースを構築する準備ができました。

current ソースのダウンロード (トップ)

伝統的に、 システムソースファイルは /usr/src に置くものですが、 これには一般的に root 権限が必要です。 現在の build.sh プロセスは、特権がまったくなくても実行可能です。 ただし、インストールについては root 権限が必要です。 このドキュメントの例示で /usr/src としているところはすべて、 ($HOME/current のような) 別の場所に置き換えてもかまいません。

  1. ソースツリーの置き場を選びます。 
        $ cd /usr
    $ su
  2. -current ソースを、最寄りの NetBSD ミラーサイト からダウンロードします。

    ダウンロードしたファイルは、ソースツリーのスナップショットになっています。 最新のファイルにするために、 anoncvs を使って以下のようにします。 

        $ cd /usr/src
    $ cvs -q -d $CVSROOT update -dP

    -d $CVSROOT は、あなたが選んだミラーサイトの CVS タグをつけるため、初めて update する場合のみ必要です。 -P フラグは必ず毎回指定するか、または .cvsrc ファイルに追加してください。

    もし、NetBSD のソースに対するローカルな変更を追跡したいならば、 ローカルな CVS ツリーをセットアップし、sup で行なわれた変更を import した方が良いでしょう。

  3. パーミッションを修正します。
    ソースツリーを、 (伝統的な) wsrc グループに属する root 以外のユーザーが保守できるようにしたい場合は、 (root になって) 以下のようにします。 
    $ chown -R user:wsrc /usr/src
$ chmod -R u=rwX,g=rwX,o=rX /usr/src

ソースからリリースの構築 (トップ)

src/BUILDING と src/UPDATING を見て、 最新の変更点を確認するのを忘れないようにしてください。

伝統的に、 システムオブジェクトファイルは /usr/obj に置くものですが、 これには一般的に root 権限が必要です。 そうするかわりに、オブジェクトファイルを別のファイルシステムに置くことで、 コンパイルにおける速度をかなり向上させることができます。 このドキュメントの例示で /usr/src としているところはすべて、 ($HOME/current のような) 別の場所に置き換えてもかまいません。

  1. オブジェクトツリーの置き場を選ぶ。 フルインストールに加えてリリース用の tarfile 一式を置けるだけの 十分な容量が必要です。 
        $ cd /usr/src
    $ su
    # mkdir ../tools
    # mkdir ../obj
  2. ソースツリーのルートに移動し、そこで実行する。 
        $ cd /usr/src
    $ ./build.sh -O ../obj -T ../tools -u -U release

この例において、 -u オプションは、構築開始前に make clean を実行する必要がないことを表しています。これは、以前構築したものの更新や、 新規の構築をおこなう場合に便利です。

-U オプションは、 root でないユーザーによる完全なビルドができるようにするものです。

完了すると、 インストールメディアとノートを含む、インストールに必要なものがすべて、 build.sh が指定 (表示されます) したディレクトリー 以下に出来上がります。

異なるアーキテクチャー用に クロスコンパイル をおこないたい場合は、 build.sh 実行時に '-m MACHINE -a ARCH' オプションをつけます。

より詳しくは、 './build.sh -h' を実行するとともに、 src/BUILDING を参照してください。

ソースを使って、既存システムを更新する (トップ)

src/UPDATING を見て、 最新の変更点を確認するのを忘れないようにしてください。

  1. ソースツリーのルートに移動する。 
    $ cd /usr/src
  2. toolchain を構築する。 
    $ ./build.sh -O ../obj -T ../tools -U -u tools
  3. 配布物を構築する。 
    $ ./build.sh  -O ../obj -T ../tools -U -u distribution
  4. カーネルを構築する。 
    $ ./build.sh  -O ../obj -T ../tools -U -u kernel=GENERIC
  5. カーネルをインストールする。 
        $ cd ../obj/sys/arch/<ARCH>/compile/GENERIC
    $ su
    # mv /netbsd /netbsd.old
    # cp netbsd /netbsd
  6. 新しいカーネルでリブートする。 
    # shutdown -r now
  7. 新しいユーザーランドをインストールする。 
        $ cd /usr/src
    $ su
    # ./build.sh -O ../obj -T ../tools -U install=/
  8. 古くなったファイルの修正のため、出力される説明に従う。たとえば以下のように。 
        # /usr/src/usr.sbin/postinstall/postinstall -s /usr/src -d // fix defaults mtree obsolete
  9. /etc の更新 
    # /usr/sbin/etcupdate -s /usr/src
  10. 動作中のサービス群がすべて新しいバイナリーを使うようにするため、リブートする。 (これはしなくてもよい) 
    # shutdown -r now

この例において、 -u オプションは更新プロセスを表し、 -U オプションは、 root でないユーザーによる完全なビルドができるようにする (その後に root でインストールする) ものです。

構築の順序 (tools, distribution, kernel) は、問題が起きた場合に、 ソース更新にかかる時間を常に最適化するために選ばたものです。 一貫性を保つため、 エラーが起きた場合や cvs update した場合は、 必ず上述の過程の最初からやり直してください。

より詳しくは、 src/UPDATING を参照してください。

覚えておくべきこと (トップ)

  • より新しいバージョンの-currentにアップグレードするときは、どれかの新しい ライブラリー(*)をインストールする前に必ず 新しいカーネルをコンパイルし、それで起動していなければなりません。 一般的にもっともよいのは他のどれよりも先に新しいカーネルを試し、何か問 題にぶつかったら カーネル FAQを参照することです。

    カーネルが動き出したらソースツリーの一番上の src/BUILDING ファイルを一読し、 build.sh スクリプトを使って新しいユーザーランドを 作るといいでしょう。

  • -current のカーネルをコンパイルする際には、常に COMPAT_<最新のリリース> オプション (例えば COMPAT_16) を含めるのを忘れないでください。current が最新の安定版リリース からかけはなれていくと互換性のコードが加えられますが、 このオプションが設定されている時だけ有効になります。 少なくとも、この互換性のためのコードは、新しいカーネルをブートして、 build.sh による構築が終了するまでは必要です。
  • NetBSD-currentを使っている人はcurrent-users メーリングリストに参加することを強く薦めます。source-changes を読むのも興味深いでしょう。

*: もし新たなシステムコールが追加されていないことが 確かでなければ、とりあえずこうしてください。それがより安全です。

Makefileのいろいろなターゲットは? (トップ)

'build.sh' スクリプト (ソースディレクトリーの最上層にあります) を使った新しい toolchain の使い方に関する詳しいドキュメンテーションについては、 './build.sh -h' を実行するとともに、 src/BUILDING を参照してください。

注意: toolchain が新しくなったことにより、 'make build' という使い方はもはや無用のものになりました。 使ってはいけません。

build.sh を使って初めてシステムの構築をする場合には、 この先でコンパイルに使うツール一式も構築されます。 その後に作られるものはすべて、すでに構築済のツールを再利用することになるので、 所要時間は初回より短くなります。

もちろん、 ./build.sh build が成功しない限り ./build.sh install=/ を実行してはいけません。 さもないと、動作しないシステムをもとに作業が進められてしまう可能性があります。

anoncvs の使用 (トップ)

ここでは暗号化されていない anoncvs 接続について説明します。 暗号化プロトコルを使いたい場合は、 後述の項目を参照してください。

  1. devel/scmcvs をインストールします。 もし NetBSD が 2000-09-04 以降の -current のソースから構築されていれば、 cvs はすでにインストールされています。
  2. 環境変数 CVSROOT を お好きな anoncvs サーバーを指すように設定します。
    • csh(1) または shells/tcsh ユーザーの方: 
      # setenv CVSROOT :pserver:anoncvs@anoncvs.NetBSD.org:/cvsroot
    • For sh(1), ksh(1), または shells/bash2 ユーザーの方: 
      $ CVSROOT=:pserver:anoncvs@anoncvs.NetBSD.org:/cvsroot; export CVSROOT
  3. $ cd /usr
$ cvs login
    (パスワードとして "anoncvs" を使用してください)

最初の checkout の際にはディレクトリーに対する書き込み権限が必要です。 その後、ソースツリーの所有者を他のユーザーに変更できます。一つの方法は 最初のチェックアウトは root で行ない、その後の使用のために ソースツリー全体を他のユーザーの所有に変更することです。

anoncvs over ssh の利用 (トップ)

anoncvs の利用で説明した方法は、取り寄せた ソースが正しいものであることを保証するため、 ssh 上でも使うことができます。 ただし、 そうすることで anoncvs サーバーにはかなりのオーバーヘッドがかかります。

ミラー一覧に載っている ssh 接続に対応したサーバーでは、各項目ごとに、必要な情報を列挙しています。

通常、 cvsroot の冒頭の ':pserver:' を削除し、 お使いのシェルに応じた方法で、変数 CVS_RSH を 'ssh' に設定します。

anoncvs を用いた NetBSD-current の追跡 (トップ)

セットアップ
  • カーネルのみをチェックアウトする 
    $ cd /usr
$ cvs checkout -P src/sys

    これにより、カーネルのソースは /usr/src/sys に用意されます。 カーネルの作り方に 関する情報は別のページで提供されています。

  • ソースツリー全体をチェックアウトする(カーネルも含みます) 

    $ cd /usr
$ cvs checkout -P src

    これにより、NetBSD ソースの全体が /usr/src に用意されます。

    注意

    最初に「ソース全体」のチェックアウトをするときは、 tarball を FTP で取得してローカルで展開するほうが、 たいてい速くなります。こちらのほうがネットワークリンクをもっともよく使うからです。 そうした後に cvs checkout/update を使うと、変更部分のみを送ることになり、 送られるバイト数が最小限になります。

  • パーミッションの修正
    もしソースツリーを root 以外のユーザーの所有にしたければ (root で)次のようにして下さい。 
    # chown -R user /usr/src
ソースの更新
  1. カーネルソースのみを更新する 
    $ cd /usr/src/sys
$ cvs update -dP
  2. ソースツリー全体を更新する 
    $ cd /usr/src
$ cvs update -dP

注意: cvs checkout -d dir src (あるいは、他の src* モジュールに対する同様のコマンド) を実行しても動作しません。 "existing repository ... does not match ...; ignoring module _gnusrc-cmp" 等のエラーメッセージが出ます。回避するには、 -d オプションを外して cvs がデフォルトのディレクトリーを作るようにします。

特定の日付のソースをチェックアウトするには次のようにして下さい
$ cvs checkout -D 20020501-UTC src
特定の枝のソースをチェックアウトするには
$ cvs checkout -rnetbsd-1-6 src
CVS リポジトリーに含まれる各ブランチの説明については、 src/doc/BRANCHES を参照してください。
有用なヒント
  • cvs の '-z' フラグは使わないでください。使った場合、データストリームが同期せず、 クライアント側でソースが壊れたり、クライアントが完全にハングアップしたりします。 さらに、 cvs サーバーに余計な負荷がかかります。
  • ツリー内のあるブランチをチェックアウトしたい場合に、 このブランチ用に新しいディレクトリーを作って、既存のディレクトリーが上書きされないように 慎重を期したい方もいるでしょう: 
    $ cd /parent/dir/to/checkout/into
$ mkdir NewName-temp
$ cd NewName-temp
$ cvs checkout ... src
$ mv src ../NewName
$ cd ..
$ rmdir NewName-temp
  • cvs による更新が正しく実行できるようにするためには objdirs を 使用する必要があります。もし、cvs から 
       cvs [update aborted]: could not chdir to gnu/usr.bin/gdb/gdb: Not a directory
    のようなエラーメッセージを受けたならば、 make cleandir を 実行して、もう一度試して下さい。cvs による更新の後、 make obj を実行するのを忘れないように。

  • 特定のコマンドに対するスイッチはホームディレクトリーの .cvsrc に 記述しておけば、自動的に使われます。.cvsrc ファイルの例を 掲げておきます。 

     update -dP
   checkout -P
   diff -u
ソースからの NetBSD の構築

(すでに、最新の NetBSD バイナリースナップショットと /usr/src に ソースがインストールされていると仮定します; また、 BSDOBJDIR は /usr/obj であると仮定します。):

はじめてユーザーランドを構築する場合: 

# mkdir /usr/obj
# cd /usr/src
# ./build.sh -O /usr/obj -D /usr/NetBSD-new-build -T /usr/tools build
# ./build.sh -O /usr/obj -D /usr/NetBSD-new-build -T /usr/tools install=/

build.sh を使って初めてシステムの構築をする場合には、 この先でコンパイルに使うツール一式も構築されます。 その後に作られるものはすべて、すでに構築済のツールを再利用することになるので、 所要時間は初回より短くなります。

もちろん、 ./build.sh build が成功しない限り ./build.sh install=/ を実行してはいけません。 さもないと、動作しないシステムをもとに作業が進められてしまう可能性があります。

CVS update の後、ユーザーランドのバイナリーを更新する場合: 

# cd /usr/src
# ./build.sh -D /usr/NetBSD-new-build -O /usr/obj -T /usr/tools -u build
# ./build.sh -D /usr/NetBSD-new-build -O /usr/obj -T /usr/tools -u install=/

これらによって、新しいバイナリーが実行されたシステムにインストールされます。 新しいバイナリーが全て有効になるようにリブートしてください。

あなたがシステムを頻繁に更新しており、動作中のシステムを直接更新したい場合は、 熟練者モードを使って DESTDIR=/ で構築することができます。 たとえば次のようにします: 

# ./build.sh -E -O /usr/obj -T /usr/tools -u build

これは熟練ユーザー専用の方法であり、これを実行するだけで システムが何も構築できない状態になってしまう可能性があることに注意してください。 構築が最後まで成功すると確信できる 場合にのみ、この方法を使ってください。

SUP と CVS の組合せによる NetBSD-current の追跡 (トップ)

概要

currentは次の方法により追跡できます。基準となるソースのコピーを、 標準的にはほぼ週に一回SUPを使い最新の状態に維持します。そして、 この基準となるソースツリーを、ローカルのCVSリポジトリーにインポー トします。そして、リポジトリーのコピーをチェックアウトし、それ からcurrentを作成します。

このアプローチには3つの主要な理由があります。

  1. いつどのようにcurrentが更新されたか追跡するため。
  2. ローカルの変更をほとんど自動的に更新されたcurrentソースにマー ジできるようにするため。
  3. 構築するときの問題に備えて、いつもまったく変更していない NetBSD-currentのソースツリーがあることを保証するため。

このアプローチの短所は、3つの独立のソースツリーのために、実際の currentの構築に必要な空きを含めないで、およそ150MBのディスクスペー スが必要なところです。

必要なもの
  • CVS 1.9かそれ以降(もし、あなたが 2000-09-04 以降の -current を使用していればすでにインストールされていますし、 そうでない場合は pkgsrcか、ソースから構築のどちらでも構いません)。 マージが上手なのでCVS 1.10かそれ以降が望ましいでしょう。
  • SUP
  • Perl 5(任意)附属スクリプトのため
詳説

currentの追跡と構築は、6つの段階からなります:

  1. マスターソースツリーにSUPでソースを更新します。
  2. SUPしたファイルをCVSにインポートし、ソースの作業用コピーを更 新します。
  3. 作業用ソースとSUPしたソースとをマージします。
  4. currentを構築してインストールします。
  5. 構築に成功したソースにタグをつけます。

ソースのSUP (トップ)

ソースは、どのNetBSD SUPサーバーからもSUP可能です。またSUPの出 力は後の参照のためにファイルに保存するべきです。

ソースのインポートとマージ (トップ)

ソースのインポートは次のように行ないます:

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

dateは追跡のためにSUP時の日付と置き換えます。 -I ! -I CVS オプションは、 ソースツリー中の 'CVS' ディレクトリーを除く全てのファイルが 無視されないことを保証します。これはNetBSDのソースファイルに、通 常CVSにより無視される拡張子のものがいくつかあるからです。もしロー カルのパッチと衝突がある場合、importコマンドはそれらを出力し、衝 突をマージするためのコマンドを次のように出力します:

$ cvs checkout -jnetbsd:yesterday -jnetbsd netbsd

このマージコマンドは、インポートされたNetBSDソースを正確にマー ジするためのものですが、SUPにより削除されたファイルは、ローカル に反映されません。これを行なうためのマージコマンドはこうなるでしょ う:

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

previous import tagは前回のCVSインポートで使用したタグ名 と置き換えます。dateは、今マージしたばかりのcurrentのイン ポートに使用したタグ名を利用できるようにするために、現在の日付と 置き換えます。

importコマンドにより表示される衝突は、衝突の可能性のあるもので す。これらは、通常updateコマンドによりマージされますが、いくつか の場合、実際に衝突を引き起こします。この場合、衝突行を手動でマー ジすることが必要です。実際に衝突がある場合、cvs update時に、 Cに続きファイルネームが表示されます。

手作業による衝突のマージは単純作業ではありませんが、多くの場合、 ファイルへ行なったローカルの変更を削除し、元のNetBSDソースコード に似せてやることで解決します。

CVSは衝突を次のように表します:

<<<<<<
  ローカルファイルのコード
======
  インポートしたファイルのコード
>>>>>> 新たにインポートされるリビジョンのローカルリビジョン番号

もしimportコマンドが何の衝突を表示しない場合でも、チェックアウ トしたツリーのコピーは衝突した場合と同じ方法で更新できます。

updateとcheckoutコマンドはすべて、チェックアウトしたソースのディ レクトリーで行なってください。私のシステムでは、これは /usr/src/netbsdです。

もし、これが最初のインポートならば、チェックアウトしたソースは ないでしょう。'/usr/src/netbsd'にソースツリーを作り たいと仮定すると、次のコマンドでソースをチェックアウトします。マー ジ作業は必要ありません。

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

構築に成功したものへのタグ付け (トップ)

もし、構築がうまくいって 動作するバイナリーセットを作成できたのならば、 動作するソースにタグ付けすることで使いやすくできます。 これは、万一なにかの原因で構築できないcurrentツリーになっても、 ひとつのCVSコマンドで、構築できるツリーに巻き戻すことを可能にします。 タグ付けは次のコマンドで行えます:

$ cvs tag successful-build-build date
註
  • もし、ファイル中の$NetBSD$マーカーを認識する NetBSDカスタムバージョンのCVSを使用しない場 合、ファイルのNetBSDリビジョン番号を、構築時に問題が起きた場合 に参照の目的に使用することができます。
  • 上記のSUP/インポート/マージの作業は、まったく簡単に自動化で きます。以下のPerlスクリプトがこの作業を自動的に行ないます。 
    #!/usr/pkg/bin/perl
#
# NetBSD-currentをSUPしてそれをCVSに取り込み、手元の変更とマージする
# スクリプト
#
# 原註:
# このスクリプトはエラー処理をしていないので、対話的でない用途には向い
# ていない。
#
# このスクリプトはcvs-1.10.1とcvs-1.9.18でのみテストされている。
#
$SRCROOT="/usr/src/netbsd";
$IMPORTROOT="/misc/import";
$CVSROOT="/misc/cvsrep";
# supを実行してその標準出力をperlに取り込む
system "/usr/sbin/sup -zsv" ; # ここは最新のシステム以外では変更する
                              # 必要がある

# 新しいファイルを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 ";

# 作業ディレクトリーを手元のNetBSDソースツリーにする
chdir $SRCROOT or die "Could not change to $SRCROOT directory\n";

# 取り込みを始める
$lastimport = `cat /usr/src/netbsd/.tag`; # `はバッククォート
$lastimport =~ s/\n//; # 文字列の終りの改行をすべて取り去る
system "/usr/local/bin/cvs update -j $lastimport  -j
current-$shortdate ";
# tag保存ファイルに最新のファイルを書き込む
open TAG,">$SRCROOT/.tag" or die "Could not open new tag file";
 print TAG "current-$shortdate";
close TAG;

    このスクリプトは作者がもっともよく使っているスクリプティングツー ルであるという理由からPerlでかかれていますが、同じことをする shellスクリプトを書くのはとても簡単でしょう。

  • CVSを用いてcurrentを追跡するテクニックについてはNetBSDの current-usersメーリングリストで何度か議論されています。他のテ クニックについてはNetBSDメーリングリストを検索してみてください。

何かコメントや提案があれば、この部分を担当している Mike Pumford (訳註:英語で)、または までメールしてください。

リポジトリー全体の入手 (トップ)

以上で説明した方法では、あなたが独自に行なった変更を自分用のリポジトリーに 保存することができます。これは、あなたが NetBSD をもとにしたソフトウェアの 開発をしている場合には便利でしょう。あなたが自分の CVS リポジトリーの 保守をしているわけでなく、単に NetBSD の CVS リポジトリーをミラーしたい だけならば、それ用の方法が三つあります。

以下に簡単に説明するいずれの方法でも、 NetBSD CVS リポジトリーのコピー (つまり、チェックアウトされたファイルでは*なく*、 RCS の ,v ファイル) を取得できます。その後は、自分の anoncvs サーバーをセットアップしたり、 ローカルハードディスクにチェックアウトしたりできます。また、 リポジトリーに記録されている履歴にすぐにアクセスするのにも便利です。

リポジトリー全体を取得する方法は、次のとおりです:

sup

すでに sup を使って NetBSD のソースの一部をミラーしている場合は、 sup の設定ファイルに下記の行を追加します:

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

それから、 "sup /path/to/supfile anoncvs" を実行してファイルを取得します。

sup ファイルの例が /usr/share/examples/supfiles にいくつかあります。 また、 SUP ミラーのリスト で、 あなたの近所のサーバーを探すようにしてください。

rsync

rsync は rsync サーバーに大きな負荷をかけることに注意してください。 このため、同時に利用できる rsync ユーザー数に制限があります。それでもなお rsync したい場合、リポジトリー取得のコマンドは次のとおりです:

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

rsync ミラーのリストをご覧ください !

cvsup

M3 コンパイラーが移植されていないため、現在、 CVSup はすべての NetBSD アーキテクチャーで使えるわけではありません。 i386 では、 devel/cvsup パッケージと下記の設定ファイルを使って、 cvsup.de.NetBSD.org から リポジトリーをミラーできます: 

*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

CVSup ミラーのリストをご覧ください!

エラーが出た場合は ? (トップ)

スナップショットや以前の -current をもとに -current の構築をしようとして うまくいかなくても、慌てないでください。次の手順を踏んでみてください:

  1. 構築をしようとしているリリースの src/UPDATING ファイルを読みます。
  2. 手がかりを得るために current-users アーカイブを読みます。
  3. 再度アップデートします。関連あるファイル群のコミットの合間に リポジトリーを受け取っていた可能性もありますし、あるいは問題が修正 されているかもしれません。
  4. どれも失敗した場合、 current-users にメールを送って、 問題を説明してください。これには、日付、時刻、 -current のソースの 入手方法と、あなたが加えた変更点をすべて含めてください。それから、 出たエラーメッセージを含む短いスクリプトを入れてください。 おそらく、誰かがすぐに問題を解決してくれるでしょう。

etcupdate を使った設定ファイルと起動ファイルの更新 (トップ)

概観
etcupdate は、オペレーティングシステムのアップグレード後の、 /dev、 /etc、 /root 以下の新しい設定ファイルや起動ファイル (etc.tgz 配布セットに含まれるファイル) の比較・マージ・インストールを 手伝ってくれるスクリプトです。オペレーティングシステムのアップグレードは、 ソースからのコンパイル、バイナリー配布物の展開の、いずれの方法でも おこなうことができます。
ソースファイルに etcupdate を使う

ソースが /usr/src 以下に置かれている場合は、 下記のコマンドで十分なはずです: 

# etcupdate

しかし、 NetBSD のソースがこれ以外の場所、たとえば /home/jdoe/netbsd/src にある場合はどうでしょうか? 案ずることはありません。ソースツリーの場所を -s srcdir を使って etcupdate に教えてやれば、うまくいきます: 

# etcupdate -s /home/jdoe/netbsd/src
バイナリー配布セットに etcupdate を使う

時には、ソースが用意されていないけれども設定ファイルや起動ファイルを 更新したいときがあるでしょう。この場合の解決法は、必要な配布セット (少なくとも etc.tgz) を展開し、 -b srcdir を使って etcupdate に 「ソースはなく公式配布セットがあるだけである」ことを伝えます。 

# mkdir /tmp/temproot
# cd /tmp/temproot
# tar xpzf /some/where/etc.tgz
# etcupdate -s /tmp/temproot

特定の問題

wsconsにアップデートした後コンソールが使えない (トップ)

以下の手順が必要です。src/etc にある適切なetc.portディレクトリーから最新のMAKEDEVファイルを /devにコピーしてシングルユーザーで起動してください。そのあと 以下をタイプします: 

# fsck -p
# mount -vt nonfs
# cd /dev
# ./MAKEDEV wscons

build.sh が常に nbmake を最初に再構築するのは、なぜか? (トップ)

たとえ、 ./build.sh tools を実行しておき、その後に -u フラグを使ったり /etc/mk.conf で TOOLDIR を指定していたとしても、 nbmake は常に build.sh によって再構築されます。これは正常な挙動です。 その理由は ./build.sh 自体の中の rebuildmake 関数に書いてあります: 

        # なお、ここでは "mk.conf" に TOOLDIR が設定されていても、
        # それに従おうとは *しません* 。なぜなら、ここに設定されている make
        # 変数の展開その他のことは、 ${toolprefix}make を行なった *後に* のみ、
        # パース可能となるからです。このため、このような TOOLDIR 指定が有効となるのは、
        # ユーザーが環境変数 TOOLDIR をあらかじめ設定しているか、 build.sh に
        # -T オプションが使われたときだけです。
        #

よって、 nbmake を再構築したくない場合は、 -T tooldir を build.sh へ渡すか、環境変数 TOOLDIR を設定しておく必要があります。