[BACK]Return to index.html CVS log [TXT][DIR] Up to [cvs.NetBSD.org] / htdocs / docs / current

File: [cvs.NetBSD.org] / htdocs / docs / current / index.html (download) (as text)

Revision 1.3, Tue Jun 12 10:55:00 2007 UTC (16 years, 9 months ago) by dsieger
Branch: MAIN
Changes since 1.2: +40 -18 lines

Apply the new visual layout. Some other minor bugfixes included,
e.g. make docs/index.html valid html. Also added a news item
announcing the new website.

Some details:

- The header common to all pages is generated through
  share/xsl/webpage.xsl
- The event items on index.html are now generated by the same
  mechanism as the news items
- The CSS stylesheet that dictates the look and feel is global.css

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<meta name="generator" content="Website XSL Stylesheet V2.6.0">
<link rel="home" href="../../." title="Welcome to The NetBSD Project: Of course it runs NetBSD.">
<link rel="up" href="../../docs/." title="NetBSD Documentation">
<link rel="previous" href="../../docs/elf.html" title="NetBSD ELF FAQ">
<link rel="next" href="../../docs/kernel/." title="NetBSD Documentation: Kernel">
<link rel="first" href="../../docs/Hardware/." title="Hardware Documentation">
<link rel="last" href="../../docs/x/." title="NetBSD Documentation: The X Window System">
<link rel="stylesheet" href="/global.css" type="text/css">



    <title>Tracking NetBSD-current</title>
</head>
<body class="website"><div class="webpage">
<a name="docs-current-index"></a><div id="top"><a href="#mainContent" class="doNotDisplay doNotPrint">Skip to main content.</a></div>
<div id="header">
<div class="topNavigation">
<span>» </span><a href="/docs/guide/en/">The Guide</a> |
	<a href="http://man.NetBSD.org/">Manual pages</a> |
	<a href="/mailinglists/">Mailing lists</a> and
	<a href="http://mail-index.NetBSD.org/">Archives</a> |
	<a href="http://cvsweb.NetBSD.org/">CVS repository</a> |
	<a href="http://www.NetBSD.org/Gnats/">Report or query a bug</a> |
	<a href="/docs/software/packages.html">Packages</a>
</div>
<div class="centralHeader">
<a href="/"><img src="/images/NetBSD-headerlogo.png" alt="[NetBSD Logo]" width="506" height="90"></a><div class="headerTools"><div id="headerSearch"><form method="get" action="http://www.google.com/custom">
<input type="text" name="q" onfocus="if(this.value==this.defaultValue ) this.value='';" size="12" maxlength="255" value="Search"><input type="hidden" name="cof" value="L:http://www.NetBSD.org/images/NetBSD-smaller.png;LH:200;LW:200;AH:center;AWFID:4f6b0499f0f58d2c;"><input type="hidden" name="domains" value="NetBSD.org"><input type="hidden" name="sitesearch" value="www.NetBSD.org"><input type="submit" value="Search">
</form></div></div>
</div>
<div class="navBar">
<span class="doNotDisplay">Navigation:</span><a href="/">Home <span>/span></a>	<a href="/about/">About <span>/span></a>	<a href="/releases/">Download <span>/span></a>	<a href="/docs/">Documentation <span>/span></a>	<a href="/support/">Support <span>/span></a>	<a href="/community/">Community <span>/span></a>	<a href="/ports/">Ports <span>/span></a>
</div>
</div>
<div id="content"><div class="fullWidth"><div class="rowOfBoxes">
<h1>Tracking NetBSD-current</h1>
<h3 class="title"><a name="faq">Frequently asked questions</a></h3>
<ul>
<li><a href="#why-track">Why track NetBSD-current?</a></li>
<li><a href="#installing">Installing a current snapshot</a></li>
<li><a href="#downloading">Downloading current source</a></li>
<li><a href="#building">Building a release from source</a></li>
<li><a href="#updating">Updating an existing system</a></li>
<li><a href="#what-to-do">Things you need to remember</a></li>
<li><a href="#build-targets">What are the various Makefile targets?</a></li>
<li><a href="#using-anoncvs-pserver">Using anoncvs</a></li>
<li><a href="#using-anoncvs-over-ssh">Using anoncvs over ssh</a></li>
<li><a href="#using-anoncvs">Tracking NetBSD-current with anoncvs</a></li>
<li><a href="#using-sup-into-cvs">Tracking NetBSD-current with SUP into CVS</a></li>
<li><a href="#supping-sources">Supping sources</a></li>
<li><a href="#import-merge">Importing and merging sources.</a></li>
<li><a href="#building-current">Building current.</a></li>
<li><a href="#tagging">Tagging a successful build</a></li>
<li><a href="#getrepos">Getting the whole repository</a></li>
<li><a href="#error">What if I get an error?</a></li>
<li><a href="#etcupdate">Updating the configuration and startup files with etcupdate</a></li>
</ul>
<h3 class="title"><a name="specific-problems">Specific problems</a></h3>
<ul>
<li><a href="#wscons">Console dead after updating to wscons</a></li>
<li><a href="#rebuild-nbmake">Why does build.sh always rebuild nbmake first?</a></li>
</ul>
<hr>
<h3 class="title">Frequently asked questions</h3>
<h4 class="title">
<a name="why-track"></a>Why track NetBSD-current? (<a href="#faq">top</a>)
  </h4>
