Tracking NetBSD-current

Frequently asked questions

• Why track NetBSD-current?
• Installing a current snapshot
• Downloading current source
• Building a release from source
• Updating an existing system
• Things you need to remember
• What are the various Makefile targets?
• Using anoncvs
• Using anoncvs over ssh
• Tracking NetBSD-current with anoncvs
• Tracking NetBSD-current with SUP into CVS
• Supping sources
• Importing and merging sources.
• Building current.
• Tagging a successful build
• Getting the whole repository
• What if I get an error?
• Updating the configuration and startup files with etcupdate

Specific problems

• Console dead after updating to wscons
• Why does build.sh always rebuild nbmake first?

Frequently asked questions

Why track NetBSD-current? (top)

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.

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.

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.

It also allows wider testing of the software as it is developed. Users of NetBSD-current are encouraged to send in bug reports 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.

Installing a current snapshot (top)

To quickly begin using current, start with a snapshot generated by release engineering. The current status of each platform can be seen at NetBSD Autobuild and the corresponding releases found in ftp://ftp.NetBSD.org/pub/NetBSD-daily/HEAD/ by date and platform.

At this point, you are relatively current and ready to build your own current source.

Downloading current source (top)

Traditionally, the system source files are kept at /usr/src, but this generally requires root privileges. The current build.sh process can run entirely unprivileged, although installation still requires root priviledges. Whenever examples in this document assume /usr/src, you can substitute another location (such as $HOME/current).

Building a release from source (top)

Please remember to check src/BUILDING for the latest changes.

Traditionally, the system object files were kept at /usr/obj, 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 /usr/src, you can substitute another location (such as $HOME/current).

In this example, the -u option indicates that a make clean 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.

The -U option allows the entire build by a non-root user.

When completed, you should have everything you need to install in a directory that build.sh selects (and will display), including install media and notes.

If you wish to cross compile for a different architecture, include '-m MACHINE -a ARCH' when running build.sh.

For more details, run './build.sh -h', and see /usr/src/BUILDING.

Updating an existing system (top)

Please remember to check src/UPDATING for the latest changes.

In this example, the -u option indicates an update process, and the -U option allows the entire build by a non-root user followed with an install by root.

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.

For more details, see /usr/src/UPDATING.

Things you need to remember (top)

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

What are the various Makefile targets? (top)

For further documentation concerning usage of the new toolchain through the script 'build.sh' (in the toplevel source directory), run './build.sh -h', and see /usr/src/BUILDING.

WARNING: The usage of 'make build' has been deprecated by the updated toolchain, and is strongly discouraged.

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.

Of course, don't invoke ./build.sh install=/ unless the ./build.sh build has succeeded previously or it's entirely possible to end up with a non-working system.

Using anoncvs (top)

These instructions cover unencrypted anoncvs connections. If you wish to use encryption protocols, see below.

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.

Using anoncvs over ssh (top)

The methods described in using anoncvs can be used over ssh to ensure the integrity of the sources you receive. However, this adds substantial overhead to the anoncvs servers.

Those servers in the mirrors that support ssh connections show the required information with each entry.

In general, remove the ':pserver:' prefix on the cvsroot, and set the variable CVS_RSH to 'ssh', using the method appropriate for your shell.

Tracking NetBSD-current with anoncvs (top)

$ cvs checkout -D 20020501-UTC src

$ cvs checkout -rnetbsd-1-6 src

# 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=/

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

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

Tracking NetBSD-current with SUP into CVS (top)

Supping sources (top)

Sources can be supped from any NetBSD sup server and the output from the SUP should be stored in a file for later reference.

Importing and merging sources. (top)

Sources are imported as follows:

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

date is replaced by the date of the SUP for tracking purposes. The -I ! -I CVS 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:

$ cvs checkout -jnetbsd:yesterday -jnetbsd netbsd

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:

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

previous import tag should be replaced with the name of the tag used for the previous cvs import. date should be replaced with the current date to yield the same tag used on the current import that has just been merged.

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 C followed by a filename.

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.

CVS marks conflicts as follows:

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

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.

All update and checkout commands should be done in the directory where the sources have been checked out. On my system this is /usr/src/netbsd.

If this is the first import then there will be no sources checked out. Assuming you wish to create the source tree in '/usr/src/netbsd' The following commands will check out the source and no merge step is required.

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

Building current. (top)

Tagging a successful build (top)

If the build 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:

$ cvs tag successful-build-build date

Getting the whole repository (top)

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 four ways to do so.

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.

The methods to retrieve the whole repository are:

What if I get an error? (top)

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:

Updating the configuration and startup files with etcupdate (top)

# etcupdate

# etcupdate -s /home/jdoe/netbsd/src/etc

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

Specific problems

Console dead after updating to wscons (top)

You should copy a current MAKEDEV from the appropriate etc.port directory in src/etc, into /dev, boot single user, then type:

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

Why does build.sh always rebuild nbmake first? (top)

Even after running ./build.sh tools and using the -u flag or specifing TOOLDIR in /etc/mk.conf, nbmake is always rebuilt by build.sh. This is normal. The reason for this can be found in ./build.sh itself, in the function rebuildmake:

        # 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.
        #               

So, if you do not want to rebuild nbmake, you will need to pass -T tooldir or set the TOOLDIR variable in the environment.

---

Home page

---