|
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. The current experimental patches branch is 4-exp on the i386™ architecture.
In general, an experimental patches build is run the same way as any other build. However, before running the dopackages script, you must apply the required patches to the ports tree. 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.
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 4). 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.
Note: One build cluster can do the control build while the other does the experimental patches build. This can be a great time-saver.
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 4 branch is the control branch, and the 4-exp branch is the experimental patches branch):
% cd /var/portbuild/i386/4-exp/errors % find . -name \*.log\* | sort > /tmp/4-exp-errs % cd /var/portbuild/i386/4/errors % find . -name \*.log\* | sort > /tmp/4-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/4-errs /tmp/4-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 [1]
Port was upgraded since the control build and has become broken [2]
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 [1] and [2] above, you can do a rebuild of the affected packages under the control branch:
% cd /var/portbuild/i386/4/ports
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:
% /var/portbuild/scripts/dopackages.4 -noportscvs -nobuild -nocvs -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/4/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.
This, and other documents, can be downloaded from ftp://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>.
Hosting by: Hurra Communications Ltd.
Generated: 2007-01-26 17:58:40