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

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

Revision 1.92, Wed Jul 7 05:08:50 2021 UTC (4 months, 3 weeks ago) by dholland
Branch: MAIN
CVS Tags: HEAD
Changes since 1.91: +6 -31 lines

regen

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<meta name="generator" content="Website XSL Stylesheet V2.6.0">
<link rel="home" href="../../." title="Welcome to The NetBSD Project: Of course it runs NetBSD.">
<link rel="up" href="../../docs/." title="NetBSD Documentation">
<link rel="previous" href="../../docs/encrypted-iscsi.html" title="Encrypted iSCSI Devices on NetBSD">
<link rel="next" href="../../docs/kernel/." title="NetBSD Documentation: Kernel">
<link rel="first" href="../../docs/Hardware/." title="Hardware Documentation">
<link rel="last" href="../../docs/x/." title="NetBSD Documentation: The X Window System">
<link rel="stylesheet" href="../../global.css" type="text/css">
<link rel="stylesheet" href="../../donations/thermo/fundraiser.css" type="text/css">



    <title>Tracking NetBSD-current</title>
</head>
<meta name="viewport" content="width=device-width, initial-scale=1.0, minimum-scale=1.0">
<body class="website"><div class="webpage">
<a name="docs-current-index"></a><div id="top"><a href="#mainContent" id="skiplink" tabindex="1">Skip to main content.</a></div>
<input id="hamburger" type="checkbox"><label class="menuicon" for="hamburger"><span></span><span></span><span></span></label><div id="navBar" role="navigation">
<div id="centralHeader"><div id="logo">
<a href="../../"><img id="projectLogo" alt="" height="120" src="../../images/NetBSD-smaller-tb.png"></a><a href="/"><div id="fundraiser">
<br><div id="fundraiser-amount"><div id="fundraiser-raised"></div></div>
</div></a>
</div></div>
<span class="doNotDisplay">
	  Navigation:
	</span><ul>
<li>
<a href="../../">
	  Home</a><ul>
<li><a href="../../changes/">
	    Recent changes</a></li>
<li><a href="//blog.NetBSD.org/">
	    NetBSD blog</a></li>
<li><a href="../../gallery/presentations/">
	    Presentations</a></li>
</ul>
</li>
<li>
<a href="../../about/">
	  About</a><ul>
<li><a href="../../people/developers.html">
	    Developers</a></li>
<li><a href="../../gallery/">
	    Gallery</a></li>
<li><a href="//wiki.NetBSD.org/ports/">
	    Ports</a></li>
<li><a href="//www.pkgsrc.org/">
	    Packages</a></li>
</ul>
</li>
<li>
<a href="../../docs/">
	  Documentation</a><ul>
<li><a href="../../docs/misc/index.html">
	    FAQ &amp; HOWTOs</a></li>
<li><a href="../../docs/guide/en/">
	    The Guide</a></li>
<li><a href="//man.NetBSD.org/">
	    Manual pages</a></li>
<li><a href="//wiki.NetBSD.org/">
	    Wiki</a></li>
</ul>
</li>
<li>
<a href="../../support/">
	  Support</a><ul>
<li><a href="/community/">
	    Community</a></li>
<li><a href="/mailinglists/">
	    Mailing lists</a></li>
<li><a href="../../support/send-pr.html">
	    Bug reports</a></li>
<li><a href="../../support/security/">
	    Security</a></li>
</ul>
</li>
<li>
<a href="../../developers/">
	  Developers</a><ul>
<li><a href="http://cvsweb.NetBSD.org/">
	    CVSWeb</a></li>
<li><a href="//anonhg.NetBSD.org/">
	    Mercurial</a></li>
<li><a href="//nxr.NetBSD.org/">
	    Cross-reference</a></li>
<li><a href="//releng.NetBSD.org/">
	    Release engineering</a></li>
<li><a href="//wiki.NetBSD.org/projects/">
	    Projects list</a></li>