<p>
The developers of NetBSD have made the current development sources
available to the public for several reasons.  Overall, providing
NetBSD-current helps us to create a more stable, accessible system.
</p>
<p>
It makes it easier for people to become involved in the development of
NetBSD.  Distributing the current development sources allows a greater
number of people to see where the system is going, and to become
involved with new features as they are implemented.
</p>
<p>
It also makes changes from users easier to integrate.
If users make changes against
the current development sources, then virtually no integration is
needed to get them into the master source tree. 
</p>
<p>
It also allows wider testing of the software as it is developed.  Users
of NetBSD-current are encouraged to send in <a href="../../support/send-pr.html" target="_top">bug reports</a> about the current sources,
and that helps find and fix bugs.  Because people are testing the
software soon after it's written, more bugs can be found and
eliminated.
</p>

<h4 class="title">
<a name="installing"></a>Installing a current snapshot (<a href="#faq">top</a>)
  </h4>
<p>
To quickly begin using current,
start with a snapshot generated by release engineering.
The current status of each platform can be seen at
<a href="http://releng.NetBSD.org/cgi-bin/builds.cgi" target="_top">
NetBSD Autobuild
</a>
and the corresponding releases found in
<a href="ftp://ftp.NetBSD.org/pub/NetBSD-daily/HEAD/" target="_top">
ftp://ftp.NetBSD.org/pub/NetBSD-daily/HEAD/
</a>
by date and platform.
</p>
<p>
</p>
<div class="orderedlist"><ol type="1">
<li> Hunt down to the desired <code class="code">binary/sets</code> directory,
and <code class="code"><span class="bold"><strong>mget *.tgz</strong></span></code> files
into your favorite local administrative directory
(for example, <span class="emphasis"><em><code class="code">$HOME/current</code></em></span>);
when limited by disk space and/or time,
only kern-GENERIC, etc, base, and comp (if you want a compiler) are
essential.</li>
<li> Extract the desired <code class="code">/etc</code> and kernel:
<pre class="programlisting">
    $ su
    $ cd /root
    $ tar -zxpf ~/etc.tgz
    $ tar -zxpf ~/kern-GENERIC.tgz
    $ ln -fh /netbsd /netbsd.old
    $ mv netbsd /netbsd
    $ shutdown -r now
</pre>
</li>
<li> Extract the matching <code class="code">base</code>,
and any other desirable feature sets:
<pre class="programlisting">
    $ su
    # cd /
    # tar -zxpf ~/comp.tgz
    # ...
    # tar -zxpf ~/base.tgz
</pre>
</li>
<li> <a href="#etcupdate" target="_top">Update</a> <code class="code">/etc</code>
as last step: postinstall whill first check and fix most things that
can be automated, and etcupdate in the second step will ask on what
to merge:
<pre class="programlisting">
    # /usr/sbin/postinstall -s /root check
    # /usr/sbin/postinstall -s /root fix
    # /usr/sbin/etcupdate -s /root
    # shutdown -r now
</pre>
</li>
</ol></div>
<p>
</p>
<p>
At this point,
you are relatively current
and ready to build your own current source.
</p>

<h4 class="title">
<a name="downloading"></a>Downloading current source (<a href="#faq">top</a>)
  </h4>
<p>

Traditionally,
the system source files are kept at <code class="code">/usr/src</code>,
but this generally requires root privileges.
The current <code class="code"><span class="bold"><strong>build.sh</strong></span></code> process can run entirely unprivileged,
although installation still requires root privileges.
Whenever examples in this document assume <code class="code">/usr/src</code>,
you can substitute another location
(such as <span class="emphasis"><em><code class="code">$HOME/current</code></em></span>).
</p>
<p>
</p>
<div class="orderedlist"><ol type="1">
<li> Select a location for the source tree:
<pre class="programlisting">
    $ cd /usr
    $ su
</pre>
</li>
<li> Download the -current source from a
<a href="../../mirrors/" target="_top">NetBSD mirror site</a>
near to you:
<div class="itemizedlist"><ul type="disc">
<li> via ftp from <a href="ftp://ftp.NetBSD.org/pub/NetBSD/NetBSD-current/tar_files/src/" target="_top">
/pub/NetBSD/NetBSD-current/tar_files/src/</a>,
or</li>
<li> using <a href="ftp://ftp.NetBSD.org/pub/NetBSD/README.sup" target="_top">sup</a>.
</li>
</ul></div>
<p>
These files represent a snapshot of the source tree.
For the most up-to-date files
using <a href="#using-anoncvs" target="_top">anoncvs</a>,
</p>
<pre class="programlisting">
    $ cd /usr/src
    $ cvs -q -d $CVSROOT update -dP
</pre>
<p>
</p>
<p>
The <code class="code">-d $CVSROOT</code> is only needed on the first update,
to populate the CVS tags with your selected mirror.
Remember to always use the <code class="code">-P</code> flag or add it to your .cvsrc file.
</p>
<p>
If you wish to track local changes to the NetBSD source you might want
to setup a local CVS tree, and then <a href="#using-sup-into-cvs" target="_top">import the
sup changes</a>.
</p>
</li>
<li>
Fix permissions<br>
If you wish for the source tree to be maintained by a non-root user
that is a member of the (traditional) wsrc group,
do (as root):
<pre class="programlisting">
$ chown -R <span class="emphasis"><em>user</em></span>:wsrc /usr/src
$ chmod -R u=rwX,g=rwX,o=rX /usr/src</pre>
</li>
</ol></div>
<p>
</p>

<h4 class="title">
<a name="building"></a>Building a release from source (<a href="#faq">top</a>)
  </h4>
