svn commit: r40368 - in translations/en_US.ISO8859-1: articles/committers-guide articles/contributing articles/contributors articles/portbuild books books/arch-handbook/driverbasics books/arch-hand...
Glen Barber
gjb at FreeBSD.org
Wed Dec 12 22:39:57 UTC 2012
Author: gjb
Date: Wed Dec 12 22:39:55 2012
New Revision: 40368
URL: http://svnweb.freebsd.org/changeset/doc/40368
Log:
Merged /projects/pkgng/en_US.ISO8859-1:r39915-40152
to translations/en_US.ISO8859-1
Merged /head/en_US.ISO8859-1:r39641,39937-40365
to translations/en_US.ISO8859-1
Added:
translations/en_US.ISO8859-1/htdocs/google6bb24ed0b804d5e9.html
- copied unchanged from r40365, head/en_US.ISO8859-1/htdocs/google6bb24ed0b804d5e9.html
translations/en_US.ISO8859-1/htdocs/news/2012-compromise/
- copied from r40365, head/en_US.ISO8859-1/htdocs/news/2012-compromise/
translations/en_US.ISO8859-1/htdocs/news/2012-compromise.xml
- copied unchanged from r40365, head/en_US.ISO8859-1/htdocs/news/2012-compromise.xml
Deleted:
translations/en_US.ISO8859-1/books/corp-net-guide/
Modified:
translations/en_US.ISO8859-1/articles/committers-guide/article.xml
translations/en_US.ISO8859-1/articles/contributing/article.xml
translations/en_US.ISO8859-1/articles/contributors/contrib.additional.xml
translations/en_US.ISO8859-1/articles/contributors/contrib.committers.xml
translations/en_US.ISO8859-1/articles/contributors/contrib.corealumni.xml
translations/en_US.ISO8859-1/articles/portbuild/article.xml
translations/en_US.ISO8859-1/books/Makefile
translations/en_US.ISO8859-1/books/arch-handbook/driverbasics/chapter.xml
translations/en_US.ISO8859-1/books/arch-handbook/sound/chapter.xml
translations/en_US.ISO8859-1/books/developers-handbook/policies/chapter.xml
translations/en_US.ISO8859-1/books/developers-handbook/tools/chapter.xml
translations/en_US.ISO8859-1/books/faq/book.xml
translations/en_US.ISO8859-1/books/handbook/basics/chapter.xml
translations/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.xml
translations/en_US.ISO8859-1/books/handbook/eresources/chapter.xml
translations/en_US.ISO8859-1/books/handbook/filesystems/chapter.xml
translations/en_US.ISO8859-1/books/handbook/geom/chapter.xml
translations/en_US.ISO8859-1/books/handbook/mac/chapter.xml
translations/en_US.ISO8859-1/books/handbook/mail/chapter.xml
translations/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml
translations/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml
translations/en_US.ISO8859-1/books/handbook/ports/chapter.xml
translations/en_US.ISO8859-1/books/handbook/virtualization/chapter.xml
translations/en_US.ISO8859-1/books/porters-handbook/book.xml
translations/en_US.ISO8859-1/htdocs/Makefile
translations/en_US.ISO8859-1/htdocs/administration.xml
translations/en_US.ISO8859-1/htdocs/art.xml
translations/en_US.ISO8859-1/htdocs/cgi/cvsweb.cgi
translations/en_US.ISO8859-1/htdocs/cgi/man.cgi
translations/en_US.ISO8859-1/htdocs/cgi/ports.cgi
translations/en_US.ISO8859-1/htdocs/developers/cvs.xml
translations/en_US.ISO8859-1/htdocs/docs/books.xml
translations/en_US.ISO8859-1/htdocs/donations/index.xml
translations/en_US.ISO8859-1/htdocs/index.xsl
translations/en_US.ISO8859-1/htdocs/internal/bylaws.xml
translations/en_US.ISO8859-1/htdocs/internal/homepage.pl
translations/en_US.ISO8859-1/htdocs/internal/i18n.xml
translations/en_US.ISO8859-1/htdocs/layout/css/layout.css
translations/en_US.ISO8859-1/htdocs/layout/js/google.js
translations/en_US.ISO8859-1/htdocs/news/Makefile
translations/en_US.ISO8859-1/htdocs/news/status/report-2001-08.xml
translations/en_US.ISO8859-1/htdocs/news/status/report-2002-05-2002-06.xml
translations/en_US.ISO8859-1/htdocs/platforms/arm.xml
translations/en_US.ISO8859-1/htdocs/releng/charter.xml
translations/en_US.ISO8859-1/htdocs/releng/index.xml
translations/en_US.ISO8859-1/htdocs/search/sitemap.xml
translations/en_US.ISO8859-1/htdocs/security/security.xml
translations/en_US.ISO8859-1/htdocs/where.xml
translations/en_US.ISO8859-1/share/xml/mailing-lists.ent
Directory Properties:
translations/en_US.ISO8859-1/ (props changed)
Modified: translations/en_US.ISO8859-1/articles/committers-guide/article.xml
==============================================================================
--- translations/en_US.ISO8859-1/articles/committers-guide/article.xml Wed Dec 12 22:39:39 2012 (r40367)
+++ translations/en_US.ISO8859-1/articles/committers-guide/article.xml Wed Dec 12 22:39:55 2012 (r40368)
@@ -370,7 +370,7 @@
<sect2 id="svn-getting-started">
<title>Getting Started</title>
- <para>There are three ways to obtain a working copy of the tree
+ <para>There are a few ways to obtain a working copy of the tree
from Subversion. This section will explain them.</para>
<sect3>
@@ -466,119 +466,6 @@
information on how to set one up.</para>
</sect3>
- <sect3>
- <title>Checkout from a Local Mirror Using
- <acronym>SVK</acronym></title>
-
- <para>The third alternative is to use <acronym>SVK</acronym>
- to maintain a local mirror. It is a version control system
- build on top of Subversion's storage engine. It is
- identical to Subversion in most respects, except that it
- allows for setting up parts of repositories as mirrors of
- other repositories, and keeping local branches for merging
- back into the upstream repositories. There are extensions
- that allow <acronym>SVK</acronym> to mirror
- <acronym>CVS</acronym> and Perforce repositories in addition
- to Subversion ones.</para>
-
- <para>Like everything, <acronym>SVK</acronym> has its
- disadvantages, one being that local revision numbers will
- not match upstream revision numbers. This makes it
- difficult to <command>svk log</command>, <command>svk
- diff</command>, or <command>svk update</command> to an
- arbitrary upstream revision.</para>
-
- <para>To set up a mirror of the &os; repository, do:</para>
-
- <screen>&prompt.user; <userinput>svk mirror svn+ssh://svn.freebsd.org/base //freebsd/base</userinput></screen>
-
- <para>The local <acronym>SVK</acronym> repository will be
- stored in <filename
- class="directory">~/.svk/local/</filename>, but can be
- moved to an alternate location. If it is moved,
- <filename>~/.svk/config</filename> should be amended
- manually to reflect the move.</para>
-
- <para>Any path can be used, not just the one in the example
- above. A common pattern is to place mirrors under
- <literal>//mirror</literal>, e.g.,
- <filename
- class="directory">//mirror/freebsd/base/</filename>, and
- local branches under <literal>//local</literal>.</para>
-
- <para>To pull down the contents of the repository to the
- mirror:</para>
-
- <screen>&prompt.user; <userinput>svk sync //freebsd/base</userinput></screen>
-
- <note>
- <para><command>svk sync</command> will take a very long
- time, possibly several days over a slow network
- connection. &a.peter; has a tarball that can be used to
- jumpstart the mirror, but only if one does not exist
- already.</para>
- </note>
-
- <para>To use the tarball referenced above:</para>
-
- <screen>&prompt.user; <userinput>cd ~</userinput>
-&prompt.user; <userinput>scp freefall:/home/peter/dot_svk_r179646.tbz2 .</userinput>
-&prompt.user; <userinput>tar xf dot_svk_r179646.tbz2</userinput></screen>
-
- <para>Then edit <filename>~/.svk/config</filename> and replace
- <filename
- class="directory">/scratch/tmp/peter/.svk/local/</filename>
- with the equivalent of <filename
- class="directory">/home/<replaceable>jarjar</replaceable>/.svk/local/</filename>.</para>
-
- <para>You can check out files directly from your mirror, once
- it has been created:</para>
-
- <screen>&prompt.user; <userinput>svk checkout //freebsd/base/head /usr/src</userinput></screen>
-
- <para>Unlike <acronym>SVN</acronym>, <acronym>SVK</acronym>
- does not store metadata or reference copies in the working
- copy. All metadata is recorded in
- <filename>~/.svk/config</filename>; reference copies are not
- used at all because <acronym>SVK</acronym> always operates
- on a local repository.</para>
-
- <para>When committing from a working copy like the one above,
- <acronym>SVN</acronym> will commit directly to the upstream
- repository, then synchronise the mirror.</para>
-
- <para>However, the <quote>killer app</quote> for
- <acronym>SVK</acronym> is the ability to work without a
- network connection. To do that, a local branch must be set
- up:</para>
-
- <screen>&prompt.user; <userinput>svk mkdir //local/freebsd</userinput>
-&prompt.user; <userinput>svk copy //freebsd/base/head //local/freebsd/head</userinput></screen>
-
- <para>Once again, any path can be used, it does not have to
- specifically be the one in the example.</para>
-
- <para>Before use, the local branch has to be synchronized,
- like so:</para>
-
- <screen>&prompt.user; <userinput>svk pull //local/freebsd/head</userinput></screen>
-
- <para>Then check out from the newly created local
- branch:</para>
-
- <screen>&prompt.user; <userinput>svk checkout //local/freebsd/head /usr/src</userinput></screen>
-
- <para>The point of this exercise is showing that it is
- possible to commit work-in-progress to a local branch, and
- only push it to the upstream repository when work is
- complete. The easy way to push is with <command>svk
- push</command>, but there is a serious disadvantage to it:
- it will push every single commit made to the local branch
- incrementally instead of lumping them all into a single
- commit. Therefore, using <command>svk smerge</command> is
- preferable.</para>
- </sect3>
-
<sect3 id="subversion-primer-base-layout">
<title><literal>RELENG_*</literal> Branches and General
Layout</title>
@@ -711,16 +598,6 @@
daily use, except for the revision renumbering mentioned
earlier.</para>
- <note>
- <para><acronym>SVN</acronym> and <acronym>SVK</acronym>
- commands that have direct <acronym>CVS</acronym> equivalents
- usually have the same name and abbreviations. For example:
- <emphasis>checkout</emphasis> and <emphasis>co</emphasis>,
- <emphasis>update</emphasis> and <emphasis>up</emphasis>, and
- <emphasis>commit</emphasis> and
- <emphasis>ci</emphasis>.</para>
- </note>
-
<sect3>
<title>Help</title>
@@ -824,11 +701,7 @@
<screen>&prompt.user; <userinput>svn status</userinput></screen>
- <para><acronym>CVS</acronym> has no direct equivalent of this
- command. The nearest would be <command>cvs up -N</command>
- which shows local changes and files that are out-of-date.
- Doing this in <acronym>SVN</acronym> is possible too,
- however:</para>
+ <para>To show local changes and files that are out-of-date do:</para>
<screen>&prompt.user; <userinput>svn status --show-updates</userinput></screen>
</sect3>
@@ -836,7 +709,7 @@
<sect3>
<title>Editing and Committing</title>
- <para>Like <acronym>CVS</acronym> but unlike Perforce,
+ <para>Unlike Perforce,
<acronym>SVN</acronym> and <acronym>SVK</acronym> do not
need to be told in advance about file editing.</para>
@@ -882,7 +755,7 @@
</para>
</note>
- <para>As with <acronym>CVS</acronym>, files are added to a
+ <para>Files are added to a
<acronym>SVN</acronym> repository with <command>svn
add</command>. To add a file named
<emphasis>foo</emphasis>, edit it, then:</para>
@@ -910,10 +783,9 @@
<screen>&prompt.user; <userinput>svn mkdir <replaceable>bar</replaceable></userinput></screen>
- <para>In <acronym>CVS</acronym>, the directory is immediately
- created in the repository when you <command>cvs
- add</command> it; this is not the case in Subversion.
- Furthermore, unlike <acronym>CVS</acronym>, Subversion
+ <para>The directory is not immediately
+ created in the repository when you use <command>svn
+ mkdir</command>. Subversion
allows directories to be removed using <command>svn
rm</command>, however there is no <command>svn
rmdir</command>:</para>
@@ -938,9 +810,6 @@
<screen>&prompt.user; <userinput>svn copy <replaceable>foo.c</replaceable> <replaceable>bar.c</replaceable></userinput>
&prompt.user; <userinput>svn remove <replaceable>foo.c</replaceable></userinput></screen>
-
- <para>Neither of these operations have equivalents in
- <acronym>CVS</acronym>.</para>
</sect3>
<sect3>
@@ -965,11 +834,11 @@
<para><command>svn diff</command> displays changes to the
working copy of the repository. Diffs generated by
- <acronym>SVN</acronym> are unified by default, unlike
- <acronym>CVS</acronym>, and include new files by default
+ <acronym>SVN</acronym> are unified
+ and include new files by default
in the diff output.</para>
- <para>As with <acronym>CVS</acronym>, <command>svn
+ <para><command>svn
diff</command> can show the changes between two revisions
of the same file:</para>
@@ -987,8 +856,8 @@
<title>Reverting</title>
<para>Local changes (including additions and deletions) can be
- reverted using <command>svn revert</command>. Unlike
- <command>cvs up -C</command>, it does not update out-of-date
+ reverted using <command>svn revert</command>.
+ It does not update out-of-date
files—it just replaces them with pristine copies of
the original version.</para>
</sect3>
@@ -1877,8 +1746,8 @@ U stable/9/share/man/man4/netmap.4
of <command>svn status</command> and <command>svn
diff</command> before committing.</para>
- <para>Mistakes will happen, but, unlike with
- <acronym>CVS</acronym>, they can generally be fixed without
+ <para>Mistakes will happen but,
+ they can generally be fixed without
disruption.</para>
<para>Take a case of adding a file in the wrong location. The
@@ -2014,37 +1883,20 @@ U stable/9/share/man/man4/netmap.4
<para>Don't remove and re-add the same file in a single commit
as this will break the CVS exporter.</para>
- <para>Speeding up checkouts and minimising network traffic is
- possible with the following recipe:</para>
+ <para>Speeding up svn is
+ possible by adding the following to <filename>~/.ssh/config</filename>:</para>
+
+ <screen>Host *
+ControlPath ~/.ssh/sockets/master-%l-%r@%h:%p
+ControlMaster auto
+ControlPersist yes</screen>
- <screen>&prompt.user; <userinput>svn co --depth=empty svn+ssh://svn.freebsd.org/base fbsvn</userinput>
-&prompt.user; <userinput>cd fbsvn</userinput>
-&prompt.user; <userinput>svn up --depth=empty stable</userinput>
-&prompt.user; <userinput>svn up head</userinput>
-&prompt.user; <userinput>cd stable</userinput>
-&prompt.user; <userinput>cp -r ../head/ 7</userinput>
-&prompt.user; <userinput>cd 7</userinput>
-&prompt.user; <userinput>svn switch svn+ssh://svn.freebsd.org/base/stable/7</userinput>
-&prompt.user; <userinput>cd ..</userinput>
-&prompt.user; <userinput>cp -r 7/ 6</userinput>
-&prompt.user; <userinput>cd 6</userinput>
-&prompt.user; <userinput>svn switch svn+ssh://svn.freebsd.org/base/stable/6</userinput></screen>
-
- <para>What this bit of evil does is check out head, stable/7 and
- stable/6. We create the empty checkout directories under
- <acronym>SVN</acronym>'s control. In <acronym>SVN</acronym>,
- subtrees are self identifying, like in <acronym>CVS</acronym>.
- We check out head and clone it as stable/7. Except we don't
- want the head version so we <quote>switch</quote> it to the
- 7.x tree location. <acronym>SVN</acronym> downloads diffs to
- convert the <quote>head</quote> files to
- <quote>stable/7</quote> instead of doing a fresh checkout.
- The same goes for stable/6. This does, however, definitely
- count as abuse of the working copy client code!</para>
+ <para>and then typing</para>
+ <screen><userinput>mkdir ~/.ssh/sockets</userinput></screen>
<para>Checking out a working copy with a stock Subversion client
without &os;-specific patches
- (<makevar>WITH_FREEBSD_TEMPLATE</makevar>) will mean that
+ (<makevar>OPTIONS_SET=FREEBSD_TEMPLATE</makevar>) will mean that
<literal>$FreeBSD$</literal> tags will not be
expanded. Once the correct version has been installed, trick
Subversion into expanding them like so:</para>
@@ -2052,8 +1904,7 @@ U stable/9/share/man/man4/netmap.4
<screen>&prompt.user; <userinput>svn propdel -R svn:keywords .</userinput>
&prompt.user; <userinput>svn revert -R .</userinput></screen>
- <para>This is not a good idea if uncommitted patches exist,
- however.</para>
+ <para>This will wipe out uncommitted patches.</para>
</sect2>
</sect1>
@@ -2081,7 +1932,7 @@ U stable/9/share/man/man4/netmap.4
<itemizedlist>
<listitem>
<para>Add your author entity to
- <filename>head/en_US.ISO8859-1/share/xml/authors.ent</filename>;
+ <filename>head/share/xml/authors.ent</filename>;
this should be done first since an omission of this commit will
cause the next commits to break the doc/ build.</para>
@@ -2594,14 +2445,13 @@ U stable/9/share/man/man4/netmap.4
<term>&a.committers;</term>
<listitem>
- <para>cvs-committers is the entity that the version control system uses to send you all your
- commit messages. You should <emphasis>never</emphasis> send email
- directly to this list. You should only send replies to this list
- when they are short and are directly related to a commit.</para>
-
- <para>There is a similar list, svn-committers, which has a
- similar purpose but is a normal list, i.e., you are free to
- send any suitable message to this list.</para>
+ <para>&a.svn-src-all.name;, &a.svn-ports-all.name; and
+ &a.svn-doc-all.name; are the mailing lists that the
+ version control system uses to send commit messages to.
+ You should <emphasis>never</emphasis> send email directly
+ to these lists. You should only send replies to this list
+ when they are short and are directly related to a
+ commit.</para>
</listitem>
</varlistentry>
@@ -4074,57 +3924,11 @@ U stable/9/share/man/man4/netmap.4
</step>
<step>
- <para>Update the instructions for &man.cvsup.1;:</para>
-
- <itemizedlist>
- <listitem>
- <para>
- add the category to
- <filename>distrib/cvsup/sup/README</filename>
- </para>
- </listitem>
-
- <listitem>
- <para>
- adding the following files into
- <filename>distrib/cvsup/sup/ports-<replaceable>categoryname</replaceable></filename>:
- <filename>list.cvs</filename> and
- <filename>releases</filename>.</para>
- </listitem>
-
- <listitem>
- <para>
- add the category to
- <filename>src/share/examples/cvsup/ports-supfile</filename>
- </para>
- </listitem>
- </itemizedlist>
-
- <para>
- (Note: these are
- in the src, not the ports, repository). If you
- are not a src committer, you will need to submit
- a PR for this.</para>
- </step>
-
- <step>
- <para>
- Update the list of categories used by &man.sysinstall.8;
- in <filename>src/usr.sbin/sysinstall</filename>.</para>
- </step>
-
- <step>
<para>Update the documentation by modifying the
following:</para>
<itemizedlist>
<listitem>
- <para>the section of the Handbook that lists the
- <ulink url="&url.books.handbook;/cvsup.html#CVSUP-COLLEC">
- cvsup collections</ulink>.</para>
- </listitem>
-
- <listitem>
<para>the
<ulink url="&url.books.porters-handbook;/makefile-categories.html#PORTING-CATEGORIES">
list of categories</ulink> in the Porter's Handbook</para>
@@ -4174,10 +3978,6 @@ U stable/9/share/man/man4/netmap.4
<itemizedlist>
<listitem>
- <para><filename>src/usr.sbin/sysinstall</filename></para>
- </listitem>
-
- <listitem>
<para>the
<ulink url="&url.books.porters-handbook;/makefile-categories.html#PORTING-CATEGORIES">
list of categories</ulink> in the Porter's Handbook</para>
Modified: translations/en_US.ISO8859-1/articles/contributing/article.xml
==============================================================================
--- translations/en_US.ISO8859-1/articles/contributing/article.xml Wed Dec 12 22:39:39 2012 (r40367)
+++ translations/en_US.ISO8859-1/articles/contributing/article.xml Wed Dec 12 22:39:55 2012 (r40368)
@@ -234,7 +234,8 @@
<title>Pick one of the items from the <quote>Ideas</quote>
page</title>
- <para>The <ulink url="&url.base;/projects/ideas/">&os; list of
+ <para>The <ulink url="http://wiki.freebsd.org/IdeasPage">&os;
+ list of
projects and ideas for volunteers</ulink> is also available
for people willing to contribute to the &os; project. The
list is being regularly updated and contains items for both
@@ -342,39 +343,22 @@
<para>The preferred &man.diff.1; format for submitting patches
is the unified output format generated by <command>diff
- -u</command>. However, for patches that substantially
- change a region of code, a context output format diff
- generated by <command>diff -c</command> may be more readable
- and thus preferable.</para>
+ -u</command>.</para>
<indexterm>
<primary><command>diff</command></primary>
</indexterm>
- <para>For example:</para>
-
- <screen>&prompt.user; <userinput>diff -c oldfile newfile</userinput></screen>
-
- <para>or</para>
-
- <screen>&prompt.user; <userinput>diff -c -r olddir newdir</userinput></screen>
-
- <para>would generate such a set of context diffs for the given
- source file or directory hierarchy.</para>
-
- <para>Likewise,</para>
-
<screen>&prompt.user; <userinput>diff -u oldfile newfile</userinput></screen>
<para>or</para>
- <screen>&prompt.user; <userinput>diff -u -r olddir newdir</userinput></screen>
+ <screen>&prompt.user; <userinput>diff -u -r -N olddir newdir</userinput></screen>
- <para>would do the same, except in the unified diff
- format.</para>
+ <para>would generate a set of unified diffs for the given source
+ file or directory hierarchy.</para>
- <para>See the manual page for &man.diff.1; for more
- details.</para>
+ <para>See &man.diff.1; for more information.</para>
<para>Once you have a set of diffs (which you may test with the
&man.patch.1; command), you should submit them for inclusion
@@ -400,9 +384,8 @@
welcome.</para>
<para>If your change is of a potentially sensitive nature,
- e.g. you are unsure of copyright issues governing its further
- distribution or you are simply not ready to release it without
- a tighter review first, then you should send it to &a.core;
+ such as if you are unsure of copyright issues governing its further
+ distribution then you should send it to &a.core;
directly rather than submitting it with &man.send-pr.1;. The
&a.core; reaches a much smaller group of people who
do much of the day-to-day work on FreeBSD. Note that this
@@ -506,7 +489,7 @@ THEORY OF LIABILITY, WHETHER IN CONTRACT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- $Id$</programlisting>
+ $&os;$</programlisting>
<para>For your convenience, a copy of this text can be found in
<filename>/usr/share/examples/etc/bsd-style-copyright</filename>.</para>
Modified: translations/en_US.ISO8859-1/articles/contributors/contrib.additional.xml
==============================================================================
--- translations/en_US.ISO8859-1/articles/contributors/contrib.additional.xml Wed Dec 12 22:39:39 2012 (r40367)
+++ translations/en_US.ISO8859-1/articles/contributors/contrib.additional.xml Wed Dec 12 22:39:55 2012 (r40368)
@@ -1144,11 +1144,6 @@
</listitem>
<listitem>
- <para>Barbara</para>
- <!-- (rene@) No email address per request. -->
- </listitem>
-
- <listitem>
<para>Barry Bierbauch
<email>pivrnec at vszbr.cz</email></para>
</listitem>
@@ -1722,6 +1717,11 @@
</listitem>
<listitem>
+ <para>Christian Heckendorf
+ <email>heckend at bu.edu</email></para>
+ </listitem>
+
+ <listitem>
<para>Christian Lackas
<email>delta at lackas.net</email></para>
</listitem>
Modified: translations/en_US.ISO8859-1/articles/contributors/contrib.committers.xml
==============================================================================
--- translations/en_US.ISO8859-1/articles/contributors/contrib.committers.xml Wed Dec 12 22:39:39 2012 (r40367)
+++ translations/en_US.ISO8859-1/articles/contributors/contrib.committers.xml Wed Dec 12 22:39:55 2012 (r40368)
@@ -500,6 +500,10 @@
</listitem>
<listitem>
+ <para>&a.bar;</para>
+ </listitem>
+
+ <listitem>
<para>&a.jmg;</para>
</listitem>
@@ -1524,6 +1528,10 @@
</listitem>
<listitem>
+ <para>&a.bryanv;</para>
+ </listitem>
+
+ <listitem>
<para>&a.avilla;</para>
</listitem>
@@ -1638,4 +1646,8 @@
<listitem>
<para>&a.az;</para>
</listitem>
+
+ <listitem>
+ <para>&a.syuu;</para>
+ </listitem>
</itemizedlist>
Modified: translations/en_US.ISO8859-1/articles/contributors/contrib.corealumni.xml
==============================================================================
--- translations/en_US.ISO8859-1/articles/contributors/contrib.corealumni.xml Wed Dec 12 22:39:39 2012 (r40367)
+++ translations/en_US.ISO8859-1/articles/contributors/contrib.corealumni.xml Wed Dec 12 22:39:55 2012 (r40368)
@@ -3,6 +3,10 @@
<itemizedlist>
<listitem>
+ <para>&a.attilio; (2012)</para>
+ </listitem>
+
+ <listitem>
<para>&a.wilko; (2006 - 2012)</para>
</listitem>
Modified: translations/en_US.ISO8859-1/articles/portbuild/article.xml
==============================================================================
--- translations/en_US.ISO8859-1/articles/portbuild/article.xml Wed Dec 12 22:39:39 2012 (r40367)
+++ translations/en_US.ISO8859-1/articles/portbuild/article.xml Wed Dec 12 22:39:55 2012 (r40368)
@@ -66,19 +66,23 @@
otherwise specified, all paths will be relative to
this location. <replaceable>${arch}</replaceable> will
be used to specify one of the package architectures
- (amd64, &i386;, ia64, powerpc, and &sparc64;), and
+ (e.g., amd64, arm, &i386;, ia64, powerpc, &sparc64;), and
<replaceable>${branch}</replaceable> will be used
- to specify the build branch (7, 7-exp, 8, 8-exp, 9, 9-exp, 10, 10-exp).
+ 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 Releases 4, 5, or 6, nor
+ <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 class="directory">/var/portbuild/scripts/</filename>.
- These are the checked-out copies from the Subversion repository
+ These are the checked-out copies from the Subversion repository at
<ulink url="http://svnweb.freebsd.org/base/projects/portbuild/scripts/">
<filename class="directory">base/projects/portbuild/scripts/</filename>
</ulink>.</para>
@@ -95,16 +99,19 @@
<literal>-CURRENT</literal>
</para></listitem>
- <listitem><para>for experimental builds</para></listitem>
+ <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">
<title>Notes on the codebase</title>
<para>Until mid-2010, the scripts were completely specific to
- <hostid>pointyhat</hostid> as the head (dispatch) node. During
+ <hostid>pointyhat.FreeBSD.org</hostid> as the head (dispatch) node. During
the summer of 2010, a significant rewrite was done in order to allow
for other hosts to be head nodes. Among the changes were:</para>
@@ -136,9 +143,11 @@
to <literal>old codebase:</literal>.</para>
<note>
- <para>As of December 2010, <hostid>pointyhat</hostid> is still
- running on the old codebase, until the new codebase is considered
- rock-solid.</para>
+ <para>Up until November 2012, <hostid>pointyhat</hostid> had still
+ been running the old codebase. That installation has now been
+ permanently offlined. Therefore, all the instructions having
+ to do with the old codebase are <emphasis>obsolete</emphasis>,
+ and will be removed in the near future.</para>
</note>
<note>
@@ -167,7 +176,7 @@
interesting data (ports and src trees, bindist tarballs,
scripts, etc.) to disconnected nodes during the node-setup
phase. Then, the disconnected portbuild directory is
- nullfs-mounted for chroot builds.</para>
+ nullfs-mounted for jail builds.</para>
<para>The
<username>ports-<replaceable>${arch}</replaceable></username>
@@ -179,41 +188,32 @@
<para>The <command>scripts/allgohans</command> script can
be used to run a command on all of the
<replaceable>${arch}</replaceable> clients.</para>
-
- <para>The <command>scripts/checkmachines</command> script
- is used to monitor the load on all the nodes of the
- build cluster, and schedule which nodes build which ports.
- This script is not very robust, and has a tendency to die.
- It is best to start up this script on the build master
- (e.g. <hostid>pointyhat</hostid>)
- after boot time using a &man.while.1; loop.
- </para>
</sect1>
<sect1 id="setup">
- <title>Chroot Build Environment Setup</title>
+ <title>Jail Build Environment Setup</title>
<para>Package builds are performed in a
- <literal>chroot</literal> populated by the
+ <literal>jail</literal> populated by the
<filename>portbuild</filename> script using the
<filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/builds/<replaceable>${buildid}</replaceable>/bindist.tar</filename>
file.</para>
- <para>The following command builds a world from the
+ <para>The <command>makeworld</command> command builds a world from the
<filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/builds/<replaceable>${buildid}</replaceable>/src/</filename>
tree and installs it into
- <replaceable>${worlddir}</replaceable>. The tree will
- be updated first unless <literal>-nocvs</literal> is
- specified.</para>
+ <filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/builds/<replaceable>${buildid}</replaceable>/bindist.tar</filename>.
+ The tree will
+ be updated first unless <literal>-novcs</literal> is
+ specified. It should be run as <username>root</username>:</para>
- <screen>/var/portbuild&prompt.root; <userinput>scripts/makeworld <replaceable>${arch}</replaceable> <replaceable>${branch}</replaceable> <replaceable>${buildid}</replaceable> [-nocvs]</userinput></screen>
+ <screen>&prompt.root; <userinput>/var/portbuild/scripts/makeworld <replaceable>${arch}</replaceable> <replaceable>${branch}</replaceable> <replaceable>${buildid}</replaceable> [-novcs]</userinput></screen>
<para>The <filename>bindist.tar</filename> tarball is created from the
previously installed world by the <command>mkbindist</command>
- script. It should be run as <username>root</username> with the following
- command:</para>
+ script. It should be also be run as <username>root</username>:</para>
- <screen>/var/portbuild&prompt.root; <userinput>scripts/mkbindist <replaceable>${arch}</replaceable> <replaceable>${branch}</replaceable> <replaceable>${buildid}</replaceable></userinput></screen>
+ <screen>&prompt.root; <userinput>/var/portbuild/scripts/mkbindist <replaceable>${arch}</replaceable> <replaceable>${branch}</replaceable> <replaceable>${buildid}</replaceable></userinput></screen>
<para>The per-machine tarballs are located in
<filename><replaceable>${arch}</replaceable>/clients</filename>.</para>
@@ -280,7 +280,7 @@
<para>(For this case, the contents are identical for both server
and client.)</para>
- <screen>RUBY_DEFAULT_VER= 1.9</screen>
+ <programlisting>RUBY_DEFAULT_VER= 1.9</programlisting>
</example>
<example>
@@ -291,7 +291,7 @@
<para>(For this case, the contents are also identical for both
server and client.)</para>
- <screen>
+ <programlisting>
.if !defined(CC) || ${CC} == "cc"
CC=clang
.endif
@@ -301,44 +301,45 @@ CXX=clang++
.if !defined(CPP) || ${CPP} == "cpp"
CPP=clang-cpp
.endif
-# Don't die on warnings
+# Do not die on warnings
NO_WERROR=
WERROR=
-</screen>
+</programlisting>
</example>
<example>
<title>Sample <filename>make.conf.server</filename> for
<application>pkgng</application></title>
- <screen>WITH_PKGNG=yes
-PKG_BIN=/usr/local/sbin/pkg</screen>
+ <programlisting>WITH_PKGNG=yes
+PKG_BIN=/usr/local/sbin/pkg</programlisting>
</example>
<example>
<title>Sample <filename>make.conf.client</filename> for
<application>pkgng</application></title>
- <screen>WITH_PKGNG=yes</screen>
+ <programlisting>WITH_PKGNG=yes</programlisting>
</example>
<example>
<title>Sample <filename>src.conf.server</filename>
to test new <application>sort</application> codebase</title>
- <screen>WITH_BSD_SORT=yes</screen>
+ <programlisting>WITH_BSD_SORT=yes</programlisting>
</example>
</sect1>
<sect1 id="starting">
<title>Starting the Build</title>
- <para>Several separate builds for each architecture - branch combination
+ <para>Separate builds for various combinations of architecture and branch
are supported. All data private to a build (ports tree, src tree,
- packages, distfiles, log files, bindist, Makefile, etc) are located under
- <filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/builds/<replaceable>${buildid}</replaceable></filename>.
- The last created build can be alternatively referenced under buildid
- <literal>latest</literal>, the one before is called
+ packages, distfiles, log files, bindist, Makefile, etc) are located under the
+ <filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/builds/<replaceable>${buildid}</replaceable>/</filename>
+ directory.
+ The most recently created build can be alternatively referenced using buildid
+ <literal>latest</literal>, and the one before using
<literal>previous</literal>.</para>
<para>New builds are cloned from the <literal>latest</literal>, which is
@@ -425,7 +426,7 @@ PKG_BIN=/usr/local/sbin/pkg</screen>
<para>The symlinks go away, and you just use
<command>dopackages.wrapper</command> directly. For example:</para>
- <screen><command>dopackages.wrapper <replaceable>${arch}</replaceable> <replaceable>${branch}</replaceable> <replaceable>${buildid}</replaceable> <literal>[-options]</literal></command></screen>
+ <screen>&prompt.root; <userinput>dopackages.wrapper <replaceable>${arch}</replaceable> <replaceable>${branch}</replaceable> <replaceable>${buildid}</replaceable> <literal>[-options]</literal></userinput></screen>
</sect3>
@@ -443,7 +444,7 @@ PKG_BIN=/usr/local/sbin/pkg</screen>
<para><literal>-keep</literal> - 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.
- Don't forget to clean it up manually when you no longer need it.
+ Do not forget to clean it up manually when you no longer need it.
</para>
</listitem>
@@ -451,8 +452,8 @@ PKG_BIN=/usr/local/sbin/pkg</screen>
<para><literal>-nofinish</literal> - 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, don't forget to cleanup
- the clients when you don't need the build anymore.
+ 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>
@@ -519,7 +520,7 @@ PKG_BIN=/usr/local/sbin/pkg</screen>
<listitem>
<para><literal>-noduds</literal> - Do not rebuild the
<filename>duds</filename> file (ports that are never
- built, e.g. those marked <literal>IGNORE</literal>,
+ built, e.g., those marked <literal>IGNORE</literal>,
<literal>NO_PACKAGE</literal>, etc.) during
preprocessing.
</para>
@@ -558,9 +559,9 @@ PKG_BIN=/usr/local/sbin/pkg</screen>
</listitem>
<listitem>
- <para><literal>-srccvs</literal> - Do not update the
+ <para><literal>-srcvcs</literal> - Do not update the
<literal>src</literal> tree from the ZFS snapshot, update it with
- <literal>cvs update</literal> instead.
+ a fresh checkout instead.
</para>
</listitem>
@@ -572,9 +573,9 @@ PKG_BIN=/usr/local/sbin/pkg</screen>
</listitem>
<listitem>
- <para><literal>-portscvs</literal> - Do not update the
+ <para><literal>-portsvcs</literal> - Do not update the
<literal>ports</literal> tree from the ZFS snapshot, update it with
- <literal>cvs update</literal> instead.
+ a fresh checkout instead.
</para>
</listitem>
@@ -600,7 +601,7 @@ PKG_BIN=/usr/local/sbin/pkg</screen>
<listitem>
<para><literal>-fetch-original</literal> - Fetch the
distfile from the original <literal>MASTER_SITES</literal>
- rather than <hostid>ftp-master</hostid>.
+ rather than any cache such as on <hostid>ftp-master</hostid>.
</para>
</listitem>
@@ -628,9 +629,9 @@ PKG_BIN=/usr/local/sbin/pkg</screen>
<literal>-nocleanup</literal>, you need to clean up clients by running
</para>
- <para><command>build cleanup <replaceable>${arch}</replaceable> <replaceable>${branch}</replaceable> <replaceable>${buildid}</replaceable> -full</command></para>
+ <para>&prompt.user; <userinput>build cleanup <replaceable>${arch}</replaceable> <replaceable>${branch}</replaceable> <replaceable>${buildid}</replaceable> -full</userinput></para>
- <para><filename>errors/</filename>,
+ <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>.
@@ -653,7 +654,7 @@ PKG_BIN=/usr/local/sbin/pkg</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
+ 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>
@@ -664,10 +665,10 @@ PKG_BIN=/usr/local/sbin/pkg</screen>
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>/make.[0|1]</filename>:
+ <filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/journal</filename>:
</para>
- <screen><literal>don't know how to make dns-all(continuing)</literal></screen>
+ <programlisting><literal>don't know how to make dns-all(continuing)</literal></programlisting>
<para>To correct this problem, simply comment out or remove
the <literal>SUBDIR</literal> entries that point to empty
@@ -685,22 +686,22 @@ PKG_BIN=/usr/local/sbin/pkg</screen>
<example>
<title>Update the i386-7 tree and do a complete build</title>
- <para><command>dopackages.7 i386 -nosrc -norestr -nofinish</command></para>
- <para><command>dopackages.wrapper i386 7 -nosrc -norestr -nofinish</command></para>
+ <screen>&prompt.user; <userinput>dopackages.7 i386 -nosrc -norestr -nofinish</userinput>
+&prompt.user; <userinput>dopackages.wrapper i386 7 -nosrc -norestr -nofinish</userinput></screen>
</example>
<example>
<title>Restart an interrupted amd64-8 build without updating</title>
- <para><command>dopackages.8 amd64 -nosrc -noports -norestr -continue -noindex -noduds -nofinish</command></para>
- <para><command>dopackages.wrapper amd64 8 -nosrc -noports -norestr -continue -noindex -noduds -nofinish</command></para>
+ <screen>&prompt.user; <userinput>dopackages.8 amd64 -nosrc -noports -norestr -continue -noindex -noduds -nofinish</userinput>
+&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>
- <para><command>dopackages.7 sparc64 -finish</command></para>
- <para><command>dopackages.wrapper sparc64 7 -finish</command></para>
+ <screen>&prompt.user; <userinput>dopackages.7 sparc64 -finish</userinput>
+&prompt.user; <userinput>dopackages.wrapper sparc64 7 -finish</userinput></screen>
</example>
<para>Hint: it is usually best to run the <command>dopackages</command>
@@ -741,7 +742,7 @@ PKG_BIN=/usr/local/sbin/pkg</screen>
<para><literal>build srcupdate <replaceable>arch</replaceable>
<replaceable>branch</replaceable>
<replaceable>buildid</replaceable></literal> - Replaces the src
- tree with a new ZFS snapshot. Don't forget to use
+ tree with a new ZFS snapshot. Do not forget to use
<literal>-nosrc</literal> flag to <command>dopackages</command>
later!
</para>
@@ -751,7 +752,7 @@ PKG_BIN=/usr/local/sbin/pkg</screen>
<para><literal>build portsupdate <replaceable>arch</replaceable>
<replaceable>branch</replaceable>
<replaceable>buildid</replaceable></literal> - Replaces the ports
- tree with a new ZFS snapshot. Don't forget to use
+ tree with a new ZFS snapshot. Do not forget to use
<literal>-noports</literal> flag to <command>dopackages</command>
later!
</para>
@@ -767,7 +768,7 @@ PKG_BIN=/usr/local/sbin/pkg</screen>
package set. This can be accomplished with the following
invocation:</para>
- <para><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>
+ <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>
</sect2>
</sect1>
@@ -846,9 +847,9 @@ PKG_BIN=/usr/local/sbin/pkg</screen>
<filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/journal</filename> (new codebase).
Individual ports will write
their build logs to
- <filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/logs</filename>
+ <filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/logs/</filename>
and their error logs to
- <filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/errors</filename>.
+ <filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/errors/</filename>.
</para>
<para>Formerly the docs tree was also checked out, however, it has
@@ -886,7 +887,7 @@ PKG_BIN=/usr/local/sbin/pkg</screen>
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. <command>ps -t p1</command> or whatever.
+ is running in this tty, e.g., <command>ps -t p1</command> or whatever.
If there is not, you can just kill off the whole term easily with
<command>pkill -t pts/1</command>; otherwise issue a
<command>kill -HUP</command> in there by, for example,
@@ -911,11 +912,11 @@ PKG_BIN=/usr/local/sbin/pkg</screen>
<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:
- <screen>&prompt.user; <userinput>/var/portbuild/scripts/build cleanup i386 8-exp 20080714120411 -full</userinput></screen></para>
+ 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>chroot</literal>s will not be cleaned up for 24 hours, and no
+ <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>
@@ -924,21 +925,21 @@ PKG_BIN=/usr/local/sbin/pkg</screen>
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 <command>ps x | grep pdispatch</command>
- and it's less than the number of jobs that <literal>loads</literal>
- thinks are in use, you're in trouble.</para>
+ 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:
-<screen>ssh -l root gohan24 df</screen>
+ command across all clients for that buildenv. For example:</para>
+<screen>&prompt.user; ssh gohan24 df</screen>
- will get you a df, and
+ <para>will get you a df, and</para>
-<screen>allgohans "umount -f pointyhat.freebsd.org:/var/portbuild/i386/8-exp/ports"
-allgohans "umount -f pointyhat.freebsd.org:/var/portbuild/i386/8-exp/src"</screen>
+<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>
- are supposed to get rid of the hanging mounts. You will have to
+ <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>
@@ -949,8 +950,8 @@ umount: pointyhat.freebsd.org:/var/portb
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 2 mean that that client did not have those mounted;
- the latter 2 are a bug.</para>
+ 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>
@@ -1006,8 +1007,8 @@ umount: Cleanup of /x/tmp/8-exp/chroot/5
<para>You can use <command>qclient</command> command to monitor the status
of build nodes, and to list the currently scheduled jobs:</para>
- <para><command>python <replaceable>path</replaceable>/qmanager/qclient jobs</command></para>
- <para><command>python <replaceable>path</replaceable>/qmanager/qclient status</command></para>
+ <screen>&prompt.user; <command>python <replaceable>path</replaceable>/qmanager/qclient jobs</command>
+&prompt.user; <command>python <replaceable>path</replaceable>/qmanager/qclient status</command></screen>
<para>The
<command>scripts/stats <replaceable>${branch}</replaceable></command>
*** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
More information about the svn-doc-translations
mailing list