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:
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
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:
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
The following example is obsolete
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>
<#> 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
.
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>.