|
|
NetBSD Documentation:Tracking NetBSD-current |
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.
binary/sets directory,
and mget *.tgz files
into your favorite local administrative directory
(for example, $HOME/current);
when limited by disk space and/or time,
only kern-GENERIC, etc, base, and comp (if you want a compiler) are essential.
/etc and kernel:
/etc
before replacing basic utilities:
base,
and any other desirable feature sets:
At this point, you are relatively current and ready to build your own current source.
/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).
These files represent a snapshot of the source tree.
For the most up-to-date files
using anoncvs,
cd /usr/src
cvs -q -d $CVSROOT update -dP
The -d $CVSROOT is only needed on the first update,
to populate the CVS tags with your selected mirror.
Remember to always use the -P flag or add it to your .cvsrc file.
If you wish to track local changes to the NetBSD source you might want to setup a local CVS tree, and then import the sup 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.
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.
Once the kernel is running, you should have a look at the BUILDING. file at the base of the source tree, and use the build.sh script to build a new userland.
build.sh
*: Unless you are certain there have been no new system calls added, but do it anyway; it's safer.
./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.
(use password "anoncvs")$ cd /usr $ cvs login
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.
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.
$ cd /usr $ cvs checkout -P src/sys
This gives you the kernel sources in /usr/src/sys. Information on how to build a kernel is also available.
$ cd /usr $ cvs checkout -P src
You should now have a full set of NetBSD sources in /usr/src.
Note: it is almost always faster for a first-time "whole source" checkout to FTP the tarballs 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.
# chown -R user /usr/src
$ cd /usr/src/sys $ cvs update -dP
$ cd /usr/src $ cvs update -dP
Note: Running cvs checkout -d dir src (or similar commands with the other src* modules) does not work. You will get error messages saying "existing repository ... does not match ...; ignoring module _gnusrc-cmp" etc. The workaround is to drop the -d option and let cvs create the default directory.
$ cvs checkout -D 20020501-UTC src
See src/doc/BRANCHES for a description of the branches in the CVS repository.$ cvs checkout -rnetbsd-1-6 src
$ cd /parent/dir/to/checkout/into $ mkdir NewName-temp $ cd NewName-temp $ cvs checkout ... src $ mv src ../NewName $ cd .. $ rmdir NewName-temp
you should do acvs [update aborted]: could not chdir to gnu/usr.bin/gdb/gdb: Not a directory
make cleandir and try again. Make sure to
run make obj after the cvs update.
-z5
(or some other number from 1 to 9) to your commandline before the
command (eg "cvs -z5 update -dP"); this turns on
compression of all data. Keep in mind that this will put extra
load on the cvs server!
Note: some versions of cvs (notably version 1.11.5) may lead to errors when using the '-z' flag. If you receive errors, try to either upgrade cvs or disable compression by leaving out the '-z' flag.
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:
cvs -q -z5 update -dP checkout -P diff -u
To build userland the first time:
# 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=/
To update userland binaries after a CVS update:
These will install the new binaries on the running system - reboot to make sure they all take effect.# 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=/
If you update system frequently and want the build to directly update your running system, you can use expert mode and build with DESTDIR=/, eg:
Note this is for expert 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 sure the build will finish successfully.# ./build.sh -E -O /usr/obj -T /usr/tools -u build
Current can be tracked in the following way. The baseline copy of the sources is kept up to date using sup approximately once a week. as normal. This baseline source tree is then imported into a local CVS repository. Current is then built from a checked out copy of the repository.
There are 3 major reasons for this approach
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.
Tracking and building current consists of 6 phases:
Sources can be supped from any NetBSD sup server and the output from the SUP should be stored in a file for later reference.
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
./build.sh -T /usr/tools -O /usr/obj .
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
#!/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,">$SRCROOT/.tag" or die "Could not open new tag file"; print TAG "current-$shortdate"; close TAG;
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.
If you have any comments or suggestions please send them to Mike Pumford mpumford@black-star.demon.co.uk (who maintains this entry) or www@NetBSD.org.
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:
After that, run "sup /path/to/supfile anoncvs" to retrieve the files.anoncvs release=all host=sup.NetBSD.org hostbase=/ftp/pub base=/usr prefix=/usr backup use-rel-suffix compress
Some example sup files are available in /usr/share/examples/supfiles. Also, check our list of SUP mirrors to find the server closest to you!
Please see our list of FTP mirrors!
Please see our list of rsync mirrors!rsync -v -a rsync://rsync.NetBSD.org/anoncvs/
Please see our list of CVSup mirrors!*default host=cvsup.de.NetBSD.org *default base=/usr *default prefix=/local/NetBSD-cvs *default release=cvs *default delete use-rel-suffix *default compress netbsd
# cd /usr/pkgsrc/sysutils # cvs update -dP etcupdate
# cd /usr/pkgsrc/sysutils/etcupdate # make install clean
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:# etcupdate
# etcupdate -s /home/jdoe/netbsd/src/etc
# mkdir /tmp/temproot # cd /tmp/temproot # tar xpzf /some/where/etc.tgz # etcupdate -b /tmp/temproot
# fsck -p # mount -vt nonfs # cd /dev # ./MAKEDEV wscons
./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:
So, if you do not want to rebuild nbmake, you will need to pass# 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. #
-T tooldir or set the TOOLDIR variable in the
environment.
|
|