<p>

<span class="emphasis"><em>Please remember to check <a href="http://cvsweb.NetBSD.org/bsdweb.cgi/src/BUILDING" target="_top">src/BUILDING</a>
for the latest changes.</em></span>
</p>
<p>
Traditionally,
the system object files were kept at <code class="code">/usr/obj</code>,
but this generally requires root privileges.
Alternatively,
keeping the object files on another filesystem
can significantly speed compilation time.
Whenever examples in this document assume <code class="code">/usr/src</code>,
you can substitute another location
(such as <span class="emphasis"><em><code class="code">$HOME/current</code></em></span>).
</p>
<div class="orderedlist"><ol type="1">
<li> Select a location for the object tree,
where there is enough space for a full install,
plus a set of release tarfiles:
<pre class="programlisting">
    $ cd /usr/src
    $ su
    # mkdir ../tools
    # mkdir ../obj
</pre>
</li>
<li> From the root of the source tree:
<pre class="programlisting">
    $ cd /usr/src
    $ ./build.sh -O ../obj -T ../tools -u -U release
</pre>
</li>
</ol></div>
<p>
</p>
<p>
In this example,
the <code class="code">-u</code> option indicates that a <code class="code">make clean</code>
operation should not be run before starting the build. This is useful when
doing an update from a previous build and/or a fresh build.
</p>
<p>
The <code class="code">-U</code> option allows the entire build by a non-root user.
</p>
<p>
When completed,
you should have everything you need to install
in a directory that <code class="code">build.sh</code> selects (and will display),
including install media and notes.
</p>
<p>
If you wish to
<a href="../guide/en/chap-build.html" target="_top">cross compile</a>
for a different architecture,
include '<code class="code">-m MACHINE -a ARCH</code>' when running build.sh.
</p>
<p>
For more details,
run '<code class="code">./build.sh -h</code>',
and see <a href="ftp://ftp.NetBSD.org/pub/NetBSD/NetBSD-current/src/BUILDING" target="_top">
/usr/src/BUILDING</a>.
</p>

<h4 class="title">
<a name="updating"></a>Updating an existing system (<a href="#faq">top</a>)
  </h4>
<p>

<span class="emphasis"><em>Please remember to check <a href="http://cvsweb.NetBSD.org/bsdweb.cgi/src/UPDATING" target="_top">src/UPDATING</a>
for the latest changes.</em></span>
</p>
<p>
</p>
<div class="orderedlist"><ol type="1">
<li> From the root of the source tree:
<pre class="programlisting">$ cd /usr/src</pre>
</li>
<li>Build the toolchain:
<pre class="programlisting">$ ./build.sh -O ../obj -T ../tools -U -u tools</pre>
</li>
<li>Build the distribution:
    <pre class="programlisting">$ ./build.sh  -O ../obj -T ../tools -U -u distribution</pre>
</li>
<li>Build the kernel:
    <pre class="programlisting">$ ./build.sh  -O ../obj -T ../tools -U -u kernel=GENERIC</pre>
</li>
<li>Install the kernel:
<pre class="programlisting">
    $ cd ../obj/sys/arch/&lt;ARCH&gt;/compile/GENERIC
    $ su
    # mv /netbsd /netbsd.old
    # cp netbsd /netbsd
</pre>
</li>
<li>Reboot into the new kernel:
    <pre class="programlisting"># shutdown -r now</pre>
</li>
<li>Install the new userland:
<pre class="programlisting">
    $ cd /usr/src
    $ su
    # ./build.sh -O ../obj -T ../tools -U install=/
</pre>
</li>
<li>Follow the instruction in the output for fixing obsolete files, for example:
<pre class="programlisting">
    # /usr/src/usr.sbin/postinstall/postinstall -s /usr/src -d // fix defaults mtree obsolete
</pre>
</li>
<li>
<a href="#etcupdate" target="_top">Update</a> /etc:
<pre class="programlisting"># /usr/sbin/etcupdate -s /usr/src</pre>
</li>
<li>Optionally reboot to ensure all running services are using the new binaries:
    <pre class="programlisting"># shutdown -r now</pre>
</li>
</ol></div>
<p>
</p>
<p>
In this example,
the <code class="code">-u</code> option indicates an update process,
and the <code class="code">-U</code> option allows the entire build by a non-root user
followed with an install by root.
</p>
<p>
The build order (tools, distribution, kernel) is chosen to optimize the time
for updating the source whenever problems occur.
To ensure consistency,
the process should be restarted from the beginning in the case of errors/cvs
updates.
</p>
<p>
For more details,
see <a href="ftp://ftp.NetBSD.org/pub/NetBSD/NetBSD-current/src/UPDATING" target="_top">
/usr/src/UPDATING</a>.
</p>

<h4 class="title">
<a name="what-to-do"></a>Things you need to remember (<a href="#faq">top</a>)
  </h4>

<div class="itemizedlist"><ul type="disc">
<li>
  <p>
  When upgrading to a more recent version of -current you should
  <span class="emphasis"><em>always</em></span> compile and boot a new kernel before installing any
  new libs (<a href="#star" target="_top">*</a>). In general the best approach is to
  try the new kernel before anything else, and if you hit any problems see
  the entry in the <a href="../kernel/#problems_compiling_a_current_kernel" target="_top">
  Kernel FAQ</a>.
  </p>
  <p>
  Once the kernel is running, you should have a look at the 
  <a href="ftp://ftp.NetBSD.org/pub/NetBSD/NetBSD-current/src/BUILDING" target="_top">BUILDING</a>.

  file at the base of the source tree, and use the build.sh script
  to build a new userland.
  </p>
 </li>
