Date: Wed, 12 Dec 2012 22:39:55 +0000 (UTC) From: Glen Barber <gjb@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-translations@freebsd.org Subject: 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... Message-ID: <201212122239.qBCMdtQ4068240@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
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@vszbr.cz</email></para> </listitem> @@ -1722,6 +1717,11 @@ </listitem> <listitem> + <para>Christian Heckendorf + <email>heckend@bu.edu</email></para> + </listitem> + + <listitem> <para>Christian Lackas <email>delta@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 ***
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201212122239.qBCMdtQ4068240>