</ul>
</li>
</ul>
</div>
<div id="content"><div id="mainContent" class="fullWidth"><div class="rowOfBoxes">
<h1>Tracking NetBSD-current</h1>
<h3 class="title"><a name="faq">Frequently asked questions</a></h3>
<ul>
<li><a href="#recovering-via-rescue">Recovering userland from /rescue</a></li>
<li><a href="#why-track">Why track NetBSD-current?</a></li>
<li><a href="#what-to-do">Things you need to remember</a></li>
<li><a href="#updating-from-snapshot">Updating an existing system from a current snapshot</a></li>
<li><a href="#downloading">Downloading current source</a></li>
<li><a href="#building">Building a release from source</a></li>
<li><a href="#updating-from-source">Updating an existing system from source</a></li>
<li><a href="#etcupdate">Updating the configuration and startup files</a></li>
<li><a href="#error">What if I get an error?</a></li>
<li><a href="#using-anoncvs">Tracking NetBSD-current with anoncvs</a></li>
<li><a href="#import-merge">Importing and merging sources.</a></li>
<li><a href="#tagging">Tagging a successful build</a></li>
<li><a href="#getrepos">Getting the whole repository</a></li>
</ul>
<hr>
<h3 class="title">Frequently asked questions</h3>
<h4 class="title">
<a name="recovering-via-rescue"></a>Recovering userland from /rescue</h4>
<p>
If you tested a bad userland change, and dynamic binaries no longer
run, you might still be able to recover that machine from /rescue.
</p>
<p>
At the worst case, you will not have a root shell already available.
If so, test that /rescue/ls works fine, and reboot.

In the bootloader, drop to boot prompt and type:
</p>
<pre class="programlisting">
    boot&gt; boot -as
</pre>
<p>
You will need to specify the names of your disks. The default choices
are usually right.
When asked which init to use, pick /rescue/init.
</p>
<p>
You should now have a root shell with a read-only root.
</p>
<p>
</p>
<pre class="programlisting">
    <code class="prompt">#</code> export PATH=/rescue		# Usable binaries
    <code class="prompt">#</code> mount -a				# Mount read-write (based on /etc/fstab)
</pre>
<p>
</p>
<p>
At the worst case, you don't have the ability to recover locally
and need to obtain new sets from the Internet.

Configure connection manually
</p>
<pre class="programlisting">
    <code class="prompt">#</code> ifconfig 192.168.200.200
    <code class="prompt">#</code> route add default 192.168.200.1
    <code class="prompt">#</code> echo "nameserver 8.8.8.8" &gt; /etc/resolv.conf
</pre>
<p>

Obtain new sets or perform other recovery actions.
</p>
<pre class="programlisting">
    <code class="prompt">#</code> cd /
    <code class="prompt">#</code> ftp -a ftp.NetBSD.org
    
    # Assuming you want to recover to NetBSD/amd64 9.2
    ftp&gt; cd pub/NetBSD/NetBSD-9.2/amd64/binary/sets
    ftp&gt; mget *
    mget MD5 [anpqy?]? a
    ftp&gt; exit
    
    <code class="prompt">#</code> tar xpf base.tgz
</pre>
<p>
</p>

<h4 class="title">
<a name="why-track"></a>Why track NetBSD-current?</h4>
<p>
The developers of NetBSD have made the current development sources
available to the public for several reasons.  Overall, providing
NetBSD-current helps us to create a more stable, accessible system.
</p>
<p>
It makes it easier for people to become involved in the development of
NetBSD.  Distributing the current development sources allows a greater
number of people to see where the system is going, and to become
involved with new features as they are implemented.
</p>
<p>
It also makes changes from users easier to integrate.
If users make changes against
the current development sources, then virtually no integration is
needed to get them into the master source tree.
</p>
<p>
It also allows wider testing of the software as it is developed.  Users
of NetBSD-current are encouraged to send in <a class="ulink" href="../../support/send-pr.html" target="_top">bug reports</a> about the current sources,
and that helps find and fix bugs.  Because people are testing the
software soon after it's written, more bugs can be found and
eliminated.
</p>

<h4 class="title">
<a name="what-to-do"></a>Things you need to remember</h4>

<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
<li class="listitem">
  <p>
  People using NetBSD-current are strongly encouraged to subscribe to
  the <span class="bold"><strong><a class="ulink" href="../../mailinglists/#current-users" target="_top">current-users</a></strong></span>
  mailing list.  The <span class="bold"><strong><a class="ulink" href="../../mailinglists/#source-changes" target="_top">source-changes</a></strong></span>
  mailing list is also of interest.
  </p>
 </li>
<li class="listitem">
  <p>
  When upgrading to a more recent version of -current you should
  <span class="emphasis"><em>always</em></span> install and boot a new kernel before installing any
  new libs (<a class="ulink" href="#star" target="_top">*</a>). In general the best approach is to
  try the new kernel before anything else, and if you hit any problems see
  the entry in the <a class="ulink" href="../kernel/#problems_compiling_a_current_kernel" target="_top">
  Kernel FAQ</a>.
  </p>
 </li>
