Annotation of wikisrc/tracking_current.mdwn, revision 1.2

1.1       jdf         1: # Tracking NetBSD-current
                      3: **Contents**
                      5: [[!toc levels=2]]
                      7: ## Why track NetBSD-current?
                      9: The developers of NetBSD have made the current development sources
                     10: available to the public for several reasons. Overall, providing
                     11: NetBSD-current helps us to create a more stable, accessible system.
                     13: It makes it easier for people to become involved in the development of
                     14: NetBSD. Distributing the current development sources allows a greater
                     15: number of people to see where the system is going, and to become
                     16: involved with new features as they are implemented.
                     18: It also makes changes from users easier to integrate. If users make
                     19: changes against the current development sources, then virtually no
                     20: integration is needed to get them into the master source tree.
                     22: It also allows wider testing of the software as it is developed. Users
                     23: of NetBSD-current are encouraged to send in
                     24: [bug reports]( about the current sources,
                     25: and that helps find and fix bugs. Because people are testing the software soon
                     26: after it's written, more bugs can be found and eliminated.
                     28: ## Things you need to remember
                     30:  * People using NetBSD-current are strongly encouraged to subscribe to
                     31:    the [current-users]( mailing
                     32:    list. The [source-changes](
                     33:    mailing list is also of interest.
                     35:  * When upgrading to a more recent version of -current you should
1.2     ! jdf        36:    *always* install and boot a new kernel before installing any new libs (unless 
        !            37:    you are certain there have been no new system calls added, but do it anyway; 
        !            38:    it's safer).In general the best approach is to try the new kernel before 
        !            39:    anything else, and if you hit any problems see the entry in the
        !            40:    [Kernel FAQ](
1.1       jdf        41: 
                     42:  * When compiling a -current kernel, always remember to include the
                     43:    `COMPAT_<lastrelease>` option (e.g., `COMPAT_16`). As current diverges from
                     44:    the last s"table release, compatibility code will be added, but it will only
                     45:    be enabled if this option is present. At a bare minimum, you will need this
                     46:    compatibility code for the time between booting the new kernel and finishing
                     47:    your build via ``
                     49: ## Updating an existing system from a current snapshot
                     51: *Please remember to check
                     52: [src/UPDATING]( for
                     53: quirks around certain specific changes.*
                     55: To quickly begin using current, start with a snapshot generated by release
                     56: engineering. The current status of each platform can be seen at
                     57: [NetBSD Autobuild]( and the
                     58: corresponding releases found in by date and platform.
                     60:  1. Hunt down to the desired `binary/sets` directory, and `mget *.tgz` files
                     61:     into your favorite local administrative directory (for example,
                     62:     `$HOME/current`); when limited by disk space and/or time, only
                     63:        `kern-GENERIC`, `etc`, `base`, and `comp` (if you want a compiler) are
                     64:        essential.
                     65:  2. Extract the desired kernel (usually `GENERIC`), copy it into (root) directory.
                     67:         # cd /root
                     68:         # tar -zxpf ~/kern-GENERIC.tgz
                     69:         # ln -fh /netbsd /netbsd.old
                     70:         # cp netbsd /
                     71:         # ln -fh / /netbsd
                     73:     > **Warning**: Don't extract any userland binary sets before rebooting your
                     74:     > machine with the new kernel. Newer binaries might use new system calls an
                     75:     > old running kernel doesn't support.
                     77:  3. Check if there are any other files which might also be required by a new
                     78:     kernel. Again,
                     79:     [src/UPDATING](
                     80:     might mention possible quirks on daily changes.
                     82:        The following items are typical files that possibly need to be updated:
                     84:      1. bootloader
                     86:         Usually a machine specific bootloader passes several parameters to a 
                     87:         loaded kernel. If some new parameters have been added or some existing 
                     88:         APIs between bootloader and kernel are changed you might also have to 
                     89:         install new bootloader files for a new kernel to handle new features. A 
                     90:         method to update bootloader files is quite machine dependent, so check 
                     91:         boot(8) and installboot(8) man pages for details.
                     94:         On i386 and amd64, if you are using FFSv1 for root file system on `wd0a` 
                     95:         (i.e. first ATA drive), typical commands to update bootloaders are:
                     97:             # tar -C /tmp -zxf ~/base.tgz ./usr/mdec
                     98:             # cp /tmp/usr/mdec/boot /
                     99:             # installboot -v /dev/rwd0a /tmp/usr/mdec/bootxx_ffsv1
                    101:         If you are using FFSv2 for root file system use the following commands 
                    102:         instead:
                    104:             # tar -C /tmp -zxf ~/base.tgz ./usr/mdec
                    105:             # cp /tmp/usr/mdec/boot /
                    106:             # installboot -v /dev/rwd0a /tmp/usr/mdec/bootxx_ffsv2
                    108:         Note `/usr/mdec/bootxx_ffsv1` and `/usr/mdec/bootxx_ffsv2` are primary 
                    109:         bootloaders which are file system dependent. `/usr/mdec/boot` is 
                    110:         secondary loader and it's file system independenet.
                    112:         If you forget your root file system type (FFSv1 or FFSv2), you can check 
                    113:         it by dumpfs(8) command:
                    115:             # dumpfs /dev/rwd0a | head -3
                    116:             file system: /dev/rwd0a
                    117:             format  FFSv2
                    118:             endian  little-endian
                    120:      2. kernel modules
                    122:         A new framework *kernel modules* has been introduced after netbsd-5 was 
                    123:         branched, and `GENERIC` kernel on i386 port has been switched to using 
                    124:         the kernel module files since November 2008. The kernel module files 
                    125:         will be loaded dynamically by the kernel to support various kernel 
                    126:         options (including file systems) on demand, rather than linking all 
                    127:         necessary (but possibly unused) object files into the kernel binary. 
                    128:         This means if you are trying to boot a new `GENERIC` kernel, you also 
                    129:         have to prepare new kernel module files for the new kernel. 
                    131:         To prepare new kernel module files, you can simply use a new `modules` 
                    132:         set file which has been prepared since September 2009:
                    134:             # cd /
                    135:             # tar -zxpf ~/modules.tgz
                    137:         Note i386 port also provides `MONOLITHIC` kernel binary in 
                    138:         `kern-MONOLITHIC.tgz` set file since October 2009. The `MONOLITHIC` 
                    139:         kernel includes all necessary options in its kernel as well as 5.0 and 
                    140:         prior `GENERIC` kernels and it doesn't depend on kernel module files at 
                    141:         all. If you would just like to test new features of a new kernel without 
                    142:         updating kernel modules, using `MONOLITHIC` kernel is easier way for the 
                    143:         first and quick trial. 
                    145:         It's also a good idea to put an old `MONOLITHIC` kernel into `/` (root) 
                    146:         directory for emergency and recovery because if newer modules have some 
                    147:         fatal issue there is no easy way to specify an alternative path of old 
                    148:         module files to a modular'ized kernel (and you can't rename directories 
                    149:         without a working kernel).
                    151:         **Warning**: The infrastructure of kernel module files mentioned here is 
                    152:         still under discussion on -current development. It could be changed at 
                    153:         some point before the next 6.0 release and in that case the description 
                    154:         in this section will be obsolete. Again, check 
                    155:         [src/UPDATING]( 
                    156:         and
                    157:         [currenet-users mailing list](
                    158:         for updated information.
                    160:         There is
                    161:         [a possible alternative structure for kernel modules](
                    162:         which was proposed on May 2009, but we have not got any conclusion yet. 
                    163:         This would be because most -current users build their own custom kernels 
                    164:         from sources, but kernel modules might be rather useful for users who 
                    165:         don't want to bother to compile their own kernels from sources to just 
                    166:         try to use optinal functions. Anyway, any feedback about this brandnew 
                    167:         kernel modules is quite appreciated.
                    169:  4. Reboot machine with the new kernel:
                    171:         # shutdown -r now
                    173:  5. Make sure the new kernel boots and works properly. If your new kernel has
                    174:     any trouble, you can recover it by loading the renamed old one. If you are 
                    175:     using modular'ized GENERIC kernel mentioned above, you might also have to 
                    176:     restore old kernel module files.
                    178:  6. Extract the matching base, and any other desirable feature sets **except 
                    179:     etc**:
                    181:         # cd /
                    182:         # tar -zxpf ~/base.tgz
                    183:         # tar -zxpf ~/comp.tgz
                    184:         # ...
                    187:     Don't forget to specify "p" option (preserve permissions) on tar(1) command 
                    188:     otherwise setuid'ed commands (like su(1)) won't work.
                    190:     **Warning**: Extracting `etc.tgz` on the installed system will overwrite your 
                    191:     local settings.
                    193:  7. [Update]( `/etc` as the 
                    194:     last step: postinstall(8) will first check and fix most things that can be 
                    195:     automated, and etcupdate(8) in the second step will ask on what to merge:
                    197:         # /usr/sbin/postinstall -s ~/etc.tgz check
                    198:         # /usr/sbin/postinstall -s ~/etc.tgz fix
                    199:         # /usr/sbin/etcupdate -s ~/etc.tgz
                    200:         # shutdown -r now
                    202:     If you have the X sets installed (xbase, ...), you can repeat the 
                    203:        postinstall and etcupdate steps with xetc.tgz as argument before rebooting.
                    205: At this point, you are relatively current and ready to build your own current 
                    206: source.
                    208: ## Downloading current source
                    210: See the [Obtaining the sources]( 
                    211: section in the [[NetBSD Guide|guide/index]].
                    213: ## Building a release from source
                    215: See the [Crosscompiling NetBSD]( 
                    216: section in the [[NetBSD Guide|guide/index]].
                    218: ## Updating an existing system from source
                    220: See the [[Updating an existing system from sources|guide/updating]] section in 
                    221: the [[NetBSD Guide|guide/index]].
                    223: ## Updating the configuration and startup files
1.2     ! jdf       225: See the
        !           226: [[More details about the updating of configuration and startup files|guide/updating]]
        !           227: section in the [[NetBSD Guide|guide/index]].
1.1       jdf       228: 
                    229: ## What if I get an error?
                    231: If you try to build -current, either from a snapshot or an earlier -current, and 
                    232: it doesn't work, don't panic. Try these steps:
                    234:  1. Read the 
                    235:     [src/UPDATING]( 
                    236:     file from the release you're trying to build.
                    238:  2. Read the [current-users archive](
                    239:     for hints.
                    241:  3. Update again. You may have caught the repository in the middle of a commit 
                    242:     to several related files, or the problem might have already been fixed.
                    244:  4. If all else fails, send email to current-users explaining the problem. 
                    245:     Include the date, time, and method you used to get your -current sources, as 
                    246:     well as any local changes you've made. Then put in a **short** script that 
                    247:     includes the error messages you're getting. Somebody will probably fix the 
                    248:     problem momentarily.
                    250: ## Tracking NetBSD-current with anoncvs
                    252: See the
                    253: [Fetching by CVS](
                    254: section in the [[NetBSD Guide|guide/index]].
                    256: ### To check out the sources from a certain date
                    258:     $ cvs checkout -D 20020501-UTC src
                    260: ### To check out the sources from a certain branch
                    262:     $ cvs checkout -rnetbsd-5-0 src
                    264: See 
                    265: [src/doc/BRANCHES]( 
                    266: for a description of the branches in the CVS repository.
                    268: ### Useful hints
                    270:  * Do not use the cvs `-z` flag. The data stream gets out of sync,
                    271:    leading to corruption on the client, or causing the client to hang
                    272:    completely. The additional load is also hard on the cvs server.
                    273:  * If you want to check out a certain branch of the tree, you may want
                    274:    to take caution not to overwrite any existing directories by
                    275:    creating a new directory for this branch:
                    277:        $ cd /parent/dir/to/checkout/into
                    278:        $ mkdir NewName-temp
                    279:        $ cd NewName-temp
                    280:        $ cvs checkout ... src
                    281:        $ mv src ../NewName
                    282:        $ cd ..
                    283:        $ rmdir NewName-temp
                    285:  * You will have to use objdirs in order for cvs updates to work correctly. If 
                    286:    you happen to get errors from cvs saying things like:
                    288:        cvs [update aborted]: could not chdir to gnu/usr.bin/gdb/gdb: Not a directory
                    290:    You should do a make cleandir and try again. Make sure to run make obj after 
                    291:    the cvs update.
                    293:  * You can put switches for specific commands in a `.cvsrc` in your home 
                    294:    directory, and they will be automatically used. A sample `.cvsrc` would be:
                    296:        update -dP
                    297:          checkout -P
                    298:          diff -u
                    300: ## Importing and merging sources.
                    302: Sources are imported as follows:
                    304:     $ cvs -d /misc/cvsrep import -I ! -I CVS netbsd netbsd current-date
                    306: `date` is replaced by the date of the SUP for tracking purposes. The
                    307: `-I ! -I CVS` options ensure that no file in the source tree is ignored
                    308: except 'CVS' directories. This is because some NetBSD source files have
                    309: extensions which are normally ignored by CVS. If there are any conflicts
                    310: with local patches the import command will report them and will describe
                    311: a command to merge the conflicts something like:
                    313:     $ cvs checkout -jnetbsd:yesterday -jnetbsd netbsd
                    315: This merge command will correctly merge the imported NetBSD sources but
                    316: it will not handle the removal of files locally which have already been
                    317: removed by the SUP process. To do this the merge command would be:
                    319:     $ cvs update -jprevious_import_tag -j current-date
                    321: `previous_import_tag` should be replaced with the name of the tag used
                    322: for the previous cvs import. `date` should be replaced with the current
                    323: date to yield the same tag used on the current import that has just been
                    324: merged.
                    326: The conflicts reported by the import command are potential conflicts.
                    327: These are usually merged by the update command but in some cases a real
                    328: conflict occurs. In these cases a manual merge of the conflicting lines
                    329: will be required. A real conflict will be reported in the cvs update
                    330: output as a `C` followed by a filename.
                    332: Merging conflicts manually is not a simple process but in most cases it
                    333: should be resolved by removing the local changes and making the file
                    334: like the original NetBSD source code.
                    336: CVS marks conflicts as follows:
                    338:     <<<<<<
                    339:       code from local file
                    340:     ======
                    341:       code from imported file
                    342:     >>>>>> local revision number of newly imported revision
                    344: If the import reports no conflicts the checked out copy of the tree
                    345: should be updated in exactly the same way as for the conflicts case.
                    347: All update and checkout commands should be done in the directory where
                    348: the sources have been checked out. On my system this is
                    349: `/usr/src/netbsd`.
                    351: If this is the first import then there will be no sources checked out.
                    352: Assuming you wish to create the source tree in `/usr/src/netbsd` The
                    353: following commands will check out the source and no merge step is
                    354: required.
                    356:     $ cd /usr/src
                    357:     $ cvs -d /misc/cvsrep checkout netbsd
                    359: ## Tagging a successful build
                    361: If the build completes successfully, and produces a working set of binaries, it 
                    362: can be useful to tag the working sources. This allows rewinding to a working 
                    363: build tree with a single CVS command in the event that the current tree becomes 
                    364: unbuildable for any reason. This can be performed by issuing the following 
                    365: command:
                    367:     $ cvs tag successful-build-BUILD date
                    369: ### Notes
1.2     ! jdf       370:  * If the NetBSD customised version of CVS, which recognises *\$NetBSD\$*
1.1       jdf       371:    markers in files, is not used, the NetBSD revision number of the file is 
                    372:    available for reference purposes when build problems occur.
                    373:  * The sup/import/merge sequence described above is quite easily
                    374:    automatable. The following Perl script automates this process.
                    376:        #!/usr/pkg/bin/perl
                    377:        #
                    378:        # Script to SUP NetBSD-current, import it into CVS and merge it with
                    379:        # any local changes.
                    380:        #
                    381:        # NOTES:
                    382:        # This script does no error handling so is not really suitable for
                    383:        # non-interactive use.
                    384:        #
                    385:        # This script has only been test with cvs-1.10.1 and cvs-1.9.18.
                    386:        #
                    387:        $SRCROOT="/usr/src/netbsd";
                    388:        $IMPORTROOT="/misc/import";
                    389:        $CVSROOT="/misc/cvsrep";
                    390:        #run the sup into a perl stream
                    391:        system "/usr/sbin/sup -zsv" ; # This may need to change for none
                    392:                                      # current systems
                    393:        # now import the new files into CVS
                    395:        chdir $IMPORTROOT or die "Could not cd to $IMPORTROOT\n";
                    397:        ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime;
                    398:        $date = localtime;
                    399:        $shortdate = sprintf "%02d%02d%04d",$mday,$mon+1,1900+$year;
                    400:        system "/usr/local/bin/cvs -d$CVSROOT import -I ! -m\"SUP Import $date\" netbsd netbsd current-$shortdate ";
                    402:        # make the working directory the local NetBSD Tree
                    403:        chdir $SRCROOT or die "Could not change to $SRCROOT directory\n";
                    405:        # Now do the import.
                    406:        $lastimport = `cat /usr/src/netbsd/.tag`; # `s are backquotes
                    407:        $lastimport =~ s/\n//; # strip off any trailing newline in the string
                    408:        system "/usr/local/bin/cvs update -j $lastimport  -j
                    409:        current-$shortdate ";
                    410:        # Now write the current file into tag save file
                    411:        open TAG,">$SRCROOT/.tag" or die "Could not open new tag file";
                    412:         print TAG "current-$shortdate";
                    413:        close TAG;
                    415:    This script was written in Perl since it is the scripting tool which the 
                    416:    author has the most experience with. It should be fairly straightforward to 
                    417:    write a shell script to perform the same task.
                    419:  * Techniques for tracking current with CVS have been discussed several times on 
                    420:    the NetBSD current-users mailing list. For alternative techniques try 
                    421:    searching the NetBSD mailing lists.
                    423: If you have any comments or suggestions please send them to
                    424: [Mike Pumford]( (who maintains this 
                    425: entry) or <>.
                    427: ## Getting the whole repository
                    429: All the procedures described above allow you keeping your own changes in your 
                    430: repository, which has its advantages if you develop your own software based on 
                    431: NetBSD. If you don't want to maintain your own CVS repository, but just want to 
                    432: mirror NetBSD's CVS repository, there are three ways to do so.
                    434: Each of the methods described briefly below will get you a copy of the NetBSD 
                    435: CVS repository (i.e. the RCS ,v files, not the checked out files!). You can then 
                    436: setup your own anoncvs server or check out to a local harddisk. It's also useful 
                    437: for fast access to the history information stored in the repository.
                    439: The methods to retrieve the whole repository are:
                    441:  * **sup**
                    443:    If you use sup already to mirror other parts of the NetBSD source,
                    444:    you will want to add the following lines to your sup config file:
                    446:        anoncvs release=all hostbase=/ftp/pub \
                    447:        base=/usr prefix=/usr backup use-rel-suffix compress
                    449:    After that, run `sup /path/to/supfile anoncvs` to retrieve the files.
                    451:    Some example sup files are available in `/usr/share/examples/supfiles`. Also, 
                    452:    check our
                    453:    [list of SUP mirrors]( to find the server 
                    454:    closest to you!
                    456:  * **rsync**
                    458:    Note that rsync puts quite a heavy load on our rsync server, and as such the 
                    459:    number of concurrent rsync users is restricted. If you still want to try 
                    460:    rsync, the command to retrieve the repository is:
                    462:        $ rsync -v -a --delete --exclude '#cvs.lock' rsync:// .
                    464:    Please see our [list of rsync mirrors](!
                    466:  * **cvsup**
                    468:  * CVSup is not currently available for all NetBSD architectures, since the M3 
                    469:    compiler has not been ported. On i386, you can mirror the repository from 
                    470: with the `devel/cvsup` package and the following config 
                    471:    file:
                    473:        *default
                    474:        *default base=/usr
                    475:        *default prefix=/local/NetBSD-cvs
                    476:        *default release=cvs
                    477:        *default delete use-rel-suffix
                    478:        *default compress
                    480:        netbsd
                    482:    Please see our [list of CVSup mirrors](!

CVSweb for NetBSD wikisrc <> software: FreeBSD-CVSweb