<li>
  When compiling a -current kernel, always remember to include the
  COMPAT_&lt;lastrelease&gt; option (e.g., COMPAT_16).  As current
  diverges from the last stable release, compatibility code will be
  added, but it will only be enabled if this option is present.  At a
  bare minimum, you will need this compatibility code for the time
  between booting the new kernel and finishing your build via 
  <code class="code">build.sh</code>
 </li>
<li>
  People using NetBSD-current are strongly encouraged to subscribe to
  the <span class="bold"><strong><a href="../../mailinglists/#current-users" target="_top">current-users</a></strong></span>
  mailing list.  The <span class="bold"><strong><a href="../../mailinglists/#source-changes" target="_top">source-changes</a></strong></span>
  mailing list is also of interest.
  </li>
</ul></div>
<p><a name="star"></a>

*: Unless you are certain there have been no new
system calls added, but do it anyway; it's safer.
</p>

<h4 class="title">
<a name="build-targets"></a>What are the various Makefile targets? (<a href="#faq">top</a>)
  </h4>
<p>

For further documentation concerning usage of the new toolchain
through the script 'build.sh' (in the toplevel source directory),
run '<code class="code">./build.sh -h</code>',
and see <a href="ftp://ftp.NetBSD.org/pub/NetBSD/NetBSD-current/src/BUILDING" target="_top">
/usr/src/BUILDING</a>.
</p>
<p>
<span class="bold"><strong>WARNING:</strong></span>
<span class="emphasis"><em>
The usage of 'make build' has been deprecated by the updated toolchain,
and is strongly discouraged.
</em></span>
</p>
<p>
When you build your system for the first time using <code class="code">build.sh</code>,
a set of tools for future use of compilations will be built, too.
Any subsequent compilation should reuse the already compiled tools,
and thus take less time.
</p>
<p>
Of course, don't invoke <code class="code">./build.sh install=/</code>
unless the <code class="code">./build.sh build</code> has succeeded previously or it's
entirely possible to end up with a non-working system.
</p>

<h4 class="title">
<a name="using-anoncvs-pserver"></a>Using anoncvs (<a href="#faq">top</a>)
  </h4>
<p>
 
<span class="emphasis"><em>
These instructions cover unencrypted anoncvs connections.
If you wish to use encryption protocols,
see <a href="#using-anoncvs-over-ssh" target="_top">below</a>.
</em></span>
</p>
<div class="orderedlist"><ol type="1">
<li>Install <a href="ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/devel/cvs/README.html" target="_top"><code class="filename">devel/cvs</code></a>.  
<span class="emphasis"><em>If NetBSD is built from -current sources
past 2000-09-04, cvs is already installed.</em></span>
</li>
<li>Set the CVSROOT environment variable to point to the
<a href="../../mirrors/#anoncvs" target="_top">anoncvs server</a> of your choice:
<div class="itemizedlist"><ul type="disc">
<li>For <a href="http://netbsd.gw.com/cgi-bin/man-cgi?csh+1+NetBSD-current">csh(1)</a> or <a href="ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/shells/tcsh/README.html" target="_top"><code class="filename">shells/tcsh</code></a> users:
<pre class="programlisting"># setenv CVSROOT :pserver:anoncvs@anoncvs.NetBSD.org:/cvsroot</pre>
</li>
<li>For <a href="http://netbsd.gw.com/cgi-bin/man-cgi?sh+1+NetBSD-current">sh(1)</a>, <a href="http://netbsd.gw.com/cgi-bin/man-cgi?ksh+1+NetBSD-current">ksh(1)</a>, or <a href="ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/shells/bash2/README.html" target="_top"><code class="filename">shells/bash2</code></a> users:
<pre class="programlisting">$ CVSROOT=:pserver:anoncvs@anoncvs.NetBSD.org:/cvsroot; export CVSROOT</pre>
    </li>
</ul></div>
</li>
<li>
<pre class="programlisting">$ cd /usr
$ cvs login</pre>
(use password "anoncvs")
</li>
</ol></div>
<p>
</p>
<p>
You have to have write permission on the directory for the initial
checkout; after that you can just change the owner of the source tree
to some other user. One of the possible ways is to do the initial
checkout as root, and then give the source tree to a different user
for later use.
</p>

<h4 class="title">
<a name="using-anoncvs-over-ssh"></a>Using anoncvs over ssh (<a href="#faq">top</a>)
  </h4>
<p>
The methods described in <a href="#using-anoncvs-pserver" target="_top">using anoncvs</a> can
be used over ssh to ensure the integrity of the sources you receive.
However,
this adds substantial overhead to the anoncvs servers.
</p>
<p>
Those servers in the <a href="../../mirrors/#anoncvs" target="_top">mirrors</a>
that support ssh connections show the required information with
each entry.
</p>
<p>
In general,
remove the ':pserver:' prefix on the cvsroot,
and set the variable CVS_RSH to 'ssh',
using the method appropriate for your shell.
</p>

<h4 class="title">
<a name="using-anoncvs"></a>Tracking NetBSD-current with anoncvs (<a href="#faq">top</a>)
  </h4>

<div class="sect4" lang="en">
<div class="titlepage"><div><div><h5 class="title">
<a name="setting-up"></a>Setting up</h5></div></div></div>


