When very important fixes are made to -current, they are backported into the two supported -stable branches.
Every six months, -current is tagged and becomes the next -release: a frozen point in the history of the source tree.
In the above illustration, the vertical dotted lines denote bug fixes being incorporated into the -stable branches.,------o-----------o----X 5.7 Stable | . . | . ,------o---------o----X 5.8 Stable | . | . . | . | . ,----o----------o--> 5.9 Stable | . | . | . . | . | . | . ,-----o--> 6.0 Stable | . | . | . | . | . | . | . | . -->5.7Rel----->5.8Rel----->5.9Rel----->6.0Rel----> Current Time --->
It is worth pointing out that the name -stable is not intended to imply that -current is unreliable or less robust in production. Rather, the APIs (how the programs talk to the OS) and features of -current are changing and evolving, whereas the operation and APIs of -stable are the same as the release it is based on.
Most users should be running either -stable or -release. That being said, many people do run -current on production systems, and it is important that people do so to identify bugs and test new features.
It is possible that you may uncover bugs in snapshots. This is one of the reasons why they are built and distributed. If you find a bug in a snapshot, make sure it is reported.
If you desire to run -current, a recent snapshot is usually all you need. Upgrading to a snapshot is the starting point before building -current from source.
Details for building -current from source can be found on this page.
Make sure you have the closest available binaries installed. Use this table to look at where you are, where you wish to go, and what binary installation you should start with:
|You are at||Goal||Binary upgrade to||then ...|
|Old -release||New release||Newest release||Done!|
|-release||-stable||Newest release||Fetch & build -stable|
|Old -stable||-stable||Newest release||Fetch & build -stable|
|-release||-current||Latest snapshot||(optional) Fetch & build -current|
|Old -current||-current||Latest snapshot||(optional) Fetch & build -current|
It is recommended that you install the binary sets by using the (U)pgrade option of the install media. If that is not possible, you can also unpack the binary sets as described in the upgrade instructions of the release.
First, you must cvs checkout the source tree. After that, you maintain the tree by running cvs update to pull updated files to your local tree.
This change takes effect with exampleuser's next login.# user mod -G wsrc exampleuser
If you want to fetch xenocara or ports as this user, you must create the directories and set their permissions manually.
# cd /usr # mkdir -p xenocara ports # chgrp wsrc xenocara ports # chmod 775 xenocara ports
Once you have the tree checked out, you can update it at a later time with:$ cd /usr $ cvs -qd firstname.lastname@example.org:/cvs checkout -rOPENBSD_6_0 -P src
Replace src with xenocara or ports as appropriate. As all parts of OpenBSD must be kept in sync, all the trees you use should be checked out and updated at the same time.$ cd /usr/src $ cvs -q up -Pd
Update the tree with:$ cd /usr $ cvs -qd email@example.com:/cvs checkout -P src
Replace src with the module you want, such as xenocara or ports.$ cd /usr/src $ cvs -q up -Pd
If you are building -current, review changes and special build instructions listed on current.html.
Follow the detailed instructions in steps 2 and 3 of release(8).
The instructions on making a release are in release(8). The release process uses the binaries created in the /usr/obj directory in the building process above.
Note: if you wish to distribute the resulting file sets by HTTP for use by the upgrade or install scripts, you will need to add an index.txt file that contains the list of all the files in your newly created release.
If you'd like to cryptographically sign the sets you created, the signify(1) man page has details on how to do so.# ls -nT > index.txt
To simplify life for OpenBSD users, a meta-build called Xenocara was developed. This system converts X back into one big tree to be built in one process. As an added bonus, this build process is much more similar to the build process used by the rest of OpenBSD than the previous versions were.
The official instructions for building X exist in the xenocara/README file and in step 5 of release(8).
Most problems are usually one of the following:
$ cd /usr/src $ find . -type l -name obj | xargs rm $ make cleandir $ rm -rf /usr/obj/* $ make obj
You will probably find it best to repair or replace the components that are causing trouble, as problems may show themselves in other ways in the future.
For much more information, see the Sig11 FAQ.
...than to remove the contents of the directory with rm.# umount /usr/obj # newfs YourObjPartition # mount /usr/obj
When the developers bring up support for a new platform, one of the first big tests is a native-build. Building the system from source puts considerable load on the OS and machine, and does a very good job of testing how well the system really works. For this reason, OpenBSD does all the build process on the platform the build is being used for.
However, this will only correct your problem for one time. If you reboot, you will have to repeat this procedure. So, this is only a temporary fix, and you should correct the problem using config(8).
To boot into the User Kernel Config, or UKC, use the -c option at boot-time.
Doing this will bring up a UKC prompt. Type help for a list of available commands.boot> boot hd0a:/bsd -c
For safety's sake, use the -o option which writes the changes out to the file specified. For example: config -e -o bsd.new /bsd will write the changes to bsd.new. Kernel modification examples are given in the config(8) man page.
Read the config(8) and the options(4) man pages first. The following steps are part of compiling a custom kernel:
$ cd /usr/src/sys/arch/$(machine)/conf $ cp GENERIC CUSTOM $ vi CUSTOM # make your changes $ config CUSTOM $ cd ../compile/CUSTOM $ make