Subject: "Tracking NetBSD-current" merged into guide
To: None <netbsd-docs@netbsd.org>
From: Mark Weinem <mark.weinem@alumni.uni-duisburg-essen.de>
List: netbsd-docs
Date: 04/15/2007 15:40:42
--Boundary-00=_atiIGZCIvpe94xD
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Hi,
i have merged the "Tracking NetBSD-current" HOWTO into a chapter for the
guide. The diff, xml and html files are attached. Please review.
Thanks & best regards, Mark
--
Mark Weinem
Jabber: weinem@jabber.cz
PGP-Key available
--Boundary-00=_atiIGZCIvpe94xD
Content-Type: text/html;
charset="utf-8";
name="chap-current.html"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="chap-current.html"
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DISO-8859-=
1">
<title>Chapter=A029.=A0Tracking NetBSD-current</title>
<link rel=3D"stylesheet" href=3D"/NetBSD.css" type=3D"text/css">
<meta name=3D"generator" content=3D"DocBook XSL Stylesheets VX.X.X">
<link rel=3D"start" href=3D"index.html" title=3D"The NetBSD Guide">
<link rel=3D"up" href=3D"part-compile.html" title=3D"Part=A0V.=A0Building t=
he system">
<link rel=3D"prev" href=3D"chap-fetch.html" title=3D"Chapter=A028.=A0Obtain=
ing the sources">
<link rel=3D"next" href=3D"chap-build.html" title=3D"Chapter=A030.=A0Crossc=
ompiling NetBSD with build.sh">
</head>
<body bgcolor=3D"white" text=3D"black" link=3D"#0000FF" vlink=3D"#840084" a=
link=3D"#0000FF">
<div class=3D"navheader">
<table width=3D"100%" summary=3D"Navigation header">
<tr><th colspan=3D"3" align=3D"center">Chapter=A029.=A0Tracking NetBSD-curr=
ent</th></tr>
<tr>
<td width=3D"20%" align=3D"left">
<a accesskey=3D"p" href=3D"chap-fetch.html">Prev</a>=A0</td>
<th width=3D"60%" align=3D"center">Part=A0V.=A0Building the system</th>
<td width=3D"20%" align=3D"right">=A0<a accesskey=3D"n" href=3D"chap-build.=
html">Next</a>
</td>
</tr>
</table>
<hr>
</div>
<div class=3D"chapter" lang=3D"en">
<div class=3D"titlepage"><div><div><h2 class=3D"title">
<a name=3D"chap-current"></a>Chapter=A029.=A0Tracking NetBSD-current</h2></=
div></div></div>
<div class=3D"toc">
<p><b>Table of Contents</b></p>
<dl>
<dt><span class=3D"sect1"><a href=3D"chap-current.html#reasons">29.1. Reaso=
ns to track NetBSD-current</a></span></dt>
<dt><span class=3D"sect1"><a href=3D"chap-current.html#installing">29.2. In=
stalling a current snapshot</a></span></dt>
<dt><span class=3D"sect1"><a href=3D"chap-current.html#downloading">29.3. D=
ownloading current source</a></span></dt>
<dt><span class=3D"sect1"><a href=3D"chap-current.html#building">29.4. Buil=
ding a release from source</a></span></dt>
<dt><span class=3D"sect1"><a href=3D"chap-current.html#updating">29.5. Upda=
ting an existing system</a></span></dt>
<dt><span class=3D"sect1"><a href=3D"chap-current.html#remember">29.6. Thin=
gs you need to remember</a></span></dt>
<dt><span class=3D"sect1"><a href=3D"chap-current.html#build-targets">29.7.=
What are the various Makefile targets?</a></span></dt>
<dt><span class=3D"sect1"><a href=3D"chap-current.html#using-anoncvs-pserve=
r">29.8. Using anoncvs</a></span></dt>
<dt><span class=3D"sect1"><a href=3D"chap-current.html#using-anoncvs-over-s=
sh">29.9. Using anoncvs over ssh(1)</a></span></dt>
<dt><span class=3D"sect1"><a href=3D"chap-current.html#using-anoncvs">29.10=
=2E Tracking NetBSD-current with anoncvs</a></span></dt>
<dd><dl>
<dt><span class=3D"sect2"><a href=3D"chap-current.html#setting-up">29.10.1.=
Setting up</a></span></dt>
<dt><span class=3D"sect2"><a href=3D"chap-current.html#update-sources">29.1=
0.2. To update the sources</a></span></dt>
<dt><span class=3D"sect2"><a href=3D"chap-current.html#checkout-by-date">29=
=2E10.3. To check out the sources from a certain date</a></span></dt>
<dt><span class=3D"sect2"><a href=3D"chap-current.html#checkout-by-branch">=
29.10.4. To check out the sources from a certain branch</a></span></dt>
<dt><span class=3D"sect2"><a href=3D"chap-current.html#hints">29.10.5. Usef=
ul hints</a></span></dt>
<dt><span class=3D"sect2"><a href=3D"chap-current.html#building-from-source=
">29.10.6. Building NetBSD from source</a></span></dt>
</dl></dd>
<dt><span class=3D"sect1"><a href=3D"chap-current.html#using-sup-into-cvs">=
29.11. Tracking NetBSD-current with sup(1) into CVS</a></span></dt>
<dd><dl>
<dt><span class=3D"sect2"><a href=3D"chap-current.html#sup-overview">29.11.=
1. Overview</a></span></dt>
<dt><span class=3D"sect2"><a href=3D"chap-current.html#sup-requirements">29=
=2E11.2. Requirements</a></span></dt>
<dt><span class=3D"sect2"><a href=3D"chap-current.html#sup-details">29.11.3=
=2E Details</a></span></dt>
</dl></dd>
<dt><span class=3D"sect1"><a href=3D"chap-current.html#supping-sources">29.=
12. Supping sources</a></span></dt>
<dt><span class=3D"sect1"><a href=3D"chap-current.html#import-merge">29.13.=
Importing and merging sources.</a></span></dt>
<dt><span class=3D"sect1"><a href=3D"chap-current.html#building-current">29=
=2E14. Building current.</a></span></dt>
<dt><span class=3D"sect1"><a href=3D"chap-current.html#tagging">29.15. Tagg=
ing a successful build</a></span></dt>
<dt><span class=3D"sect1"><a href=3D"chap-current.html#getrepos">29.16. Get=
ting the whole repository</a></span></dt>
<dt><span class=3D"sect1"><a href=3D"chap-current.html#error">29.17. What i=
f I get an error?</a></span></dt>
<dt><span class=3D"sect1"><a href=3D"chap-current.html#etcupdate">29.18. Up=
dating the configuration and startup files with etcupdate(8)</a></span></dt>
<dd><dl>
<dt><span class=3D"sect2"><a href=3D"chap-current.html#etcupdate-overview">=
29.18.1. Overview</a></span></dt>
<dt><span class=3D"sect2"><a href=3D"chap-current.html#using-etcupdate-sour=
ce">29.18.2. Using etcupdate with source files</a></span></dt>
<dt><span class=3D"sect2"><a href=3D"chap-current.html#using-etcupdate-bina=
ry">29.18.3. Using etcupdate with binary distribution sets</a></span></dt>
</dl></dd>
<dt><span class=3D"sect1"><a href=3D"chap-current.html#specific-problems">2=
9.19. Specific problems</a></span></dt>
<dd><dl>
<dt><span class=3D"sect2"><a href=3D"chap-current.html#wscons">29.19.1. Con=
sole dead after updating to wscons</a></span></dt>
<dt><span class=3D"sect2"><a href=3D"chap-current.html#rebuild-nbmake">29.1=
9.2. Why does <code class=3D"filename">build.sh</code> always
rebuild <code class=3D"filename">bmake</code> first?</a></span></dt>
</dl></dd>
</dl>
</div>
<div class=3D"sect1" lang=3D"en">
<div class=3D"titlepage"><div><div><h2 class=3D"title" style=3D"clear: both=
">
<a name=3D"reasons"></a>29.1.=A0Reasons to track NetBSD-current</h2></div><=
/div></div>
<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.=20
</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=3D"http://www.NetBSD.or=
g/Misc/send-pr.html" target=3D"_top">bug reports</a> about the current sour=
ces,
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>
</div>
<div class=3D"sect1" lang=3D"en">
<div class=3D"titlepage"><div><div><h2 class=3D"title" style=3D"clear: both=
">
<a name=3D"installing"></a>29.2.=A0Installing a current snapshot</h2></div>=
</div></div>
<p>
To quickly begin using NetBSD-current,
start with a snapshot generated by the release engineering team.
The current status of each platform can be seen at
<a href=3D"http://releng.NetBSD.org/cgi-bin/builds.cgi" target=3D"_top">
NetBSD Autobuild</a> and the corresponding releases found in
<a href=3D"ftp://ftp.NetBSD.org/pub/NetBSD-daily/HEAD/" target=3D"_top">
ftp://ftp.NetBSD.org/pub/NetBSD-daily/HEAD/</a>
by date and platform.
</p>
<div class=3D"orderedlist"><ol type=3D"1">
<li><p>
Hunt down to the desired <code class=3D"filename">binary/sets/</code> dir=
ectory,
and <strong class=3D"userinput"><code>mget *.tgz</code></strong> the files
into your favorite local administrative directory
(for example, <code class=3D"filename">$HOME/current/</code>);
when limited by disk space /or time,
only the sets <code class=3D"filename">kern-GENERIC</code>, <code class=
=3D"filename">etc</code>,
<code class=3D"filename">base</code>, and <code class=3D"filename">comp</=
code> (if you want a compiler) are
essential.</p></li>
<li>
<p>
Extract the desired <code class=3D"filename">/etc</code> and kernel:
</p>
<pre class=3D"screen">
$ su
# cd /root
# tar -zxpf ~/etc.tgz
# tar -zxpf ~/kern-GENERIC.tgz
# ln -fh /NetBSD /NetBSD.old
# mv NetBSD /NetBSD
n shutdown -r now</pre>
<p>
</p>
</li>
<li>
<p>
Extract the matching <code class=3D"filename">base</code> sets
and any other desirable feature sets:
</p>
<pre class=3D"screen">
$ su
# cd /
# tar -zxpf ~/comp.tgz
# ...
# tar -zxpf ~/base.tgz</pre>
<p>
</p>
</li>
<li>
<p>=20
<a href=3D"#etcupdate" target=3D"_top">Update</a> <code class=3D"filename=
">/etc</code>
as last step: <a href=3D"http://netbsd.gw.com/cgi-bin/man-cgi?postinstall=
+8+NetBSD-current"><span class=3D"citerefentry"><span class=3D"refentrytitl=
e">postinstall</span>(8)</span></a> whill first check and fix most things t=
hat
can be automated, and <a href=3D"http://netbsd.gw.com/cgi-bin/man-cgi?etc=
update+8+NetBSD-current"><span class=3D"citerefentry"><span class=3D"refent=
rytitle">etcupdate</span>(8)</span></a> in the second step will ask on what
to merge:
</p>
<pre class=3D"screen">
# /usr/sbin/postinstall -s /root check
# /usr/sbin/postinstall -s /root fix
# /usr/sbin/etcupdate -b /root
# shutdown -r now</pre>
<p>
</p>
</li>
</ol></div>
<p>
At this point, you are relatively current
and ready to build your own current source.
</p>
</div>
<div class=3D"sect1" lang=3D"en">
<div class=3D"titlepage"><div><div><h2 class=3D"title" style=3D"clear: both=
">
<a name=3D"downloading"></a>29.3.=A0Downloading current source</h2></div></=
div></div>
<p>
Traditionally,
the system source files are kept at <code class=3D"filename">/usr/src/</cod=
e>,
but this generally requires root privileges.
The current <code class=3D"filename">build.sh</code>
process can run entirely unprivileged, although installation still requires=
root privileges.
Whenever examples in this document assume <code class=3D"filename">/usr/src=
/</code>,
you can substitute another location
(such as <code class=3D"filename">$HOME/current/</code>).
</p>
<div class=3D"orderedlist"><ol type=3D"1">
<li>
<p>
Select a location for the source tree:
</p>
<pre class=3D"screen">
$ cd /usr
$ su</pre>
</li>
<li>
<p>Download the -current source from a
<a href=3D"http://www.NetBSD.org/mirrors/" target=3D"_top">NetBSD mirror =
site</a>
near to you:
</p>
<div class=3D"itemizedlist"><ul type=3D"disc">
<li><p>=20
via ftp from <a href=3D"ftp://ftp.NetBSD.org/pub/NetBSD/NetBSD-current/=
tar_files/src/" target=3D"_top">
/pub/NetBSD/NetBSD-current/tar_files/src/</a>,
or</p></li>
<li><p>=20
using <a href=3D"ftp://ftp.NetBSD.org/pub/NetBSD/README.sup" target=3D"=
_top">sup</a>.
</p></li>
</ul></div>
<p>
</p>
<p>These files represent a snapshot of the source tree.
For the most up-to-date files using <a href=3D"#using-anoncvs" target=3D"=
_top">anoncvs</a>,
</p>
<pre class=3D"screen">
$ cd /usr/src
$ cvs -q -d $CVSROOT update -dP</pre>
<p>
The <code class=3D"option">-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=3D"option">-P</code> flag or add i=
t to your=20
<code class=3D"filename">.cvsrc</code> 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=3D"#using-sup-into-cvs" targe=
t=3D"_top">import the
sup changes</a>.</p>
</li>
<li>
<p>
=46ix permissions
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):
</p>
<pre class=3D"screen">
# chown -R <span class=3D"emphasis"><em>user</em></span>:wsrc /usr/src
# chmod -R u=3DrwX,g=3DrwX,o=3DrX /usr/src</pre>
<p>
</p>
</li>
</ol></div>
</div>
<div class=3D"sect1" lang=3D"en">
<div class=3D"titlepage"><div><div><h2 class=3D"title" style=3D"clear: both=
">
<a name=3D"building"></a>29.4.=A0Building a release from source</h2></div><=
/div></div>
<p>
<span class=3D"emphasis"><em>Please remember to check <a href=3D"http://cvs=
web.NetBSD.org/bsdweb.cgi/src/BUILDING" target=3D"_top">src/BUILDING</a>
for the latest changes.</em></span></p>
<p>
Traditionally,
the system object files were kept at=20
<code class=3D"filename">/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=20
<code class=3D"filename">/usr/src/</code>,
you can substitute another location
(such as <code class=3D"filename">$HOME/current</code>).</p>
<div class=3D"orderedlist"><ol type=3D"1">
<li>
<p> Select a location for the object tree,
where there is enough space for a full install,
plus a set of release tarfiles:
</p>
<pre class=3D"screen">
$ cd /usr/src
$ su
# mkdir ../tools
# mkdir ../obj</pre>
</li>
<li>
<p>
From the root of the source tree:
</p>
<pre class=3D"screen">
$ cd /usr/src
$ ./build.sh -O ../obj -T ../tools -u -U release</pre>
<p>
</p>
</li>
</ol></div>
<p>
In this example,
the <code class=3D"option">-u</code> option indicates that a=20
<code class=3D"filename">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=3D"option">-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=3D"filename">build.sh</code> selects (and w=
ill display),
including install media and notes.</p>
<p>
If you wish to cross compile (see <a href=3D"chap-build.html" title=3D"Chap=
ter=A030.=A0Crosscompiling NetBSD with build.sh">Chapter=A030, <i>Crosscomp=
iling NetBSD with <code class=3D"filename">build.sh</code></i></a>)
for a different architecture, include=20
<code class=3D"option">-m MACHINE -a ARCH</code> when running=20
<code class=3D"filename">build.sh</code>.</p>
<p>
=46or more details, run <strong class=3D"userinput"><code>build.sh -h</code=
></strong>
and see <a href=3D"ftp://ftp.NetBSD.org/pub/NetBSD/NetBSD-current/src/BUILD=
ING" target=3D"_top">
/usr/src/BUILDING</a>.</p>
</div>
<div class=3D"sect1" lang=3D"en">
<div class=3D"titlepage"><div><div><h2 class=3D"title" style=3D"clear: both=
">
<a name=3D"updating"></a>29.5.=A0Updating an existing system</h2></div></di=
v></div>
<p>
<span class=3D"emphasis"><em>Please remember to check <a href=3D"http://cvs=
web.NetBSD.org/bsdweb.cgi/src/UPDATING" target=3D"_top">src/UPDATING</a>
for the latest changes.</em></span></p>
<div class=3D"orderedlist"><ol type=3D"1">
<li>
<p> From the root of the source tree:
</p>
<pre class=3D"screen">
$ cd /usr/src</pre>
</li>
<li>
<p>Build the toolchain:
</p>
<pre class=3D"screen">
$ ./build.sh -O ../obj -T ../tools -U -u tools
</pre>
</li>
<li>
<p>Build the distribution:
</p>
<pre class=3D"screen">
$ ./build.sh -O ../obj -T ../tools -U -u distribution
</pre>
</li>
<li>
<p>Build the kernel:
</p>
<pre class=3D"screen">$ ./build.sh -O ../obj -T ../tools -U -u kernel=3DGE=
NERIC
</pre>
</li>
<li>
<p>Install the kernel:
</p>
<pre class=3D"screen">
$ cd ../obj/sys/arch/<ARCH>/compile/GENERIC
$ su
# mv /NetBSD /NetBSD.old
# cp NetBSD /NetBSD</pre>
</li>
<li>
<p>Reboot into the new kernel:
</p>
<pre class=3D"screen">
# shutdown -r now</pre>
</li>
<li>
<p>Install the new userland:
</p>
<pre class=3D"screen">
$ cd /usr/src
$ su
# ./build.sh -O ../obj -T ../tools -U install=3D/
</pre>
</li>
<li>
<p>
Follow the instruction in the output for fixing obsolete files, for exampl=
e:
</p>
<pre class=3D"screen">
# /usr/src/usr.sbin/postinstall/postinstall -s /usr/src -d // fix default=
s mtree obsolete
</pre>
</li>
<li>
<p>
<a href=3D"#etcupdate" target=3D"_top">Update</a> /etc:
</p>
<pre class=3D"screen">
# /usr/sbin/etcupdate -s /usr/src</pre>
</li>
<li>
<p>
Optionally reboot to ensure all running services are using the new binaries:
</p>
<pre class=3D"screen">
# shutdown -r now</pre>
</li>
</ol></div>
<p>
In this example,
the <code class=3D"option">-u</code> option indicates an update process,
and the <code class=3D"option">-U</code> option allows the entire build by
a non-root userfollowed 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>
=46or more details see
<a href=3D"ftp://ftp.NetBSD.org/pub/NetBSD/NetBSD-current/src/UPDATING" tar=
get=3D"_top">
/usr/src/UPDATING</a>.</p>
</div>
<div class=3D"sect1" lang=3D"en">
<div class=3D"titlepage"><div><div><h2 class=3D"title" style=3D"clear: both=
">
<a name=3D"remember"></a>29.6.=A0Things you need to remember</h2></div></di=
v></div>
<div class=3D"itemizedlist"><ul type=3D"disc">
<li><p>
When upgrading to a more recent version of -current you should
<span class=3D"emphasis"><em>always</em></span> compile and boot a new kern=
el before installing any
new libs (<a href=3D"#star" target=3D"_top">*</a>). In general the best app=
roach is to
try the new kernel before anything else, and if you hit any problems see
the entry in the <a href=3D"http://www.NetBSD.org/Documentation/kernel/#pro=
blems_compiling_a_current_kernel" target=3D"_top">
Kernel FAQ</a>.</p></li>
<li><p>
Once the kernel is running, you should have a look at the=20
<a href=3D"ftp://ftp.NetBSD.org/pub/NetBSD/NetBSD-current/src/BUILDING" tar=
get=3D"_top">BUILDING</a>
file at the base of the source tree, and use the <code class=3D"filename">b=
uild.sh</code> script
to build a new userland.</p></li>
<li><p>
When compiling a -current kernel, always remember to include the
<code class=3D"constant">COMPAT_<lastrelease></code> option
(e.g., <code class=3D"constant">COMPAT_16</code>). 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=20
<code class=3D"filename">build.sh</code></p></li>
<li><p>
People using NetBSD-current are strongly encouraged to subscribe to
the <span class=3D"bold"><strong><a href=3D"http://www.NetBSD.org/Mailing=
Lists/#current-users" target=3D"_top">current-users</a></strong></span>
mailing list. The <span class=3D"bold"><strong><a href=3D"http://www.NetB=
SD.org/MailingLists/#source-changes" target=3D"_top">source-changes</a></st=
rong></span>
mailing list is also of interest.</p></li>
</ul></div>
<p><a name=3D"star"></a>
*: Unless you are certain there have been no new
system calls added, but do it anyway; it is safer.</p>
</div>
<div class=3D"sect1" lang=3D"en">
<div class=3D"titlepage"><div><div><h2 class=3D"title" style=3D"clear: both=
">
<a name=3D"build-targets"></a>29.7.=A0What are the various Makefile targets=
?</h2></div></div></div>
<p>
=46or further documentation concerning usage of the new toolchain
through the script <code class=3D"filename">build.sh</code> (in the topleve=
l source directory),
run <strong class=3D"userinput"><code>./build.sh -h</code></strong>,
and see <a href=3D"ftp://ftp.NetBSD.org/pub/NetBSD/NetBSD-current/src/BUILD=
ING" target=3D"_top">
/usr/src/BUILDINT</a>.</p>
<div class=3D"warning" style=3D"margin-left: 0.5in; margin-right: 0.5in;">
<h3 class=3D"title">Warning</h3>
<p>
The usage of <strong class=3D"userinput"><code>make build</code></strong>=
has been deprecated by
the updated toolchain,and is strongly discouraged</p>
</div>
<p>
When you build your system for the first time using <code class=3D"filename=
">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 <strong class=3D"userinput"><code>./build.sh instal=
l =3D/</code></strong>
unless the <strong class=3D"userinput"><code>./build.sh build</code></stron=
g> has succeeded previously or it's
entirely possible to end up with a non-working system.</p>
</div>
<div class=3D"sect1" lang=3D"en">
<div class=3D"titlepage"><div><div><h2 class=3D"title" style=3D"clear: both=
">
<a name=3D"using-anoncvs-pserver"></a>29.8.=A0Using anoncvs</h2></div></div=
></div>
<p><span class=3D"emphasis"><em>
These instructions cover unencrypted anoncvs connections.
If you wish to use encryption protocols,
see <a href=3D"#using-anoncvs-over-ssh" target=3D"_top">below</a>.
</em></span></p>
<div class=3D"orderedlist"><ol type=3D"1">
<li>
<p>Set the <code class=3D"envar">CVSROOT</code> environment variable to poi=
nt to the
<a href=3D"http://www.NetBSD.org/mirrors/#anoncvs" target=3D"_top">anon=
cvs server</a> of your choice:
</p>
<div class=3D"itemizedlist"><ul type=3D"disc">
<li>
<p>
For <a href=3D"http://netbsd.gw.com/cgi-bin/man-cgi?csh+1+NetBSD-curren=
t"><span class=3D"citerefentry"><span class=3D"refentrytitle">csh</span>(1)=
</span></a> or <a href=3D"ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/sh=
ells/tcsh/README.html" target=3D"_top"><code class=3D"filename">shells/tcsh=
</code></a> users:
</p>
<pre class=3D"screen"># setenv CVSROOT :pserver:anoncvs@anoncvs.NetBSD.org:=
/cvsroot
</pre>
</li>
<li>
<p>
For <a href=3D"http://netbsd.gw.com/cgi-bin/man-cgi?sh+1+NetBSD-current=
"><span class=3D"citerefentry"><span class=3D"refentrytitle">sh</span>(1)</=
span></a>, <a href=3D"http://netbsd.gw.com/cgi-bin/man-cgi?ksh+1+NetBSD-cur=
rent"><span class=3D"citerefentry"><span class=3D"refentrytitle">ksh</span>=
(1)</span></a>, or <a href=3D"ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsr=
c/shells/bash2/README.html" target=3D"_top"><code class=3D"filename">shells=
/bash2</code></a> users:
</p>
<pre class=3D"screen">
$ CVSROOT=3D:pserver:anoncvs@anoncvs.NetBSD.org:/cvsroot; export CVSRO=
OT
</pre>
</li>
</ul></div>
<p>
</p>
</li>
<li>
<p>
Continue with:
</p>
<pre class=3D"screen">
$ cd /usr
$ cvs login</pre>
<p>
(use "anoncvs"as password)</p>
</li>
</ol></div>
<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>
</div>
<div class=3D"sect1" lang=3D"en">
<div class=3D"titlepage"><div><div><h2 class=3D"title" style=3D"clear: both=
">
<a name=3D"using-anoncvs-over-ssh"></a>29.9.=A0Using anoncvs over <a href=
=3D"http://netbsd.gw.com/cgi-bin/man-cgi?ssh+1+NetBSD-current"><span class=
=3D"citerefentry"><span class=3D"refentrytitle">ssh</span>(1)</span></a>
</h2></div></div></div>
<p>
The methods described in <a href=3D"#using-anoncvs-pserver" target=3D"_top"=
>using anoncvs</a> can
be used over <a href=3D"http://netbsd.gw.com/cgi-bin/man-cgi?ssh+1+NetBSD-c=
urrent"><span class=3D"citerefentry"><span class=3D"refentrytitle">ssh</spa=
n>(1)</span></a> 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=3D"http://www.NetBSD.org/mirrors/#anoncvs" t=
arget=3D"_top">mirrors</a>
that support ssh connections show the required information with each entry.=
</p>
<p>
In general, remove the <code class=3D"constant">:pserver:</code> prefix on =
the cvsroot,
and set the variable <code class=3D"envar">CVS_RSH</code> to <code class=3D=
"filename">ssh</code>
using the method appropriate for your shell.</p>
</div>
<div class=3D"sect1" lang=3D"en">
<div class=3D"titlepage"><div><div><h2 class=3D"title" style=3D"clear: both=
">
<a name=3D"using-anoncvs"></a>29.10.=A0Tracking NetBSD-current with anoncvs=
</h2></div></div></div>
<div class=3D"sect2" lang=3D"en">
<div class=3D"titlepage"><div><div><h3 class=3D"title">
<a name=3D"setting-up"></a>29.10.1.=A0Setting up</h3></div></div></div>
<div class=3D"itemizedlist"><ul type=3D"disc">
<li>
<p>
To checkout only the kernel sources:
</p>
<pre class=3D"screen">
$ cd /usr
$ cvs checkout -P src/sys</pre>
<p>
This gives you the kernel sources in <code class=3D"filename">/usr/src/sys<=
/code>.
Information on <a href=3D"http://www.NetBSD.org/Documentation/kernel/#how_t=
o_build_a_kernel" target=3D"_top">
how to build a kernel</a> is also available.</p>
</li>
<li>
<p>
Checkout the entire source tree (including kernel)
</p>
<pre class=3D"screen">
$ cd /usr
$ cvs checkout -P src</pre>
<p>
You should now have a full set of NetBSD sources in /usr/src.
</p>
<div class=3D"note" style=3D"margin-left: 0.5in; margin-right: 0.5in;">
<h3 class=3D"title">Note</h3>
<p>
It is almost always faster for a first-time "whole
source" checkout to <a href=3D"#downloading" target=3D"_top">FTP the ta=
rballs</a> and untar
them locally because that makes best use of the network link. After tha=
t,
using cvs checkout/update works to minimize the number of bytes coming =
over
by sending only the changes.</p>
</div>
<p>
</p>
</li>
<li>
<p>
=46ix permissions: If you wish for the source tree to be owned by a non-roo=
t user,
do (as root):
</p>
<pre class=3D"screen">
# chown -R <span class=3D"emphasis"><em>user</em></span> /usr/src
</pre>
</li>
</ul></div>
</div>
<div class=3D"sect2" lang=3D"en">
<div class=3D"titlepage"><div><div><h3 class=3D"title">
<a name=3D"update-sources"></a>29.10.2.=A0To update the sources</h3></div><=
/div></div>
<div class=3D"orderedlist"><ol type=3D"1">
<li>
<p>To update only the kernel sources:
</p>
<pre class=3D"screen">
$ cd /usr/src/sys
$ cvs update -dP</pre>
<p>
</p>
</li>
<li>
<p>To update the entire source tree:
</p>
<pre class=3D"screen">$ cd /usr/src
$ cvs update -dP</pre>
<p>
</p>
</li>
</ol></div>
<div class=3D"note" style=3D"margin-left: 0.5in; margin-right: 0.5in;">
<h3 class=3D"title">Note</h3>
<p>Running <strong class=3D"userinput"><code>cvs checkout -d dir src</code>=
</strong> (or similar commands
with the other src* modules) does not work. You will get error messages sa=
ying:
</p>
<pre class=3D"screen">existing repository ... does not match ...; ignoring =
module _gnusrc-cmp</pre>
<p> etc;
The workaround is to drop the <code class=3D"filename">-d</code> option and=
let <span class=3D"application">cvs</span>
create the default directory.</p>
</div>
</div>
<div class=3D"sect2" lang=3D"en">
<div class=3D"titlepage"><div><div><h3 class=3D"title">
<a name=3D"checkout-by-date"></a>29.10.3.=A0To check out the sources from a=
certain date</h3></div></div></div>
<p>
</p>
<pre class=3D"programlisting">
$ cvs checkout -D 20070301-UTC src</pre>
<p>
</p>
</div>
<div class=3D"sect2" lang=3D"en">
<div class=3D"titlepage"><div><div><h3 class=3D"title">
<a name=3D"checkout-by-branch"></a>29.10.4.=A0To check out the sources from=
a certain branch</h3></div></div></div>
<p>
</p>
<pre class=3D"programlisting">
$ cvs checkout -r NetBSD-3-1 src</pre>
<p>
See
<a href=3D"http://cvsweb.NetBSD.org/bsdweb.cgi/src/doc/BRANCHES?rev=3DHEAD&=
amp;content-type=3Dtext/x-cvsweb-markup" target=3D"_top">src/doc/BRANCHES</=
a>
for a description of the branches in the CVS repository.
</p>
</div>
<div class=3D"sect2" lang=3D"en">
<div class=3D"titlepage"><div><div><h3 class=3D"title">
<a name=3D"hints"></a>29.10.5.=A0Useful hints</h3></div></div></div>
<div class=3D"itemizedlist"><ul type=3D"disc">
<li><p>
Do not use the cvs <code class=3D"option">-z</code> 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.
</p></li>
<li>
<p>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:
</p>
<pre class=3D"programlisting">
$ cd /parent/dir/to/checkout/into
$ mkdir NewName-temp
$ cd NewName-temp
$ cvs checkout ... src
$ mv src ../NewName
$ cd ..
$ rmdir NewName-temp</pre>
<p>
</p>
</li>
<li>
<p>
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:
</p>
<pre class=3D"programlisting">
cvs [update aborted]: could not chdir to gnu/usr.bin/gdb/gdb: Not a direc=
tory
</pre>
<p>
you should do a <strong class=3D"userinput"><code>make cleandir</code></str=
ong> and try again. Make sure to
run <strong class=3D"userinput"><code>make obj</code></strong> after the cv=
s update.
</p>
</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=3D"programlisting">=20
update -dP
checkout -P
diff -u</pre>
<p>
</p>
</li>
</ul></div>
</div>
<div class=3D"sect2" lang=3D"en">
<div class=3D"titlepage"><div><div><h3 class=3D"title">
<a name=3D"building-from-source"></a>29.10.6.=A0Building NetBSD from source=
</h3></div></div></div>
<p>
<span class=3D"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=3D"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=
=3D/
</pre>
<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>
<div class=3D"warning" style=3D"margin-left: 0.5in; margin-right: 0.5in;">
<h3 class=3D"title">Warning</h3>
<p>
Of course, don't invoke <strong class=3D"userinput"><code>./build.sh instal=
l=3D/</code></strong>
unless the <strong class=3D"userinput"><code>./build.sh build</code></stron=
g> has succeeded previously or it's
entirely possible to end up with a non-working system.
</p>
</div>
<p>
To update userland binaries after a CVS update:
</p>
<pre class=3D"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 instal=
l=3D/
</pre>
<p>
These steps 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=3D"emphasis"><em>expert</em></=
span> mode and build
with <code class=3D"envar">DESTDIR=3D/</code> eg:
<strong class=3D"userinput"><code>
# ./build.sh -E -O /usr/obj -T /usr/tools -u build</code></strong>
</p>
<div class=3D"warning" style=3D"margin-left: 0.5in; margin-right: 0.5in;">
<h3 class=3D"title">Warning</h3>
<p>this is for <span class=3D"bold"><strong>expert</strong></span> users on=
ly
and you can very easily render your system into state where it won't be a=
ble
to compile anything anymore. Use only if you are <span class=3D"bold"><st=
rong>sure</strong></span>
the build will finish successfully.</p>
</div>
<p>
</p>
</div>
</div>
<div class=3D"sect1" lang=3D"en">
<div class=3D"titlepage"><div><div><h2 class=3D"title" style=3D"clear: both=
">
<a name=3D"using-sup-into-cvs"></a>29.11.=A0Tracking NetBSD-current with <a=
href=3D"http://netbsd.gw.com/cgi-bin/man-cgi?sup+1+NetBSD-current"><span c=
lass=3D"citerefentry"><span class=3D"refentrytitle">sup</span>(1)</span></a=
> into CVS</h2></div></div></div>
<div class=3D"sect2" lang=3D"en">
<div class=3D"titlepage"><div><div><h3 class=3D"title">
<a name=3D"sup-overview"></a>29.11.1.=A0Overview</h3></div></div></div>
<p>Current can be tracked in the following way: The baseline copy of
the sources is kept up to date using <a href=3D"http://netbsd.gw.com/=
cgi-bin/man-cgi?sup+1+NetBSD-current"><span class=3D"citerefentry"><span cl=
ass=3D"refentrytitle">sup</span>(1)</span></a> 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=3D"orderedlist"><ol type=3D"1">
<li><p>It keeps track of how current changes over time.</p></li>
<li><p>It allows for local changes to be almost automatically merged
into the updated current sources.</p></li>
<li><p>It ensures there is always a clean unmodified copy of the
NetBSD-current source tree is available in case of problems when
building.</p></li>
</ol></div>
<p>
The only downside to this approach is that 3 independent copies=20
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=3D"sect2" lang=3D"en">
<div class=3D"titlepage"><div><div><h3 class=3D"title">
<a name=3D"sup-requirements"></a>29.11.2.=A0Requirements</h3></div></div></=
div>
<div class=3D"itemizedlist"><ul type=3D"disc">
<li><p><a href=3D"http://netbsd.gw.com/cgi-bin/man-cgi?cvs+1+NetBSD-current=
"><span class=3D"citerefentry"><span class=3D"refentrytitle">cvs</span>(1)<=
/span></a> 1.9 or later</p></li>
<li><p><a href=3D"http://netbsd.gw.com/cgi-bin/man-cgi?sup+1+NetBSD-current=
"><span class=3D"citerefentry"><span class=3D"refentrytitle">sup</span>(1)<=
/span></a> installation</p></li>
<li><p>optional: Perl 5 installation (for the supplied script)=20
</p></li>
</ul></div>
</div>
<div class=3D"sect2" lang=3D"en">
<div class=3D"titlepage"><div><div><h3 class=3D"title">
<a name=3D"sup-details"></a>29.11.3.=A0Details</h3></div></div></div>
<p>Tracking and building current consists of 5 phases:
</p>
<div class=3D"orderedlist"><ol type=3D"1">
<li><p>
Supping updated sources into master source tree.</p></li>
<li><p>
Importing supped sources into CVS and updating working copy
of sources.</p></li>
<li><p>
Merging supped sources with local working sources.</p></li>
<li><p>
Building and installing current.</p></li>
<li><p>
Tagging the sources for a successful build in the
repository.</p></li>
</ol></div>
<p>
</p>
</div>
</div>
<div class=3D"sect1" lang=3D"en">
<div class=3D"titlepage"><div><div><h2 class=3D"title" style=3D"clear: both=
">
<a name=3D"supping-sources"></a>29.12.=A0Supping sources</h2></div></div></=
div>
<p>Sources can be supped from any NetBSD sup server and the output=20
from the SUP (man page: <a href=3D"http://netbsd.gw.com/cgi-bin/man-cgi?s=
up+1+NetBSD-current"><span class=3D"citerefentry"><span class=3D"refentryti=
tle">sup</span>(1)</span></a>) should be stored in a file for later referen=
ce.
</p>
</div>
<div class=3D"sect1" lang=3D"en">
<div class=3D"titlepage"><div><div><h2 class=3D"title" style=3D"clear: both=
">
<a name=3D"import-merge"></a>29.13.=A0Importing and merging sources.</h2></=
div></div></div>
<p>Sources are imported as follows:
</p>
<pre class=3D"programlisting">
$ cvs -d /misc/cvsrep import -I ! -I CVS NetBSD NetBSD current-<span cl=
ass=3D"emphasis"><em>date</em></span>
</pre>
<p>
<span class=3D"emphasis"><em>date</em></span> is replaced by the date of th=
e SUP for tracking
purposes. The <code class=3D"filename">-I ! -I CVS</code> options ensure th=
at 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=3D"screen">
$ 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=3D"programlisting">
$ cvs update -j<span class=3D"emphasis"><em>previous import tag</em></spa=
n> -j current-<span class=3D"emphasis"><em>date</em></span>
</pre>
<p>
<span class=3D"emphasis"><em>previous import tag</em></span> should be repl=
aced with the name of
the tag used for the previous cvs import. <span class=3D"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=3D"filename">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><a href=3D"http://netbsd.gw.com/cgi-bin/man-cgi?cvs+1+NetBSD-current"><s=
pan class=3D"citerefentry"><span class=3D"refentrytitle">cvs</span>(1)</spa=
n></a> marks conflicts as follows:
</p>
<pre class=3D"screen">
<<<<<<
<span class=3D"emphasis"><em>code from local file</em></span>
=3D=3D=3D=3D=3D=3D
<span class=3D"emphasis"><em>code from imported file</em></span>
>>>>>> <span class=3D"emphasis"><em>local revision numb=
er 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=3D"filename">/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=3D"filename">/usr/src/NetBSD</code>. The following commands wi=
ll check
out the source and no merge step is required:
</p>
<pre class=3D"programlisting">
$ cd /usr/src
$ cvs -d /misc/cvsrep checkout NetBSD
</pre>
<p>
</p>
</div>
<div class=3D"sect1" lang=3D"en">
<div class=3D"titlepage"><div><div><h2 class=3D"title" style=3D"clear: both=
">
<a name=3D"building-current"></a>29.14.=A0Building current.</h2></div></div=
></div>
<div class=3D"orderedlist"><ol type=3D"1">
<li><p>Configure, <a href=3D"http://www.NetBSD.org/Documentation/kernel/#ho=
w_to_build_a_kernel%20" target=3D"_top">
build</a>, and reboot into a new kernel.</p></li>
<li><p>cd to the base of your -current source tree and type
<strong class=3D"userinput"><code>./build.sh -T /usr/tools -O /usr/obj </co=
de></strong>.
</p></li>
<li><p>You may need to merge in any changes that have been made to files in
/etc.</p></li>
</ol></div>
</div>
<div class=3D"sect1" lang=3D"en">
<div class=3D"titlepage"><div><div><h2 class=3D"title" style=3D"clear: both=
">
<a name=3D"tagging"></a>29.15.=A0Tagging a successful build</h2></div></div=
></div>
<p> If the <a href=3D"#building" target=3D"_top">build</a> completes succes=
sfully,
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=3D"programlisting">$ cvs tag successful-build-<span class=3D"emp=
hasis"><em>build date</em></span>
</pre>
<p>
</p>
<p>Notes:
</p>
<div class=3D"itemizedlist"><ul type=3D"disc">
<li><p>If the NetBSD customised version of CVS, which recognises
<span class=3D"bold"><strong>$Net</strong></span><span class=3D"bold"><st=
rong>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.</p></li>
<li>
<p>The sup/import/merge sequence described above is quite
easily automatable. The following Perl script automates this
process:
</p>
<pre class=3D"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=20
# non-interactive use.
#
# This script has only been test with cvs-1.10.1 and cvs-1.9.18.
#
$SRCROOT=3D"/usr/src/NetBSD";
$IMPORTROOT=3D"/misc/import";
$CVSROOT=3D"/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=20
chdir $IMPORTROOT or die "Could not cd to $IMPORTROOT\n";
($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) =3D localtime;
$date =3D localtime;
$shortdate =3D 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 =3D `cat /usr/src/NetBSD/.tag`; # `s are backquotes
$lastimport =3D~ 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;
</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=20
the same task.</p>
</li>
<li><p>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.</p></li>
</ul></div>
<p>
</p>
</div>
<div class=3D"sect1" lang=3D"en">
<div class=3D"titlepage"><div><div><h2 class=3D"title" style=3D"clear: both=
">
<a name=3D"getrepos"></a>29.16.=A0Getting the whole repository</h2></div></=
div></div>
<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=3D"variablelist"><dl>
<dt><span class=3D"term"><a href=3D"http://netbsd.gw.com/cgi-bin/man-cgi?su=
p+1+NetBSD-current"><span class=3D"citerefentry"><span class=3D"refentrytit=
le">sup</span>(1)</span></a></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:
<strong class=3D"userinput"><code>anoncvs release=3Dall host=3Dsup.NetBSD=
=2Eorg hostbase=3D/ftp/pub base=3D/usr prefix=3D/usr backup use-rel-suffix =
compress
</code></strong>
After that, run <strong class=3D"userinput"><code>sup /path/to/supfile =
anoncvs" to retrieve the files.</code></strong></p>
<p>
Some example sup files are available in <code class=3D"filename">/usr/=
share/examples/supfiles</code>.=20
Also, check our <a href=3D"http://www.NetBSD.org/mirrors/#sup" target=
=3D"_top">list of SUP mirrors</a>
to find the server closest to you!</p>
</dd>
<dt><span class=3D"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=3D"programlisting">
rsync -v -a rsync://anoncvs.NetBSD.org/cvsroot/src .
</pre>
<p>
Please see our <a href=3D"http://www.NetBSD.org/mirrors/#rsync" target=3D=
"_top">list of rsync mirrors</a>!
</p>
</dd>
<dt><span class=3D"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=20
<a href=3D"ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/devel/cvsup/=
README.html" target=3D"_top"><code class=3D"filename">devel/cvsup</code></a=
> package and the=20
following config file:
</p>
<pre class=3D"screen">
*default host=3Dcvsup.de.NetBSD.org
*default base=3D/usr
*default prefix=3D/local/NetBSD-cvs
*default release=3Dcvs
*default delete use-rel-suffix
*default compress
NetBSD</pre>
<p>
Please see our <a href=3D"http://www.NetBSD.org/mirrors/#cvsup" targ=
et=3D"_top">list of CVSup mirrors</a>!
</p>
</dd>
</dl></div>
</div>
<div class=3D"sect1" lang=3D"en">
<div class=3D"titlepage"><div><div><h2 class=3D"title" style=3D"clear: both=
">
<a name=3D"error"></a>29.17.=A0What if I get an error?</h2></div></div></di=
v>
<p>If you try to build -current, either from a snapshot or an earlier
=2Dcurrent, and it doesn't work, don't panic. Try these steps:
</p>
<div class=3D"orderedlist"><ol type=3D"1">
<li><p>
Read the <a href=3D"http://cvsweb.NetBSD.org/bsdweb.cgi/src/UPDATING" tar=
get=3D"_top">UPDATING</a>
file from the release you're trying to build.</p></li>
<li><p>
Read the <a href=3D"http://mail-index.NetBSD.org/current-users/" target=
=3D"_top">current-users
archive</a> for hints.</p></li>
<li><p>
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.</p></li>
<li><p>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=3D"bold"><strong>short</strong></span> script that=
includes the error messages
you're getting. Somebody will probably fix the problem momentarily.
</p></li>
</ol></div>
<p>
</p>
</div>
<div class=3D"sect1" lang=3D"en">
<div class=3D"titlepage"><div><div><h2 class=3D"title" style=3D"clear: both=
">
<a name=3D"etcupdate"></a>29.18.=A0Updating the configuration and startup f=
iles with <a href=3D"http://netbsd.gw.com/cgi-bin/man-cgi?etcupdate+8+NetBS=
D-current"><span class=3D"citerefentry"><span class=3D"refentrytitle">etcup=
date</span>(8)</span></a>
</h2></div></div></div>
<div class=3D"sect2" lang=3D"en">
<div class=3D"titlepage"><div><div><h3 class=3D"title">
<a name=3D"etcupdate-overview"></a>29.18.1.=A0Overview</h3></div></div></di=
v>
<p><code class=3D"filename">etcupdate</code> is a script to help users comp=
are, 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.</p>
</div>
<div class=3D"sect2" lang=3D"en">
<div class=3D"titlepage"><div><div><h3 class=3D"title">
<a name=3D"using-etcupdate-source"></a>29.18.2.=A0Using etcupdate with sour=
ce files</h3></div></div></div>
<p>
In case where the sources are in /usr/src/ the following command should be
enough:
<strong class=3D"userinput"><code>etcupdate</code></strong>
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=3D"programlisting"># etcupdate -s /home/jdoe/NetBSD/src</pre>
<p>
</p>
</div>
<div class=3D"sect2" lang=3D"en">
<div class=3D"titlepage"><div><div><h3 class=3D"title">
<a name=3D"using-etcupdate-binary"></a>29.18.3.=A0Using etcupdate with bina=
ry distribution sets</h3></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=3D"programlisting">
# mkdir /tmp/temproot
# cd /tmp/temproot
# tar xpzf /some/where/etc.tgz
# etcupdate -b /tmp/temproot</pre>
<p>
</p>
</div>
</div>
<div class=3D"sect1" lang=3D"en">
<div class=3D"titlepage"><div><div><h2 class=3D"title" style=3D"clear: both=
">
<a name=3D"specific-problems"></a>29.19.=A0Specific problems</h2></div></di=
v></div>
<div class=3D"sect2" lang=3D"en">
<div class=3D"titlepage"><div><div><h3 class=3D"title">
<a name=3D"wscons"></a>29.19.1.=A0Console dead after updating to wscons</h3=
></div></div></div>
<p>
You should copy a current MAKEDEV from the appropriate etc.<span class=3D"e=
mphasis"><em>port</em></span>
directory in <a href=3D"ftp://ftp.NetBSD.org/pub/NetBSD/NetBSD-current/src/=
etc/" target=3D"_top">src/etc</a>,
into <code class=3D"filename">/dev</code>, boot single user, then type:
</p>
<pre class=3D"programlisting">
# fsck -p
# mount -vt nonfs
# cd /dev
# ./MAKEDEV wscons</pre>
<p>
</p>
</div>
<div class=3D"sect2" lang=3D"en">
<div class=3D"titlepage"><div><div><h3 class=3D"title">
<a name=3D"rebuild-nbmake"></a>29.19.2.=A0Why does <code class=3D"filename"=
>build.sh</code> always
rebuild <code class=3D"filename">bmake</code> first?</h3></div></div></div>
<p>
Even after running <strong class=3D"userinput"><code>./build.sh tools</code=
></strong> and using the <code class=3D"option">-u</code>
flag or specifying <code class=3D"constant">TOOLDIR</code> in <code class=
=3D"filename">/etc/mk.conf</code>,
<code class=3D"filename">nbmake</code> is always rebuilt by <code class=3D"=
filename">build.sh</code>. This is normal.
The reason for this can be found in <code class=3D"filename">/build.sh</cod=
e> itself, in the
function <code class=3D"constant">rebuildmake</code>:
</p>
<pre class=3D"programlisting">=20
# 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=3D"filename">nbmake</code>, y=
ou will need to pass
<code class=3D"option">-T tooldir</code> or set the <code class=3D"envar">T=
OOLDIR</code> variable in the
environment.
</p>
</div>
</div>
</div>
<div class=3D"navfooter">
<hr>
<table width=3D"100%" summary=3D"Navigation footer">
<tr>
<td width=3D"40%" align=3D"left">
<a accesskey=3D"p" href=3D"chap-fetch.html">Prev</a>=A0</td>
<td width=3D"20%" align=3D"center"><a accesskey=3D"u" href=3D"part-compile.=
html">Up</a></td>
<td width=3D"40%" align=3D"right">=A0<a accesskey=3D"n" href=3D"chap-build.=
html">Next</a>
</td>
</tr>
<tr>
<td width=3D"40%" align=3D"left" valign=3D"top">Chapter=A028.=A0Obtaining t=
he sources=A0</td>
<td width=3D"20%" align=3D"center"><a accesskey=3D"h" href=3D"index.html">H=
ome</a></td>
<td width=3D"40%" align=3D"right" valign=3D"top">=A0Chapter=A030.=A0Crossco=
mpiling NetBSD with <code class=3D"filename">build.sh</code>
</td>
</tr>
</table>
</div>
</body>
</html>
--Boundary-00=_atiIGZCIvpe94xD
Content-Type: text/xml;
charset="utf-8";
name="chap-current.xml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="chap-current.xml"
<!-- $&os;: chap-current.xml,v 1.20 2007/04/10 00:01:11 Exp $ -->
<chapter id="chap-current">
<title>Tracking &os;-current</title>
<sect1 id="reasons">
<title>Reasons to track &os;-current</title>
<para>The developers of &os; have made the current development sources
available to the public for several reasons. Overall, providing
&os;-current helps us to create a more stable, accessible system.
</para>
<para>
It makes it easier for people to become involved in the development of
&os;. 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.
</para>
<para>
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.
</para>
<para>
It also allows wider testing of the software as it is developed. Users
of &os;-current are encouraged to send in <ulink
url="http://www.&os;.org/Misc/send-pr.html">bug reports</ulink> 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.
</para>
</sect1>
<!-- ============================================================= -->
<sect1 id="installing">
<title>Installing a current snapshot</title>
<para>
To quickly begin using &os;-current,
start with a snapshot generated by the release engineering team.
The current status of each platform can be seen at
<ulink url="http://releng.&os;.org/cgi-bin/builds.cgi">
&os; Autobuild</ulink> and the corresponding releases found in
<ulink url="ftp://ftp.&os;.org/pub/&os;-daily/HEAD/">
ftp://ftp.&os;.org/pub/&os;-daily/HEAD/</ulink>
by date and platform.
</para>
<orderedlist>
<listitem><para>
Hunt down to the desired <filename>binary/sets/</filename> directory,
and <userinput>mget *.tgz</userinput> the files
into your favorite local administrative directory
(for example, <filename>$HOME/current/</filename>);
when limited by disk space /or time,
only the sets <filename>kern-GENERIC</filename>, <filename>etc</filename>,
<filename>base</filename>, and <filename>comp</filename> (if you want a compiler) are
essential.</para></listitem>
<listitem><para>
Extract the desired <filename>/etc</filename> and kernel:
<screen>
$ su
# cd /root
# tar -zxpf ~/etc.tgz
# tar -zxpf ~/kern-GENERIC.tgz
# ln -fh /&os; /&os;.old
# mv &os; /&os;
n shutdown -r now</screen>
</para></listitem>
<listitem><para>
Extract the matching <filename>base</filename> sets
and any other desirable feature sets:
<screen>
$ su
# cd /
# tar -zxpf ~/comp.tgz
# ...
# tar -zxpf ~/base.tgz</screen>
</para></listitem>
<listitem><para>
<ulink url="#etcupdate">Update</ulink> <filename>/etc</filename>
as last step: &man.postinstall.8; whill first check and fix most things that
can be automated, and &man.etcupdate.8; in the second step will ask on what
to merge:
<screen>
# /usr/sbin/postinstall -s /root check
# /usr/sbin/postinstall -s /root fix
# /usr/sbin/etcupdate -b /root
# shutdown -r now</screen>
</para></listitem>
</orderedlist>
<para>
At this point, you are relatively current
and ready to build your own current source.
</para>
</sect1>
<!-- ============================================================= -->
<sect1 id="downloading">
<title>Downloading current source</title>
<para>
Traditionally,
the system source files are kept at <filename>/usr/src/</filename>,
but this generally requires root privileges.
The current <filename>build.sh</filename>
process can run entirely unprivileged, although installation still requires root privileges.
Whenever examples in this document assume <filename>/usr/src/</filename>,
you can substitute another location
(such as <filename>$HOME/current/</filename>).
</para>
<orderedlist>
<listitem><para>
Select a location for the source tree:
<screen>
$ cd /usr
$ su</screen></para></listitem>
<listitem>
<para>Download the -current source from a
<ulink url="http://www.&os;.org/mirrors/">&os; mirror site</ulink>
near to you:
<itemizedlist>
<listitem><para>
via ftp from <ulink
url="ftp://ftp.&os;.org/pub/&os;/&os;-current/tar_files/src/">
/pub/&os;/&os;-current/tar_files/src/</ulink>,
or</para></listitem>
<listitem><para>
using <ulink url="ftp://ftp.&os;.org/pub/&os;/README.sup">sup</ulink>.
</para></listitem>
</itemizedlist>
</para>
<para>These files represent a snapshot of the source tree.
For the most up-to-date files using <ulink
url="#using-anoncvs">anoncvs</ulink>,
<screen>
$ cd /usr/src
$ cvs -q -d $CVSROOT update -dP</screen></para>
<para>
The <option>-d $CVSROOT</option> is only needed on the first update,
to populate the CVS tags with your selected mirror.
Remember to always use the <option>-P</option> flag or add it to your
<filename>.cvsrc</filename> file.</para>
<para>
If you wish to track local changes to the &os; source you might want
to setup a local CVS tree, and then <ulink url="#using-sup-into-cvs">import the
sup changes</ulink>.</para>
</listitem>
<listitem><para>
Fix permissions
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):
<screen>
# chown -R <emphasis>user</emphasis>:wsrc /usr/src
# chmod -R u=rwX,g=rwX,o=rX /usr/src</screen>
</para></listitem>
</orderedlist>
</sect1>
<!-- ============================================================= -->
<sect1 id="building">
<title>Building a release from source</title>
<para>
<emphasis>Please remember to check <ulink
url="http://cvsweb.&os;.org/bsdweb.cgi/src/BUILDING">src/BUILDING</ulink>
for the latest changes.</emphasis></para>
<para>
Traditionally,
the system object files were kept at
<filename>/usr/obj/</filename>,
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
<filename>/usr/src/</filename>,
you can substitute another location
(such as <filename>$HOME/current</filename>).</para>
<orderedlist>
<listitem><para> Select a location for the object tree,
where there is enough space for a full install,
plus a set of release tarfiles:
<screen>
$ cd /usr/src
$ su
# mkdir ../tools
# mkdir ../obj</screen></para></listitem>
<listitem><para>
From the root of the source tree:
<screen>
$ cd /usr/src
$ ./build.sh -O ../obj -T ../tools -u -U release</screen>
</para></listitem>
</orderedlist>
<para>
In this example,
the <option>-u</option> option indicates that a
<filename>make clean</filename>
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.</para>
<para>
The <option>-U</option> option allows the entire build
by a non-root user.</para>
<para>
When completed,
you should have everything you need to install
in a directory that <filename>build.sh</filename> selects (and will display),
including install media and notes.</para>
<para>
If you wish to cross compile (see <xref linkend="chap-build"/>)
for a different architecture, include
<option>-m MACHINE -a ARCH</option> when running
<filename>build.sh</filename>.</para>
<para>
For more details, run <userinput>build.sh -h</userinput>
and see <ulink url="ftp://ftp.&os;.org/pub/&os;/&os;-current/src/BUILDING">
/usr/src/BUILDING</ulink>.</para>
</sect1>
<!-- ============================================================= -->
<sect1 id="updating">
<title>Updating an existing system</title>
<para>
<emphasis>Please remember to check <ulink
url="http://cvsweb.&os;.org/bsdweb.cgi/src/UPDATING">src/UPDATING</ulink>
for the latest changes.</emphasis></para>
<orderedlist>
<listitem><para> From the root of the source tree:
<screen>
$ cd /usr/src</screen></para></listitem>
<listitem><para>Build the toolchain:
<screen>
$ ./build.sh -O ../obj -T ../tools -U -u tools
</screen></para></listitem>
<listitem><para>Build the distribution:
<screen>
$ ./build.sh -O ../obj -T ../tools -U -u distribution
</screen></para></listitem>
<listitem><para>Build the kernel:
<screen>$ ./build.sh -O ../obj -T ../tools -U -u kernel=GENERIC
</screen></para></listitem>
<listitem><para>Install the kernel:
<screen>
$ cd ../obj/sys/arch/<ARCH>/compile/GENERIC
$ su
# mv /&os; /&os;.old
# cp &os; /&os;</screen></para></listitem>
<listitem><para>Reboot into the new kernel:
<screen>
# shutdown -r now</screen></para></listitem>
<listitem><para>Install the new userland:
<screen>
$ cd /usr/src
$ su
# ./build.sh -O ../obj -T ../tools -U install=/
</screen></para></listitem>
<listitem><para>
Follow the instruction in the output for fixing obsolete files, for example:
<screen>
# /usr/src/usr.sbin/postinstall/postinstall -s /usr/src -d // fix defaults mtree obsolete
</screen></para></listitem>
<listitem><para>
<ulink url="#etcupdate">Update</ulink> /etc:
<screen>
# /usr/sbin/etcupdate -s /usr/src</screen></para></listitem>
<listitem><para>
Optionally reboot to ensure all running services are using the new binaries:
<screen>
# shutdown -r now</screen></para></listitem>
</orderedlist>
<para>
In this example,
the <option>-u</option> option indicates an update process,
and the <option>-U</option> option allows the entire build by
a non-root userfollowed with an install by root.</para>
<para>
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.</para>
<para>
For more details see
<ulink url="ftp://ftp.&os;.org/pub/&os;/&os;-current/src/UPDATING">
/usr/src/UPDATING</ulink>.</para>
</sect1>
<!-- ============================================================= -->
<sect1 id="remember">
<title>Things you need to remember</title>
<itemizedlist>
<listitem><para>
When upgrading to a more recent version of -current you should
<emphasis>always</emphasis> compile and boot a new kernel before installing any
new libs (<ulink url="#star">*</ulink>). 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 <ulink url="http://www.&os;.org/Documentation/kernel/#problems_compiling_a_current_kernel">
Kernel FAQ</ulink>.</para></listitem>
<listitem><para>
Once the kernel is running, you should have a look at the
<ulink url="ftp://ftp.&os;.org/pub/&os;/&os;-current/src/BUILDING">BUILDING</ulink>
file at the base of the source tree, and use the <filename>build.sh</filename> script
to build a new userland.</para></listitem>
<listitem><para>
When compiling a -current kernel, always remember to include the
<constant>COMPAT_<lastrelease></constant> option
(e.g., <constant>COMPAT_16</constant>). 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
<filename>build.sh</filename></para></listitem>
<listitem><para>
People using &os;-current are strongly encouraged to subscribe to
the <emphasis role="bold"><ulink
url="http://www.&os;.org/MailingLists/#current-users">current-users</ulink></emphasis>
mailing list. The <emphasis role="bold"><ulink
url="http://www.&os;.org/MailingLists/#source-changes">source-changes</ulink></emphasis>
mailing list is also of interest.</para></listitem>
</itemizedlist>
<para id="star">
*: Unless you are certain there have been no new
system calls added, but do it anyway; it is safer.</para>
</sect1>
<!-- ============================================================= -->
<sect1 id="build-targets">
<title>What are the various Makefile targets?</title>
<para>
For further documentation concerning usage of the new toolchain
through the script <filename>build.sh</filename> (in the toplevel source directory),
run <userinput>./build.sh -h</userinput>,
and see <ulink url="ftp://ftp.&os;.org/pub/&os;/&os;-current/src/BUILDING">
/usr/src/BUILDINT</ulink>.</para>
<warning><para>
The usage of <userinput>make build</userinput> has been deprecated by
the updated toolchain,and is strongly discouraged</para></warning>
<para>
When you build your system for the first time using <filename>build.sh</filename>,
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.</para>
<para>
Of course, don't invoke <userinput>./build.sh install =/</userinput>
unless the <userinput>./build.sh build</userinput> has succeeded previously or it's
entirely possible to end up with a non-working system.</para>
</sect1>
<!-- ============================================================= -->
<sect1 id="using-anoncvs-pserver">
<title>Using anoncvs</title>
<para><emphasis>
These instructions cover unencrypted anoncvs connections.
If you wish to use encryption protocols,
see <ulink url="#using-anoncvs-over-ssh">below</ulink>.
</emphasis></para>
<orderedlist>
<listitem><para>Set the <envar>CVSROOT</envar> environment variable to point to the
<ulink url="http://www.&os;.org/mirrors/#anoncvs">anoncvs server</ulink> of your choice:
<itemizedlist>
<listitem><para>
For &man.csh.1; or <filename
role="pkg">shells/tcsh</filename> users:
<screen># setenv CVSROOT :pserver:anoncvs@anoncvs.&os;.org:/cvsroot
</screen></para></listitem>
<listitem><para>
For &man.sh.1;, &man.ksh.1;, or <filename
role="pkg">shells/bash2</filename> users:
<screen>
$ CVSROOT=:pserver:anoncvs@anoncvs.&os;.org:/cvsroot; export CVSROOT
</screen></para></listitem>
</itemizedlist>
</para></listitem>
<listitem><para>
Continue with:
<screen>
$ cd /usr
$ cvs login</screen>
(use "anoncvs"as password)</para></listitem>
</orderedlist>
<para>
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.</para>
</sect1>
<!-- ============================================================= -->
<sect1 id="using-anoncvs-over-ssh">
<title>Using anoncvs over &man.ssh.1;</title>
<para>
The methods described in <ulink url="#using-anoncvs-pserver">using anoncvs</ulink> can
be used over &man.ssh.1; to ensure the integrity of the sources you receive.
However,this adds substantial overhead to the anoncvs servers.</para>
<para>
Those servers in the <ulink url="http://www.&os;.org/mirrors/#anoncvs">mirrors</ulink>
that support ssh connections show the required information with each entry.</para>
<para>
In general, remove the <constant>:pserver:</constant> prefix on the cvsroot,
and set the variable <envar>CVS_RSH</envar> to <filename>ssh</filename>
using the method appropriate for your shell.</para>
</sect1>
<!-- ============================================================= -->
<sect1 id="using-anoncvs">
<title>Tracking &os;-current with anoncvs</title>
<!-- ........................................................... -->
<sect2 id="setting-up"><title>Setting up</title>
<itemizedlist>
<listitem><para>
To checkout only the kernel sources:
<screen>
$ cd /usr
$ cvs checkout -P src/sys</screen>
This gives you the kernel sources in <filename>/usr/src/sys</filename>.
Information on <ulink url="http://www.&os;.org/Documentation/kernel/#how_to_build_a_kernel">
how to build a kernel</ulink> is also available.</para></listitem>
<listitem><para>
Checkout the entire source tree (including kernel)
<screen>
$ cd /usr
$ cvs checkout -P src</screen>
You should now have a full set of &os; sources in /usr/src.
<note><para>
It is almost always faster for a first-time "whole
source" checkout to <ulink url="#downloading">FTP the tarballs</ulink> 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.</para></note>
</para></listitem>
<listitem><para>
Fix permissions: If you wish for the source tree to be owned by a non-root user,
do (as root):
<screen>
# chown -R <emphasis>user</emphasis> /usr/src
</screen></para></listitem>
</itemizedlist>
</sect2>
<!-- ........................................................... -->
<sect2 id="update-sources">
<title>To update the sources</title>
<orderedlist>
<listitem><para>To update only the kernel sources:
<screen>
$ cd /usr/src/sys
$ cvs update -dP</screen>
</para></listitem>
<listitem><para>To update the entire source tree:
<screen>$ cd /usr/src
$ cvs update -dP</screen>
</para></listitem>
</orderedlist>
<note>
<para>Running <userinput>cvs checkout -d dir src</userinput> (or similar commands
with the other src* modules) does not work. You will get error messages saying:
<screen>existing repository ... does not match ...; ignoring module _gnusrc-cmp</screen> etc;
The workaround is to drop the <filename>-d</filename> option and let <application>cvs</application>
create the default directory.</para></note>
</sect2>
<!-- ........................................................... -->
<sect2 id="checkout-by-date">
<title>To check out the sources from a certain date</title>
<para>
<programlisting>
$ cvs checkout -D 20070301-UTC src</programlisting>
</para>
</sect2>
<!-- ........................................................... -->
<sect2 id="checkout-by-branch">
<title>To check out the sources from a certain branch</title>
<para>
<programlisting>
$ cvs checkout -r &os;-3-1 src</programlisting>
See
<ulink url="http://cvsweb.&os;.org/bsdweb.cgi/src/doc/BRANCHES?rev=HEAD&content-type=text/x-cvsweb-markup">src/doc/BRANCHES</ulink>
for a description of the branches in the CVS repository.
</para>
</sect2>
<!-- ........................................................... -->
<sect2 id="hints">
<title>Useful hints</title>
<itemizedlist>
<listitem><para>
Do not use the cvs <option>-z</option> 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.
</para></listitem>
<listitem><para>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:
<programlisting>
$ cd /parent/dir/to/checkout/into
$ mkdir NewName-temp
$ cd NewName-temp
$ cvs checkout ... src
$ mv src ../NewName
$ cd ..
$ rmdir NewName-temp</programlisting>
</para></listitem>
<listitem><para>
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:
<programlisting>
cvs [update aborted]: could not chdir to gnu/usr.bin/gdb/gdb: Not a directory
</programlisting>
you should do a <userinput>make cleandir</userinput> and try again. Make sure to
run <userinput>make obj</userinput> after the cvs update.
</para></listitem>
<listitem><para>
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:
<programlisting>
update -dP
checkout -P
diff -u</programlisting>
</para></listitem>
</itemizedlist>
</sect2>
<!-- ........................................................... -->
<sect2 id="building-from-source">
<title>Building &os; from source</title>
<para>
<emphasis>(Assuming you have an up-to-date &os; binary
snapshot, and source in /usr/src/, on your machine already; further
assuming your BSDOBJDIR should be /usr/obj/):</emphasis></para>
<para>
To build userland the first time:
<programlisting>
# mkdir /usr/obj
# cd /usr/src
# ./build.sh -O /usr/obj -D /usr/&os;-new-build -T /usr/tools build
# ./build.sh -O /usr/obj -D /usr/&os;-new-build -T /usr/tools install=/
</programlisting></para>
<para>
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.</para>
<warning><para>
Of course, don't invoke <userinput>./build.sh install=/</userinput>
unless the <userinput>./build.sh build</userinput> has succeeded previously or it's
entirely possible to end up with a non-working system.
</para></warning>
<para>
To update userland binaries after a CVS update:
<programlisting># cd /usr/src
# ./build.sh -D /usr/&os;-new-build -O /usr/obj -T /usr/tools -u build
# ./build.sh -D /usr/&os;-new-build -O /usr/obj -T /usr/tools -u install=/
</programlisting>
These steps will install the new binaries on the running system. Reboot to make
sure they all take effect.</para>
<para>
If you update system frequently and want the build to directly update
your running system, you can use <emphasis>expert</emphasis> mode and build
with <envar>DESTDIR=/</envar> eg:
<userinput>
# ./build.sh -E -O /usr/obj -T /usr/tools -u build</userinput>
<warning><para>this is for <emphasis role="bold">expert</emphasis> 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 <emphasis role="bold">sure</emphasis>
the build will finish successfully.</para></warning>
</para>
</sect2>
</sect1>
<!-- ============================================================= -->
<sect1 id="using-sup-into-cvs">
<title>Tracking &os;-current with &man.sup.1; into CVS</title>
<!-- ........................................................... -->
<sect2 id="sup-overview">
<title>Overview</title>
<para>Current can be tracked in the following way: The baseline copy of
the sources is kept up to date using &man.sup.1; 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.</para>
<para>There are 3 major reasons for this approach
<orderedlist>
<listitem><para>It keeps track of how current changes over time.</para></listitem>
<listitem><para>It allows for local changes to be almost automatically merged
into the updated current sources.</para></listitem>
<listitem><para>It ensures there is always a clean unmodified copy of the
&os;-current source tree is available in case of problems when
building.</para></listitem>
</orderedlist>
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.</para>
</sect2>
<!-- ........................................................... -->
<sect2 id="sup-requirements">
<title>Requirements</title>
<itemizedlist>
<listitem><para>&man.cvs.1; 1.9 or later</para></listitem>
<listitem><para>&man.sup.1; installation</para></listitem>
<listitem><para>optional: Perl 5 installation (for the supplied script)
</para></listitem>
</itemizedlist>
</sect2>
<!-- ........................................................... -->
<sect2 id="sup-details">
<title>Details</title>
<para>Tracking and building current consists of 5 phases:
<orderedlist>
<listitem><para>
Supping updated sources into master source tree.</para></listitem>
<listitem><para>
Importing supped sources into CVS and updating working copy
of sources.</para></listitem>
<listitem><para>
Merging supped sources with local working sources.</para></listitem>
<listitem><para>
Building and installing current.</para></listitem>
<listitem><para>
Tagging the sources for a successful build in the
repository.</para></listitem>
</orderedlist>
</para>
</sect2>
</sect1>
<!-- ============================================================= -->
<sect1 id="supping-sources">
<title>Supping sources</title>
<para>Sources can be supped from any &os; sup server and the output
from the SUP (man page: &man.sup.1;) should be stored in a file for later reference.
</para></sect1>
<!-- ============================================================= -->
<sect1 id="import-merge">
<title>Importing and merging sources.</title>
<para>Sources are imported as follows:
<programlisting>
$ cvs -d /misc/cvsrep import -I ! -I CVS &os; &os; current-<emphasis>date</emphasis>
</programlisting>
<emphasis>date</emphasis> is replaced by the date of the SUP for tracking
purposes. The <filename>-I ! -I CVS</filename> options ensure that no file in
the source tree is ignored except 'CVS' directories. This is because
some &os; 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:
<screen>
$ cvs checkout -j&os;:yesterday -j&os; &os;</screen>
This merge command will correctly merge the imported &os;
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:
<programlisting>
$ cvs update -j<emphasis>previous import tag</emphasis> -j current-<emphasis>date</emphasis>
</programlisting>
<emphasis>previous import tag</emphasis> should be replaced with the name of
the tag used for the previous cvs import. <emphasis>date</emphasis> should be
replaced with the current date to yield the same tag used on
the current import that has just been merged.
</para>
<para>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 <filename>C</filename>
followed by a filename.</para>
<para>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 &os; source code.</para>
<para>&man.cvs.1; marks conflicts as follows:
<screen>
<<<<<<
<emphasis>code from local file</emphasis>
======
<emphasis>code from imported file</emphasis>
>>>>>> <emphasis>local revision number of newly imported revision</emphasis>
</screen></para>
<para>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.</para>
<para> All update and checkout commands should be done in the
directory where the sources have been checked out. On my system
this is <filename>/usr/src/&os;</filename>.</para>
<para>If this is the first import then there will be no sources
checked out. Assuming you wish to create the source tree in
<filename>/usr/src/&os;</filename>. The following commands will check
out the source and no merge step is required:
<programlisting>
$ cd /usr/src
$ cvs -d /misc/cvsrep checkout &os;
</programlisting>
</para>
</sect1>
<!-- ============================================================= -->
<sect1 id="building-current">
<title>Building current.</title>
<orderedlist>
<listitem><para>Configure, <ulink
url="http://www.&os;.org/Documentation/kernel/#how_to_build_a_kernel ">
build</ulink>, and reboot into a new kernel.</para></listitem>
<listitem><para>cd to the base of your -current source tree and type
<userinput>./build.sh -T /usr/tools -O /usr/obj </userinput>.
</para></listitem>
<listitem><para>You may need to merge in any changes that have been made to files in
/etc.</para></listitem>
</orderedlist>
</sect1>
<!-- ============================================================= -->
<sect1 id="tagging">
<title>Tagging a successful build</title>
<para> If the <ulink url="#building">build</ulink> 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:
<programlisting>$ cvs tag successful-build-<emphasis>build date</emphasis>
</programlisting>
</para>
<para>Notes:
<itemizedlist>
<listitem><para>If the &os; customised version of CVS, which recognises
<emphasis role="bold">$Net</emphasis><emphasis role="bold">BSD$</emphasis> markers in files, is not used, the
&os; revision number of the file is available for reference
purposes when build problems occur.</para></listitem>
<listitem><para>The sup/import/merge sequence described above is quite
easily automatable. The following Perl script automates this
process:
<programlisting>
#!/usr/pkg/bin/perl
#
# Script to SUP &os;-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/&os;";
$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\" &os; &os; current-$shortdate ";
# make the working directory the local &os; Tree
chdir $SRCROOT or die "Could not change to $SRCROOT directory\n";
# Now do the import.
$lastimport = `cat /usr/src/&os;/.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;
</programlisting>
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.</para></listitem>
<listitem><para>Techniques for tracking current with CVS have been discuss several
times on the &os; current-users mailing list. For
alternative techniques try searching the &os; mailing lists.</para></listitem>
</itemizedlist>
</para>
</sect1>
<!-- ============================================================= -->
<sect1 id="getrepos">
<title>Getting the whole repository</title>
<para>
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 &os;. If you don't want to maintain your
own CVS repository, but just want to mirror &os;'s CVS repository,
there are three ways to do so.</para>
<para>
Each of the methods described briefly below will get you a copy
of the &os; 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.</para>
<para>
The methods to retrieve the whole repository are:</para>
<variablelist>
<varlistentry><term>&man.sup.1;</term>
<listitem><para>
If you use sup already to mirror other parts of the &os; source,
you will want to add the following lines to your sup config file:
<userinput>anoncvs release=all host=sup.&os;.org hostbase=/ftp/pub base=/usr prefix=/usr backup use-rel-suffix compress
</userinput>
After that, run <userinput>sup /path/to/supfile anoncvs" to retrieve the files.</userinput></para>
<para>
Some example sup files are available in <filename>/usr/share/examples/supfiles</filename>.
Also, check our <ulink url="http://www.&os;.org/mirrors/#sup">list of SUP mirrors</ulink>
to find the server closest to you!</para>
</listitem>
</varlistentry>
<varlistentry><term>rsync</term>
<listitem><para>
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:
<programlisting>
rsync -v -a rsync://anoncvs.&os;.org/cvsroot/src .
</programlisting>
Please see our <ulink url="http://www.&os;.org/mirrors/#rsync">list of rsync mirrors</ulink>!
</para></listitem>
</varlistentry>
<varlistentry>
<term>cvsup</term>
<listitem><para>CVSup is not currently available for all &os; architectures, since the M3
compiler has not been ported. On i386, you can mirror the repository
from cvsup.de.&os;.org with the
<filename role="pkg">devel/cvsup</filename> package and the
following config file:
<screen>
*default host=cvsup.de.&os;.org
*default base=/usr
*default prefix=/local/&os;-cvs
*default release=cvs
*default delete use-rel-suffix
*default compress
&os;</screen>
Please see our <ulink
url="http://www.&os;.org/mirrors/#cvsup">list of CVSup mirrors</ulink>!
</para></listitem>
</varlistentry>
</variablelist>
</sect1>
<!-- ============================================================= -->
<sect1 id="error">
<title>What if I get an error?</title>
<para>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:
<orderedlist>
<listitem><para>
Read the <ulink
url="http://cvsweb.&os;.org/bsdweb.cgi/src/UPDATING">UPDATING</ulink>
file from the release you're trying to build.</para></listitem>
<listitem><para>
Read the <ulink
url="http://mail-index.&os;.org/current-users/">current-users
archive</ulink> for hints.</para></listitem>
<listitem><para>
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.</para></listitem>
<listitem><para>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 <emphasis role="bold">short</emphasis> script that includes the error messages
you're getting. Somebody will probably fix the problem momentarily.
</para></listitem>
</orderedlist>
</para>
</sect1>
<!-- ============================================================= -->
<sect1 id="etcupdate">
<title>Updating the configuration and startup files with &man.etcupdate.8;</title>
<!-- ........................................................... -->
<sect2 id="etcupdate-overview"><title>Overview</title>
<para><filename>etcupdate</filename> 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.</para>
</sect2>
<!-- ........................................................... -->
<sect2 id="using-etcupdate-source">
<title>Using etcupdate with source files</title>
<para>
In case where the sources are in /usr/src/ the following command should be
enough:
<userinput>etcupdate</userinput>
But what if your &os; sources are in an alternative location, such as
in /home/jdoe/&os;/src? Don't worry, tell etcupdate the location of
your source tree with -s srcdir and it will work just fine:
<programlisting># etcupdate -s /home/jdoe/&os;/src</programlisting>
</para>
</sect2>
<!-- ........................................................... -->
<sect2 id="using-etcupdate-binary">
<title>Using etcupdate with binary distribution sets</title>
<para>
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.
<programlisting>
# mkdir /tmp/temproot
# cd /tmp/temproot
# tar xpzf /some/where/etc.tgz
# etcupdate -b /tmp/temproot</programlisting>
</para>
</sect2>
</sect1>
<!-- ============================================================= -->
<sect1 id="specific-problems">
<title>Specific problems</title>
<!-- ........................................................... -->
<sect2 id="wscons">
<title>Console dead after updating to wscons</title>
<para>
You should copy a current MAKEDEV from the appropriate etc.<emphasis>port</emphasis>
directory in <ulink
url="ftp://ftp.&os;.org/pub/&os;/&os;-current/src/etc/">src/etc</ulink>,
into <filename>/dev</filename>, boot single user, then type:
<programlisting>
# fsck -p
# mount -vt nonfs
# cd /dev
# ./MAKEDEV wscons</programlisting>
</para>
</sect2>
<!-- ........................................................... -->
<sect2 id="rebuild-nbmake">
<title>Why does <filename>build.sh</filename> always
rebuild <filename>bmake</filename> first?</title>
<para>
Even after running <userinput>./build.sh tools</userinput> and using the <option>-u</option>
flag or specifying <constant>TOOLDIR</constant> in <filename>/etc/mk.conf</filename>,
<filename>nbmake</filename> is always rebuilt by <filename>build.sh</filename>. This is normal.
The reason for this can be found in <filename>/build.sh</filename> itself, in the
function <constant>rebuildmake</constant>:
<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.
#</programlisting>
So, if you do not want to rebuild <filename>nbmake</filename>, you will need to pass
<option>-T tooldir</option> or set the <envar>TOOLDIR</envar> variable in the
environment.
</para>
</sect2>
</sect1>
</chapter>
--Boundary-00=_atiIGZCIvpe94xD
Content-Type: text/x-diff;
charset="utf-8";
name="current.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="current.diff"
Index: guide/en/Makefile
===================================================================
RCS file: /cvsroot/htdocs/guide/en/Makefile,v
retrieving revision 1.32
diff -u -r1.32 Makefile
--- guide/en/Makefile 17 Sep 2006 22:37:48 -0000 1.32
+++ guide/en/Makefile 15 Apr 2007 13:02:57 -0000
@@ -18,6 +18,7 @@
SRCS+= chap-ccd.xml
SRCS+= chap-cgd.xml
SRCS+= chap-cons.xml
+SRCS+= chap-current.xml
SRCS+= chap-dns.xml
SRCS+= chap-edit.xml
SRCS+= chap-exinst.xml
Index: guide/en/chap-current.xml
===================================================================
RCS file: guide/en/chap-current.xml
diff -N guide/en/chap-current.xml
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ guide/en/chap-current.xml 15 Apr 2007 13:03:14 -0000
@@ -0,0 +1,1196 @@
+<!-- $&os;: chap-current.xml,v 1.20 2007/04/10 00:01:11 Exp $ -->
+
+<chapter id="chap-current">
+ <title>Tracking &os;-current</title>
+
+
+<sect1 id="reasons">
+<title>Reasons to track &os;-current</title>
+
+<para>The developers of &os; have made the current development sources
+available to the public for several reasons. Overall, providing
+&os;-current helps us to create a more stable, accessible system.
+</para>
+
+<para>
+It makes it easier for people to become involved in the development of
+&os;. 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.
+</para>
+
+<para>
+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.
+</para>
+
+<para>
+It also allows wider testing of the software as it is developed. Users
+of &os;-current are encouraged to send in <ulink
+url="http://www.&os;.org/Misc/send-pr.html">bug reports</ulink> 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.
+</para>
+</sect1>
+
+<!-- ============================================================= -->
+
+<sect1 id="installing">
+<title>Installing a current snapshot</title>
+
+<para>
+To quickly begin using &os;-current,
+start with a snapshot generated by the release engineering team.
+The current status of each platform can be seen at
+<ulink url="http://releng.&os;.org/cgi-bin/builds.cgi">
+&os; Autobuild</ulink> and the corresponding releases found in
+<ulink url="ftp://ftp.&os;.org/pub/&os;-daily/HEAD/">
+ftp://ftp.&os;.org/pub/&os;-daily/HEAD/</ulink>
+by date and platform.
+</para>
+
+<orderedlist>
+
+ <listitem><para>
+ Hunt down to the desired <filename>binary/sets/</filename> directory,
+ and <userinput>mget *.tgz</userinput> the files
+ into your favorite local administrative directory
+ (for example, <filename>$HOME/current/</filename>);
+ when limited by disk space /or time,
+ only the sets <filename>kern-GENERIC</filename>, <filename>etc</filename>,
+ <filename>base</filename>, and <filename>comp</filename> (if you want a compiler) are
+ essential.</para></listitem>
+
+ <listitem><para>
+ Extract the desired <filename>/etc</filename> and kernel:
+ <screen>
+ $ su
+ # cd /root
+ # tar -zxpf ~/etc.tgz
+ # tar -zxpf ~/kern-GENERIC.tgz
+ # ln -fh /&os; /&os;.old
+ # mv &os; /&os;
+ n shutdown -r now</screen>
+ </para></listitem>
+
+ <listitem><para>
+ Extract the matching <filename>base</filename> sets
+ and any other desirable feature sets:
+ <screen>
+ $ su
+ # cd /
+ # tar -zxpf ~/comp.tgz
+ # ...
+ # tar -zxpf ~/base.tgz</screen>
+ </para></listitem>
+
+ <listitem><para>
+ <ulink url="#etcupdate">Update</ulink> <filename>/etc</filename>
+ as last step: &man.postinstall.8; whill first check and fix most things that
+ can be automated, and &man.etcupdate.8; in the second step will ask on what
+ to merge:
+ <screen>
+ # /usr/sbin/postinstall -s /root check
+ # /usr/sbin/postinstall -s /root fix
+ # /usr/sbin/etcupdate -b /root
+ # shutdown -r now</screen>
+ </para></listitem>
+
+</orderedlist>
+
+<para>
+At this point, you are relatively current
+and ready to build your own current source.
+</para>
+
+</sect1>
+
+<!-- ============================================================= -->
+
+<sect1 id="downloading">
+<title>Downloading current source</title>
+
+<para>
+Traditionally,
+the system source files are kept at <filename>/usr/src/</filename>,
+but this generally requires root privileges.
+The current <filename>build.sh</filename>
+process can run entirely unprivileged, although installation still requires root privileges.
+Whenever examples in this document assume <filename>/usr/src/</filename>,
+you can substitute another location
+(such as <filename>$HOME/current/</filename>).
+</para>
+
+<orderedlist>
+
+<listitem><para>
+Select a location for the source tree:
+ <screen>
+ $ cd /usr
+ $ su</screen></para></listitem>
+
+<listitem>
+<para>Download the -current source from a
+ <ulink url="http://www.&os;.org/mirrors/">&os; mirror site</ulink>
+near to you:
+ <itemizedlist>
+
+ <listitem><para>
+ via ftp from <ulink
+ url="ftp://ftp.&os;.org/pub/&os;/&os;-current/tar_files/src/">
+ /pub/&os;/&os;-current/tar_files/src/</ulink>,
+ or</para></listitem>
+
+ <listitem><para>
+ using <ulink url="ftp://ftp.&os;.org/pub/&os;/README.sup">sup</ulink>.
+ </para></listitem>
+
+ </itemizedlist>
+</para>
+
+<para>These files represent a snapshot of the source tree.
+ For the most up-to-date files using <ulink
+ url="#using-anoncvs">anoncvs</ulink>,
+ <screen>
+ $ cd /usr/src
+ $ cvs -q -d $CVSROOT update -dP</screen></para>
+
+ <para>
+ The <option>-d $CVSROOT</option> is only needed on the first update,
+ to populate the CVS tags with your selected mirror.
+ Remember to always use the <option>-P</option> flag or add it to your
+ <filename>.cvsrc</filename> file.</para>
+
+ <para>
+ If you wish to track local changes to the &os; source you might want
+ to setup a local CVS tree, and then <ulink url="#using-sup-into-cvs">import the
+ sup changes</ulink>.</para>
+
+</listitem>
+
+<listitem><para>
+Fix permissions
+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):
+ <screen>
+ # chown -R <emphasis>user</emphasis>:wsrc /usr/src
+ # chmod -R u=rwX,g=rwX,o=rX /usr/src</screen>
+</para></listitem>
+
+</orderedlist>
+
+</sect1>
+
+<!-- ============================================================= -->
+
+<sect1 id="building">
+<title>Building a release from source</title>
+
+<para>
+<emphasis>Please remember to check <ulink
+url="http://cvsweb.&os;.org/bsdweb.cgi/src/BUILDING">src/BUILDING</ulink>
+for the latest changes.</emphasis></para>
+
+<para>
+Traditionally,
+the system object files were kept at
+<filename>/usr/obj/</filename>,
+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
+<filename>/usr/src/</filename>,
+you can substitute another location
+(such as <filename>$HOME/current</filename>).</para>
+
+
+<orderedlist>
+
+<listitem><para> Select a location for the object tree,
+where there is enough space for a full install,
+plus a set of release tarfiles:
+ <screen>
+ $ cd /usr/src
+ $ su
+ # mkdir ../tools
+ # mkdir ../obj</screen></para></listitem>
+
+<listitem><para>
+ From the root of the source tree:
+ <screen>
+ $ cd /usr/src
+ $ ./build.sh -O ../obj -T ../tools -u -U release</screen>
+</para></listitem>
+
+</orderedlist>
+
+
+<para>
+In this example,
+the <option>-u</option> option indicates that a
+<filename>make clean</filename>
+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.</para>
+
+
+<para>
+The <option>-U</option> option allows the entire build
+by a non-root user.</para>
+
+
+<para>
+When completed,
+you should have everything you need to install
+in a directory that <filename>build.sh</filename> selects (and will display),
+including install media and notes.</para>
+
+
+<para>
+If you wish to cross compile (see <xref linkend="chap-build"/>)
+for a different architecture, include
+<option>-m MACHINE -a ARCH</option> when running
+<filename>build.sh</filename>.</para>
+
+
+<para>
+For more details, run <userinput>build.sh -h</userinput>
+and see <ulink url="ftp://ftp.&os;.org/pub/&os;/&os;-current/src/BUILDING">
+/usr/src/BUILDING</ulink>.</para>
+
+</sect1>
+
+<!-- ============================================================= -->
+
+<sect1 id="updating">
+<title>Updating an existing system</title>
+
+<para>
+<emphasis>Please remember to check <ulink
+url="http://cvsweb.&os;.org/bsdweb.cgi/src/UPDATING">src/UPDATING</ulink>
+for the latest changes.</emphasis></para>
+
+<orderedlist>
+
+<listitem><para> From the root of the source tree:
+ <screen>
+ $ cd /usr/src</screen></para></listitem>
+
+<listitem><para>Build the toolchain:
+ <screen>
+ $ ./build.sh -O ../obj -T ../tools -U -u tools
+ </screen></para></listitem>
+
+<listitem><para>Build the distribution:
+ <screen>
+ $ ./build.sh -O ../obj -T ../tools -U -u distribution
+ </screen></para></listitem>
+
+<listitem><para>Build the kernel:
+ <screen>$ ./build.sh -O ../obj -T ../tools -U -u kernel=GENERIC
+ </screen></para></listitem>
+
+<listitem><para>Install the kernel:
+ <screen>
+ $ cd ../obj/sys/arch/<ARCH>/compile/GENERIC
+ $ su
+ # mv /&os; /&os;.old
+ # cp &os; /&os;</screen></para></listitem>
+
+<listitem><para>Reboot into the new kernel:
+ <screen>
+ # shutdown -r now</screen></para></listitem>
+
+<listitem><para>Install the new userland:
+ <screen>
+ $ cd /usr/src
+ $ su
+ # ./build.sh -O ../obj -T ../tools -U install=/
+ </screen></para></listitem>
+
+<listitem><para>
+ Follow the instruction in the output for fixing obsolete files, for example:
+ <screen>
+ # /usr/src/usr.sbin/postinstall/postinstall -s /usr/src -d // fix defaults mtree obsolete
+ </screen></para></listitem>
+
+<listitem><para>
+<ulink url="#etcupdate">Update</ulink> /etc:
+ <screen>
+ # /usr/sbin/etcupdate -s /usr/src</screen></para></listitem>
+
+<listitem><para>
+Optionally reboot to ensure all running services are using the new binaries:
+ <screen>
+ # shutdown -r now</screen></para></listitem>
+
+</orderedlist>
+
+
+<para>
+In this example,
+the <option>-u</option> option indicates an update process,
+and the <option>-U</option> option allows the entire build by
+a non-root userfollowed with an install by root.</para>
+
+<para>
+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.</para>
+
+<para>
+For more details see
+<ulink url="ftp://ftp.&os;.org/pub/&os;/&os;-current/src/UPDATING">
+/usr/src/UPDATING</ulink>.</para>
+
+</sect1>
+
+<!-- ============================================================= -->
+
+<sect1 id="remember">
+<title>Things you need to remember</title>
+
+<itemizedlist>
+
+<listitem><para>
+When upgrading to a more recent version of -current you should
+<emphasis>always</emphasis> compile and boot a new kernel before installing any
+new libs (<ulink url="#star">*</ulink>). 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 <ulink url="http://www.&os;.org/Documentation/kernel/#problems_compiling_a_current_kernel">
+Kernel FAQ</ulink>.</para></listitem>
+
+<listitem><para>
+Once the kernel is running, you should have a look at the
+<ulink url="ftp://ftp.&os;.org/pub/&os;/&os;-current/src/BUILDING">BUILDING</ulink>
+file at the base of the source tree, and use the <filename>build.sh</filename> script
+to build a new userland.</para></listitem>
+
+ <listitem><para>
+ When compiling a -current kernel, always remember to include the
+ <constant>COMPAT_<lastrelease></constant> option
+ (e.g., <constant>COMPAT_16</constant>). 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
+ <filename>build.sh</filename></para></listitem>
+
+<listitem><para>
+ People using &os;-current are strongly encouraged to subscribe to
+ the <emphasis role="bold"><ulink
+ url="http://www.&os;.org/MailingLists/#current-users">current-users</ulink></emphasis>
+ mailing list. The <emphasis role="bold"><ulink
+ url="http://www.&os;.org/MailingLists/#source-changes">source-changes</ulink></emphasis>
+ mailing list is also of interest.</para></listitem>
+
+</itemizedlist>
+
+<para id="star">
+*: Unless you are certain there have been no new
+system calls added, but do it anyway; it is safer.</para>
+
+</sect1>
+
+<!-- ============================================================= -->
+
+<sect1 id="build-targets">
+<title>What are the various Makefile targets?</title>
+
+<para>
+For further documentation concerning usage of the new toolchain
+through the script <filename>build.sh</filename> (in the toplevel source directory),
+run <userinput>./build.sh -h</userinput>,
+and see <ulink url="ftp://ftp.&os;.org/pub/&os;/&os;-current/src/BUILDING">
+ /usr/src/BUILDINT</ulink>.</para>
+
+<warning><para>
+ The usage of <userinput>make build</userinput> has been deprecated by
+ the updated toolchain,and is strongly discouraged</para></warning>
+
+<para>
+When you build your system for the first time using <filename>build.sh</filename>,
+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.</para>
+
+<para>
+Of course, don't invoke <userinput>./build.sh install =/</userinput>
+unless the <userinput>./build.sh build</userinput> has succeeded previously or it's
+entirely possible to end up with a non-working system.</para>
+
+</sect1>
+
+<!-- ============================================================= -->
+
+<sect1 id="using-anoncvs-pserver">
+<title>Using anoncvs</title>
+
+<para><emphasis>
+These instructions cover unencrypted anoncvs connections.
+If you wish to use encryption protocols,
+see <ulink url="#using-anoncvs-over-ssh">below</ulink>.
+</emphasis></para>
+
+<orderedlist>
+
+<listitem><para>Set the <envar>CVSROOT</envar> environment variable to point to the
+ <ulink url="http://www.&os;.org/mirrors/#anoncvs">anoncvs server</ulink> of your choice:
+ <itemizedlist>
+
+ <listitem><para>
+ For &man.csh.1; or <filename
+ role="pkg">shells/tcsh</filename> users:
+ <screen># setenv CVSROOT :pserver:anoncvs@anoncvs.&os;.org:/cvsroot
+ </screen></para></listitem>
+
+ <listitem><para>
+ For &man.sh.1;, &man.ksh.1;, or <filename
+ role="pkg">shells/bash2</filename> users:
+ <screen>
+ $ CVSROOT=:pserver:anoncvs@anoncvs.&os;.org:/cvsroot; export CVSROOT
+ </screen></para></listitem>
+
+ </itemizedlist>
+
+</para></listitem>
+
+<listitem><para>
+ Continue with:
+ <screen>
+ $ cd /usr
+ $ cvs login</screen>
+(use "anoncvs"as password)</para></listitem>
+
+</orderedlist>
+
+
+<para>
+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.</para>
+
+</sect1>
+
+<!-- ============================================================= -->
+
+<sect1 id="using-anoncvs-over-ssh">
+<title>Using anoncvs over &man.ssh.1;</title>
+
+<para>
+The methods described in <ulink url="#using-anoncvs-pserver">using anoncvs</ulink> can
+be used over &man.ssh.1; to ensure the integrity of the sources you receive.
+However,this adds substantial overhead to the anoncvs servers.</para>
+
+<para>
+ Those servers in the <ulink url="http://www.&os;.org/mirrors/#anoncvs">mirrors</ulink>
+that support ssh connections show the required information with each entry.</para>
+
+<para>
+In general, remove the <constant>:pserver:</constant> prefix on the cvsroot,
+and set the variable <envar>CVS_RSH</envar> to <filename>ssh</filename>
+using the method appropriate for your shell.</para>
+
+</sect1>
+
+<!-- ============================================================= -->
+
+<sect1 id="using-anoncvs">
+<title>Tracking &os;-current with anoncvs</title>
+
+<!-- ........................................................... -->
+
+<sect2 id="setting-up"><title>Setting up</title>
+
+<itemizedlist>
+<listitem><para>
+ To checkout only the kernel sources:
+ <screen>
+ $ cd /usr
+ $ cvs checkout -P src/sys</screen>
+This gives you the kernel sources in <filename>/usr/src/sys</filename>.
+Information on <ulink url="http://www.&os;.org/Documentation/kernel/#how_to_build_a_kernel">
+how to build a kernel</ulink> is also available.</para></listitem>
+
+<listitem><para>
+Checkout the entire source tree (including kernel)
+ <screen>
+ $ cd /usr
+ $ cvs checkout -P src</screen>
+You should now have a full set of &os; sources in /usr/src.
+ <note><para>
+ It is almost always faster for a first-time "whole
+ source" checkout to <ulink url="#downloading">FTP the tarballs</ulink> 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.</para></note>
+
+</para></listitem>
+
+<listitem><para>
+Fix permissions: If you wish for the source tree to be owned by a non-root user,
+do (as root):
+ <screen>
+ # chown -R <emphasis>user</emphasis> /usr/src
+ </screen></para></listitem>
+
+</itemizedlist>
+
+</sect2>
+
+<!-- ........................................................... -->
+
+<sect2 id="update-sources">
+<title>To update the sources</title>
+
+<orderedlist>
+
+<listitem><para>To update only the kernel sources:
+ <screen>
+ $ cd /usr/src/sys
+ $ cvs update -dP</screen>
+</para></listitem>
+
+<listitem><para>To update the entire source tree:
+ <screen>$ cd /usr/src
+ $ cvs update -dP</screen>
+</para></listitem>
+
+</orderedlist>
+
+<note>
+<para>Running <userinput>cvs checkout -d dir src</userinput> (or similar commands
+with the other src* modules) does not work. You will get error messages saying:
+<screen>existing repository ... does not match ...; ignoring module _gnusrc-cmp</screen> etc;
+The workaround is to drop the <filename>-d</filename> option and let <application>cvs</application>
+create the default directory.</para></note>
+
+</sect2>
+
+<!-- ........................................................... -->
+
+<sect2 id="checkout-by-date">
+<title>To check out the sources from a certain date</title>
+<para>
+ <programlisting>
+ $ cvs checkout -D 20070301-UTC src</programlisting>
+</para>
+</sect2>
+
+<!-- ........................................................... -->
+
+<sect2 id="checkout-by-branch">
+<title>To check out the sources from a certain branch</title>
+<para>
+ <programlisting>
+ $ cvs checkout -r &os;-3-1 src</programlisting>
+See
+<ulink url="http://cvsweb.&os;.org/bsdweb.cgi/src/doc/BRANCHES?rev=HEAD&content-type=text/x-cvsweb-markup">src/doc/BRANCHES</ulink>
+for a description of the branches in the CVS repository.
+</para>
+</sect2>
+
+<!-- ........................................................... -->
+
+<sect2 id="hints">
+<title>Useful hints</title>
+<itemizedlist>
+
+<listitem><para>
+Do not use the cvs <option>-z</option> 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.
+</para></listitem>
+
+<listitem><para>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:
+ <programlisting>
+ $ cd /parent/dir/to/checkout/into
+ $ mkdir NewName-temp
+ $ cd NewName-temp
+ $ cvs checkout ... src
+ $ mv src ../NewName
+ $ cd ..
+ $ rmdir NewName-temp</programlisting>
+</para></listitem>
+
+<listitem><para>
+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:
+ <programlisting>
+ cvs [update aborted]: could not chdir to gnu/usr.bin/gdb/gdb: Not a directory
+ </programlisting>
+you should do a <userinput>make cleandir</userinput> and try again. Make sure to
+run <userinput>make obj</userinput> after the cvs update.
+</para></listitem>
+
+<listitem><para>
+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:
+ <programlisting>
+ update -dP
+ checkout -P
+ diff -u</programlisting>
+</para></listitem>
+
+</itemizedlist>
+
+</sect2>
+
+<!-- ........................................................... -->
+
+<sect2 id="building-from-source">
+<title>Building &os; from source</title>
+<para>
+<emphasis>(Assuming you have an up-to-date &os; binary
+snapshot, and source in /usr/src/, on your machine already; further
+assuming your BSDOBJDIR should be /usr/obj/):</emphasis></para>
+
+<para>
+To build userland the first time:
+ <programlisting>
+ # mkdir /usr/obj
+ # cd /usr/src
+ # ./build.sh -O /usr/obj -D /usr/&os;-new-build -T /usr/tools build
+ # ./build.sh -O /usr/obj -D /usr/&os;-new-build -T /usr/tools install=/
+ </programlisting></para>
+
+<para>
+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.</para>
+
+<warning><para>
+Of course, don't invoke <userinput>./build.sh install=/</userinput>
+unless the <userinput>./build.sh build</userinput> has succeeded previously or it's
+entirely possible to end up with a non-working system.
+</para></warning>
+
+<para>
+To update userland binaries after a CVS update:
+ <programlisting># cd /usr/src
+ # ./build.sh -D /usr/&os;-new-build -O /usr/obj -T /usr/tools -u build
+ # ./build.sh -D /usr/&os;-new-build -O /usr/obj -T /usr/tools -u install=/
+ </programlisting>
+These steps will install the new binaries on the running system. Reboot to make
+sure they all take effect.</para>
+
+<para>
+If you update system frequently and want the build to directly update
+your running system, you can use <emphasis>expert</emphasis> mode and build
+with <envar>DESTDIR=/</envar> eg:
+ <userinput>
+ # ./build.sh -E -O /usr/obj -T /usr/tools -u build</userinput>
+
+ <warning><para>this is for <emphasis role="bold">expert</emphasis> 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 <emphasis role="bold">sure</emphasis>
+ the build will finish successfully.</para></warning>
+</para>
+
+</sect2>
+
+</sect1>
+
+<!-- ============================================================= -->
+
+<sect1 id="using-sup-into-cvs">
+<title>Tracking &os;-current with &man.sup.1; into CVS</title>
+
+<!-- ........................................................... -->
+
+<sect2 id="sup-overview">
+<title>Overview</title>
+
+<para>Current can be tracked in the following way: The baseline copy of
+ the sources is kept up to date using &man.sup.1; 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.</para>
+
+ <para>There are 3 major reasons for this approach
+ <orderedlist>
+
+ <listitem><para>It keeps track of how current changes over time.</para></listitem>
+
+ <listitem><para>It allows for local changes to be almost automatically merged
+ into the updated current sources.</para></listitem>
+
+ <listitem><para>It ensures there is always a clean unmodified copy of the
+ &os;-current source tree is available in case of problems when
+ building.</para></listitem>
+
+ </orderedlist>
+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.</para>
+
+</sect2>
+
+<!-- ........................................................... -->
+
+<sect2 id="sup-requirements">
+<title>Requirements</title>
+<itemizedlist>
+
+<listitem><para>&man.cvs.1; 1.9 or later</para></listitem>
+
+<listitem><para>&man.sup.1; installation</para></listitem>
+
+<listitem><para>optional: Perl 5 installation (for the supplied script)
+</para></listitem>
+
+</itemizedlist>
+
+</sect2>
+
+<!-- ........................................................... -->
+
+<sect2 id="sup-details">
+<title>Details</title>
+
+<para>Tracking and building current consists of 5 phases:
+ <orderedlist>
+ <listitem><para>
+ Supping updated sources into master source tree.</para></listitem>
+
+ <listitem><para>
+ Importing supped sources into CVS and updating working copy
+ of sources.</para></listitem>
+
+ <listitem><para>
+ Merging supped sources with local working sources.</para></listitem>
+
+ <listitem><para>
+ Building and installing current.</para></listitem>
+
+ <listitem><para>
+ Tagging the sources for a successful build in the
+ repository.</para></listitem>
+
+ </orderedlist>
+ </para>
+</sect2>
+
+
+</sect1>
+
+<!-- ============================================================= -->
+
+
+<sect1 id="supping-sources">
+<title>Supping sources</title>
+<para>Sources can be supped from any &os; sup server and the output
+ from the SUP (man page: &man.sup.1;) should be stored in a file for later reference.
+ </para></sect1>
+
+<!-- ============================================================= -->
+
+
+<sect1 id="import-merge">
+<title>Importing and merging sources.</title>
+
+<para>Sources are imported as follows:
+ <programlisting>
+ $ cvs -d /misc/cvsrep import -I ! -I CVS &os; &os; current-<emphasis>date</emphasis>
+ </programlisting>
+<emphasis>date</emphasis> is replaced by the date of the SUP for tracking
+purposes. The <filename>-I ! -I CVS</filename> options ensure that no file in
+the source tree is ignored except 'CVS' directories. This is because
+some &os; 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:
+ <screen>
+ $ cvs checkout -j&os;:yesterday -j&os; &os;</screen>
+This merge command will correctly merge the imported &os;
+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:
+ <programlisting>
+ $ cvs update -j<emphasis>previous import tag</emphasis> -j current-<emphasis>date</emphasis>
+ </programlisting>
+<emphasis>previous import tag</emphasis> should be replaced with the name of
+the tag used for the previous cvs import. <emphasis>date</emphasis> should be
+replaced with the current date to yield the same tag used on
+the current import that has just been merged.
+</para>
+
+<para>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 <filename>C</filename>
+ followed by a filename.</para>
+
+<para>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 &os; source code.</para>
+
+<para>&man.cvs.1; marks conflicts as follows:
+ <screen>
+ <<<<<<
+ <emphasis>code from local file</emphasis>
+ ======
+ <emphasis>code from imported file</emphasis>
+ >>>>>> <emphasis>local revision number of newly imported revision</emphasis>
+</screen></para>
+
+<para>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.</para>
+
+<para> All update and checkout commands should be done in the
+ directory where the sources have been checked out. On my system
+ this is <filename>/usr/src/&os;</filename>.</para>
+
+<para>If this is the first import then there will be no sources
+ checked out. Assuming you wish to create the source tree in
+ <filename>/usr/src/&os;</filename>. The following commands will check
+ out the source and no merge step is required:
+ <programlisting>
+ $ cd /usr/src
+ $ cvs -d /misc/cvsrep checkout &os;
+ </programlisting>
+</para>
+
+</sect1>
+
+<!-- ============================================================= -->
+
+
+<sect1 id="building-current">
+<title>Building current.</title>
+<orderedlist>
+
+ <listitem><para>Configure, <ulink
+url="http://www.&os;.org/Documentation/kernel/#how_to_build_a_kernel ">
+ build</ulink>, and reboot into a new kernel.</para></listitem>
+
+<listitem><para>cd to the base of your -current source tree and type
+<userinput>./build.sh -T /usr/tools -O /usr/obj </userinput>.
+</para></listitem>
+
+<listitem><para>You may need to merge in any changes that have been made to files in
+/etc.</para></listitem>
+
+</orderedlist>
+
+</sect1>
+
+<!-- ============================================================= -->
+
+
+<sect1 id="tagging">
+<title>Tagging a successful build</title>
+
+<para> If the <ulink url="#building">build</ulink> 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:
+ <programlisting>$ cvs tag successful-build-<emphasis>build date</emphasis>
+ </programlisting>
+</para>
+
+<para>Notes:
+ <itemizedlist>
+ <listitem><para>If the &os; customised version of CVS, which recognises
+ <emphasis role="bold">$Net</emphasis><emphasis role="bold">BSD$</emphasis> markers in files, is not used, the
+ &os; revision number of the file is available for reference
+ purposes when build problems occur.</para></listitem>
+
+ <listitem><para>The sup/import/merge sequence described above is quite
+ easily automatable. The following Perl script automates this
+ process:
+ <programlisting>
+ #!/usr/pkg/bin/perl
+ #
+ # Script to SUP &os;-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/&os;";
+ $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\" &os; &os; current-$shortdate ";
+
+ # make the working directory the local &os; Tree
+ chdir $SRCROOT or die "Could not change to $SRCROOT directory\n";
+
+ # Now do the import.
+ $lastimport = `cat /usr/src/&os;/.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;
+ </programlisting>
+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.</para></listitem>
+
+<listitem><para>Techniques for tracking current with CVS have been discuss several
+times on the &os; current-users mailing list. For
+alternative techniques try searching the &os; mailing lists.</para></listitem>
+
+</itemizedlist>
+
+</para>
+
+</sect1>
+
+<!-- ============================================================= -->
+
+
+<sect1 id="getrepos">
+<title>Getting the whole repository</title>
+
+<para>
+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 &os;. If you don't want to maintain your
+own CVS repository, but just want to mirror &os;'s CVS repository,
+there are three ways to do so.</para>
+
+<para>
+Each of the methods described briefly below will get you a copy
+of the &os; 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.</para>
+
+<para>
+The methods to retrieve the whole repository are:</para>
+
+<variablelist>
+<varlistentry><term>&man.sup.1;</term>
+<listitem><para>
+ If you use sup already to mirror other parts of the &os; source,
+ you will want to add the following lines to your sup config file:
+ <userinput>anoncvs release=all host=sup.&os;.org hostbase=/ftp/pub base=/usr prefix=/usr backup use-rel-suffix compress
+ </userinput>
+ After that, run <userinput>sup /path/to/supfile anoncvs" to retrieve the files.</userinput></para>
+
+ <para>
+ Some example sup files are available in <filename>/usr/share/examples/supfiles</filename>.
+ Also, check our <ulink url="http://www.&os;.org/mirrors/#sup">list of SUP mirrors</ulink>
+ to find the server closest to you!</para>
+</listitem>
+</varlistentry>
+
+<varlistentry><term>rsync</term>
+<listitem><para>
+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:
+ <programlisting>
+ rsync -v -a rsync://anoncvs.&os;.org/cvsroot/src .
+ </programlisting>
+ Please see our <ulink url="http://www.&os;.org/mirrors/#rsync">list of rsync mirrors</ulink>!
+</para></listitem>
+</varlistentry>
+
+<varlistentry>
+ <term>cvsup</term>
+<listitem><para>CVSup is not currently available for all &os; architectures, since the M3
+ compiler has not been ported. On i386, you can mirror the repository
+ from cvsup.de.&os;.org with the
+ <filename role="pkg">devel/cvsup</filename> package and the
+ following config file:
+ <screen>
+ *default host=cvsup.de.&os;.org
+ *default base=/usr
+ *default prefix=/local/&os;-cvs
+ *default release=cvs
+ *default delete use-rel-suffix
+ *default compress
+
+ &os;</screen>
+ Please see our <ulink
+ url="http://www.&os;.org/mirrors/#cvsup">list of CVSup mirrors</ulink>!
+
+</para></listitem>
+</varlistentry>
+
+</variablelist>
+
+</sect1>
+
+<!-- ============================================================= -->
+
+
+<sect1 id="error">
+<title>What if I get an error?</title>
+
+<para>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:
+ <orderedlist>
+ <listitem><para>
+ Read the <ulink
+ url="http://cvsweb.&os;.org/bsdweb.cgi/src/UPDATING">UPDATING</ulink>
+ file from the release you're trying to build.</para></listitem>
+
+ <listitem><para>
+ Read the <ulink
+ url="http://mail-index.&os;.org/current-users/">current-users
+ archive</ulink> for hints.</para></listitem>
+
+ <listitem><para>
+ 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.</para></listitem>
+
+ <listitem><para>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 <emphasis role="bold">short</emphasis> script that includes the error messages
+ you're getting. Somebody will probably fix the problem momentarily.
+ </para></listitem>
+
+</orderedlist>
+
+</para>
+
+</sect1>
+
+<!-- ============================================================= -->
+
+
+<sect1 id="etcupdate">
+<title>Updating the configuration and startup files with &man.etcupdate.8;</title>
+
+<!-- ........................................................... -->
+
+<sect2 id="etcupdate-overview"><title>Overview</title>
+<para><filename>etcupdate</filename> 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.</para>
+</sect2>
+
+<!-- ........................................................... -->
+
+<sect2 id="using-etcupdate-source">
+<title>Using etcupdate with source files</title>
+
+<para>
+In case where the sources are in /usr/src/ the following command should be
+enough:
+ <userinput>etcupdate</userinput>
+But what if your &os; sources are in an alternative location, such as
+in /home/jdoe/&os;/src? Don't worry, tell etcupdate the location of
+your source tree with -s srcdir and it will work just fine:
+ <programlisting># etcupdate -s /home/jdoe/&os;/src</programlisting>
+</para>
+</sect2>
+
+<!-- ........................................................... -->
+
+<sect2 id="using-etcupdate-binary">
+<title>Using etcupdate with binary distribution sets</title>
+
+<para>
+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.
+ <programlisting>
+ # mkdir /tmp/temproot
+ # cd /tmp/temproot
+ # tar xpzf /some/where/etc.tgz
+ # etcupdate -b /tmp/temproot</programlisting>
+</para>
+
+</sect2>
+
+</sect1>
+
+<!-- ============================================================= -->
+
+
+<sect1 id="specific-problems">
+<title>Specific problems</title>
+
+<!-- ........................................................... -->
+
+<sect2 id="wscons">
+<title>Console dead after updating to wscons</title>
+
+<para>
+You should copy a current MAKEDEV from the appropriate etc.<emphasis>port</emphasis>
+directory in <ulink
+url="ftp://ftp.&os;.org/pub/&os;/&os;-current/src/etc/">src/etc</ulink>,
+into <filename>/dev</filename>, boot single user, then type:
+ <programlisting>
+ # fsck -p
+ # mount -vt nonfs
+ # cd /dev
+ # ./MAKEDEV wscons</programlisting>
+</para>
+
+</sect2>
+
+<!-- ........................................................... -->
+
+<sect2 id="rebuild-nbmake">
+<title>Why does <filename>build.sh</filename> always
+ rebuild <filename>bmake</filename> first?</title>
+
+<para>
+Even after running <userinput>./build.sh tools</userinput> and using the <option>-u</option>
+flag or specifying <constant>TOOLDIR</constant> in <filename>/etc/mk.conf</filename>,
+<filename>nbmake</filename> is always rebuilt by <filename>build.sh</filename>. This is normal.
+The reason for this can be found in <filename>/build.sh</filename> itself, in the
+function <constant>rebuildmake</constant>:
+ <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.
+ #</programlisting>
+
+So, if you do not want to rebuild <filename>nbmake</filename>, you will need to pass
+<option>-T tooldir</option> or set the <envar>TOOLDIR</envar> variable in the
+environment.
+</para>
+
+</sect2>
+
+</sect1>
+
+</chapter>
Index: guide/en/chapters.ent
===================================================================
RCS file: /cvsroot/htdocs/guide/en/chapters.ent,v
retrieving revision 1.10
diff -u -r1.10 chapters.ent
--- guide/en/chapters.ent 29 Aug 2006 12:40:16 -0000 1.10
+++ guide/en/chapters.ent 15 Apr 2007 13:03:54 -0000
@@ -20,6 +20,7 @@
<!ENTITY chap-mail SYSTEM "chap-mail.xml">
<!ENTITY chap-carp SYSTEM "chap-carp.xml">
<!ENTITY chap-cons SYSTEM "chap-cons.xml">
+<!ENTITY chap-current SYSTEM "chap-current.xml">
<!ENTITY chap-edit SYSTEM "chap-edit.xml">
<!ENTITY chap-x SYSTEM "chap-x.xml">
<!ENTITY chap-linux SYSTEM "chap-linux.xml">
Index: guide/en/netbsd.xml
===================================================================
RCS file: /cvsroot/htdocs/guide/en/netbsd.xml,v
retrieving revision 1.40
diff -u -r1.40 netbsd.xml
--- guide/en/netbsd.xml 2 Apr 2007 09:45:42 -0000 1.40
+++ guide/en/netbsd.xml 15 Apr 2007 13:03:58 -0000
@@ -107,6 +107,7 @@
<title>Building the system</title>
&chap-fetch;
+ &chap-current;
&chap-build;
&chap-kernel;
&chap-pack; <!-- pkgsrc.xml in its own part! -->
--Boundary-00=_atiIGZCIvpe94xD--