<li class="listitem">
  <p>
  When compiling a -current kernel, always remember to include the
  COMPAT_&lt;lastrelease&gt; option (e.g., COMPAT_16).  As current
  diverges from the last stable release, compatibility code will be
  added, but it will only be enabled if this option is present.  At a
  bare minimum, you will need this compatibility code for the time
  between booting the new kernel and finishing your build via
  <code class="code">build.sh</code>
  </p>
 </li>
</ul></div>
<p><a name="star"></a>
*: Unless you are certain there have been no new
system calls added, but do it anyway; it's safer.
</p>

<h4 class="title">
<a name="updating-from-snapshot"></a>Updating an existing system from a current snapshot</h4>
<p>
<span class="emphasis"><em>Please remember to check <a class="ulink" href="http://ftp.NetBSD.org/pub/NetBSD/NetBSD-current/src/UPDATING" target="_top">src/UPDATING</a>
for quirks around certain specific changes.</em></span></p>
<p>
To quickly begin using current,
start with a snapshot generated by release engineering.
The current status of each platform can be seen at
<a class="ulink" href="http://releng.NetBSD.org/cgi-bin/builds.cgi" target="_top">
NetBSD Autobuild
</a>
and the corresponding releases found in <a class="ulink" href="https://nycdn.NetBSD.org/pub/NetBSD-daily/HEAD/">https://nycdn.NetBSD.org/pub/NetBSD-daily/HEAD/</a>
by date and platform.
</p>
<p>
</p>
<div class="orderedlist"><ol class="orderedlist" type="1">
<li class="listitem"> Hunt down to the desired <code class="code">binary/sets</code> directory,
and download <code class="code"><span class="bold"><strong>*.tgz</strong></span></code> or 
<code class="code"><span class="bold"><strong>*.tar.xz</strong></span></code> files
into your favorite local administrative directory
(for example, <span class="emphasis"><em><code class="code">$HOME/current</code></em></span>);
when limited by disk space and/or time,
only kern-GENERIC, etc, base, and comp (if you want a compiler) are
essential.</li>
<li class="listitem"> Extract the desired kernel (usually <code class="code">GENERIC</code>),
copy it into <code class="code">/</code> (root) directory.
<pre class="programlisting">
    <code class="prompt">$</code> su
    <code class="prompt">#</code> cd /root
    <code class="prompt">#</code> tar -zxpf ~/kern-GENERIC.tgz
    <code class="prompt">#</code> ln -fh /netbsd /netbsd.old
    <code class="prompt">#</code> cp netbsd /netbsd.new
    <code class="prompt">#</code> ln -fh /netbsd.new /netbsd
</pre>
<p>
  <span class="bold"><strong>Warning: Don't extract any userland binary sets
  before rebooting your machine with the new kernel.</strong></span>
  Newer binaries might use new system calls an old running kernel doesn't
  support.
</p>
</li>
<li class="listitem"> Check if there are any other files which might also be required
by a new kernel.
Again, <a class="ulink" href="http://ftp.NetBSD.org/pub/NetBSD/NetBSD-current/src/UPDATING" target="_top">src/UPDATING</a>
might mention possible quirks on daily changes.
<p> The following items are typical files that possibly need to be updated:
  </p>
<div class="orderedlist"><ol class="orderedlist" type="a">
<li class="listitem">bootloader
  <p>Usually a machine specific bootloader passes several parameters to
  a loaded kernel.
  If some new parameters have been added or
  some existing APIs between bootloader and kernel are changed
  you might also have to install new bootloader files for a new kernel
  to handle new features.
  A method to update bootloader files is quite machine dependent,
  so check <a href="//man.NetBSD.org/NetBSD-9.2/i386/boot.8">boot(8)</a> and <a href="//man.NetBSD.org/NetBSD-9.2/i386/installboot.8">installboot(8)</a> man pages for details.</p>
  <p>On i386 and amd64, if you are using FFSv1 for root file system
  on <code class="code">wd0a</code> (i.e. first ATA drive), typical commands to update
  bootloaders are:
</p>
<pre class="programlisting">
    <code class="prompt">#</code> tar -C /tmp -zxf ~/base.tgz ./usr/mdec
    <code class="prompt">#</code> cp /tmp/usr/mdec/boot /
    <code class="prompt">#</code> installboot -v /dev/rwd0a /tmp/usr/mdec/bootxx_ffsv1
</pre>
  <p>If you are using FFSv2 for root file system use the following commands
  instead:
