OpenBSD Ports - Testing Guide [Handbook Index]



Introduction

The ports tree is a huge piece of work that permits OpenBSD users to use third party programs without wasting time patching, configuring and installing each one individually. This work is done by a group of volunteers who spend their time porting and testing applications across the range of OpenBSD platforms.

Many people think that they cannot help this process because they do not have enough knowledge, but this is wrong because they can help porters work better and faster. Test submitted updates or new ports which are posted on the ports mailing list. By doing this, you reduce the latency of commits and also increase the number of ports to be committed. Many ports are not committed because of lack of testing.

The ports tree is developed against -current; there is no guarantee that new ports or updates will work correctly on the other branches. This means you should upgrade your system and ports tree to -current. Instructions on how to do this can be found at the following current page. It is also recommended that you subscribe to the ports and ports-changes mailing lists. This way, you will be notified about new or updated ports and about changes in the ports tree.

Testing

There are two types of submissions on the mailing lists: new ports and updates. New ports are generally posted as tarball attachments or URLs. A good idea is to extract them into the /usr/ports/mystuff/ directory and test from there. Updates are generally a diff against the -current ports tree, so it is best to copy the port to mystuff/ and apply the diff to prevent tree breakage. If the previous version of the port is installed, it is a good idea to remove it before building the newer version to avoid side effects, like symbols missing from the older version of a library.

Step-by-step building is needed to verify that every target, see ports(7), is achieved correctly:

Remaining pkg/ files like DESCR and MESSAGE should be checked for grammar and typos. Paragraphs should be formatted using fmt(1) and wrapped at 80 characters.

Commenting

At the end of the test comes the really important thing: comments. Even if the port is working fine comments must be done. If we have ten posts where people say that the port runs fine under different architectures then the commit is done faster. If it does not work, then some information must be given. There are tools that can help in this task, like portslogger(1) which is like an "intelligent tee" that redirects output into a log file.

Example:

# make install 2>&1 | /usr/ports/infrastructure/bin/portslogger .
This will redirect the output into a log file located in the current directory.

Finally, once the port is found to be okay, other ports depending on it should also be tested, to check whether they are still working correctly. The show-required-by make target will help to find other ports which depend on the current one.

More Testing

Check the port's Makefile for correct dependencies, typos, incorrect links, useless or missing variables, correct licensing and categories. Those who are more skilled can help by examining patches, as well as providing diffs to correct bugs, add flavors, or other enhancements.

These diffs should be done with the -uNprx CVS options. cvs diff -uNp can also be used to generate patches against the CVS repository.