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 /var/portbuild/i386/8-exp/errors % find . -name \*.log\* | sort > /tmp/8-exp-errs % cd /var/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 /var/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 (old codebase):
% /var/portbuild/scripts/dopackages.8 -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 /var/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 /var/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.