</p>
<pre class="programlisting">
    <code class="prompt">#</code> tar -C /tmp -zxf ~/base.tgz ./usr/mdec
    <code class="prompt">#</code> cp /tmp/usr/mdec/boot /
    <code class="prompt">#</code> installboot -v /dev/rwd0a /tmp/usr/mdec/bootxx_ffsv2
</pre>
  <p>Note <code class="code">/usr/mdec/bootxx_ffsv1</code> and
  <code class="code">/usr/mdec/bootxx_ffsv2</code> are primary bootloaders which are
  file system dependent.
  <code class="code">/usr/mdec/boot</code> is secondary loader and it's file system
  independent.</p>
  <p>If you forget your root file system type (FFSv1 or FFSv2),
  you can check it by <a href="//man.NetBSD.org/NetBSD-9.2/i386/dumpfs.8">dumpfs(8)</a> command:
</p>
<pre class="programlisting">
    <code class="prompt">#</code> dumpfs /dev/rwd0a | head -3
    file system: /dev/rwd0a
    format  FFSv2
    endian  little-endian
    <code class="prompt">#</code>
</pre>
</li>
<li class="listitem">kernel modules
  <p>A new framework <span class="quote">&#8220;<span class="quote">kernel modules</span>&#8221;</span> has been introduced
  after netbsd-5 was branched, and <code class="code">GENERIC</code> kernel on i386
  port has been switched to using the kernel module files since November 2008.
  The kernel module files will be loaded dynamically by the kernel
  to support various kernel options (including file systems) on demand,
  rather than linking all necessary (but possibly unused) object files
  into the kernel binary.
  This means if you are trying to boot a new <code class="code">GENERIC</code> kernel,
  you also have to prepare new kernel module files for the new kernel.</p>

  <p>To prepare new kernel module files, you can simply use a new
  <code class="code">modules</code> set file which has been prepared since September 2009:
</p>
<pre class="programlisting">
    <code class="prompt">#</code> cd /
    <code class="prompt">#</code> tar -zxpf ~/modules.tgz