<div class="itemizedlist"><ul type="disc">
<li>To checkout only the kernel sources
<pre class="programlisting">$ cd /usr
$ cvs checkout -P src/sys</pre>
<p>
This gives you the kernel sources in <code class="code">/usr/src/sys</code>. Information
on <a href="../kernel/#how_to_build_a_kernel" target="_top">how to build a
kernel</a> is also available.
</p>
</li>
<li>
<p>Checkout the entire source tree (including kernel)
</p>
<pre class="programlisting">$ cd /usr
$ cvs checkout -P src</pre>
<p>
</p>
<p>
You should now have a full set of NetBSD sources in /usr/src.
</p>
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Note</h3>
<p>It is almost always faster for a first-time "whole
source" checkout to <a href="#downloading" target="_top">FTP the tarballs</a> and untar
them locally because that makes best use of the network link. After that,
using cvs checkout/update works to minimize the number of bytes coming over
by sending only the changes.
</p>
</div>
</li>
<li>Fix permissions<br>
    If you wish for the source tree to be owned by a non-root user,
    do (as root):
<pre class="programlisting"># chown -R <span class="emphasis"><em>user</em></span> /usr/src</pre>
</li>
</ul></div>
</div>

<div class="sect4" lang="en">
<div class="titlepage"><div><div><h5 class="title">
<a name="update-sources"></a>To update the sources</h5></div></div></div>


<div class="orderedlist"><ol type="1">
<li>To update only the kernel sources
<pre class="programlisting">$ cd /usr/src/sys
$ cvs update -dP</pre>
</li>
<li>To update the entire source tree
<pre class="programlisting">$ cd /usr/src
$ cvs update -dP</pre>
</li>
</ol></div>
<p>
<span class="bold"><strong>Note:</strong></span> Running <code class="code">cvs checkout -d dir src</code> (or similar commands
with the other src* modules) does not work.  You will get error messages saying
"existing repository ... does not match ...; ignoring module _gnusrc-cmp" etc.
The workaround is to drop the <code class="code">-d</code> option and let cvs create the
default directory.
</p>
</div>

<div class="sect4" lang="en">
<div class="titlepage"><div><div><h5 class="title">
<a name="checkout-by-date"></a>To check out the sources from a certain date</h5></div></div></div>

<pre class="programlisting">$ cvs checkout -D 20020501-UTC src</pre>
</div>

<div class="sect4" lang="en">
<div class="titlepage"><div><div><h5 class="title">
<a name="checkout-by-branch"></a>To check out the sources from a certain branch</h5></div></div></div>

<pre class="programlisting">$ cvs checkout -rnetbsd-1-6 src</pre>
See
<a href="http://cvsweb.NetBSD.org/bsdweb.cgi/src/doc/BRANCHES?rev=HEAD&amp;content-type=text/x-cvsweb-markup" target="_top">src/doc/BRANCHES</a>
for a description of the branches in the CVS repository.
</div>

<div class="sect4" lang="en">
<div class="titlepage"><div><div><h5 class="title">
<a name="hints"></a>Useful hints</h5></div></div></div>

<div class="itemizedlist"><ul type="disc">
<li>
Do not use the cvs '-z' flag.  The data stream gets out of sync,
leading to corruption on the client, or causing the client to hang
completely.  The additional load is also hard on the cvs server.
</li>
<li>If you want to check out a certain branch of the tree, you may
want to take caution not to overwrite any existing directories by creating a
new directory for this branch:

<pre class="programlisting">$ cd /parent/dir/to/checkout/into
$ mkdir NewName-temp
$ cd NewName-temp
$ cvs checkout ... src
$ mv src ../NewName
$ cd ..
$ rmdir NewName-temp</pre>
</li>
<li>
You will have to use objdirs in order for cvs updates to work
correctly.  If you happen to get errors from cvs saying things like:
<pre class="programlisting">   cvs [update aborted]: could not chdir to gnu/usr.bin/gdb/gdb: Not a directory</pre>
you should do a <code class="code">make cleandir</code> and try again.  Make sure to
run <code class="code">make obj</code> after the cvs update.
</li>
<li>
<p>

You can put switches for specific commands in a .cvsrc in your home
directory, and they will be automatically used. A sample .cvsrc would be:
</p>

<pre class="programlisting"> update -dP
   checkout -P
   diff -u</pre>
</li>
</ul></div>
</div>

<div class="sect4" lang="en">
<div class="titlepage"><div><div><h5 class="title">
<a name="building-from-source"></a>Building NetBSD from source</h5></div></div></div>

<p>
<span class="emphasis"><em>(assuming you have an up-to-date NetBSD binary
snapshot, and source in /usr/src, on your machine already; further
assuming your BSDOBJDIR should be /usr/obj):</em></span>
</p>
<p>
To build userland the first time:
</p>
<pre class="programlisting"># 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=/
</pre>
<p>
</p>
<p>
When you build your system for the first time using build.sh,
a set of tools for future use of compilations will be built, too.
Any subsequent compilation should reuse the already compiled tools,
and thus take less time.
</p>
<p>
Of course, don't invoke <code class="code">./build.sh install=/</code>
unless the <code class="code">./build.sh build</code> has succeeded previously or it's
entirely possible to end up with a non-working system.
</p>
<p>

To update userland binaries after a CVS update:

</p>
<pre class="programlisting"># 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=/
</pre>
<p>

These will install the new binaries on the running system - reboot to make
sure they all take effect.
</p>
<p>

If you update system frequently and want the build to directly update
your running system, you can use <span class="emphasis"><em>expert</em></span> mode and build
with DESTDIR=/, eg:

