OpenBSD Journal

Contributing Part 2: Testing OpenBSD Ports

Contributed by deanna on from the too-much-free-time dept.

A previous article listed some requests to the community from the developers and offered suggestions on how we can become involved. Continuing the theme, here's a rough guide to testing new OpenBSD ports.

Major Disclaimer

As always with OpenBSD, there is a huge amount of official documentation available for everything that will be discussed. Links will be provided and it is expected that you'll read them all before doing anything that may render your system unusable. This process requires a decent amount of system administration skills and OpenBSD knowledge; you could pick a lot of this up along the way, but you are putting your system's stability at risk. This guide is intended for hobbyists and home users -- if you need to read it, then you probably have no business doing any of this at work, in production, or on someone else's machine. The author is in no way responsible for you trashing your system, even if the instructions here are in any way at fault. This is a rough guide; it would be wise to let it sit a while then check the comments for the inevitable corrections. With that out of the way, as Richard Gabriel says: let's rock.

Upgrade to a snapshot

Go to your nearest OpenBSD mirror and upgrade to a snapshot. I find it most convenient to download the files to disk, and upgrade from there, using a less frequently updated boot CD across upgrades.

Upgrade packages

Set your PKG_PATH to the package snapshot directory of the mirror you chose for your snapshot, and use pkg_add(1) to upgrade all of your ports/packages.

Check out the source tree

The step-by-step instructions for doing this are quite clear; however, now might be a good time to get familiar with cvs commands. They are notoriously many and confusing -- watch the changes list to see even developers screwing it up. The cvs commands you'll be using the most of are checkout, update, diff, and log.

Run mergemaster

Mergemaster is a nice little port that will check the source tree for changes to configuration files, alert you of these changes, and let you choose to install the new files or merge the changes in with your existing ones. You could do this by hand, of course; however you choose to do it, it should be done.

Check cruft

Things get removed or replaced. A recent example is wicontrol; if you're running -current, you shouldn't even have it. It is usually ok to keep things like this around, but they make a mess. In any case you should keep your system clean so that you don't introduce more complications into the testing process. Someone has surely come up with an automated way to scan for these cases; hopefully they'll share it.

At this point your system should be ready for testing ports.

Check out ports

Get a fresh checkout of ports from CVS. You should know how to do this by now; if not, stop here and start all over.

RTFL/RTFA

You should read the ports list. I'll sneak in a little plug for gmane here; it allows you to read and post to the mailing lists and the entire archive over nntp, which makes the content all on-demand. This is much more manageable than receiving a flood of actual email messages to your inbox, and obviates the hated "Please Cc me, I am not on the list" entirely.

Testing Ports

Though it's not necessary, it's cleanest to test your ports outside of the official tree, in a folder that is usually called '/usr/ports/mystuff'. Mystuff isn't just a cute name, it is recognized as part of the ports system, so everything that works in /usr/ports/subdir will work just fine if located under mystuff.

Applying patches, testing ported apps

Now, someone has posted a new port or a port upgrade to the list. Untar it in mystuff, or apply the patch. If it won't build, and you're sure it's not your fault, notify the list. If it does build, install it and start testing. There are plenty of people who test the build and packaging; what's most needed is for people to actually try to use the programs being ported. Read the docs, get an idea of what the program is supposed to do, and make sure that it does. Report success or failure to the list.

Eventually, you may want to test the port itself, rather than the program it creates. It seems that a full, new ports guide has been in the works since the epoch. For now your best bet is reading the list, the porting section on the OpenBSD web page, and the manual pages for ports, packages, make, bsd.port.mk, library-specs, packages-specs, and everything cross-referenced by these. When you have this down, you may then critique or improve others' ports. Until then, you should probably keep your hands off and just do functional testing.

Next installment: testing src and XF4.. which you, the reader, are most welcome to write and submit yourself!

(Comments are closed)


Comments
  1. By Chris Kuethe (129.128.11.75) on

    With regard to cleaning old cruft:

    find /*bin /usr/*bin /usr/lib* /usr/in* -type f -ctime +X

    where X is some reasonable number of days is a handy way to scan for old stuff. I upgraded two machines this morning and there weren't many files older than 180 days worth keeping. You can choose to "-exec rm '{}' \;", "-ls", "-print0 | xargs -0 " ... see if there is anything you want to keep, tar it up just in case or simply remove it.

    Comments
    1. By Matthias Kilian (84.134.31.132) on

      > With regard to cleaning old cruft:
      >
      > find /*bin /usr/*bin /usr/lib* /usr/in* -type f -ctime +X

      Or just use the checkflist scripts from the distrib/sets directories. The makefiles will tell how to use them. (and use your brain, too)

  2. By grg (219.90.242.217) on

    s/PKGPATH/PKG_PATH/

    Comments
    1. By Anonymous Coward (64.231.232.103) on

      > s/PKGPATH/PKG_PATH/

      indeed. thanks!

      (too bad mg lacks tab completion for environment variables:-)

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]