12. Experimental Patches Builds
Prev |  | Next

## 12. Experimental Patches Builds

### Note:

Most of the information in this section is obsolete as of 2013 and needs to be rewritten.

Experimental patches builds are run from time to time to new features or bugfixes to the ports infrastructure (i.e. `bsd.port.mk`), or to test large sweeping upgrades. At any given time there may be several simultaneous experimental patches branches, such as `8-exp` on the amd64 architecture.

In general, an experimental patches build is run the same way as any other build, except that you should first update the ports tree to the latest version and then apply your patches. To do the former, you can use the following:

### Note:

The following example is obsolete

`%` `cvs -R update -dP > update.out` `%` `date > .updated`

This will most closely simulate what the `dopackages` script does. (While `.updated` is merely informative, it can be a help.)

You will need to edit `update.out` to look for lines beginning with `^M`, `^C`, or `^?` and then deal with them.

It is always a good idea to save original copies of all changed files, as well as a list of what you are changing. You can then look back on this list when doing the final commit, to make sure you are committing exactly what you tested.

Since the machine is shared, someone else may delete your changes by mistake, so keep a copy of them in e.g., your home directory on `freefall`. Do not use `tmp/`; since `pointyhat` itself runs some version of `-CURRENT`, you can expect reboots (if nothing else, for updates).

In order to have a good control case with which to compare failures, you should first do a package build of the branch on which the experimental patches branch is based for the i386™ architecture (currently this is `8`). Then, when preparing for the experimental patches build, checkout a ports tree and a src tree with the same date as was used for the control build. This will ensure an apples-to-apples comparison later.

Once the build finishes, compare the control build failures to those of the experimental patches build. Use the following commands to facilitate this (this assumes the `8` branch is the control branch, and the `8-exp` branch is the experimental patches branch):

`%` `cd /a/portbuild/i386/8-exp/errors` `%` `find . -name \*.log\* | sort > /tmp/8-exp-errs` `%` `cd /a/portbuild/i386/8/errors` `%` `find . -name \*.log\* | sort > /tmp/8-errs`

### Note:

If it has been a long time since one of the builds finished, the logs may have been automatically compressed with bzip2. In that case, you must use `sort | sed 's,\.bz2,,g'` instead.

`%` `comm -3 /tmp/8-errs /tmp/8-exp-errs | less`

This last command will produce a two-column report. The first column is ports that failed on the control build but not in the experimental patches build; the second column is vice versa. Reasons that the port might be in the first column include:

- Port was fixed since the control build was run, or was upgraded to a newer version that is also broken (thus the newer version should appear in the second column)

- Port is fixed by the patches in the experimental patches build

- Port did not build under the experimental patches build due to a dependency failure

Reasons for a port appearing in the second column include:

- Port was broken by the experimental patches

- Port was upgraded since the control build and has become broken

- Port was broken due to a transient error (e.g., FTP site down, package client error, etc.)

Both columns should be investigated and the reason for the errors understood before committing the experimental patches set. To differentiate between broken by experimental patches and broken by upgrading above, you can do a rebuild of the affected packages under the control branch:

`%` `cd /a/portbuild/i386/8/ports`

### Note:

The following example is obsolete

### Note:

Be sure to `cvs update` this tree to the same date as the experimental patches tree.

The following command will set up the control branch for the partial build:

`%` `/a/portbuild/scripts/dopackages.wrapper i386 8 latest -noportsvcs -nobuild -novcs -nofinish`

The builds must be performed from the `packages/All` directory. This directory should initially be empty except for the Makefile symlink. If this symlink does not exist, it must be created:

`%` `cd /a/portbuild/i386/8/packages/All` `%` `ln -sf ../../Makefile .` `%` `make -k -j<#> <list of packages to build>`

### Note:

<#> is the concurrency of the build to attempt. It is usually the sum of the weights listed in `/a/portbuild/i386/mlist` unless you have a reason to run a heavier or lighter build.

The list of packages to build should be a list of package names (including versions) as they appear in `INDEX`. The `PKGSUFFIX` (i.e., `.tgz` or `.tbz`) is optional.

This will build only those packages listed as well as all of their dependencies.

You can check the progress of this partial build the same way you would a regular build.

Once all the errors have been resolved, you can commit the package set. After committing, it is customary to send a `HEADS UP` email to ports@FreeBSD.org and copy ports-developers@FreeBSD.org informing people of the changes. A summary of all changes should also be committed to `/usr/ports/CHANGES`.

Prev |  | Next
11. Uploading Packages | Home | 13. How to configure a new package building node

This, and other documents, can be downloaded from http://ftp.FreeBSD.org/pub/FreeBSD/doc/

For questions about FreeBSD, read the documentation before contacting <questions@FreeBSD.org>.
For questions about this documentation, e-mail <doc@FreeBSD.org>.