</p>
<pre class="programlisting"># ./build.sh -E -O /usr/obj -T /usr/tools -u build</pre>
<p>

Note this is for <span class="bold"><strong>expert</strong></span> users only and you can
very easily render your system into state where it won't be able
to compile anything anymore. Use only if you are <span class="bold"><strong>sure</strong></span>
the build will finish successfully.
</p>
</div>

<h4 class="title">
<a name="using-sup-into-cvs"></a>Tracking NetBSD-current with SUP into CVS (<a href="#faq">top</a>)
  </h4>

    <div class="sect4" lang="en">
<div class="titlepage"><div><div><h5 class="title">
<a name="sup-overview"></a>Overview</h5></div></div></div>


    <p>Current can be tracked in the following way. The baseline copy of
      the sources is kept up to date using sup approximately once a week.
      as normal. This baseline source tree is then imported into a local
      CVS repository. Current is then built from a checked out copy of
      the repository.</p>

    <p>There are 3 major reasons for this approach
    </p>
<div class="orderedlist"><ol type="1">
<li>It keeps track of how current changes over time.</li>
<li>It allows for local changes to be almost automatically merged
	into the updated current sources.</li>
<li>It ensures there is always a clean unmodified copy of the
	NetBSD-current source tree is available in case of problems when
	building.</li>
</ol></div>
<p>
    </p>
    
    <p>The only downside to this approach is that 3 independent copies 
      of the source tree are needed which amounts to about 150MB of
      disk space not including the space required to actually build
      current.
    </p>
    </div>

    <div class="sect4" lang="en">
<div class="titlepage"><div><div><h5 class="title">
<a name="sup-requirements"></a>Requirements</h5></div></div></div>

    <div class="itemizedlist"><ul type="disc">
<li>CVS 1.9 or later (either already installed if you're running
          -current after 2000-09-04, installed from pkgsrc or just
          built from source). CVS 1.10 or later is preferred as it
          handles merging better.</li>
<li>SUP installation</li>
<li>Perl 5 installation for supplied script (optional)</li>
</ul></div>
    </div>
    <div class="sect4" lang="en">
<div class="titlepage"><div><div><h5 class="title">
<a name="sup-details"></a>Details</h5></div></div></div>

    <p>Tracking and building current consists of 6 phases:
    </p>
<div class="orderedlist"><ol type="1">
<li>Supping updated sources into master source tree.</li>
<li>Importing supped sources into CVS and updating working copy
	of sources.</li>
<li>Merging supped sources with local working sources.</li>
<li>Building and installing current.</li>
<li>Tagging the sources for a successful build in the
	repository.</li>
</ol></div>
<p>
    </p>
    </div>
    
<h4 class="title">
<a name="supping-sources"></a>Supping sources (<a href="#faq">top</a>)
  </h4>
    <p>Sources can be supped from any NetBSD sup server and the output 
      from the SUP should be stored in a file for later reference.
    </p>
    
<h4 class="title">
<a name="import-merge"></a>Importing and merging sources. (<a href="#faq">top</a>)
  </h4>
    <p>Sources are imported as follows:</p>
<pre class="programlisting">$ cvs -d /misc/cvsrep import -I ! -I CVS netbsd netbsd current-<span class="emphasis"><em>date</em></span></pre>

    <p><span class="emphasis"><em>date</em></span> is replaced by the date of the SUP for tracking
      purposes. The <code class="code">-I ! -I CVS</code> options ensure that no file in
      the source tree is ignored except 'CVS' directories.  This is because
      some NetBSD source files have extensions which are normally ignored by
      CVS. If there are any conflicts with local patches the import command
      will report them and will describe a command to merge the conflicts
      something like:</p>
<pre class="programlisting">$ cvs checkout -jnetbsd:yesterday -jnetbsd netbsd</pre>
    <p>This merge command will correctly merge the imported NetBSD
      sources but it will not handle the removal of files locally
      which have already been removed by the SUP process. To do this the
      merge command would be:</p>
<pre class="programlisting">$ cvs update -j<span class="emphasis"><em>previous import tag</em></span> -j current-<span class="emphasis"><em>date</em></span></pre>
    <p><span class="emphasis"><em>previous import tag</em></span> should be replaced with the name of
      the tag used for the previous cvs import. <span class="emphasis"><em>date</em></span> should be
      replaced with the current date to yield the same tag used on
      the current import that has just been merged.</p>
    <p>The conflicts reported by the import command are potential
      conflicts. These are usually merged by the update command but in
      some cases a real conflict occurs. In these cases a manual merge
      of the conflicting lines will be required. A real conflict will
      be reported in the cvs update output as a <code class="code">C</code>
      followed by a filename.</p>
    <p>Merging conflicts manually is not a simple process but in most
      cases it should be resolved by removing the local changes and
      making the file like the original NetBSD source code.  </p>
    <p>CVS marks conflicts as follows:</p>
<pre class="programlisting">
&lt;&lt;&lt;&lt;&lt;&lt;
  <span class="emphasis"><em>code from local file</em></span>
======
  <span class="emphasis"><em>code from imported file</em></span>
&gt;&gt;&gt;&gt;&gt;&gt; <span class="emphasis"><em>local revision number of newly imported revision</em></span>
</pre>

    <p>If the import reports no conflicts the checked out copy of the
      tree should be updated in exactly the same way as for the
      conflicts case.</p>
    <p> All update and checkout commands should be done in the
      directory where the sources have been checked out. On my system
      this is <code class="code">/usr/src/netbsd</code>.</p>
    <p>If this is the first import then there will be no sources
      checked out. Assuming you wish to create the source tree in
      '<code class="code">/usr/src/netbsd</code>' The following commands will check
      out the source and no merge step is required.</p>