</pre>
<p>
</p>
  <p>Note i386 port also provides <code class="code">MONOLITHIC</code> kernel binary
  in <code class="code">kern-MONOLITHIC.tgz</code> set file since October 2009.
  The <code class="code">MONOLITHIC</code> kernel includes all necessary options
  in its kernel as well as 5.0 and prior <code class="code">GENERIC</code> kernels
  and it doesn't depend on kernel module files at all.
  If you would just like to test new features of a new kernel
  without updating kernel modules, using <code class="code">MONOLITHIC</code> kernel
  is easier way for the first and quick trial.</p>

  <p>It's also a good idea to put an old <code class="code">MONOLITHIC</code> kernel
  into <code class="code">/</code> (root) directory for emergency and recovery because
  if newer modules have some fatal issue there is no easy way to specify
  an alternative path of old module files to a modular'ized kernel
  (and you can't rename directories without a working kernel).</p>

  <p>
    <span class="emphasis"><em>Warning: The infrastructure of kernel module files
    mentioned here is still under discussion on -current development.
    It could be changed at some point before the next 6.0 release
    and in that case the description in this section will be obsolete.
    Again, check <a class="ulink" href="http://ftp.NetBSD.org/pub/NetBSD/NetBSD-current/src/UPDATING" target="_top">src/UPDATING</a>
    and <a class="ulink" href="http://mail-index.NetBSD.org/current-users/" target="_top">current-users
    mailing list</a> for updated information.</em></span>
  </p>
  <p>There is <a class="ulink" href="http://mail-index.NetBSD.org/current-users/2009/05/10/msg009372.html" target="_top">a
  possible alternative structure for kernel modules</a>
  which was proposed on May 2009, but we have not got any conclusion yet.
  This would be because most -current users build their own custom kernels
  from sources, but kernel modules might be rather useful for users
  who don't want to bother to compile their own kernels from sources
  to just try to use optinal functions.
  Anyway, any feedback about this brandnew kernel modules is quite appreciated.
  </p>
</li>
</ol></div>
<p>
</p>
</li>
<li class="listitem"> Reboot machine with the new kernel:
<pre class="programlisting">
    <code class="prompt">#</code> shutdown -r now
</pre>
</li>
<li class="listitem"> Make sure the new kernel boots and works properly.
If your new kernel has any trouble, you can recover it by loading
the renamed old one.
If you are using modular'ized <code class="code">GENERIC</code> kernel mentioned above,
you might also have to restore old kernel module files.
</li>
<li class="listitem"> Extract the matching <code class="code">base</code>,
and any other desirable feature sets
<span class="bold"><strong>except <code class="code">etc</code></strong></span>:
<pre class="programlisting">
    <code class="prompt">$</code> su
    <code class="prompt">#</code> cd /
    <code class="prompt">#</code> tar -zxpf ~/base.tgz
    <code class="prompt">#</code> tar -zxpf ~/comp.tgz
    <code class="prompt">#</code> ...
</pre>
Don't forget to specify <code class="code">"p"</code> option (preserve permissions)
on <a href="//man.NetBSD.org/NetBSD-9.2/i386/tar.1">tar(1)</a> command otherwise setuid'ed commands (like <a href="//man.NetBSD.org/NetBSD-9.2/i386/su.1">su(1)</a>)
won't work.
<p>
  <span class="bold"><strong>Warning: Extracting <code class="code">etc.tgz</code> on
  the installed system will overwrite your local settings.</strong></span>
</p>
</li>
<li class="listitem"> <a class="ulink" href="#etcupdate" target="_top">Update</a> <code class="code">/etc</code>
as last step: <a href="//man.NetBSD.org/NetBSD-9.2/i386/postinstall.8">postinstall(8)</a> will first check and fix most things that
can be automated, and <a href="//man.NetBSD.org/NetBSD-9.2/i386/etcupdate.8">etcupdate(8)</a> in the second step will ask on what
to merge:
<pre class="programlisting">
    <code class="prompt">#</code> /usr/sbin/postinstall -s ~/etc.tgz check
    <code class="prompt">#</code> /usr/sbin/postinstall -s ~/etc.tgz fix
    <code class="prompt">#</code> /usr/sbin/etcupdate -s ~/etc.tgz
    <code class="prompt">#</code> shutdown -r now
</pre>
For some architectures you will have to use etc.tar.xz instead
of etc.tgz.
If you have the X sets installed (xbase, ...), you can repeat the
postinstall and etcupdate steps with xetc.tgz (or xetc.tar.xz) as argument
before rebooting.
</li>
</ol></div>
<p>
</p>
<p>
At this point,
you are relatively current
and ready to build your own current source.
</p>

<h4 class="title">
<a name="downloading"></a>Downloading current source</h4>
<p>
See the <a class="ulink" href="../guide/en/chap-fetch.html" target="_top">Obtaining the sources</a>
section in the <a class="ulink" href="../guide/en/" target="_top">NetBSD Guide</a>.
</p>

<h4 class="title">
<a name="building"></a>Building a release from source</h4>
<p>
See the <a class="ulink" href="../guide/en/chap-build.html" target="_top">Crosscompiling NetBSD</a>
section in the <a class="ulink" href="../guide/en/" target="_top">NetBSD Guide</a>.
</p>

<h4 class="title">
<a name="updating-from-source"></a>Updating an existing system from source</h4>
<p>
See the <a class="ulink" href="../guide/en/chap-updating.html" target="_top">Updating an existing system
from sources</a>
section in the <a class="ulink" href="../guide/en/" target="_top">NetBSD Guide</a>.
</p>

<h4 class="title">
<a name="etcupdate"></a>Updating the configuration and startup files</h4>
<p>
See the <a class="ulink" href="../guide/en/chap-updating.html#updating-etcupdate" target="_top">More
details about the updating of configuration and startup files</a>
section in the <a class="ulink" href="../guide/en/" target="_top">NetBSD Guide</a>.
</p>

<h4 class="title">
<a name="error"></a>What if I get an error?</h4>
<p>

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

<h4 class="title">
<a name="using-anoncvs"></a>Tracking NetBSD-current with anoncvs</h4>
<p>
See the <a class="ulink" href="../guide/en/chap-fetch.html#chap-fetch-cvs" target="_top">Fetching
by CVS</a>
section in the <a class="ulink" href="../guide/en/" target="_top">NetBSD Guide</a>.
</p>

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

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

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

<pre class="programlisting">$ cvs checkout -rnetbsd-5-0 src</pre>
See
<a class="ulink" href="http://ftp.NetBSD.org/pub/NetBSD/NetBSD-current/src/doc/BRANCHES" target="_top">src/doc/BRANCHES</a>
for a description of the branches in the CVS repository.
</div>

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

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

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

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

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

<h4 class="title">
<a name="import-merge"></a>Importing and merging sources.</h4>
    <p>Sources are imported as follows:</p>
<pre class="programlisting">$ cvs -d /misc/cvsrep import -I ! -I CVS netbsd netbsd current-<span class="emphasis"><em>date</em></span></pre>

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

    <p>If the import reports no conflicts the checked out copy of the
      tree should be updated in exactly the same way as for the
      conflicts case.</p>
    <p> All update and checkout commands should be done in the
      directory where the sources have been checked out. On my system
      this is <code class="code">/usr/src/netbsd</code>.</p>
    <p>If this is the first import then there will be no sources
      checked out. Assuming you wish to create the source tree in
      '<code class="code">/usr/src/netbsd</code>' The following commands will check
      out the source and no merge step is required.</p>
<pre class="programlisting">$ cd /usr/src
$ cvs -d /misc/cvsrep checkout netbsd
</pre>
    
<h4 class="title">
<a name="tagging"></a>Tagging a successful build</h4>
    <p> If the <a class="ulink" href="#building" target="_top">build</a> completes successfully,
      and produces a working set of binaries,
      it can be useful to tag the working sources.
      This allows rewinding to a working build tree with a single CVS
      command in the event that the current tree becomes unbuildable
      for any reason. This can be performed by issuing the following
      command:</p>
<pre class="programlisting">$ cvs tag successful-build-<span class="emphasis"><em>build date</em></span></pre>

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

    <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
<li class="listitem">If the NetBSD customised version of CVS, which recognises
	<span class="bold"><strong>$Net</strong></span><span class="bold"><strong>BSD$</strong></span> markers in files, is not used, the
	NetBSD revision number of the file is available for reference
	purposes when build problems occur.</li>
<li class="listitem">The sup/import/merge sequence described above is quite
	easily automatable. The following Perl script automates this
	process.
<pre class="programlisting">#!/usr/pkg/bin/perl
#
# Script to SUP NetBSD-current, import it into CVS and merge it with
# any local changes.
#
# NOTES:
# This script does no error handling so is not really suitable for
# non-interactive use.
#
# This script has only been test with cvs-1.10.1 and cvs-1.9.18.
#
$SRCROOT="/usr/src/netbsd";
$IMPORTROOT="/misc/import";
$CVSROOT="/misc/cvsrep";
#run the sup into a perl stream
system "/usr/sbin/sup -zsv" ; # This may need to change for none
                              # current systems

# now import the new files into CVS

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

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

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

# Now do the import.
$lastimport = `cat /usr/src/netbsd/.tag`; # `s are backquotes
$lastimport =~ s/\n//; # strip off any trailing newline in the string
system "/usr/local/bin/cvs update -j $lastimport  -j
current-$shortdate ";
# Now write the current file into tag save file
open TAG,"&gt;$SRCROOT/.tag" or die "Could not open new tag file";
 print TAG "current-$shortdate";
close TAG;
</pre>
    <p>This script was written in Perl since it is the scripting tool
	  which the author has the most experience with. It should
	  be fairly straightforward to write a shell script to perform
      the same task.</p>
</li>
<li class="listitem">Techniques for tracking current with CVS have been discussed
        several times on the NetBSD current-users mailing list. For
	alternative techniques try searching the NetBSD mailing lists.</li>
</ul></div>
    <p>
    If you have any comments or suggestions please send them to
    Mike Pumford <code class="email">&lt;<a class="email" href="mailto:mpumford@black-star.demon.co.uk">mpumford@black-star.demon.co.uk</a>&gt;</code> (who maintains this entry) or
    <code class="email">&lt;<a class="email" href="mailto:www@NetBSD.org">www@NetBSD.org</a>&gt;</code>.
</p>
</div>

<h4 class="title">
<a name="getrepos"></a>Getting the whole repository</h4>
<p>

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

The method 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 method to retrieve the whole repository, via rsync, is:

</p>
<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>
<p>
</p>
<pre class="programlisting">rsync -v -a --delete --exclude '#cvs.lock' rsync://anoncvs.NetBSD.org/cvsroot/src .</pre>
<p>
     </p>
<p>Please see our <a class="ulink" href="../../mirrors/#rsync" target="_top">list of rsync mirrors</a>!</p>
<p>
</p>
</div></div></div>
<div class="navfoot"></div>
<div id="footer"><div id="footerContent"><center>
<span class="footfeed"><a href="//www.NetBSD.org/cgi-bin/feedback.cgi">
	  Contact</a> |
      </span><span class="footcopy"><a href="../../about/disclaimer.html">
      Disclaimer</a> |

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