svn commit: r40467 - head/en_US.ISO8859-1/articles/portbuild
Hiroki Sato
hrs at FreeBSD.org
Mon Dec 24 09:41:46 UTC 2012
Author: hrs
Date: Mon Dec 24 09:41:46 2012
New Revision: 40467
URL: http://svnweb.freebsd.org/changeset/doc/40467
Log:
Markup style/whitespace cleanup. No content change.
Modified:
head/en_US.ISO8859-1/articles/portbuild/article.xml
Modified: head/en_US.ISO8859-1/articles/portbuild/article.xml
==============================================================================
--- head/en_US.ISO8859-1/articles/portbuild/article.xml Mon Dec 24 09:14:24 2012 (r40466)
+++ head/en_US.ISO8859-1/articles/portbuild/article.xml Mon Dec 24 09:41:46 2012 (r40467)
@@ -50,61 +50,64 @@
<ulink url="http://pointyhat.FreeBSD.org"></ulink>.</para>
<para>This article documents the internal workings of the
- cluster.</para>
+ cluster.</para>
<note>
<para>Many of the details in this article will be of interest only to
- those on the <ulink url="&url.base;/portmgr/">Ports Management</ulink>
- team.</para>
+ those on the <ulink url="&url.base;/portmgr/">Ports Management</ulink>
+ team.</para>
</note>
<sect2 id="codebase">
<title>The codebase</title>
- <para>Most of the package building magic occurs under the
- <filename>/var/portbuild</filename> directory. Unless
- otherwise specified, all paths will be relative to
- this location. <replaceable>${arch}</replaceable> will
- be used to specify one of the package architectures
- (e.g., amd64, arm, &i386;, ia64, powerpc, &sparc64;), and
- <replaceable>${branch}</replaceable> will be used
- to specify the build branch (e.g., 7, 7-exp, 8, 8-exp, 9, 9-exp, 10, 10-exp).
- The set of branches that <username>portmgr</username> currently
- supports is the same as those that the &os;
- <ulink url="http://www.freebsd.org/security/index.html#supported-branches">security team</ulink>
- supports.
- </para>
-
- <note>
- <para>Packages are no longer built for branches 4, 5, or 6, nor
- for the alpha architecture.</para>
- </note>
-
- <para>The scripts that control all of this live in
- <filename role="directory">/var/portbuild/scripts/</filename>.
- These are the checked-out copies from the Subversion repository at
- <ulink url="http://svnweb.freebsd.org/base/projects/portbuild/scripts/">
- <filename role="directory">base/projects/portbuild/scripts/</filename>
- </ulink>.</para>
-
- <para>Typically, incremental builds are done that use previous
- packages as dependencies; this takes less time, and puts less
- load on the mirrors. Full builds are usually only done:</para>
+ <para>Most of the package building magic occurs under the
+ <filename>/var/portbuild</filename> directory. Unless
+ otherwise specified, all paths will be relative to
+ this location. <replaceable>${arch}</replaceable> will
+ be used to specify one of the package architectures
+ (e.g., amd64, arm, &i386;, ia64, powerpc, &sparc64;), and
+ <replaceable>${branch}</replaceable> will be used
+ to specify the build branch (e.g., 7, 7-exp, 8, 8-exp, 9, 9-exp, 10, 10-exp).
+ The set of branches that <username>portmgr</username> currently
+ supports is the same as those that the &os;
+ <ulink url="http://www.freebsd.org/security/index.html#supported-branches">security team</ulink>
+ supports.
+ </para>
- <itemizedlist>
- <listitem><para>right after release time, for the
- <literal>-STABLE</literal> branches</para></listitem>
+ <note>
+ <para>Packages are no longer built for branches 4, 5, or 6, nor
+ for the alpha architecture.</para>
+ </note>
- <listitem><para>periodically to test changes to
- <literal>-CURRENT</literal>
- </para></listitem>
+ <para>The scripts that control all of this live in
+ <filename role="directory">/var/portbuild/scripts/</filename>.
+ These are the checked-out copies from the Subversion repository at
+ <ulink url="http://svnweb.freebsd.org/base/projects/portbuild/scripts/">
+ <filename role="directory">base/projects/portbuild/scripts/</filename>
+ </ulink>.</para>
+
+ <para>Typically, incremental builds are done that use previous
+ packages as dependencies; this takes less time, and puts less
+ load on the mirrors. Full builds are usually only done:</para>
- <listitem><para>for experimental (<literal>"exp-"</literal>) builds</para></listitem>
+ <itemizedlist>
+ <listitem>
+ <para>right after release time, for the
+ <literal>-STABLE</literal> branches</para>
+ </listitem>
- </itemizedlist>
+ <listitem>
+ <para>periodically to test changes to
+ <literal>-CURRENT</literal></para>
+ </listitem>
- <para>Packages from experimental builds are not uploaded.</para>
+ <listitem>
+ <para>for experimental (<literal>"exp-"</literal>) builds</para>
+ </listitem>
+ </itemizedlist>
+ <para>Packages from experimental builds are not uploaded.</para>
</sect2>
<sect2 id="codebase-notes">
@@ -116,25 +119,32 @@
for other hosts to be head nodes. Among the changes were:</para>
<itemizedlist>
- <listitem><para>removal of the hard-coding of the string
- <literal>pointyhat</literal></para></listitem>
+ <listitem>
+ <para>removal of the hard-coding of the string
+ <literal>pointyhat</literal></para>
+ </listitem>
- <listitem><para>factoring out all configuration constants (which
- were previously scattered throughout the code) into configuration
- files (see <link linkend="new-head-node">below</link>)
- </para></listitem>
-
- <listitem><para>appending the hostname to the directories
- specified by <literal>buildid</literal> (this will allow
- directories to be unambigious when copied between machines.)
- </para></listitem>
+ <listitem>
+ <para>factoring out all configuration constants (which
+ were previously scattered throughout the code) into configuration
+ files (see <link linkend="new-head-node">below</link>)</para>
+ </listitem>
- <listitem><para>making the scripts more robust in terms of setting
- up directories and symlinks</para></listitem>
+ <listitem>
+ <para>appending the hostname to the directories
+ specified by <literal>buildid</literal> (this will allow
+ directories to be unambigious when copied between machines.)</para>
+ </listitem>
- <listitem><para>where necessary, changing certain script invocations
- to make all the above easier</para></listitem>
+ <listitem>
+ <para>making the scripts more robust in terms of setting
+ up directories and symlinks</para>
+ </listitem>
+ <listitem>
+ <para>where necessary, changing certain script invocations
+ to make all the above easier</para>
+ </listitem>
</itemizedlist>
<para>This document was originally written before these changes
@@ -220,13 +230,11 @@
<para>The <filename>bindist.tar</filename> file is extracted
onto each client at client boot time, and at the start of
each pass of the <command>dopackages</command>
- script.
- </para>
+ script.</para>
- <para>For both commands above, if
- <replaceable>${buildid}</replaceable> is
- <literal>latest</literal>, it may be omitted.
- </para>
+ <para>For both commands above, if
+ <replaceable>${buildid}</replaceable> is
+ <literal>latest</literal>, it may be omitted.</para>
</sect1>
<sect1 id="customizing">
@@ -339,281 +347,260 @@ PKG_BIN=/usr/local/sbin/pkg</programlist
<sect2 id="build-dopackages">
<title><command>dopackages</command> scripts</title>
- <para>The <filename>scripts/dopackages.wrapper</filename> script
- is used to perform the builds.</para>
-
- <screen>&prompt.root; <userinput>dopackages.wrapper <replaceable>${arch}</replaceable> <replaceable>${branch}</replaceable> <replaceable>${buildid}</replaceable> <option>[-options]</option></userinput></screen>
-
- <para>Most often, you will be using <literal>latest</literal> for
- the value of <replaceable>buildid</replaceable>.</para>
+ <para>The <filename>scripts/dopackages.wrapper</filename> script
+ is used to perform the builds.</para>
- <para><literal>[-options]</literal> may be zero or more of the
- following:</para>
+ <screen>&prompt.root; <userinput>dopackages.wrapper <replaceable>${arch}</replaceable> <replaceable>${branch}</replaceable> <replaceable>${buildid}</replaceable> <option>[-options]</option></userinput></screen>
- <itemizedlist>
- <listitem>
- <para><option>-keep</option> - Do not delete this build in the
- future, when it would be normally deleted as part of the
- <literal>latest</literal> - <literal>previous</literal> cycle.
- Do not forget to clean it up manually when you no longer need it.
- </para>
- </listitem>
+ <para>Most often, you will be using <literal>latest</literal> for
+ the value of <replaceable>buildid</replaceable>.</para>
- <listitem>
- <para><option>-nofinish</option> - Do not perform
- post-processing once the build is complete. Useful
- if you expect that the build will need to be restarted
- once it finishes. If you use this option, do not forget to cleanup
- the clients when you do not need the build any more.
- </para>
- </listitem>
+ <para><literal>[-options]</literal> may be zero or more of the
+ following:</para>
- <listitem>
- <para><option>-finish</option> - Perform
- post-processing only.
- </para>
- </listitem>
+ <itemizedlist>
+ <listitem>
+ <para><option>-keep</option> - Do not delete this build in the
+ future, when it would be normally deleted as part of the
+ <literal>latest</literal> - <literal>previous</literal> cycle.
+ Do not forget to clean it up manually when you no longer need it.</para>
+ </listitem>
- <listitem>
- <para><option>-nocleanup</option> - By default, when the
- <option>-finish</option> stage of the build is complete, the build
- data will be deleted from the clients. This option will prevent
- that.</para>
- </listitem>
+ <listitem>
+ <para><option>-nofinish</option> - Do not perform
+ post-processing once the build is complete. Useful
+ if you expect that the build will need to be restarted
+ once it finishes. If you use this option, do not forget to cleanup
+ the clients when you do not need the build any more.</para>
+ </listitem>
- <listitem>
- <para><option>-restart</option> - Restart an interrupted
- (or non-<literal>finish</literal>ed) build from the
- beginning. Ports that failed on the previous build will
- be rebuilt.
- </para>
- </listitem>
+ <listitem>
+ <para><option>-finish</option> - Perform
+ post-processing only.</para>
+ </listitem>
- <listitem>
- <para><option>-continue</option> - Restart an interrupted
- (or non-<literal>finish</literal>ed) build. Will not
- rebuild ports that failed on the previous build.
- </para>
- </listitem>
+ <listitem>
+ <para><option>-nocleanup</option> - By default, when the
+ <option>-finish</option> stage of the build is complete, the build
+ data will be deleted from the clients. This option will prevent
+ that.</para>
+ </listitem>
- <listitem>
- <para><option>-incremental</option> - Compare the
- interesting fields of the new
- <filename>INDEX</filename> with the previous one,
- remove packages and log files for the old ports that
- have changed, and rebuild the rest. This
- cuts down on build times substantially since
- unchanged ports do not get rebuilt every time.
- </para>
- </listitem>
+ <listitem>
+ <para><option>-restart</option> - Restart an interrupted
+ (or non-<literal>finish</literal>ed) build from the
+ beginning. Ports that failed on the previous build will
+ be rebuilt.</para>
+ </listitem>
- <listitem>
- <para><option>-cdrom</option> - This package build is
- intended to end up on a CD-ROM, so
- <makevar>NO_CDROM</makevar> packages and distfiles
- should be deleted in post-processing.
- </para>
- </listitem>
+ <listitem>
+ <para><option>-continue</option> - Restart an interrupted
+ (or non-<literal>finish</literal>ed) build. Will not
+ rebuild ports that failed on the previous build.</para>
+ </listitem>
- <listitem>
- <para><option>-nobuild</option> - Perform all
- the preprocessing steps, but do not actually do
- the package build.
- </para>
- </listitem>
+ <listitem>
+ <para><option>-incremental</option> - Compare the
+ interesting fields of the new
+ <filename>INDEX</filename> with the previous one,
+ remove packages and log files for the old ports that
+ have changed, and rebuild the rest. This
+ cuts down on build times substantially since
+ unchanged ports do not get rebuilt every time.</para>
+ </listitem>
- <listitem>
- <para><option>-noindex</option> - Do not rebuild
- <filename>INDEX</filename> during preprocessing.
- </para>
- </listitem>
+ <listitem>
+ <para><option>-cdrom</option> - This package build is
+ intended to end up on a CD-ROM, so
+ <makevar>NO_CDROM</makevar> packages and distfiles
+ should be deleted in post-processing.</para>
+ </listitem>
- <listitem>
- <para><option>-noduds</option> - Do not rebuild the
- <filename>duds</filename> file (ports that are never
- built, e.g., those marked <literal>IGNORE</literal>,
- <makevar>NO_PACKAGE</makevar>, etc.) during
- preprocessing.
- </para>
- </listitem>
+ <listitem>
+ <para><option>-nobuild</option> - Perform all
+ the preprocessing steps, but do not actually do
+ the package build.</para>
+ </listitem>
- <listitem>
- <para><option>-nochecksubdirs</option> - Do not check the
- <makevar>SUBDIRS</makevar> for ports that are not connected
- to the build.
- </para>
- </listitem>
+ <listitem>
+ <para><option>-noindex</option> - Do not rebuild
+ <filename>INDEX</filename> during preprocessing.</para>
+ </listitem>
- <listitem>
- <para><option>-trybroken</option> - Try to build
- <makevar>BROKEN</makevar> ports (off by default
- because the amd64/&i386; clusters are fast enough now
- that when doing incremental builds, more time
- was spent rebuilding things that were going to
- fail anyway. Conversely, the other clusters
- are slow enough that it would be a waste of time
- to try and build <makevar>BROKEN</makevar> ports).
- </para>
- <note>
- <para>With <option>-trybroken</option>, you probably
- also want to use <option>-fetch-original</option>
- and
- <option>-unlimited-errors</option>.</para>
- </note>
- </listitem>
+ <listitem>
+ <para><option>-noduds</option> - Do not rebuild the
+ <filename>duds</filename> file (ports that are never
+ built, e.g., those marked <literal>IGNORE</literal>,
+ <makevar>NO_PACKAGE</makevar>, etc.) during
+ preprocessing.</para>
+ </listitem>
- <listitem>
- <para><option>-nosrc</option> - Do not update the
- <filename>src</filename> tree from the ZFS snapshot, keep the tree from
- previous build instead.
- </para>
- </listitem>
+ <listitem>
+ <para><option>-nochecksubdirs</option> - Do not check the
+ <makevar>SUBDIRS</makevar> for ports that are not connected
+ to the build.</para>
+ </listitem>
- <listitem>
- <para><option>-srcvcs</option> - Do not update the
- <filename>src</filename> tree from the ZFS snapshot, update it with
- a fresh checkout instead.
- </para>
- </listitem>
+ <listitem>
+ <para><option>-trybroken</option> - Try to build
+ <makevar>BROKEN</makevar> ports (off by default
+ because the amd64/&i386; clusters are fast enough now
+ that when doing incremental builds, more time
+ was spent rebuilding things that were going to
+ fail anyway. Conversely, the other clusters
+ are slow enough that it would be a waste of time
+ to try and build <makevar>BROKEN</makevar> ports).</para>
- <listitem>
- <para><option>-noports</option> - Do not update the
- <filename>ports</filename> tree from the ZFS snapshot, keep the tree from
- previous build instead.
- </para>
- </listitem>
+ <note>
+ <para>With <option>-trybroken</option>, you probably
+ also want to use <option>-fetch-original</option>
+ and
+ <option>-unlimited-errors</option>.</para>
+ </note>
+ </listitem>
- <listitem>
- <para><option>-portsvcs</option> - Do not update the
- <filename>ports</filename> tree from the ZFS snapshot, update it with
- a fresh checkout instead.
- </para>
- </listitem>
+ <listitem>
+ <para><option>-nosrc</option> - Do not update the
+ <filename>src</filename> tree from the ZFS snapshot, keep the tree from
+ previous build instead.</para>
+ </listitem>
- <listitem>
- <para><option>-norestr</option> - Do not attempt to build
- <makevar>RESTRICTED</makevar> ports.
- </para>
- </listitem>
+ <listitem>
+ <para><option>-srcvcs</option> - Do not update the
+ <filename>src</filename> tree from the ZFS snapshot, update it with
+ a fresh checkout instead.</para>
+ </listitem>
- <listitem>
- <para><option>-noplistcheck</option> - Do not make it fatal for
- ports to leave behind files after deinstallation.
- </para>
- </listitem>
+ <listitem>
+ <para><option>-noports</option> - Do not update the
+ <filename>ports</filename> tree from the ZFS snapshot, keep the tree from
+ previous build instead.</para>
+ </listitem>
- <listitem>
- <para><option>-nodistfiles</option> - Do not collect distfiles
- that pass <command>make checksum</command> for later
- uploading to <hostid>ftp-master</hostid>.
- </para>
- </listitem>
+ <listitem>
+ <para><option>-portsvcs</option> - Do not update the
+ <filename>ports</filename> tree from the ZFS snapshot, update it with
+ a fresh checkout instead.</para>
+ </listitem>
- <listitem>
- <para><option>-fetch-original</option> - Fetch the
- distfile from the original <makevar>MASTER_SITES</makevar>
- rather than any cache such as on <hostid>ftp-master</hostid>.
- </para>
- </listitem>
+ <listitem>
+ <para><option>-norestr</option> - Do not attempt to build
+ <makevar>RESTRICTED</makevar> ports.</para>
+ </listitem>
- <listitem>
- <para><option>-unlimited-errors</option>
- - defeat the "qmanager threshhold" check for runaway
- builds. You want this primarily when doing a
- <option>-restart</option> of a build that you expect to mostly
- fail, or perhaps a <option>-trybroken</option> run. By default,
- the threshhold check is done.</para>
- </listitem>
- </itemizedlist>
+ <listitem>
+ <para><option>-noplistcheck</option> - Do not make it fatal for
+ ports to leave behind files after deinstallation.</para>
+ </listitem>
- <para>Unless you specify <option>-restart</option>,
- <option>-continue</option>, or <option>-finish</option>,
- the symlinks for the existing builds will be rotated. i.e,
- the existing symlink for <filename>previous</filename> will
- be deleted; the most recent build will have its symlink changed
- to <filename>previous/</filename>; and a new build will be
- created and symlinked into <filename>latest/</filename>.
- </para>
+ <listitem>
+ <para><option>-nodistfiles</option> - Do not collect distfiles
+ that pass <command>make checksum</command> for later
+ uploading to <hostid>ftp-master</hostid>.</para>
+ </listitem>
- <para>If the last build finished cleanly you do not need to delete
- anything. If it was interrupted, or you selected
- <option>-nocleanup</option>, you need to clean up clients by running
- </para>
+ <listitem>
+ <para><option>-fetch-original</option> - Fetch the
+ distfile from the original <makevar>MASTER_SITES</makevar>
+ rather than any cache such as on <hostid>ftp-master</hostid>.</para>
+ </listitem>
- <para>&prompt.user; <userinput>build cleanup <replaceable>${arch}</replaceable> <replaceable>${branch}</replaceable> <replaceable>${buildid}</replaceable> -full</userinput></para>
+ <listitem>
+ <para><option>-unlimited-errors</option>
+ - defeat the "qmanager threshhold" check for runaway
+ builds. You want this primarily when doing a
+ <option>-restart</option> of a build that you expect to mostly
+ fail, or perhaps a <option>-trybroken</option> run. By default,
+ the threshhold check is done.</para>
+ </listitem>
+ </itemizedlist>
- <para>When a new build is created, the directories <filename>errors/</filename>,
- <filename>logs/</filename>, <filename>packages/</filename>, and so
- forth, are cleaned by the scripts. If you are short of space,
- you can also clean out <filename>ports/distfiles/</filename>.
- Leave the <filename>latest/</filename> directory alone; it is
- a symlink for the webserver.</para>
+ <para>Unless you specify <option>-restart</option>,
+ <option>-continue</option>, or <option>-finish</option>,
+ the symlinks for the existing builds will be rotated. i.e,
+ the existing symlink for <filename>previous</filename> will
+ be deleted; the most recent build will have its symlink changed
+ to <filename>previous/</filename>; and a new build will be
+ created and symlinked into <filename>latest/</filename>.</para>
+
+ <para>If the last build finished cleanly you do not need to delete
+ anything. If it was interrupted, or you selected
+ <option>-nocleanup</option>, you need to clean up clients by running</para>
+
+ <screen>&prompt.user; <userinput>build cleanup <replaceable>${arch}</replaceable> <replaceable>${branch}</replaceable> <replaceable>${buildid}</replaceable> -full</userinput></screen>
+
+ <para>When a new build is created, the directories <filename>errors/</filename>,
+ <filename>logs/</filename>, <filename>packages/</filename>, and so
+ forth, are cleaned by the scripts. If you are short of space,
+ you can also clean out <filename>ports/distfiles/</filename>.
+ Leave the <filename>latest/</filename> directory alone; it is
+ a symlink for the webserver.</para>
- <note>
- <para><literal>dosetupnodes</literal> is supposed to be run from
- the <literal>dopackages</literal> script in the
- <option>-restart</option> case, but it can be a good idea to
- run it by hand and then verify that the clients all have the
- expected job load. Sometimes,
- <filename>dosetupnode</filename> cannot clean up a build and you
- need to do it by hand. (This is a bug.)</para>
- </note>
+ <note>
+ <para><literal>dosetupnodes</literal> is supposed to be run from
+ the <literal>dopackages</literal> script in the
+ <option>-restart</option> case, but it can be a good idea to
+ run it by hand and then verify that the clients all have the
+ expected job load. Sometimes,
+ <filename>dosetupnode</filename> cannot clean up a build and you
+ need to do it by hand. (This is a bug.)</para>
+ </note>
- <para>Make sure the <replaceable>${arch}</replaceable> build
- is run as the ports-<replaceable>${arch}</replaceable> user
- or it will complain loudly.</para>
-
- <note><para>The actual package build itself occurs in two
- identical phases. The reason for this is that sometimes
- transient problems (e.g., NFS failures, FTP sites being
- unreachable, etc.) may halt a build. Doing things
- in two phases is a workaround for these types of
- problems.</para></note>
-
- <para>Be careful that <filename>ports/Makefile</filename>
- does not specify any empty subdirectories. This is especially
- important if you are doing an -exp build. If the build
- process encounters an empty subdirectory, both package build
- phases will stop short, and an error similar to the following
- will be written to
- <filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/journal</filename>:
- </para>
+ <para>Make sure the <replaceable>${arch}</replaceable> build
+ is run as the ports-<replaceable>${arch}</replaceable> user
+ or it will complain loudly.</para>
- <screen>don't know how to make dns-all(continuing)</screen>
+ <note>
+ <para>The actual package build itself occurs in two
+ identical phases. The reason for this is that sometimes
+ transient problems (e.g., NFS failures, FTP sites being
+ unreachable, etc.) may halt a build. Doing things
+ in two phases is a workaround for these types of
+ problems.</para>
+ </note>
- <para>To correct this problem, simply comment out or remove
- the <makevar>SUBDIR</makevar> entries that point to empty
- subdirectories. After doing this, you can restart the build
- by running the proper <command>dopackages</command> command
- with the <option>-restart</option> option.
- </para>
+ <para>Be careful that <filename>ports/Makefile</filename>
+ does not specify any empty subdirectories. This is especially
+ important if you are doing an -exp build. If the build
+ process encounters an empty subdirectory, both package build
+ phases will stop short, and an error similar to the following
+ will be written to
+ <filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/journal</filename>:</para>
+
+ <screen>don't know how to make dns-all(continuing)</screen>
+
+ <para>To correct this problem, simply comment out or remove
+ the <makevar>SUBDIR</makevar> entries that point to empty
+ subdirectories. After doing this, you can restart the build
+ by running the proper <command>dopackages</command> command
+ with the <option>-restart</option> option.</para>
- <note>
- <para>This problem also appears if you create a new category
- <filename>Makefile</filename> with no <makevar>SUBDIR</makevar>s
- in it. This is probably a bug.</para>
- </note>
+ <note>
+ <para>This problem also appears if you create a new category
+ <filename>Makefile</filename> with no <makevar>SUBDIR</makevar>s
+ in it. This is probably a bug.</para>
+ </note>
- <example>
- <title>Update the i386-7 tree and do a complete build</title>
+ <example>
+ <title>Update the i386-7 tree and do a complete build</title>
- <screen>&prompt.user; <userinput>dopackages.wrapper i386 7 -nosrc -norestr -nofinish</userinput></screen>
- </example>
+ <screen>&prompt.user; <userinput>dopackages.wrapper i386 7 -nosrc -norestr -nofinish</userinput></screen>
+ </example>
- <example>
- <title>Restart an interrupted amd64-8 build without updating</title>
+ <example>
+ <title>Restart an interrupted amd64-8 build without updating</title>
- <screen>&prompt.user; <userinput>dopackages.wrapper amd64 8 -nosrc -noports -norestr -continue -noindex -noduds -nofinish</userinput></screen>
- </example>
+ <screen>&prompt.user; <userinput>dopackages.wrapper amd64 8 -nosrc -noports -norestr -continue -noindex -noduds -nofinish</userinput></screen>
+ </example>
- <example>
- <title>Post-process a completed sparc64-7 tree</title>
+ <example>
+ <title>Post-process a completed sparc64-7 tree</title>
- <screen>&prompt.user; <userinput>dopackages.wrapper sparc64 7 -finish</userinput></screen>
- </example>
+ <screen>&prompt.user; <userinput>dopackages.wrapper sparc64 7 -finish</userinput></screen>
+ </example>
- <para>Hint: it is usually best to run the <command>dopackages</command>
- command inside of <command>screen(1)</command>.</para>
+ <para>Hint: it is usually best to run the <command>dopackages</command>
+ command inside of <command>screen(1)</command>.</para>
</sect2>
<sect2 id="build-command">
@@ -630,8 +617,7 @@ PKG_BIN=/usr/local/sbin/pkg</programlist
<replaceable>branch</replaceable>
[<replaceable>newid</replaceable>]</literal> - Creates
<replaceable>newid</replaceable> (or a datestamp if not specified).
- Only needed when bringing up a new branch or a new architecture.
- </para>
+ Only needed when bringing up a new branch or a new architecture.</para>
</listitem>
<listitem>
@@ -639,8 +625,7 @@ PKG_BIN=/usr/local/sbin/pkg</programlist
<replaceable>branch</replaceable> <replaceable>oldid</replaceable>
[<replaceable>newid</replaceable>]</literal> - Clones
<replaceable>oldid</replaceable> to
- <replaceable>newid</replaceable> (or a datestamp if not specified).
- </para>
+ <replaceable>newid</replaceable> (or a datestamp if not specified).</para>
</listitem>
<listitem>
@@ -649,8 +634,7 @@ PKG_BIN=/usr/local/sbin/pkg</programlist
<replaceable>buildid</replaceable></literal> - Replaces the src
tree with a new ZFS snapshot. Do not forget to use
<literal>-nosrc</literal> flag to <command>dopackages</command>
- later!
- </para>
+ later!</para>
</listitem>
<listitem>
@@ -659,10 +643,8 @@ PKG_BIN=/usr/local/sbin/pkg</programlist
<replaceable>buildid</replaceable></literal> - Replaces the ports
tree with a new ZFS snapshot. Do not forget to use
<literal>-noports</literal> flag to <command>dopackages</command>
- later!
- </para>
+ later!</para>
</listitem>
-
</itemizedlist>
</sect2>
@@ -673,7 +655,7 @@ PKG_BIN=/usr/local/sbin/pkg</programlist
package set. This can be accomplished with the following
invocation:</para>
- <para>&prompt.root; <command><replaceable>path</replaceable>/qmanager/packagebuild <replaceable>amd64</replaceable> <replaceable>7-exp</replaceable> <replaceable>20080904212103</replaceable> <replaceable>aclock-0.2.3_2.tbz</replaceable></command></para>
+ <screen>&prompt.root; <command><replaceable>path</replaceable>/qmanager/packagebuild <replaceable>amd64</replaceable> <replaceable>7-exp</replaceable> <replaceable>20080904212103</replaceable> <replaceable>aclock-0.2.3_2.tbz</replaceable></command></screen>
</sect2>
</sect1>
@@ -696,15 +678,13 @@ PKG_BIN=/usr/local/sbin/pkg</programlist
<listitem>
<para>An update of the running branch's
- <filename>src</filename> tree from the ZFS snapshot<footnoteref linkend='footnote-status1'></footnoteref>
- </para>
+ <filename>src</filename> tree from the ZFS snapshot<footnoteref linkend='footnote-status1'></footnoteref></para>
</listitem>
<listitem>
<para>Checks which ports do not have a
<makevar>SUBDIR</makevar> entry in their respective
- category's <filename>Makefile</filename><footnoteref linkend='footnote-status1'></footnoteref>
- </para>
+ category's <filename>Makefile</filename><footnoteref linkend='footnote-status1'></footnoteref></para>
</listitem>
<listitem>
@@ -716,14 +696,12 @@ PKG_BIN=/usr/local/sbin/pkg</programlist
<listitem>
<para>Generates a fresh <filename>INDEX</filename>
- file<footnoteref linkend='footnote-status1'></footnoteref><footnoteref linkend='footnote-buildstop'></footnoteref>
- </para>
+ file<footnoteref linkend='footnote-status1'></footnoteref><footnoteref linkend='footnote-buildstop'></footnoteref></para>
</listitem>
<listitem>
<para>Sets up the nodes that will be used in the
- build<footnoteref linkend='footnote-status1'></footnoteref><footnoteref linkend='footnote-buildstop'></footnoteref>
- </para>
+ build<footnoteref linkend='footnote-status1'></footnoteref><footnoteref linkend='footnote-buildstop'></footnoteref></para>
</listitem>
<listitem>
@@ -755,8 +733,7 @@ PKG_BIN=/usr/local/sbin/pkg</programlist
<title>Build Maintenance</title>
<para>There are several cases where you will need to manually clean
- up a build:
- </para>
+ up a build:</para>
<orderedlist>
<listitem>
@@ -772,101 +749,98 @@ PKG_BIN=/usr/local/sbin/pkg</programlist
<para><filename>qmanager</filename> has crashed and
has been restarted.</para>
</listitem>
- </orderedlist>
-
- <sect2 id="interrupting">
- <title>Interrupting a Build</title>
-
- <para>Manually interrupting a build is a bit messy. First you need to
- identify the tty in which it's running (either record the output
- of &man.tty.1; when you start the build, or use <command>ps x</command>
- to identify it. You need to make sure that nothing else important
- is running in this tty, e.g., <userinput>ps -t p1</userinput> or whatever.
- If there is not, you can just kill off the whole term easily with
- <userinput>pkill -t pts/1</userinput>; otherwise issue a
- <userinput>kill -HUP</userinput> in there by, for example,
-<userinput>ps -t pts/1 -o pid= | xargs kill -HUP</userinput>. Replace
- <replaceable>p1</replaceable> by whatever the tty is, of course.</para>
+ </orderedlist>
- <para>The
- package builds dispatched by <command>make</command> to
- the client machines will clean themselves up after a
- few minutes (check with <command>ps x</command> until they
- all go away).</para>
-
- <para>If you do not kill &man.make.1;, then it will spawn more jobs.
- If you do not kill <command>dopackages</command>, then it will restart
- the entire build. If you do not kill the <command>pdispatch</command>
- processes, they'll keep going (or respawn) until they've built their
- package.</para>
+ <sect2 id="interrupting">
+ <title>Interrupting a Build</title>
- </sect2>
+ <para>Manually interrupting a build is a bit messy. First you need to
+ identify the tty in which it's running (either record the output
+ of &man.tty.1; when you start the build, or use <command>ps x</command>
+ to identify it. You need to make sure that nothing else important
+ is running in this tty, e.g., <userinput>ps -t p1</userinput> or whatever.
+ If there is not, you can just kill off the whole term easily with
+ <userinput>pkill -t pts/1</userinput>; otherwise issue a
+ <userinput>kill -HUP</userinput> in there by, for example,
+ <userinput>ps -t pts/1 -o pid= | xargs kill -HUP</userinput>. Replace
+ <replaceable>p1</replaceable> by whatever the tty is, of course.</para>
+
+ <para>The
+ package builds dispatched by <command>make</command> to
+ the client machines will clean themselves up after a
+ few minutes (check with <command>ps x</command> until they
+ all go away).</para>
+
+ <para>If you do not kill &man.make.1;, then it will spawn more jobs.
+ If you do not kill <command>dopackages</command>, then it will restart
+ the entire build. If you do not kill the <command>pdispatch</command>
+ processes, they'll keep going (or respawn) until they've built their
+ package.</para>
+ </sect2>
- <sect2 id="cleanup">
- <title>Cleaning up a Build</title>
+ <sect2 id="cleanup">
+ <title>Cleaning up a Build</title>
- <para>To free up resources, you will need to clean up client machines by
- running <command>build cleanup</command> command. For example:</para>
+ <para>To free up resources, you will need to clean up client machines by
+ running <command>build cleanup</command> command. For example:</para>
<screen>&prompt.user; <userinput>/var/portbuild/scripts/build cleanup i386 8-exp 20080714120411 -full</userinput></screen>
- <para>If you forget to do this, then the old build
- <literal>jail</literal>s will not be cleaned up for 24 hours, and no
- new jobs will be dispatched in their place since
- <hostid>pointyhat</hostid> thinks the job slot is still occupied.</para>
-
- <para>To check, <userinput>cat ~/loads/*</userinput> to display the
- status of client machines; the first column is the number of jobs
- it thinks is running, and this should be roughly concordant
- with the load average. <literal>loads</literal> is refreshed
- every 2 minutes. If you do <userinput>ps x | grep pdispatch</userinput>
- and it is less than the number of jobs that <literal>loads</literal>
- thinks are in use, you are in trouble.</para>
-
- <para>You may have problem with the <command>umount</command>
- commands hanging. If so, you are going to have to use the
- <command>allgohans</command> script to run an &man.ssh.1;
- command across all clients for that buildenv. For example:</para>
+ <para>If you forget to do this, then the old build
+ <literal>jail</literal>s will not be cleaned up for 24 hours, and no
+ new jobs will be dispatched in their place since
+ <hostid>pointyhat</hostid> thinks the job slot is still occupied.</para>
+
+ <para>To check, <userinput>cat ~/loads/*</userinput> to display the
+ status of client machines; the first column is the number of jobs
+ it thinks is running, and this should be roughly concordant
+ with the load average. <literal>loads</literal> is refreshed
+ every 2 minutes. If you do <userinput>ps x | grep pdispatch</userinput>
+ and it is less than the number of jobs that <literal>loads</literal>
+ thinks are in use, you are in trouble.</para>
+
+ <para>You may have problem with the <command>umount</command>
+ commands hanging. If so, you are going to have to use the
+ <command>allgohans</command> script to run an &man.ssh.1;
+ command across all clients for that buildenv. For example:</para>
<screen>&prompt.user; ssh gohan24 df</screen>
- <para>will get you a df, and</para>
+ <para>will get you a df, and</para>
<screen>&prompt.user; allgohans "umount -f pointyhat.freebsd.org:/var/portbuild/i386/8-exp/ports"
&prompt.user; allgohans "umount -f pointyhat.freebsd.org:/var/portbuild/i386/8-exp/src"</screen>
- <para>are supposed to get rid of the hanging mounts. You will have to
- keep doing them since there can be multiple mounts.</para>
+ <para>are supposed to get rid of the hanging mounts. You will have to
+ keep doing them since there can be multiple mounts.</para>
- <note>
- <para>Ignore the following:
+ <note>
+ <para>Ignore the following:</para>
- <screen>umount: pointyhat.freebsd.org:/var/portbuild/i386/8-exp/ports: statfs: No such file or directory
+ <screen>umount: pointyhat.freebsd.org:/var/portbuild/i386/8-exp/ports: statfs: No such file or directory
umount: pointyhat.freebsd.org:/var/portbuild/i386/8-exp/ports: unknown file system
umount: Cleanup of /x/tmp/8-exp/chroot/53837/compat/linux/proc failed!
/x/tmp/8-exp/chroot/53837/compat/linux/proc: not a file system root directory</screen>
- The former two mean that the client did not have those mounted;
- the latter two are a bug.</para>
-
- <para>You may also see messages about <literal>procfs</literal>.</para>
- </note>
-
- <para>After you have done all the above, remove the
- <filename><replaceable>${arch}</replaceable>/lock</filename>
- file before trying to restart the build. If you do not,
- <filename>dopackages</filename> will simply exit.
- </para>
+ <para>The former two mean that the client did not have those mounted;
+ the latter two are a bug.</para>
- <para>If you have to do a ports tree update before
- restarting, you may have to rebuild either <filename>duds</filename>,
- <filename>INDEX</filename>, or both.</para>
+ <para>You may also see messages about <literal>procfs</literal>.</para>
+ </note>
+ <para>After you have done all the above, remove the
+ <filename><replaceable>${arch}</replaceable>/lock</filename>
+ file before trying to restart the build. If you do not,
+ <filename>dopackages</filename> will simply exit.</para>
+
+ <para>If you have to do a ports tree update before
+ restarting, you may have to rebuild either <filename>duds</filename>,
+ <filename>INDEX</filename>, or both.</para>
</sect2>
<sect2 id="build-command-2">
<title>Maintaining builds with the <command>build</command>
- command</title>
+ command</title>
<para>Here are the rest of the options for the <command>build</command>
command:</para>
@@ -875,21 +849,16 @@ umount: Cleanup of /x/tmp/8-exp/chroot/5
<listitem>
<para><literal>build destroy <replaceable>arch</replaceable>
<replaceable>branch</replaceable></literal> - Destroy the
- build id.
- </para>
+ build id.</para>
</listitem>
<listitem>
<para><literal>build list <replaceable>arch</replaceable>
<replaceable>branch</replaceable></literal> - Shows the current set
- of build ids.
- </para>
+ of build ids.</para>
</listitem>
-
</itemizedlist>
-
</sect2>
-
</sect1>
<sect1 id="monitoring">
@@ -930,8 +899,7 @@ umount: Cleanup of /x/tmp/8-exp/chroot/5
directory. The next time the cluster tries to build this port,
it will tar, compress, and copy the <makevar>WRKDIR</makevar>
to
- <filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/wrkdirs/</filename>.
- </para>
+ <filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/wrkdirs/</filename>.</para>
<para>If you find that the system is looping trying to build the
same package over and over again, you may be able to fix the
@@ -944,8 +912,7 @@ umount: Cleanup of /x/tmp/8-exp/chroot/5
<para>Keep an eye on &man.df.1; output. If the
<filename>/var/portbuild</filename> file system becomes full
- then <trademark>Bad Things</trademark> happen.
- </para>
+ then <trademark>Bad Things</trademark> happen.</para>
<para>The status of all current builds is generated periodically
into the <filename>packagestats.html</filename> file, e.g.,
@@ -1072,8 +1039,7 @@ umount: Cleanup of /x/tmp/8-exp/chroot/5
and inform them of the release package location.</para>
<para>Remember to coordinate with the &a.re; about the timing
- and status of the release builds.
- </para>
+ and status of the release builds.</para>
</sect1>
<sect1 id="uploading">
@@ -1132,8 +1098,9 @@ umount: Cleanup of /x/tmp/8-exp/chroot/5
</listitem>
</itemizedlist>
- <note><para>Some of the directories on
- <hostid>ftp-master</hostid> are, in fact, symlinks. Examples:</para>
+ <note>
+ <para>Some of the directories on
+ <hostid>ftp-master</hostid> are, in fact, symlinks. Examples:</para>
<itemizedlist>
*** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
More information about the svn-doc-head
mailing list