<pre class="programlisting">$ cd /usr/src
$ cvs -d /misc/cvsrep checkout netbsd
</pre>
    
<h4 class="title">
<a name="building-current"></a>Building current. (<a href="#faq">top</a>)
  </h4>
    <div class="orderedlist"><ol type="1">
<li>Configure, <a href="../kernel/#how_to_build_a_kernel" target="_top">
	build</a>, and reboot into a new kernel.</li>
<li>cd to the base of your -current source tree and type
	<code class="code">./build.sh -T /usr/tools -O /usr/obj </code>.</li>
<li>You may need to merge in any changes that have been made to files in
	/etc.</li>
</ol></div>
    
<h4 class="title">
<a name="tagging"></a>Tagging a successful build (<a href="#faq">top</a>)
  </h4>
    <p> If the <a href="#building" target="_top">build</a> completes successfully,
      and produces a working set of binaries,
      it can be useful to tag the working sources.
      This allows rewinding to a working build tree with a single CVS
      command in the event that the current tree becomes unbuildable
      for any reason. This can be performed by issuing the following
      command:</p>
<pre class="programlisting">$ cvs tag successful-build-<span class="emphasis"><em>build date</em></span></pre>

    <div class="sect4" lang="en">
<div class="titlepage"><div><div><h5 class="title">
<a name="tag-notes"></a>Notes</h5></div></div></div>

    <div class="itemizedlist"><ul type="disc">
<li>If the NetBSD customised version of CVS, which recognises
	<span class="bold"><strong>$Net</strong></span><span class="bold"><strong>BSD$</strong></span> markers in files, is not used, the
	NetBSD revision number of the file is available for reference
	purposes when build problems occur.</li>
<li>The sup/import/merge sequence described above is quite
	easily automatable. The following Perl script automates this
	process.
<pre class="programlisting">#!/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,"&gt;$SRCROOT/.tag" or die "Could not open new tag file";
 print TAG "current-$shortdate";
close TAG;
</pre>
    <p>This script was written in Perl since it is the scripting tool
	  which the author has the most experience with. It should
	  be fairly straightforward to write a shell script to perform 
      the same task.</p>
</li>
<li>Techniques for tracking current with CVS have been discuss several
	times on the NetBSD current-users mailing list. For
	alternative techniques try searching the NetBSD mailing lists.</li>
</ul></div>
    <p>
    If you have any comments or suggestions please send them to
    Mike Pumford <code class="email">&lt;<a href="mailto:mpumford@black-star.demon.co.uk">mpumford@black-star.demon.co.uk</a>&gt;</code> (who maintains this entry) or
    <code class="email">&lt;<a href="mailto:www@NetBSD.org">www@NetBSD.org</a>&gt;</code>.
</p>
</div>

<h4 class="title">
<a name="getrepos"></a>Getting the whole repository (<a href="#faq">top</a>)
  </h4>
<p>

All the procedures described above allow you keeping your own
changes in your repository, which has its advantages if you develop
your own software based on NetBSD. If you don't want to maintain your
own CVS repository, but just want to mirror NetBSD's CVS repository,
there are three ways to do so.
</p>
<p>

Each of the methods described briefly below will get you a copy
of the NetBSD CVS repository (i.e. the RCS ,v files, not the checked
out files!). You can then setup your own anoncvs server or check
out to a local harddisk. It's also useful for fast access to the history
information stored in the repository.
</p>
<p>

The methods to retrieve the whole repository are:

</p>
<div class="variablelist"><dl>
<dt><span class="term">sup</span></dt>
<dd>
<p>If you use sup already to mirror other parts of the NetBSD source,
     you will want to add the following lines to your sup config file:</p>
<pre class="programlisting">anoncvs release=all  host=sup.NetBSD.org hostbase=/ftp/pub \
base=/usr prefix=/usr backup use-rel-suffix compress
</pre>
     <p>
     After that, run "sup /path/to/supfile anoncvs" to retrieve the files.
     </p>
     <p>
     Some example sup files are available in <code class="code">/usr/share/examples/supfiles</code>. 
     Also, check our <a href="../../mirrors/#sup" target="_top">list of SUP mirrors</a>
     to find the server closest to you!
     </p>
</dd>
<dt><span class="term">rsync</span></dt>
<dd>
<p>Note that rsync puts quite a heavy load on our rsync server, and
     as such the number of concurrent rsync users is restricted. If you
     still want to try rsync, the command to retrieve the repository
is:</p>
<pre class="programlisting">rsync -v -a rsync://anoncvs.NetBSD.org/cvsroot/src .</pre>
     <p>Please see our <a href="../../mirrors/#rsync" target="_top">list of rsync mirrors</a>!</p>
</dd>
<dt><span class="term">cvsup</span></dt>
<dd>
<p>CVSup is not currently available for all NetBSD architectures, since the M3
     compiler has not been ported. On i386, you can mirror the repository
     from cvsup.de.NetBSD.org with the 
     <a href="ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/devel/cvsup/README.html" target="_top"><code class="filename">devel/cvsup</code></a> package and the 
     following config file:
</p>
<pre class="programlisting">*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
</pre>
<p>
     </p>
     <p>
     Please see our <a href="../../mirrors/#cvsup" target="_top">list of CVSup mirrors</a>!
