Port Testing Guide

Index

• Introduction
• How
• First step
• Testing
• Commenting
• More testing

Introduction

The ports tree is an huge piece of work that permits OpenBSD users to use third-party programs without losing time in patching, configuring, etc. This work is done by a few volunteers who spend hours making your favorite applications work fine on your system. Many people think that they can't help our project because they don't have enough knowledge; this is false because they can help porters work better and faster.

How

Simply by testing submitted updates or new ports which are posted on 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!).

First step

Before starting the tester must have in mind that ports development is done with OpenBSD-current as target.This means that there is no guarantee that new ports will work correctly on the other branches. This also means that the tester should upgrade his system to -current as well as the ports tree (instructions on how to do this can be found at the anoncvs page and in the proper faq section. Having this done, the system is now prepared to do port testing. It is also advisable the subscription of ports and ports-changes mailing-lists, this way the tester will be notified about new/updated ports (to be tested) and about changes in the ports tree.

Testing

In the mailing-lists two types of submission can be found; new ports and updates. New ports are generally posted as tarball attachment (or an url is given) which contains the port tree. A good idea is to extract it into the /usr/ports/mystuff/ directory and test the port from here. Updates are generally a diff against current ports tree, so it is suggested to copy the port in mystuff/ and apply the diff to prevent tree breakage.

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

• fetch : Needed to verify that distfile(s) are correctly downloaded.
• extract : Generally extract is done without a problem, this target can be ignored in most cases.
• patch : Check if patches are applied correctly and track down forgotten .orig files.
• configure : For ports which use a configure script the tester can verify if it has the correct path for dependencies, use(less) features, etc ...
• build : The build itself should not give errors but could contain minor warnings about tmpnam(3) issues to be resolved by using mkstemp(3).
• fake : This target fakes installation of the package and prepares its installation. Checking can be done by verifying that files are properly installed in the fake directory.
• package : Package creation can break if pkg/PLIST* and/or pkg/PFRAG* are wrong.
• install : Check that package installation works fine.
• deinstall : Don't forget to test deinstall.

Checking of pkg/ files like DESCR, MESSAGE, INSTALL, DEINSTALL is also to be done

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.

Example :

    # make install | /usr/ports/infrastructure/build/portslogger .

This will redirect the output into a log file located in the current directory.

More testing

Check the port Makefile for typos, incorrect links, useless or missing variables, correct licensing and correct category. For those who are more skilled other targets can be tested like lib-depends-check. Patches and pkg directories deep verification as well as providing diffs to correct bugs, add flavors, or other enhancements.