11 Ports Specific FAQ

First, please read the section about repository copy.

The easiest way to add a new port is to use the addport script on freefall. It will add a port from the directory you specify, determining the category automatically from the port Makefile. It will also add an entry to the CVSROOT/modules file and the port's category Makefile. It was written by Michael Haro <mharo@FreeBSD.org> and Will Andrews <will@FreeBSD.org>, but Will is the current maintainer so please send questions/patches about addport to him.

Check the port, preferably to make sure it compiles and packages correctly. This is the recommended sequence:

    # make install
    # make package
    # make deinstall
    # pkg_add package you built above
    # make deinstall
    # make reinstall
    # make package
           

The Porters Handbook contains more detailed instructions.

Use portlint(1) to check the syntax of the port. You do not necessarily have to eliminate all warnings but make sure you have fixed the simple ones.

If the port came from a submitter who has not contributed to the project before, add that person's name to the Additional Contributors section of the FreeBSD Contributors List.

Close the PR if the port came in as a PR. To close a PR, just do edit-pr PR# on freefall and change the state from open to closed. You will be asked to enter a log message and then you are done.

When you want to add a port that is related to any port that is already in the tree in a separate directory, please send mail to the ports manager asking about it. Here related means it is a different version or a slightly modified version. Examples are print/ghostscript* (different versions) and x11-wm/windowmaker* (English-only and internationalized version).

Another example is when a port is moved from one subdirectory to another, or when you want to change the name of a directory because the author(s) renamed their software even though it is a descendant of a port already in a tree.

When there is no history to preserve. If a port is added into a wrong category and is moved immediately, it suffices to simply cvs remove the old one and addport the new one.

Send mail to the ports manager, who will do a copy from the old location/name to the new location/name. You will then get a notice, at which point you are expected to perform the following:

• When a port has been repo copied:

  1. Upgrade the copied port to the new version (remember to change the PORTNAME so there aren't duplicate ports with the same name).

  2. Add the new subdirectory to the SUBDIR listing in the parent directory Makefile. You can run make checksubdirs in the parent directory to check this.

  3. If the port changed categories, modify the CATEGORIES line of the port's Makefile accordingly

  4. Add the new module entry.

• When removing a port:

  1. Perform a thorough check of the ports collection for any dependencies on the old port location/name, and update them. Running grep on INDEX is not enough because some ports have dependencies enabled by compile-time options. A full grep -r of the ports collection is recommended.

  2. Remove the old port, the old SUBDIR entry and the old module entry.

• After repo moves (``rename'' operations where a port is copied and the old location is removed):

  1. Follow the same steps that are outlined in the previous two entries, to activate the new location of the port and remove the old one.

Before a release, it is necessary to restrict commits to the ports tree for a short period of time while the packages and the release itself are being built. This is to ensure consistency among the various parts of the release, and is called the ``ports freeze''.

Usually an hour or two.

During the ports freeze, you are not allowed to commit anything to the tree without explicit approval from the ports manager. ``Explicit approval'' here means either of the following:

• You asked the ports manager and got a reply saying, ``Go ahead and commit it.''

• The ports manager sent a mail to you or the mailing lists during the ports freeze pointing out that the port is broken and has to be fixed.

Note that you do not have implicit permission to fix a port during the freeze just because it is broken.

The ports manager will send out warning messages to the FreeBSD ports mailing list <freebsd-ports@FreeBSD.org> and FreeBSD committer's mailing list <cvs-committers@FreeBSD.org> announcing the start of the impending release, usually two or three weeks in advance. The exact starting time will not be determined until a few days before the actual release. This is because the ports freeze has to be synchronized with the release, and it is usually not known until then when exactly the release will be rolled.

When the freeze starts, there will be another announcement to the FreeBSD committer's mailing list <cvs-committers@FreeBSD.org>, of course.

A few hours after the release, the ports manager will send out a mail to the FreeBSD ports mailing list <freebsd-ports@FreeBSD.org> and FreeBSD committer's mailing list <cvs-committers@FreeBSD.org> announcing the end of the ports freeze. Note that the release being cut does not automatically end the freeze. We have to make sure there will not be any last minute snafus that result in an immediate re-rolling of the release.

First, go check http://bento.FreeBSD.org/~asami/errorlogs/. There you will find error logs from the latest package building runs on 3-stable, 4-stable and 5-current.

However, just because the port does not show up there does not mean it is building correctly. (One of the dependencies may have failed, for instance.) Here are the relevant directories on bento, so feel free to dig around.

     /a/asami/portbuild/3/errors        error logs from latest 3-stable run
                         /logs          all logs from latest 3-stable run
                         /packages      packages from latest 3-stable run
                         /bak/errors    error logs from last complete 3-stable run
                         /bak/logs      all logs from last complete 3-stable run
                         /bak/packages  packages from last complete 3-stable run
                       /4/errors        error logs from latest 4-stable run
                         /logs          all logs from latest 4-stable run
                         /packages      packages from latest 4-stable run
                         /bak/errors    error logs from last complete 4-stable run
                         /bak/logs      all logs from last complete 4-stable run
                         /bak/packages  packages from last complete 4-stable run
                       /5/errors        error logs from latest 5-current run
                         /logs          all logs from latest 5-current run
                         /packages      packages from latest 5-current run
                         /bak/errors    error logs from last complete 5-current run
                         /bak/logs      all logs from last complete 5-current run
                         /bak/packages  packages from last complete 5-current run
           

Basically, if the port shows up in packages, or it is in logs but not in errors, it built fine. (The errors directories are what you get from the web page.)

No. The ports manager will regenerate the INDEX and commit it every few days.

Any file directly under ports/, or any file under a subdirectory that starts with an uppercase letter (Mk/, Tools/, etc.). In particular, the ports manager is very protective of ports/Mk/bsd.port*.mk so do not commit changes to those files unless you want to face his wra(i)th.

When the checksum for a port's distfile is updated due to the author updating the file without changing the port's revision, the commit message should include a summary of the relevant diffs between the original and new distfile to ensure that the distfile has not been corrupted or maliciously altered. If the current version of the port has been in the ports tree for a while, a copy of the old distfile will usually be available on the ftp servers; otherwise the author or maintainer should be contacted to find out why the distfile has changed.