</p>
</dd>
</dl></div>
<p>
</p>

<h4 class="title">
<a name="error"></a>What if I get an error? (<a href="#faq">top</a>)
  </h4>
<p>

If you try to build -current, either from a snapshot or an earlier
-current, and it doesn't work, don't panic.  Try these steps:
</p>
<div class="orderedlist"><ol type="1">
<li>Read the <a href="http://cvsweb.NetBSD.org/bsdweb.cgi/src/UPDATING" target="_top">UPDATING</a>
    file from the release you're trying to build.
</li>
<li>Read the <a href="http://mail-index.NetBSD.org/current-users/" target="_top">current-users
    archive</a> for hints.
</li>
<li>Update again.  You may have caught the repository in the middle of
    a commit to several related files, or the problem might have
    already been fixed.
</li>
<li>If all else fails, send email to current-users explaining the
    problem.  Include the date, time, and method you used to get your
    -current sources, as well as any local changes you've made.  Then
    put in a <span class="bold"><strong>short</strong></span> script that includes the error messages
    you're getting.  Somebody will probably fix the problem
    momentarily.
</li>
</ol></div>
<p>
</p>

<h4 class="title">
<a name="etcupdate"></a>Updating the configuration and startup files with etcupdate (<a href="#faq">top</a>)
  </h4>

<div class="sect4" lang="en">
<div class="titlepage"><div><div><h5 class="title">
<a name="etcupdate-overview"></a>Overview</h5></div></div></div>


etcupdate is a script to help users compare, merge and install new
configuration and startup files (files found in the etc.tgz
distribution set) in /dev, /etc and /root after performing an operating
system upgrade. The upgrade of the operating system could have
been performed either by compiling sources or by extracting
the distribution binaries. 
</div>

<div class="sect4" lang="en">
<div class="titlepage"><div><div><h5 class="title">
<a name="using-etcupdate-source"></a>Using etcupdate with source files</h5></div></div></div>

<p>
In case where the sources are in /usr/src the following command should be
enough:
</p>
<pre class="programlisting"># etcupdate</pre>
<p>
But what if your NetBSD sources are in an alternative location, such as
in /home/jdoe/netbsd/src? Don't worry, tell etcupdate the location of
your source tree with -s srcdir and it will work just fine:
</p>
<pre class="programlisting"># etcupdate -s /home/jdoe/netbsd/src</pre>
</div>

<div class="sect4" lang="en">
<div class="titlepage"><div><div><h5 class="title">
<a name="using-etcupdate-binary"></a>Using etcupdate with binary distribution sets</h5></div></div></div>

<p>
Sometimes it's not possible have the sources around but you still want
to update the configuration and startup files. The solution is to extract
the desired distribution files (at least etc.tgz) and use the -b
srcdir switch to tell etcupdate that we don't have the sources but
only the official distribution sets.
</p>
<pre class="programlisting"># mkdir /tmp/temproot
# cd /tmp/temproot
# tar xpzf /some/where/etc.tgz
# etcupdate -s /tmp/temproot</pre>
</div>
<hr>
<h3 class="title">Specific problems</h3>
<h4 class="title">
<a name="wscons"></a>Console dead after updating to wscons (<a href="#specific-problems">top</a>)
  </h4>
<p>

You should copy a current MAKEDEV from the appropriate etc.<span class="emphasis"><em>port</em></span>
directory in <a href="ftp://ftp.NetBSD.org/pub/NetBSD/NetBSD-current/src/etc/" target="_top">src/etc</a>,
into <code class="code">/dev</code>, boot single user, then type:
</p>
<pre class="programlisting"># fsck -p
# mount -vt nonfs
# cd /dev
# ./MAKEDEV wscons
</pre>
<p>
</p>

<h4 class="title">
<a name="rebuild-nbmake"></a>Why does build.sh always rebuild nbmake first? (<a href="#specific-problems">top</a>)
  </h4>
<p>

Even after running <code class="code">./build.sh tools</code> and using the <code class="code">-u</code>
flag or specifying <span class="emphasis"><em>TOOLDIR</em></span> in <code class="code">/etc/mk.conf</code>,
<code class="code">nbmake</code> is always rebuilt by <code class="code">build.sh</code>.  This is normal.
The reason for this can be found in <code class="code">./build.sh</code> itself, in the
function <code class="code">rebuildmake</code>:
</p>
<pre class="programlisting">        # Note that we do NOT try to grovel "mk.conf" here to find out if
        # TOOLDIR is set there, because it can contain make variable
        # expansions and other stuff only parsable *after* we have a working
        # ${toolprefix}make.  So this logic can only work if the user has
        # pre-set TOOLDIR in the environment or used the -T option to
        # build.sh.
        #               
</pre>
<p>
So, if you do not want to rebuild <code class="code">nbmake</code>, you will need to pass
<code class="code">-T tooldir</code> or set the <span class="emphasis"><em>TOOLDIR</em></span> variable in the
environment.
</p>

</div></div></div>
<div class="navfoot"></div>
<div id="footer"><center>
<span class="footfeed"><a href="http://www.NetBSD.org/cgi-bin/feedback.cgi">
	  Contact</a> |
      </span><span class="footcopy"><a href="/about/disclaimer.html">
      Disclaimer</a> |

      <span class="copyright">Copyright 1994-2007 The NetBSD Foundation, Inc. </span>ALL RIGHTS RESERVED.<br>NetBSD<sup>/sup> is a registered trademark of The NetBSD
	Foundation, Inc.</span>
</center></div>
</div></body>
</html>