From owner-svn-doc-head@FreeBSD.ORG Sun Feb 16 00:44:25 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4133587; Sun, 16 Feb 2014 00:44:25 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BF6441905; Sun, 16 Feb 2014 00:44:25 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1G0iPUc004564; Sun, 16 Feb 2014 00:44:25 GMT (envelope-from pluknet@svn.freebsd.org) Received: (from pluknet@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1G0iPmE004563; Sun, 16 Feb 2014 00:44:25 GMT (envelope-from pluknet@svn.freebsd.org) Message-Id: <201402160044.s1G0iPmE004563@svn.freebsd.org> From: Sergey Kandaurov Date: Sun, 16 Feb 2014 00:44:25 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43951 - head/en_US.ISO8859-1/books/porters-handbook/special X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 00:44:25 -0000 Author: pluknet Date: Sun Feb 16 00:44:25 2014 New Revision: 43951 URL: http://svnweb.freebsd.org/changeset/doc/43951 Log: Fix typo. Modified: head/en_US.ISO8859-1/books/porters-handbook/special/chapter.xml Modified: head/en_US.ISO8859-1/books/porters-handbook/special/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/porters-handbook/special/chapter.xml Sat Feb 15 14:30:55 2014 (r43950) +++ head/en_US.ISO8859-1/books/porters-handbook/special/chapter.xml Sun Feb 16 00:44:25 2014 (r43951) @@ -255,7 +255,7 @@ above variables, the variable LEGAL_TEXT should be set to a string explaining the concern. For example, if special permission was obtained for &os; to - redistribute the binary, this variable should indiate + redistribute the binary, this variable should indicate so. From owner-svn-doc-head@FreeBSD.ORG Sun Feb 16 02:10:30 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 391BFA90; Sun, 16 Feb 2014 02:10:30 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 22E611DDE; Sun, 16 Feb 2014 02:10:30 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1G2AUSP041952; Sun, 16 Feb 2014 02:10:30 GMT (envelope-from wblock@svn.freebsd.org) Received: (from wblock@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1G2AUQT041951; Sun, 16 Feb 2014 02:10:30 GMT (envelope-from wblock@svn.freebsd.org) Message-Id: <201402160210.s1G2AUQT041951@svn.freebsd.org> From: Warren Block Date: Sun, 16 Feb 2014 02:10:30 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43952 - head/en_US.ISO8859-1/books/porters-handbook/quick-porting X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 02:10:30 -0000 Author: wblock Date: Sun Feb 16 02:10:29 2014 New Revision: 43952 URL: http://svnweb.freebsd.org/changeset/doc/43952 Log: Whitespace-only cleanup, translators please ignore. Modified: head/en_US.ISO8859-1/books/porters-handbook/quick-porting/chapter.xml Modified: head/en_US.ISO8859-1/books/porters-handbook/quick-porting/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/porters-handbook/quick-porting/chapter.xml Sun Feb 16 00:44:25 2014 (r43951) +++ head/en_US.ISO8859-1/books/porters-handbook/quick-porting/chapter.xml Sun Feb 16 02:10:29 2014 (r43952) @@ -4,45 +4,47 @@ $FreeBSD$ --> - + + + Quick Porting + + This section tells you how to quickly create a new port. In + many cases, it is not sufficient, so you will have to read + further on into the document. + + First, get the original tarball and put it into + DISTDIR, which defaults to + /usr/ports/distfiles. + + + The following assumes that the software compiled + out-of-the-box, i.e., there was absolutely no change required + for the port to work on your &os; box. If you needed to + change something, you will have to refer to the next section + too. + + + + It is recommended to set the DEVELOPER + &man.make.1; variable in /etc/make.conf + before getting into porting. + + &prompt.root; echo DEVELOPER=yes >> /etc/make.conf + + This setting enables the developer mode + that displays deprecation warnings and activates some further + quality checks on calling make. + - Quick Porting + + Writing the <filename>Makefile</filename> - This section tells you how to quickly create a new port. In - many cases, it is not sufficient, so you will have to read - further on into the document. + The minimal Makefile would look + something like this: - First, get the original tarball and put it into - DISTDIR, which defaults to - /usr/ports/distfiles. - - - The following assumes that the software compiled - out-of-the-box, i.e., there was absolutely no change required - for the port to work on your &os; box. If you needed to - change something, you will have to refer to the next section - too. - - - - It is recommended to set the DEVELOPER - &man.make.1; variable in /etc/make.conf - before getting into porting. - - &prompt.root; echo DEVELOPER=yes >> /etc/make.conf - - This setting enables the developer mode - that displays deprecation warnings and activates some further - quality checks on calling make. - - - - Writing the <filename>Makefile</filename> - - The minimal Makefile would look - something like this: - - # $FreeBSD$ + # $FreeBSD$ PORTNAME= oneko PORTVERSION= 1.1b @@ -54,101 +56,100 @@ COMMENT= Cat chasing a mouse all over th .include <bsd.port.mk> + + In some cases, the Makefile of an + existing port may contain additional lines in the header, + such as the name of the port and the date it was created. + This additional information has been declared obsolete, and + is being phased out. + + + See if you can figure it out. Do not worry about the + contents of the $FreeBSD$ + line, it will be filled in automatically by + Subversion when the port is + imported to our main ports tree. You can find a more detailed + example in the + sample Makefile + section. + + + + Writing the Description Files + + There are two description files that are required for + any port, whether they actually package or not. They are + pkg-descr and + pkg-plist. Their + pkg- prefix distinguishes them from other + files. + + + <filename>pkg-descr</filename> + + This is a longer description of the port. One to a few + paragraphs concisely explaining what the port does is + sufficient. + - In some cases, the Makefile of an - existing port may contain additional lines in the header, - such as the name of the port and the date it was created. - This additional information has been declared obsolete, and - is being phased out. + This is not a manual or an + in-depth description on how to use or compile the port! + Please be careful if you are copying from the + README or manpage; too + often they are not a concise description of the port or + are in an awkward format (e.g., manpages have justified + spacing, which looks particularly bad with monospaced + fonts). - See if you can figure it out. Do not worry about the - contents of the $FreeBSD$ - line, it will be filled in automatically by - Subversion when the port is - imported to our main ports tree. You can find a more detailed - example in the - sample Makefile - section. - - - - Writing the Description Files - - There are two description files that are required for - any port, whether they actually package or not. They are - pkg-descr and - pkg-plist. Their - pkg- prefix distinguishes them from other - files. - - - <filename>pkg-descr</filename> - - This is a longer description of the port. One to a few - paragraphs concisely explaining what the port does is - sufficient. - - - This is not a manual or an - in-depth description on how to use or compile the port! - Please be careful if you are copying from the - README or manpage; too - often they are not a concise description of the port or - are in an awkward format (e.g., manpages have justified - spacing, which looks particularly bad with monospaced - fonts). - - - A well-written pkg-descr describes - the port completely enough that users would not have to - consult the documentation or visit the website to understand - what the software does, how it can be useful, or what - particularly nice features it has. Mentioning certain - requirements like a graphical toolkit, heavy dependencies, - runtime environment, or implementation languages help users - decide whether this port will work for them. - - Include a URL to the official WWW homepage. Prepend - one of the websites (pick the most - common one) with WWW: (followed by single - space) so that automated tools will work correctly. If the - URI is the root of the website or directory, it should be - terminated with a slash. - - - If the listed webpage for a port is not available, try - to search the Internet first to see if the official site - moved, was renamed, or is hosted elsewhere. - + A well-written pkg-descr describes + the port completely enough that users would not have to + consult the documentation or visit the website to understand + what the software does, how it can be useful, or what + particularly nice features it has. Mentioning certain + requirements like a graphical toolkit, heavy dependencies, + runtime environment, or implementation languages help users + decide whether this port will work for them. + + Include a URL to the official WWW homepage. Prepend + one of the websites (pick the most + common one) with WWW: (followed by single + space) so that automated tools will work correctly. If the + URI is the root of the website or directory, it should be + terminated with a slash. - The following example shows how your - pkg-descr should look: + + If the listed webpage for a port is not available, try + to search the Internet first to see if the official site + moved, was renamed, or is hosted elsewhere. + + + The following example shows how your + pkg-descr should look: - This is a port of oneko, in which a cat chases a poor mouse all over + This is a port of oneko, in which a cat chases a poor mouse all over the screen. : (etc.) WWW: http://www.oneko.org/ - + - - <filename>pkg-plist</filename> + + <filename>pkg-plist</filename> - This file lists all the files installed by the port. It - is also called the packing list because the - package is generated by packing the files listed here. The - pathnames are relative to the installation prefix (usually - /usr/local. - If the - port creates directories during installation, make sure to - add @dirrm lines to remove them when the - package is deleted. + This file lists all the files installed by the port. It + is also called the packing list because the + package is generated by packing the files listed here. The + pathnames are relative to the installation prefix (usually + /usr/local. If the port creates + directories during installation, make sure to add + @dirrm lines to remove them when the + package is deleted. - Here is a small example: + Here is a small example: - bin/oneko + bin/oneko man/man1/oneko.1.gz lib/X11/app-defaults/Oneko lib/X11/oneko/cat1.xpm @@ -156,34 +157,34 @@ lib/X11/oneko/cat2.xpm lib/X11/oneko/mouse.xpm @dirrm lib/X11/oneko - Refer to the &man.pkg-create.8; manual page for details - on the packing list. + Refer to the &man.pkg-create.8; manual page for details + on the packing list. - - It is recommended that you keep all the filenames in - this file sorted alphabetically. It will make verifying - the changes when you upgrade the port much easier. - - - - Creating a packing list manually can be a very tedious - task. If the port installs a large numbers of files, - creating the packing list - automatically might save time. - - - There is only one case when - pkg-plist can be omitted from a port. - If the port installs just a handful of files, and perhaps - directories, the files and directories may be listed in the - variables PLIST_FILES and - PLIST_DIRS, respectively, within the - port's Makefile. For instance, we - could get along without pkg-plist in - the above oneko port by adding the - following lines to the Makefile: + + It is recommended that you keep all the filenames in + this file sorted alphabetically. It will make verifying + the changes when you upgrade the port much easier. + + + + Creating a packing list manually can be a very tedious + task. If the port installs a large numbers of files, + creating the packing list + automatically might save time. + - PLIST_FILES= bin/oneko \ + There is only one case when + pkg-plist can be omitted from a port. + If the port installs just a handful of files, and perhaps + directories, the files and directories may be listed in the + variables PLIST_FILES and + PLIST_DIRS, respectively, within the + port's Makefile. For instance, we + could get along without pkg-plist in + the above oneko port by adding the + following lines to the Makefile: + + PLIST_FILES= bin/oneko \ man/man1/oneko.1.gz \ lib/X11/app-defaults/Oneko \ lib/X11/oneko/cat1.xpm \ @@ -191,215 +192,211 @@ lib/X11/oneko/mouse.xpm lib/X11/oneko/mouse.xpm PLIST_DIRS= lib/X11/oneko - Of course, PLIST_DIRS should be left - unset if a port installs no directories of its own. - - - - Several ports can share a common directory. In that - case, PLIST_DIRS should be replaced by - PLIST_DIRSTRY so that the directory is - removed only if empty, otherwise it is silently ignored. - PLIST_DIRS and - PLIST_DIRSTRY are equivalent to using - @dirrm and @dirrmtry - in pkg-plist, as described in - . - - - The price for this way of listing port's files and - directories is that you cannot use command sequences - described in &man.pkg-create.8;. Therefore, it is suitable - only for simple ports and makes them even simpler. At the - same time, it has the advantage of reducing the number of - files in the ports collection. Please consider using this - technique before you resort to - pkg-plist. - - Later we will see how pkg-plist - and PLIST_FILES can be used to fulfill - more sophisticated - tasks. - - - - - Creating the Checksum File - - Just type make makesum. The ports make - rules will automatically generate the file - distinfo. - - If a file fetched has its checksum changed regularly and - you are certain the source is trusted (i.e., it comes from - manufacturer CDs or documentation generated daily), you should - specify these files in the IGNOREFILES - variable. Then the checksum is not calculated for that file - when you run make makesum, but set to - IGNORE. - - - - Testing the Port - - You should make sure that the port rules do exactly what - you want them to do, including packaging up the port. These - are the important points you need to verify. - - - - pkg-plist does not contain - anything not installed by the port. - - - - pkg-plist contains everything - that is installed by the port. - - - - The port can be installed using the - install target. This verifies - that the install script works correctly. - - - - The port can be deinstalled properly using the - deinstall target. This - verifies that the deinstall script works correctly. - - - - Make sure that make package can be - run as a normal user (that is, not as - root). If that - fails, NEED_ROOT=yes must be added to - the port Makefile. - - - - - Recommended Test Ordering - - - make stage - - - - make check-orphans - - - - make package - - - - make install - - - - make deinstall - - - - pkg add package-filename - - - - make package (as user) - - - - Make certain no warnings are shown in any of - the stages. - - Thorough automated testing can be done with - ports-mgmt/tinderbox or - ports-mgmt/poudriere from the - Ports Collection. These applications maintain - jails where all of the steps shown above - can be tested without affecting the state of the host - system. - - - - Checking Your Port with - <command>portlint</command> - - Please use portlint to see if your port - conforms to our guidelines. The - ports-mgmt/portlint - program is part of the ports collection. In particular, you - may want to check if the - Makefile is in the - right shape and the - package is named - appropriately. - - - - Submitting the New Port - - Before submitting the new port, read - the DOs and DON'Ts - section. - - Once happy with your port, the only thing remaining is to - put it in the main &os; ports tree and make everybody else - happy about it too. We do not need the - work directory or the - pkgname.tgz package, so delete them - now. - - Next, build the &man.shar.1; file. Assuming the port is - called oneko, cd to the - directory above where the oneko directory - is located, and then type: - shar `find oneko` > oneko.shar - - Include oneko.shar in a bug - report and send it with &man.send-pr.1;. See - Bug - Reports and General Commentary for more information - about &man.send-pr.1;. - - Classify the bug report as Category - ports and Class - change-request. Do - not mark the report - confidential! Add a short description of - the program to the Description field of the PR (perhaps a - short version of the COMMENT), and add the - .shar file to the Fix field. + Of course, PLIST_DIRS should be left + unset if a port installs no directories of its own. - Giving a good description in the synopsis of the problem - report makes the work of port committers a lot easier. We - prefer something like New port: - <category>/<portname> <short description of - the port> for new ports. Using this - scheme makes it easier and faster to begin the work of - committing the new port. + Several ports can share a common directory. In that + case, PLIST_DIRS should be replaced by + PLIST_DIRSTRY so that the directory is + removed only if empty, otherwise it is silently ignored. + PLIST_DIRS and + PLIST_DIRSTRY are equivalent to using + @dirrm and @dirrmtry + in pkg-plist, as described in + . - One more time, do not include the original - source distfile, the work directory, or - the package you built with - make package; and, do use - &man.shar.1; for new ports, not &man.diff.1;. - - After submitting the port, please be patient. The time - needed to include a new port in &os; can vary from a few days - to a few months. The list of pending port - PRs can be viewed at . - - After looking at the new port, we will reply if necessary, - and put it in the tree. Your name will also be added to the - list of Additional - &os; Contributors and other files. - - + The price for this way of listing port's files and + directories is that you cannot use command sequences + described in &man.pkg-create.8;. Therefore, it is suitable + only for simple ports and makes them even simpler. At the + same time, it has the advantage of reducing the number of + files in the ports collection. Please consider using this + technique before you resort to + pkg-plist. + + Later we will see how pkg-plist + and PLIST_FILES can be used to fulfill + more sophisticated + tasks. + + + + + Creating the Checksum File + + Just type make makesum. The ports make + rules will automatically generate the file + distinfo. + + If a file fetched has its checksum changed regularly and + you are certain the source is trusted (i.e., it comes from + manufacturer CDs or documentation generated daily), you should + specify these files in the IGNOREFILES + variable. Then the checksum is not calculated for that file + when you run make makesum, but set to + IGNORE. + + + + Testing the Port + + You should make sure that the port rules do exactly what + you want them to do, including packaging up the port. These + are the important points you need to verify. + + + + pkg-plist does not contain + anything not installed by the port. + + + + pkg-plist contains everything + that is installed by the port. + + + + The port can be installed using the + install target. This verifies + that the install script works correctly. + + + + The port can be deinstalled properly using the + deinstall target. This + verifies that the deinstall script works correctly. + + + + Make sure that make package can be + run as a normal user (that is, not as + root). If that + fails, NEED_ROOT=yes must be added to + the port Makefile. + + + + + Recommended Test Ordering + + + make stage + + + + make check-orphans + + + + make package + + + + make install + + + + make deinstall + + + + pkg add package-filename + + + + make package (as user) + + + + Make certain no warnings are shown in any of + the stages. + + Thorough automated testing can be done with + ports-mgmt/tinderbox or + ports-mgmt/poudriere from the + Ports Collection. These applications maintain + jails where all of the steps shown above + can be tested without affecting the state of the host + system. + + + + Checking Your Port with + <command>portlint</command> + + Please use portlint to see if your port + conforms to our guidelines. The + ports-mgmt/portlint + program is part of the ports collection. In particular, you + may want to check if the + Makefile is in the + right shape and the + package is named + appropriately. + + + + Submitting the New Port + + Before submitting the new port, read the + DOs and DON'Ts + section. + + Once happy with your port, the only thing remaining is to + put it in the main &os; ports tree and make everybody else + happy about it too. We do not need the + work directory or the + pkgname.tgz package, so delete them + now. + + Next, build the &man.shar.1; file. Assuming the port is + called oneko, cd to the + directory above where the oneko directory + is located, and then type: + shar `find oneko` > oneko.shar + + Include oneko.shar in a bug + report and send it with &man.send-pr.1;. See Bug + Reports and General Commentary for more information + about &man.send-pr.1;. + + Classify the bug report as Category + ports and Class + change-request. Do not + mark the report confidential! Add a short + description of the program to the Description field of the PR + (perhaps a short version of the COMMENT), and + add the .shar file to the Fix field. + + + Giving a good description in the synopsis of the problem + report makes the work of port committers a lot easier. We + prefer something like New port: + <category>/<portname> <short description of + the port> for new ports. Using this + scheme makes it easier and faster to begin the work of + committing the new port. + + One more time, do not include the original + source distfile, the work directory, or + the package you built with + make package; and, do use + &man.shar.1; for new ports, not &man.diff.1;. + + After submitting the port, please be patient. The time + needed to include a new port in &os; can vary from a few days + to a few months. The list of pending port + PRs can be viewed at . + + After looking at the new port, we will reply if necessary, + and put it in the tree. Your name will also be added to the + list of Additional + &os; Contributors and other files. + + From owner-svn-doc-head@FreeBSD.ORG Sun Feb 16 02:24:39 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 044CBC61; Sun, 16 Feb 2014 02:24:39 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DF31E1F71; Sun, 16 Feb 2014 02:24:38 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1G2OciE047741; Sun, 16 Feb 2014 02:24:38 GMT (envelope-from wblock@svn.freebsd.org) Received: (from wblock@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1G2Ocar047740; Sun, 16 Feb 2014 02:24:38 GMT (envelope-from wblock@svn.freebsd.org) Message-Id: <201402160224.s1G2Ocar047740@svn.freebsd.org> From: Warren Block Date: Sun, 16 Feb 2014 02:24:38 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43953 - head/en_US.ISO8859-1/books/porters-handbook/security X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 02:24:39 -0000 Author: wblock Date: Sun Feb 16 02:24:38 2014 New Revision: 43953 URL: http://svnweb.freebsd.org/changeset/doc/43953 Log: Whitespace-only fixes, translators please ignore. Modified: head/en_US.ISO8859-1/books/porters-handbook/security/chapter.xml Modified: head/en_US.ISO8859-1/books/porters-handbook/security/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/porters-handbook/security/chapter.xml Sun Feb 16 02:10:29 2014 (r43952) +++ head/en_US.ISO8859-1/books/porters-handbook/security/chapter.xml Sun Feb 16 02:24:38 2014 (r43953) @@ -4,160 +4,159 @@ $FreeBSD$ --> - + + + Security + + + Why Security is So Important + + Bugs are occasionally introduced to the software. Arguably, + the most dangerous of them are those opening security + vulnerabilities. From the technical viewpoint, such + vulnerabilities are to be closed by exterminating the bugs that + caused them. However, the policies for handling mere bugs and + security vulnerabilities are very different. + + A typical small bug affects only those users who have + enabled some combination of options triggering the bug. The + developer will eventually release a patch followed by a new + version of the software, free of the bug, but the majority of + users will not take the trouble of upgrading immediately because + the bug has never vexed them. A critical bug that may cause + data loss represents a graver issue. Nevertheless, prudent + users know that a lot of possible accidents, besides software + bugs, are likely to lead to data loss, and so they make backups + of important data; in addition, a critical bug will be + discovered really soon. + + A security vulnerability is all different. First, it may + remain unnoticed for years because often it does not cause + software malfunction. Second, a malicious party can use it to + gain unauthorized access to a vulnerable system, to destroy or + alter sensitive data; and in the worst case the user will not + even notice the harm caused. Third, exposing a vulnerable + system often assists attackers to break into other systems that + could not be compromised otherwise. Therefore closing a + vulnerability alone is not enough: the audience should be + notified of it in most clear and comprehensive manner, which + will allow to evaluate the danger and take appropriate + actions. + + + + Fixing Security Vulnerabilities + + While on the subject of ports and packages, a security + vulnerability may initially appear in the original distribution + or in the port files. In the former case, the original software + developer is likely to release a patch or a new version + instantly, and you will only need to update the port promptly + with respect to the author's fix. If the fix is delayed for + some reason, you should either + mark the port as + FORBIDDEN or introduce a patch file of + your own to the port. In the case of a vulnerable port, just + fix the port as soon as possible. In either case, + the standard procedure for + submitting your change should be followed unless you have + rights to commit it directly to the ports tree. + + + Being a ports committer is not enough to commit to an + arbitrary port. Remember that ports usually have maintainers, + whom you should respect. + + + Please make sure that the port's revision is bumped as soon + as the vulnerability has been closed. That is how the users who + upgrade installed packages on a regular basis will see they need + to run an update. Besides, a new package will be built and + distributed over FTP and WWW mirrors, replacing the vulnerable + one. PORTREVISION should be bumped unless + PORTVERSION has changed in the course of + correcting the vulnerability. That is you should bump + PORTREVISION if you have added a patch file + to the port, but you should not if you have updated the port to + the latest software version and thus already touched + PORTVERSION. Please refer to the + corresponding + section for more information. + + + + Keeping the Community Informed + + + The VuXML Database + + A very important and urgent step to take as early after a + security vulnerability is discovered as possible is to notify + the community of port users about the jeopardy. Such + notification serves two purposes. First, should the danger be + really severe it will be wise to apply an instant workaround. + E.g., stop the affected network service or even deinstall the + port completely until the vulnerability is closed. Second, a + lot of users tend to upgrade installed packages only + occasionally. They will know from the notification that they + must update the package without delay as + soon as a corrected version is available. + + Given the huge number of ports in the tree, a security + advisory cannot be issued on each incident without creating a + flood and losing the attention of the audience when it comes + to really serious matters. Therefore security vulnerabilities + found in ports are recorded in + the &os; + VuXML database. The Security Officer Team members + also monitor it for issues requiring their + intervention. + + If you have committer rights you can update the VuXML + database by yourself. So you will both help the Security + Officer Team and deliver the crucial information to the + community earlier. However, if you are not a committer, or + you believe you have found an exceptionally severe + vulnerability please do not hesitate to contact the Security + Officer Team directly as described on the + &os; + Security Information page. + + The VuXML database is an XML document. + Its source file vuln.xml is kept right + inside the port security/vuxml. + Therefore the file's full pathname will be + PORTSDIR/security/vuxml/vuln.xml. Each + time you discover a security vulnerability in a port, please + add an entry for it to that file. Until you are familiar with + VuXML, the best thing you can do is to find an existing entry + fitting your case, then copy it and use it as a + template. + + + + A Short Introduction to VuXML + + The full-blown XML format is complex, + and far beyond the scope of this book. However, to gain basic + insight on the structure of a VuXML entry you need only the + notion of tags. XML tag names are enclosed in angle brackets. + Each opening <tag> must have a matching closing + </tag>. Tags may be nested. If nesting, the inner tags + must be closed before the outer ones. There is a hierarchy of + tags, i.e., more complex rules of nesting them. This is + similar to HTML. The major difference is that XML is + eXtensible, i.e., based on defining + custom tags. Due to its intrinsic structure XML puts + otherwise amorphous data into shape. VuXML is particularly + tailored to mark up descriptions of security + vulnerabilities. - Security + Now consider a realistic VuXML entry: - - Why Security is So Important - - Bugs are occasionally introduced to the software. - Arguably, the most dangerous of them are those opening - security vulnerabilities. From the technical viewpoint, such - vulnerabilities are to be closed by exterminating the bugs - that caused them. However, the policies for handling mere - bugs and security vulnerabilities are very different. - - A typical small bug affects only those users who have - enabled some combination of options triggering the bug. The - developer will eventually release a patch followed by a new - version of the software, free of the bug, but the majority of - users will not take the trouble of upgrading immediately - because the bug has never vexed them. A critical bug that may - cause data loss represents a graver issue. Nevertheless, - prudent users know that a lot of possible accidents, besides - software bugs, are likely to lead to data loss, and so they - make backups of important data; in addition, a critical bug - will be discovered really soon. - - A security vulnerability is all different. First, it may - remain unnoticed for years because often it does not cause - software malfunction. Second, a malicious party can use it to - gain unauthorized access to a vulnerable system, to destroy or - alter sensitive data; and in the worst case the user will not - even notice the harm caused. Third, exposing a vulnerable - system often assists attackers to break into other systems - that could not be compromised otherwise. Therefore closing a - vulnerability alone is not enough: the audience should be - notified of it in most clear and comprehensive manner, which - will allow to evaluate the danger and take appropriate - actions. - - - - Fixing Security Vulnerabilities - - While on the subject of ports and packages, a security - vulnerability may initially appear in the original - distribution or in the port files. In the former case, the - original software developer is likely to release a patch or a - new version instantly, and you will only need to update the - port promptly with respect to the author's fix. If the fix is - delayed for some reason, you should either - mark the port as - FORBIDDEN or introduce a patch file - of your own to the port. In the case of a vulnerable port, - just fix the port as soon as possible. In either case, - the standard procedure for - submitting your change should be followed unless you - have rights to commit it directly to the ports tree. - - - Being a ports committer is not enough to commit to - an arbitrary port. Remember that ports usually have - maintainers, whom you should respect. - - - Please make sure that the port's revision is bumped - as soon as the vulnerability has been closed. - That is how the users who upgrade installed packages - on a regular basis will see they need to run an update. - Besides, a new package will be built and distributed - over FTP and WWW mirrors, replacing the vulnerable one. - PORTREVISION should be bumped unless - PORTVERSION has changed in the course - of correcting the vulnerability. That is you should - bump PORTREVISION if you have added a - patch file to the port, but you should not if you have updated - the port to the latest software version and thus already - touched PORTVERSION. Please refer to the - corresponding - section for more information. - - - - Keeping the Community Informed - - - The VuXML Database - - A very important and urgent step to take as early after - a security vulnerability is discovered as possible is to - notify the community of port users about the jeopardy. Such - notification serves two purposes. First, should the danger - be really severe it will be wise to apply an instant - workaround. E.g., stop the affected network service or even - deinstall the port completely until the vulnerability is - closed. Second, a lot of users tend to upgrade installed - packages only occasionally. They will know from the - notification that they must update the - package without delay as soon as a corrected version is - available. - - Given the huge number of ports in the tree, a security - advisory cannot be issued on each incident without creating - a flood and losing the attention of the audience when it - comes to really serious matters. Therefore security - vulnerabilities found in ports are recorded in - the &os; - VuXML database. The Security Officer Team members - also monitor it for issues requiring their - intervention. - - If you have committer rights you can update the VuXML - database by yourself. So you will both help the Security - Officer Team and deliver the crucial information to the - community earlier. However, if you are not a committer, or - you believe you have found an exceptionally severe - vulnerability please do not hesitate to contact the Security - Officer Team directly as described on the &os; - Security Information page. - - The VuXML database is an XML - document. Its source file vuln.xml is - kept right inside the port - security/vuxml. Therefore - the file's full pathname will be - PORTSDIR/security/vuxml/vuln.xml. Each - time you discover a security vulnerability in a port, please - add an entry for it to that file. Until you are familiar - with VuXML, the best thing you can do is to find an existing - entry fitting your case, then copy it and use it as a - template. - - - - A Short Introduction to VuXML - - The full-blown XML format is complex, - and far beyond the scope of this book. However, to gain - basic insight on the structure of a VuXML entry you need - only the notion of tags. XML tag names are enclosed in - angle brackets. Each opening <tag> must have a - matching closing </tag>. Tags may be nested. If - nesting, the inner tags must be closed before the outer - ones. There is a hierarchy of tags, i.e., more complex - rules of nesting them. This is similar to HTML. The major - difference is that XML is eXtensible, - i.e., based on defining custom tags. Due to its intrinsic - structure XML puts otherwise amorphous data into shape. - VuXML is particularly tailored to mark up descriptions of - security vulnerabilities. - - Now consider a realistic VuXML entry: - - <vuln vid="f4bc80f4-da62-11d8-90ea-0004ac98a7b9"> + <vuln vid="f4bc80f4-da62-11d8-90ea-0004ac98a7b9"> <topic>Several vulnerabilities found in Foo</topic> <affects> <package> @@ -206,314 +205,300 @@ </dates> </vuln> - The tag names are supposed to be self-explanatory so we - shall take a closer look only at fields you will need to - fill in by yourself: - - - - This is the top-level tag of a VuXML entry. It has - a mandatory attribute, vid, - specifying a universally unique identifier (UUID) for - this entry (in quotes). You should generate a UUID for - each new VuXML entry (and do not forget to substitute it - for the template UUID unless you are writing the entry - from scratch). You can use &man.uuidgen.1; to generate - a VuXML UUID. - - - - This is a one-line description of the issue - found. - - - - The names of packages affected are listed there. - Multiple names can be given since several packages may - be based on a single master port or software product. - This may include stable and development branches, - localized versions, and slave ports featuring different - choices of important build-time configuration - options. - - - It is your responsibility to find all such related - packages when writing a VuXML entry. Keep in mind - that make search name=foo is your - friend. The primary points to look for are as - follows: - - - - the foo-devel variant - for a foo port; - - - - other variants with a suffix like - -a4 (for print-related - packages), -without-gui (for - packages with X support disabled), or - similar; - - - - jp-, - ru-, zh-, - and other possible localized variants in the - corresponding national categories of the ports - collection. - - - - - - - Affected versions of the package(s) are specified - there as one or more ranges using a combination of - <lt>, - <le>, - <eq>, - <ge>, and - <gt> elements. The version - ranges given should not overlap. - - In a range specification, * - (asterisk) denotes the smallest version number. In - particular, 2.* is less than - 2.a. Therefore an asterisk may be - used for a range to match all possible - alpha, beta, and - RC versions. For instance, - <ge>2.*</ge><lt>3.*</lt> - will selectively match every 2.x - version while - <ge>2.0</ge><lt>3.0</lt> - will not since the latter misses - 2.r3 and matches - 3.b. - - The above example specifies that affected are - versions from 1.6 to - 1.9 inclusive, versions - 2.x before 2.4_1, - and version 3.0b1. - - - - Several related package groups (essentially, ports) - can be listed in the <affected> - section. This can be used if several software products - (say FooBar, FreeBar and OpenBar) grow from the same - code base and still share its bugs and vulnerabilities. - Note the difference from listing multiple names within a - single <package> section. - - - - The version ranges should allow for - PORTEPOCH and - PORTREVISION if applicable. Please - remember that according to the collation rules, a - version with a non-zero PORTEPOCH is - greater than any version without - PORTEPOCH, e.g., - 3.0,1 is greater than - 3.1 or even than - 8.9. - - - - This is a summary of the issue. XHTML is used in - this field. At least enclosing - <p> and - </p> should appear. More - complex mark-up may be used, but only for the sake of - accuracy and clarity: No eye candy please. - - - - This section contains references to relevant - documents. As many references as apply are - encouraged. - - - - This is a &os; - security advisory. - - - - This is a &os; - problem report. - - - - This is a - MITRE - CVE identifier. - - - - This is a SecurityFocus - Bug ID. - - - - This is a - US-CERT - security advisory. - - - - This is a - US-CERT - vulnerability note. - - - - This is a - US-CERT - Cyber Security Alert. - - - - This is a - US-CERT - Technical Cyber Security Alert. - - - - This is a URL to an archived posting in a mailing - list. The attribute msgid is - optional and may specify the message ID of the - posting. - - - - This is a generic URL. It should be used only if - none of the other reference categories apply. - - - - This is the date when the issue was disclosed - (YYYY-MM-DD). - - - - This is the date when the entry was added - (YYYY-MM-DD). - - - - This is the date when any information in the entry - was last modified - (YYYY-MM-DD). New entries - must not include this field. It should be added upon - editing an existing entry. - - - - - - Testing Your Changes to the VuXML Database - - Assume you just wrote or filled in an entry for a - vulnerability in the package clamav that - has been fixed in version 0.65_7. - - As a prerequisite, you need to - install fresh versions of the ports - ports-mgmt/portaudit, - ports-mgmt/portaudit-db, - and - security/vuxml. - - - To run packaudit you must have - permission to write to its - DATABASEDIR, - typically /var/db/portaudit. - - To use a different directory set the - DATABASEDIR - environment variable to a different location. - - If you are working in a directory other than - ${PORTSDIR}/security/vuxml set the - VUXMLDIR - environment variable to the directory where - vuln.xml is located. - - - First, check whether there already is an entry for this - vulnerability. If there were such an entry, it would match - the previous version of the package, - 0.65_6: + The tag names are supposed to be self-explanatory so we + shall take a closer look only at fields you will need to fill + in by yourself: + + + + This is the top-level tag of a VuXML entry. It has a + mandatory attribute, vid, specifying a + universally unique identifier (UUID) for this entry (in + quotes). You should generate a UUID for each new VuXML + entry (and do not forget to substitute it for the template + UUID unless you are writing the entry from scratch). You + can use &man.uuidgen.1; to generate a VuXML UUID. + + + + This is a one-line description of the issue + found. + + + + The names of packages affected are listed there. + Multiple names can be given since several packages may be + based on a single master port or software product. This + may include stable and development branches, localized + versions, and slave ports featuring different choices of + important build-time configuration options. + + + It is your responsibility to find all such related + packages when writing a VuXML entry. Keep in mind that + make search name=foo is your friend. + The primary points to look for are as follows: + + + + the foo-devel variant for a + foo port; + + + + other variants with a suffix like + -a4 (for print-related packages), + -without-gui (for packages with X + support disabled), or similar; + + + + jp-, ru-, + zh-, and other possible localized + variants in the corresponding national categories of + the ports collection. + + + + + + + Affected versions of the package(s) are specified + there as one or more ranges using a combination of + <lt>, + <le>, + <eq>, + <ge>, and + <gt> elements. The version + ranges given should not overlap. + + In a range specification, * + (asterisk) denotes the smallest version number. In + particular, 2.* is less than + 2.a. Therefore an asterisk may be used + for a range to match all possible + alpha, beta, and + RC versions. For instance, + <ge>2.*</ge><lt>3.*</lt> + will selectively match every 2.x + version while + <ge>2.0</ge><lt>3.0</lt> + will not since the latter misses 2.r3 + and matches 3.b. + + The above example specifies that affected are versions + from 1.6 to 1.9 + inclusive, versions 2.x before + 2.4_1, and version + 3.0b1. + + + + Several related package groups (essentially, ports) + can be listed in the <affected> + section. This can be used if several software products + (say FooBar, FreeBar and OpenBar) grow from the same code + base and still share its bugs and vulnerabilities. Note + the difference from listing multiple names within a single + <package> section. + + + + The version ranges should allow for + PORTEPOCH and + PORTREVISION if applicable. Please + remember that according to the collation rules, a version + with a non-zero PORTEPOCH is greater + than any version without PORTEPOCH, + e.g., 3.0,1 is greater than + 3.1 or even than + 8.9. + + + + This is a summary of the issue. XHTML is used in this + field. At least enclosing <p> + and </p> should appear. More + complex mark-up may be used, but only for the sake of + accuracy and clarity: No eye candy please. + + + + This section contains references to relevant + documents. As many references as apply are + encouraged. + + + + This is a &os; + security advisory. + + + + This is a &os; + problem report. + + + + This is a + MITRE + CVE identifier. + + + + This is a SecurityFocus + Bug ID. + + + + This is a + US-CERT + security advisory. + + + + This is a + US-CERT + vulnerability note. + + + + This is a + US-CERT + Cyber Security Alert. + + + + This is a + US-CERT + Technical Cyber Security Alert. + + + + This is a URL to an archived posting in a mailing + list. The attribute msgid is optional + and may specify the message ID of the posting. + + + + This is a generic URL. It should be used only if none + of the other reference categories apply. + + + + This is the date when the issue was disclosed + (YYYY-MM-DD). + + + + This is the date when the entry was added + (YYYY-MM-DD). + + + + This is the date when any information in the entry was + last modified (YYYY-MM-DD). + New entries must not include this field. It should be + added upon editing an existing entry. + + + + + + Testing Your Changes to the VuXML Database + + Assume you just wrote or filled in an entry for a + vulnerability in the package clamav that + has been fixed in version 0.65_7. + + As a prerequisite, you need to + install fresh versions of the ports + ports-mgmt/portaudit, + ports-mgmt/portaudit-db, and + security/vuxml. + + + To run packaudit you must have + permission to write to its DATABASEDIR, + typically /var/db/portaudit. + + To use a different directory set the + DATABASEDIR environment variable to a + different location. + + If you are working in a directory other than + ${PORTSDIR}/security/vuxml set the + VUXMLDIR environment variable to the + directory where vuln.xml is + located. + + + First, check whether there already is an entry for this + vulnerability. If there were such an entry, it would match + the previous version of the package, + 0.65_6: - &prompt.user; packaudit + &prompt.user; packaudit &prompt.user; portaudit clamav-0.65_6 - If there is none found, you have the green light to add - a new entry for this vulnerability. + If there is none found, you have the green light to add a + new entry for this vulnerability. - &prompt.user; cd ${PORTSDIR}/security/vuxml + &prompt.user; cd ${PORTSDIR}/security/vuxml &prompt.user; make newentry - When you are done verify its syntax and - formatting. + When you are done verify its syntax and formatting. - &prompt.user; make validate + &prompt.user; make validate - - You will need at least one of the following packages - installed: - textproc/libxml2, - textproc/jade. - + + You will need at least one of the following packages + installed: textproc/libxml2, + textproc/jade. + - Now rebuild the portaudit database - from the VuXML file: + Now rebuild the portaudit database from + the VuXML file: - &prompt.user; packaudit + &prompt.user; packaudit - To verify that the <affected> - section of your entry will match correct package(s), issue - the following command: + To verify that the <affected> + section of your entry will match correct package(s), issue the + following command: - &prompt.user; portaudit -f /usr/ports/INDEX -r uuid + &prompt.user; portaudit -f /usr/ports/INDEX -r uuid - - Please refer to &man.portaudit.1; for better - understanding of the command syntax. - + + Please refer to &man.portaudit.1; for better + understanding of the command syntax. + - Make sure that your entry produces no spurious matches - in the output. + Make sure that your entry produces no spurious matches in + the output. - Now check whether the right package versions are matched - by your entry: + Now check whether the right package versions are matched + by your entry: - &prompt.user; portaudit clamav-0.65_6 clamav-0.65_7 + &prompt.user; portaudit clamav-0.65_6 clamav-0.65_7 Affected package: clamav-0.65_6 (matched by clamav<0.65_7) Type of problem: clamav remote denial-of-service. Reference: <http://www.freebsd.org/ports/portaudit/74a9541d-5d6c-11d8-80e3-0020ed76ef5a.html> 1 problem(s) found. - The former version should match while the latter one - should not. + The former version should match while the latter one + should not. - Finally, verify whether the web page generated from the - VuXML database looks like expected: + Finally, verify whether the web page generated from the + VuXML database looks like expected: - &prompt.user; mkdir -p ~/public_html/portaudit + &prompt.user; mkdir -p ~/public_html/portaudit &prompt.user; packaudit &prompt.user; lynx ~/public_html/portaudit/74a9541d-5d6c-11d8-80e3-0020ed76ef5a.html - - - + + + From owner-svn-doc-head@FreeBSD.ORG Sun Feb 16 02:39:13 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B447FF33; Sun, 16 Feb 2014 02:39:13 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9AC621062; Sun, 16 Feb 2014 02:39:13 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1G2dDYv052952; Sun, 16 Feb 2014 02:39:13 GMT (envelope-from wblock@svn.freebsd.org) Received: (from wblock@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1G2dDF0052951; Sun, 16 Feb 2014 02:39:13 GMT (envelope-from wblock@svn.freebsd.org) Message-Id: <201402160239.s1G2dDF0052951@svn.freebsd.org> From: Warren Block Date: Sun, 16 Feb 2014 02:39:13 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43954 - head/en_US.ISO8859-1/books/porters-handbook/slow-porting X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 02:39:13 -0000 Author: wblock Date: Sun Feb 16 02:39:13 2014 New Revision: 43954 URL: http://svnweb.freebsd.org/changeset/doc/43954 Log: Whitespace-only fixes, translators please ignore. Modified: head/en_US.ISO8859-1/books/porters-handbook/slow-porting/chapter.xml Modified: head/en_US.ISO8859-1/books/porters-handbook/slow-porting/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/porters-handbook/slow-porting/chapter.xml Sun Feb 16 02:24:38 2014 (r43953) +++ head/en_US.ISO8859-1/books/porters-handbook/slow-porting/chapter.xml Sun Feb 16 02:39:13 2014 (r43954) @@ -4,427 +4,414 @@ $FreeBSD$ --> - + + + Slow Porting + + Okay, so it was not that simple, and the port required some + modifications to get it to work. In this section, we will + explain, step by step, how to modify it to get it to work with the + ports paradigm. + + + How Things Work + + First, this is the sequence of events which occurs when the + user first types make in your port's + directory. You may find that having + bsd.port.mk in another window while you + read this really helps to understand it. + + But do not worry if you do not really understand what + bsd.port.mk is doing, not many people do... + :-) + + + + The fetch target is run. The + fetch target is responsible for + making sure that the tarball exists locally in + DISTDIR. If + fetch cannot find the required + files in DISTDIR it will look up the URL + MASTER_SITES, which is set in the + Makefile, as well as our FTP mirrors where we put distfiles + as backup. It will then attempt to fetch the named + distribution file with FETCH, assuming + that the requesting site has direct access to the Internet. + If that succeeds, it will save the file in + DISTDIR for future use and + proceed. + + + + The extract target is run. + It looks for your port's distribution file (typically a + gzipped tarball) in + DISTDIR and unpacks it into a temporary + subdirectory specified by WRKDIR + (defaults to work). + + + + The patch target is run. + First, any patches defined in PATCHFILES + are applied. Second, if any patch files named + patch-* are found in + PATCHDIR (defaults to the + files subdirectory), they are applied + at this time in alphabetical order. + + + + The configure target is run. + This can do any one of many different things. + + + + If it exists, scripts/configure + is run. + + + + If HAS_CONFIGURE or + GNU_CONFIGURE is set, + WRKSRC/configure is run. + + + + + + The build target is run. + This is responsible for descending into the port's private + working directory (WRKSRC) and building + it. + + + + The stage target is run. + This puts the final set of built files into a temporary + directory (STAGEDIR, see + ). The hierarchy of this directory + mirrors that of the system on which the package will be + installed. + + + + The install target is run. + This copies the files listed in the port's pkg-plist to the + host system. + + + + The above are the default actions. In addition, you can + define targets + pre-something + or + post-something, + or put scripts with those names, in the + scripts subdirectory, and they will be + run before or after the default actions are done. + + For example, if you have a + post-extract target defined in your + Makefile, and a file + pre-build in the + scripts subdirectory, the + post-extract target will be called + after the regular extraction actions, and the + pre-build script will be executed before + the default build rules are done. It is recommended that you + use Makefile targets if the actions are + simple enough, because it will be easier for someone to figure + out what kind of non-default action the port requires. + + The default actions are done by the + bsd.port.mk targets + do-something. + For example, the commands to extract a port are in the target + do-extract. If you are not happy + with the default target, you can fix it by redefining the + do-something + target in your Makefile. + + + The main targets (e.g., + extract, + configure, etc.) do nothing more + than make sure all the stages up to that one are completed and + call the real targets or scripts, and they are not intended to + be changed. If you want to fix the extraction, fix + do-extract, but never ever change + the way extract operates! + Additionally, the target + post-deinstall is invalid and is + not run by the ports infrastructure. + + + Now that you understand what goes on when the user types + make install, let us go through the + recommended steps to create the perfect port. + + + + Getting the Original Sources + + Get the original sources (normally) as a compressed tarball + (foo.tar.gz or + foo.tar.bz2) and copy it into + DISTDIR. Always use + mainstream sources when and where you + can. + + You will need to set the variable + MASTER_SITES to reflect where the original + tarball resides. You will find convenient shorthand definitions + for most mainstream sites in bsd.sites.mk. + Please use these sites—and the associated + definitions—if at all possible, to help avoid the problem + of having the same information repeated over again many times in + the source base. As these sites tend to change over time, this + becomes a maintenance nightmare for everyone involved. + + If you cannot find a FTP/HTTP site that is well-connected to + the net, or can only find sites that have irritatingly + non-standard formats, you might want to put a copy on a reliable + FTP or HTTP server that you control (e.g., your home + page). + + If you cannot find somewhere convenient and reliable to put + the distfile we can house it ourselves on + ftp.FreeBSD.org; however, this is the + least-preferred solution. The distfile must be placed into + ~/public_distfiles/ of someone's + freefall account. Ask the person who + commits your port to do this. This person will also set + MASTER_SITES to + MASTER_SITE_LOCAL and + MASTER_SITE_SUBDIR to their + freefall username. + + If your port's distfile changes all the time without any + kind of version update by the author, consider putting the + distfile on your home page and listing it as the first + MASTER_SITES. If you can, try to talk the + port author out of doing this; it really does help to establish + some kind of source code control. Hosting your own version will + prevent users from getting + checksum mismatch errors, and also reduce + the workload of maintainers of our FTP site. Also, if there is + only one master site for the port, it is recommended that you + house a backup at your site and list it as the second + MASTER_SITES. + + If your port requires some additional `patches' that are + available on the Internet, fetch them too and put them in + DISTDIR. Do not worry if they come from a + site other than where you got the main source tarball, we have a + way to handle these situations (see the description of PATCHFILES below). + + + + Modifying the Port + + Unpack a copy of the tarball in a private directory and make + whatever changes are necessary to get the port to compile + properly under the current version of &os;. Keep + careful track of everything you do, as you + will be automating the process shortly. Everything, including + the deletion, addition, or modification of files should be + doable using an automated script or patch file when your port is + finished. + + If your port requires significant user + interaction/customization to compile or install, you should take + a look at one of Larry Wall's classic + Configure scripts and perhaps do + something similar yourself. The goal of the new ports + collection is to make each port as plug-and-play + as possible for the end-user while using a minimum of disk + space. + + + Unless explicitly stated, patch files, scripts, and other + files you have created and contributed to the &os; ports + collection are assumed to be covered by the standard BSD + copyright conditions. + + + + + Patching + + In the preparation of the port, files that have been added + or changed can be recorded with &man.diff.1; for later feeding + to &man.patch.1;. Doing this with a typical file involves + saving a copy of the original file before making any + changes. + + &prompt.user; cp file file.orig + + Patches are saved into files named + patch-* where * + indicates the pathname of the file that is patched, such as + patch-Imakefile or + patch-src-config.h. + + After the file has been modified, &man.diff.1; is used to + record the differences between the original and the modified + version. causes &man.diff.1; to produce + unified diffs, the preferred form. + + &prompt.user; diff -u file.orig file > patch-pathname-file + + When generating patches for new, added files, + is added to tell &man.diff.1; to treat the + non-existent original file as if it existed but was + empty: + + &prompt.user; diff -u -N newfile.orig newfile > patch-pathname-newfile + + Patch files are stored in PATCHDIR + (usually files/, from + where they will be automatically applied. All patches must be + relative to WRKSRC (generally the directory + the port's tarball unpacks itself into, that being where the + build is done). To make fixes and upgrades easier, avoid having + more than one patch fix the same file (that is, + patch-file and + patch-file2 both changing + WRKSRC/foobar.c). Note that if the path of + a patched file contains an underscore (_) + character, the patch needs to have two underscores instead in + its name. For example, to patch a file named + src/freeglut_joystick.c, the corresponding + patch should be named + patch-src-freeglut__joystick.c. + + Please only use characters + [-+._a-zA-Z0-9] for naming patches. Do not + use any other characters besides them. Do not name patches like + patch-aa or patch-ab, + always mention the path and file name in patch names. + + There is an alternate, easier method for creating patches to + existing files. The first steps are the same, make a copy of + the unmodified file with an .orig + extension, then make modifications. Then use + make makepatch to write updated patch files + to the files directory of the port. + + Do not put RCS strings in patches. + Subversion will mangle them when we + put the files into the ports tree, and when we check them out + again, they will come out different and the patch will fail. + RCS strings are surrounded by dollar + ($) signs, and typically start with + $Id or + $RCS. + + Using the recurse () option to + &man.diff.1; to generate patches is fine, but please look at the + resulting patches to make sure there is no unnecessary junk in + there. In particular, diffs between two backup files, + Makefiles when the port uses + Imake or GNU configure, + etc., are unnecessary and should be deleted. If it was + necessary to edit configure.in and run + autoconf to regenerate + configure, do not take the diffs of + configure (it often grows to a few thousand + lines!). Instead, define + USE_AUTOTOOLS=autoconf:261 and take the diffs + of configure.in. + + Try to minimize the amount of non-functional whitespace + changes in patches. It is common in the Open Source world for + projects to share large amounts of a code base, but obey + different style and indenting rules. When taking a working + piece of functionality from one project to fix similar areas in + another, please be careful: the resulting line patch may be full + of non-functional changes. It not only increases the size of + the Subversion repository but makes + it hard to find out what exactly caused the problem and what was + changed at all. + + If a file must be deleted, do it in the + post-extract target rather than as + part of the patch. + + Simple replacements can be performed directly from the port + Makefile using the in-place mode of + &man.sed.1;. This is useful when changes use the value of a + variable: + + post-patch: + @${REINPLACE_CMD} -e 's|for Linux|for FreeBSD|g' ${WRKSRC}/README + + Quite often, software being ported uses the CR/LF convention + in source files. This may cause problems with further patching, + compiler warnings, or script execution (like + /bin/sh^M not found.) To quickly convert all + files from CR/LF to just LF, add this entry to the port + Makefile: - Slow Porting + USES= dos2unix - Okay, so it was not that simple, and the port required some - modifications to get it to work. In this section, we will - explain, step by step, how to modify it to get it to work with - the ports paradigm. - - - How Things Work - - First, this is the sequence of events which occurs when - the user first types make in your port's - directory. You may find that having - bsd.port.mk in another window while you - read this really helps to understand it. - - But do not worry if you do not really understand what - bsd.port.mk is doing, not many people - do... :-) - - - - The fetch target is run. - The fetch target is responsible - for making sure that the tarball exists locally in - DISTDIR. If - fetch cannot find the required - files in DISTDIR it will look up the - URL MASTER_SITES, which is set in the - Makefile, as well as our FTP mirrors where we put - distfiles as backup. It will then attempt to fetch the - named distribution file with FETCH, - assuming that the requesting site has direct access to the - Internet. If that succeeds, it will save the file in - DISTDIR for future use and - proceed. - - - - The extract target is run. - It looks for your port's distribution file (typically a - gzipped tarball) in - DISTDIR and unpacks it into a temporary - subdirectory specified by WRKDIR - (defaults to work). - - - - The patch target is run. - First, any patches defined in - PATCHFILES are applied. Second, if any - patch files named - patch-* - are found in PATCHDIR (defaults to the - files subdirectory), they are applied - at this time in alphabetical order. - - - - The configure target is - run. This can do any one of many different things. - - - - If it exists, - scripts/configure is run. - - - - If HAS_CONFIGURE or - GNU_CONFIGURE is set, - WRKSRC/configure - is run. - - - - - - - The build target is run. - This is responsible for descending into the port's private - working directory (WRKSRC) and building - it. - - - - The stage target is run. - This puts the final set of built files into a temporary - directory (STAGEDIR, see - ). The hierarchy of this - directory mirrors that of the system on which the package - will be installed. - - - - The install target is run. - This copies the files listed in the port's pkg-plist to - the host system. - - - - The above are the default actions. In addition, you can - define targets - pre-something - or - post-something, - or put scripts with those names, in the - scripts subdirectory, and they will be - run before or after the default actions are done. - - For example, if you have a - post-extract target defined in your - Makefile, and a file - pre-build in the - scripts subdirectory, the - post-extract target will be called - after the regular extraction actions, and the - pre-build script will be executed before - the default build rules are done. It is recommended that you - use Makefile targets if the actions are - simple enough, because it will be easier for someone to figure - out what kind of non-default action the port requires. - - The default actions are done by the - bsd.port.mk targets - do-something. - For example, the commands to extract a port are in the target - do-extract. If you are not happy - with the default target, you can fix it by redefining the - do-something - target in your Makefile. - - - The main targets (e.g., - extract, - configure, etc.) do nothing more - than make sure all the stages up to that one are completed - and call the real targets or scripts, and they are not - intended to be changed. If you want to fix the extraction, - fix do-extract, but never ever - change the way extract - operates! Additionally, the target - post-deinstall is invalid and - is not run by the ports infrastructure. - - - Now that you understand what goes on when the user types - make install, let - us go through the recommended steps to create the perfect - port. - - - - Getting the Original Sources - - Get the original sources (normally) as a compressed - tarball - (foo.tar.gz or - foo.tar.bz2) - and copy it into DISTDIR. Always use - mainstream sources when and where you - can. - - You will need to set the variable - MASTER_SITES to reflect where the original - tarball resides. You will find convenient shorthand - definitions for most mainstream sites in - bsd.sites.mk. Please use these - sites—and the associated definitions—if at all - possible, to help avoid the problem of having the same - information repeated over again many times in the source base. - As these sites tend to change over time, this becomes a - maintenance nightmare for everyone involved. - - If you cannot find a FTP/HTTP site that is well-connected - to the net, or can only find sites that have irritatingly - non-standard formats, you might want to put a copy on a - reliable FTP or HTTP server that you control (e.g., your home - page). - - If you cannot find somewhere convenient and reliable to - put the distfile we can house it ourselves on - ftp.FreeBSD.org; however, this is the - least-preferred solution. The distfile must be placed into - ~/public_distfiles/ of someone's - freefall account. Ask the person who - commits your port to do this. This person will also set - MASTER_SITES to - MASTER_SITE_LOCAL and - MASTER_SITE_SUBDIR to their - freefall username. - - If your port's distfile changes all the time without any - kind of version update by the author, consider putting the - distfile on your home page and listing it as the first - MASTER_SITES. If you can, try to talk the - port author out of doing this; it really does help to - establish some kind of source code control. Hosting your own - version will prevent users from getting - checksum mismatch errors, and also - reduce the workload of maintainers of our FTP site. Also, if - there is only one master site for the port, it is recommended - that you house a backup at your site and list it as the second - MASTER_SITES. - - If your port requires some additional `patches' that are - available on the Internet, fetch them too and put them in - DISTDIR. Do not worry if they come from a - site other than where you got the main source tarball, we have - a way to handle these situations (see the description of - PATCHFILES - below). - - - - Modifying the Port - - Unpack a copy of the tarball in a private directory and - make whatever changes are necessary to get the port to compile - properly under the current version of &os;. Keep - careful track of everything you do, as - you will be automating the process shortly. Everything, - including the deletion, addition, or modification of files - should be doable using an automated script or patch file when - your port is finished. - - If your port requires significant user - interaction/customization to compile or install, you should - take a look at one of Larry Wall's classic - Configure scripts and perhaps do - something similar yourself. The goal of the new ports - collection is to make each port as - plug-and-play as possible for the end-user - while using a minimum of disk space. - - - Unless explicitly stated, patch files, scripts, and - other files you have created and contributed to the &os; - ports collection are assumed to be covered by the standard - BSD copyright conditions. - - - - - Patching - - In the preparation of the port, files that have been added - or changed can be recorded with &man.diff.1; for later - feeding to &man.patch.1;. Doing this with a typical file - involves saving a copy of the original file before making any - changes. - - &prompt.user; cp file file.orig - - Patches are saved into files named - patch-* where - * indicates the pathname of the - file that is patched, such as - patch-Imakefile or - patch-src-config.h. - - After the file has been modified, &man.diff.1; is used to - record the differences between the original and the modified - version. causes &man.diff.1; to produce - unified diffs, the preferred form. - - &prompt.user; diff -u file.orig file > patch-pathname-file - - When generating patches for new, added files, - is added to tell &man.diff.1; to treat the - non-existent original file as if it existed but was - empty: - - &prompt.user; diff -u -N newfile.orig newfile > patch-pathname-newfile - - Patch files are stored in PATCHDIR - (usually files/, from - where they will be automatically applied. All patches must be - relative to WRKSRC (generally the directory - the port's tarball unpacks itself into, that being where the - build is done). To make fixes and upgrades easier, avoid - having more than one patch fix the same file (that is, - patch-file and - patch-file2 both changing - WRKSRC/foobar.c). Note that if the path - of a patched file contains an underscore - (_) character, the patch needs to have two - underscores instead in its name. For example, to patch a file - named src/freeglut_joystick.c, the - corresponding patch should be named - patch-src-freeglut__joystick.c. - - Please only use characters - [-+._a-zA-Z0-9] for naming patches. Do not - use any other characters besides them. Do not name patches - like patch-aa or - patch-ab, always mention the path and - file name in patch names. - - There is an alternate, easier method for creating patches - to existing files. The first steps are the same, make a copy - of the unmodified file with an .orig - extension, then make modifications. Then use - make makepatch to write updated patch files - to the files directory of the - port. - - Do not put RCS strings in patches. - Subversion will mangle them when we - put the files into the ports tree, and when we check them out - again, they will come out different and the patch will fail. - RCS strings are surrounded by dollar - ($) signs, and typically start with - $Id or - $RCS. - - Using the recurse () option to - &man.diff.1; to generate patches is fine, but please - look at the resulting patches to make sure there is no - unnecessary junk in there. In particular, diffs between two - backup files, Makefiles when the port - uses Imake or GNU - configure, etc., are unnecessary and should - be deleted. If it was necessary to edit - configure.in and run - autoconf to regenerate - configure, do not take the diffs of - configure (it often grows to a few thousand - lines!). Instead, define - USE_AUTOTOOLS=autoconf:261 and take the - diffs of configure.in. - - Try to minimize the amount of non-functional whitespace - changes in patches. It is common in the Open Source world for - projects to share large amounts of a code base, but obey - different style and indenting rules. When taking a working - piece of functionality from one project to fix similar areas - in another, please be careful: the resulting line patch may be - full of non-functional changes. It not only increases the - size of the Subversion repository - but makes it hard to find out what exactly caused the problem - and what was changed at all. - - If a file must be deleted, do it in the - post-extract target rather than as - part of the patch. - - Simple replacements can be performed directly from the - port Makefile using the in-place mode of - &man.sed.1;. This is useful when changes use the value of a - variable: - - post-patch: - @${REINPLACE_CMD} -e 's|for Linux|for FreeBSD|g' ${WRKSRC}/README - - Quite often, software being ported uses the CR/LF - convention in source files. This may cause problems with - further patching, compiler warnings, or script execution (like - /bin/sh^M not found.) To quickly convert - all files from CR/LF to just LF, add this entry to the port - Makefile: + A list of specific files to convert can be given: - USES= dos2unix - - A list of specific files to convert can - be given: - - USES= dos2unix + USES= dos2unix DOS2UNIX_FILES= util.c util.h - Use DOS2UNIX_REGEX to convert a group - of files across subdirectories. Its argument is a - &man.find.1;-compatible regular expression. More on the - format is in &man.re.format.7;. This option is useful for - converting all files of a given extension. For example, - convert all source code files, leaving binary files - intact: + Use DOS2UNIX_REGEX to convert a group of + files across subdirectories. Its argument is a + &man.find.1;-compatible regular expression. More on the format + is in &man.re.format.7;. This option is useful for converting + all files of a given extension. For example, convert all source + code files, leaving binary files intact: - USES= dos2unix + USES= dos2unix DOS2UNIX_REGEX= .*\.([ch]|cpp) - A similar option is DOS2UNIX_GLOB, - which invokes find for each element listed - in it. + A similar option is DOS2UNIX_GLOB, which + invokes find for each element listed in + it. - USES= dos2unix + USES= dos2unix DOS2UNIX_GLOB= *.c *.cpp *.h - - - - Configuring + - Include any additional customization commands in your - configure script and save it in the - scripts subdirectory. As mentioned - above, you can also do this with Makefile - targets and/or scripts with the name - pre-configure or - post-configure. - - - - Handling User Input - - If your port requires user input to build, configure, or - install, you must set IS_INTERACTIVE in - your Makefile. This will allow - overnight builds to skip your port if the user - sets the variable BATCH in his environment (and - if the user sets the variable INTERACTIVE, then - only those ports requiring interaction - are built). This will save a lot of wasted time on the set of - machines that continually build ports (see below). - - It is also recommended that if there are reasonable - default answers to the questions, you check the - PACKAGE_BUILDING variable and turn off the - interactive script when it is set. This will allow us to - build the packages for CDROMs and FTP. - - + + Configuring + Include any additional customization commands in your + configure script and save it in the + scripts subdirectory. As mentioned above, + you can also do this with Makefile targets + and/or scripts with the name pre-configure + or post-configure. + + + + Handling User Input + + If your port requires user input to build, configure, or + install, you must set IS_INTERACTIVE in your + Makefile. This will allow + overnight builds to skip your port if the user + sets the variable BATCH in his environment (and + if the user sets the variable INTERACTIVE, then + only those ports requiring interaction are + built). This will save a lot of wasted time on the set of + machines that continually build ports (see below). + + It is also recommended that if there are reasonable default + answers to the questions, you check the + PACKAGE_BUILDING variable and turn off the + interactive script when it is set. This will allow us to build + the packages for CDROMs and FTP. + + From owner-svn-doc-head@FreeBSD.ORG Sun Feb 16 03:09:36 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E927B749; Sun, 16 Feb 2014 03:09:35 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C4EBC15CD; Sun, 16 Feb 2014 03:09:35 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1G39Z3C067187; Sun, 16 Feb 2014 03:09:35 GMT (envelope-from wblock@svn.freebsd.org) Received: (from wblock@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1G39ZTv067184; Sun, 16 Feb 2014 03:09:35 GMT (envelope-from wblock@svn.freebsd.org) Message-Id: <201402160309.s1G39ZTv067184@svn.freebsd.org> From: Warren Block Date: Sun, 16 Feb 2014 03:09:35 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43955 - head/en_US.ISO8859-1/books/porters-handbook/special X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 03:09:36 -0000 Author: wblock Date: Sun Feb 16 03:09:35 2014 New Revision: 43955 URL: http://svnweb.freebsd.org/changeset/doc/43955 Log: Update and expand description of various make(1) implementations. Revised version of patch supplied. Submitted by: Alexey Dokuchaev Modified: head/en_US.ISO8859-1/books/porters-handbook/special/chapter.xml Modified: head/en_US.ISO8859-1/books/porters-handbook/special/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/porters-handbook/special/chapter.xml Sun Feb 16 02:39:13 2014 (r43954) +++ head/en_US.ISO8859-1/books/porters-handbook/special/chapter.xml Sun Feb 16 03:09:35 2014 (r43955) @@ -313,39 +313,34 @@ IGNORE= may not be redistributed because - <command>make</command>, <command>gmake</command>, and - <command>imake</command> + <command>make</command>, <command>gmake</command>, + <command>fmake</command>, and <command>imake</command> - If your port uses GNU make, - set USES= gmake. - - - Variables for Ports Related to - <application>gmake</application> - - - - - Variable - Means - - - - - - USES= gmake - The port requires gmake to - build. - - - - GMAKE - The full path for gmake if - it is not in the PATH. - - - -
+ Several differing make + implementations exist. Ported software often requires a + particular implementation, like GNU + make, known in &os; as + gmake, or fmake, the + legacy &os; make. + + If the port uses GNU make, + add gmake to USES. If + the legacy &os; make is needed, add + fmake there. + + MAKE_CMD can be used to reference the + specific command configured by the USES + setting in the port's Makefile. In + rare cases when more than one make + implementation is listed in USES, the + variables GMAKE (for the + GNU version) or FMAKE + (for the legacy &os; version) are available. Most ports + should only use MAKE_CMD within the + application Makefiles in + WRKSRC to call the + make implementation expected by the + ported software. If your port is an X application that creates Makefile files from From owner-svn-doc-head@FreeBSD.ORG Sun Feb 16 03:25:23 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A39BA6C; Sun, 16 Feb 2014 03:25:23 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 125F6171B; Sun, 16 Feb 2014 03:25:23 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1G3PNVl075668; Sun, 16 Feb 2014 03:25:23 GMT (envelope-from wblock@svn.freebsd.org) Received: (from wblock@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1G3PM7E075667; Sun, 16 Feb 2014 03:25:22 GMT (envelope-from wblock@svn.freebsd.org) Message-Id: <201402160325.s1G3PM7E075667@svn.freebsd.org> From: Warren Block Date: Sun, 16 Feb 2014 03:25:22 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43956 - head/en_US.ISO8859-1/books/porters-handbook/special X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 03:25:23 -0000 Author: wblock Date: Sun Feb 16 03:25:22 2014 New Revision: 43956 URL: http://svnweb.freebsd.org/changeset/doc/43956 Log: Whitespace-only fixes, translators please ignore. Modified: head/en_US.ISO8859-1/books/porters-handbook/special/chapter.xml Modified: head/en_US.ISO8859-1/books/porters-handbook/special/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/porters-handbook/special/chapter.xml Sun Feb 16 03:09:35 2014 (r43955) +++ head/en_US.ISO8859-1/books/porters-handbook/special/chapter.xml Sun Feb 16 03:25:22 2014 (r43956) @@ -4,3542 +4,3540 @@ $FreeBSD$ --> - + + + Special Considerations + + There are some more things you have to take into account + when you create a port. This section explains the most common + of those. + + + Staging + + bsd.port.mk expects ports to work + with a stage directory. This means that a port + should not install files directly to the regular destination + directories (that is, under PREFIX, for + example) but instead into a separate directory from which the + package is then built. In many cases, this does not require + root privileges, making it possible to build packages as an + unprivileged user. With staging, the port is built and + installed into the stage directory, + STAGEDIR. A package is created from the + stage directory and then installed on the system. Automake + tools refer to this concept as DESTDIR, but + in &os;, DESTDIR has a different meaning + (see ). + + When a port still requires system-wide privileges in order + to run the package target, this + line must be added to the + Makefile: + + NEED_ROOT= yes + + Meta ports, or ports that do not install files themselves + but only depend on other ports, should avoid needlessly + extracting the &man.mtree.8; to the stage directory. This is + the basic directory layout of the package, and these empty + directories will be seens as orphans. To prevent + &man.mtree.8; extraction, add this line: + + NO_MTREE= yes + + Staging is enabled by prepending the + STAGEDIR variable to paths used in the + pre-install, + do-install, and + post-install targets (see the + examples through the book). Typically, this includes + PREFIX, ETCDIR, + DATADIR, EXAMPLESDIR, + MANPREFIX, DOCSDIR, and + so on. Directories should be created as part of the + post-install target. Avoid using + absolute paths whenever possible. + + When creating a symlink, STAGEDIR + should be prepended to the target path only. For + example: + + ${LN} -sf libfoo.so.42 ${STAGEDIR}${PREFIX}/lib/libfoo.so + + The source path + ${PREFIX}/lib/libfoo.so.42 looks fine but + could, in fact, be incorrect. Absolute paths can point to a + wrong location, like when a remote file system has been + mounted with NFS under a non-root mount + point. Relative paths are less fragile, and often much + shorter. + + Ports that install kernel modules must prepend the + STAGEDIR variable to + their destination, by default + /boot/modules. + + + + Shared Libraries + + If your port installs one or more shared libraries, define + a USE_LDCONFIG make variable, which will + instruct a bsd.port.mk to run + ${LDCONFIG} -m on the directory + where the new library is installed (usually + PREFIX/lib) during + post-install target to register it + into the shared library cache. This variable, when defined, + will also facilitate addition of an appropriate + @exec /sbin/ldconfig -m and + @unexec /sbin/ldconfig -R pair into your + pkg-plist file, so that a user who + installed the package can start using the shared library + immediately and de-installation will not cause the system to + still believe the library is there. + + USE_LDCONFIG= yes + + If you need, you can override the default directory by + setting the USE_LDCONFIG value to a list of + directories into which shared libraries are to be installed. + For example if your port installs shared libraries into + PREFIX/lib/foo and + PREFIX/lib/bar + directories you could use the following in your + Makefile: + + USE_LDCONFIG= ${PREFIX}/lib/foo ${PREFIX}/lib/bar + + Please double-check, often this is not necessary at all or + can be avoided through -rpath or setting + LD_RUN_PATH during linking (see + lang/moscow_ml for an + example), or through a shell-wrapper which sets + LD_LIBRARY_PATH before invoking the binary, + like www/seamonkey + does. + + When installing 32-bit libraries on 64-bit system, use + USE_LDCONFIG32 instead. + + Try to keep shared library version numbers in the + libfoo.so.0 format. Our runtime linker + only cares for the major (first) number. + + When the major library version number increments in the + update to the new port version, all other ports that link to + the affected library should have their + PORTREVISION incremented, to force + recompilation with the new library version. + + + + Ports with Distribution Restrictions or Legal + Concerns + + Licenses vary, and some of them place restrictions on how + the application can be packaged, whether it can be sold for + profit, and so on. + + + It is your responsibility as a porter to read the + licensing terms of the software and make sure that the + &os; project will not be held accountable for violating + them by redistributing the source or compiled binaries + either via FTP/HTTP or CD-ROM. If in doubt, please contact + the &a.ports;. + + + In situations like this, the variables described in the + following sections can be set. + + + <varname>NO_PACKAGE</varname> + + This variable indicates that we may not generate a + binary package of the application. For instance, the + license may disallow binary redistribution, or it may + prohibit distribution of packages created from patched + sources. + + However, the port's DISTFILES may be + freely mirrored on FTP/HTTP. They may also be distributed + on a CD-ROM (or similar media) unless + NO_CDROM is set as well. + + NO_PACKAGE should also be used if the + binary package is not generally useful, and the application + should always be compiled from the source code. For + example, if the application has configuration information + that is site specific hard coded in to it at compile time, + set NO_PACKAGE. + + NO_PACKAGE should be set to a string + describing the reason why the package should not be + generated. + + + + <varname>NO_CDROM</varname> + + This variable alone indicates that, although we are + allowed to generate binary packages, we may put neither + those packages nor the port's DISTFILES + onto a CD-ROM (or similar media) for resale. However, the + binary packages and the port's DISTFILES + will still be available via FTP/HTTP. + + If this variable is set along with + NO_PACKAGE, then only the port's + DISTFILES will be available, and only via + FTP/HTTP. + + NO_CDROM should be set to a string + describing the reason why the port cannot be redistributed + on CD-ROM. For instance, this should be used if the port's + license is for non-commercial use + only. + + + + <varname>NOFETCHFILES</varname> + + Files defined in the NOFETCHFILES + variable are not fetchable from any of the + MASTER_SITES. An example of such a file + is when the file is supplied on CD-ROM by the vendor. + + Tools which check for the availability of these files + on the MASTER_SITES should ignore these + files and not report about them. + + + + <varname>RESTRICTED</varname> + + Set this variable alone if the application's license + permits neither mirroring the application's + DISTFILES nor distributing the binary + package in any way. + + NO_CDROM or + NO_PACKAGE should not be set along with + RESTRICTED since the latter variable + implies the former ones. + + RESTRICTED should be set to a string + describing the reason why the port cannot be redistributed. + Typically, this indicates that the port contains proprietary + software and that the user will need to manually download + the DISTFILES, possibly after registering + for the software or agreeing to accept the terms of an + EULA. + + + + <varname>RESTRICTED_FILES</varname> + + When RESTRICTED or + NO_CDROM is set, this variable defaults + to ${DISTFILES} ${PATCHFILES}, otherwise + it is empty. If only some of the distribution files are + restricted, then set this variable to list them. + + + + + <varname>LEGAL_TEXT</varname> + + If the port has legal concerns not addressed by the + above variables, the variable LEGAL_TEXT + should be set to a string explaining the concern. For + example, if special permission was obtained for &os; to + redistribute the binary, this variable should indicate + so. + + + + <filename>/usr/ports/LEGAL</filename> and + <varname>LEGAL</varname> + + A port which sets any of the above variables must also + be added to /usr/ports/LEGAL. The + first column is a glob which matches the restricted + distfiles. The second column is the port's origin. The + third column is the output of + make -VLEGAL. + - Special Considerations + + Examples - There are some more things you have to take into account - when you create a port. This section explains the most common - of those. - - - Staging - - bsd.port.mk expects ports to work - with a stage directory. This means that a port - should not install files directly to the regular destination - directories (that is, under PREFIX, for - example) but instead into a separate directory from which the - package is then built. In many cases, this does not require - root privileges, making it possible to build packages as an - unprivileged user. With staging, the port is built and - installed into the stage directory, - STAGEDIR. A package is created from the - stage directory and then installed on the system. Automake - tools refer to this concept as DESTDIR, but - in &os;, DESTDIR has a different meaning - (see ). - - When a port still requires system-wide privileges in order - to run the package target, this - line must be added to the - Makefile: - - NEED_ROOT= yes - - Meta ports, or ports that do not install files themselves - but only depend on other ports, should avoid needlessly - extracting the &man.mtree.8; to the stage directory. This is - the basic directory layout of the package, and these empty - directories will be seens as orphans. To prevent - &man.mtree.8; extraction, add this line: - - NO_MTREE= yes - - Staging is enabled by prepending the - STAGEDIR variable to paths used in the - pre-install, - do-install, and - post-install targets (see the - examples through the book). Typically, this includes - PREFIX, ETCDIR, - DATADIR, EXAMPLESDIR, - MANPREFIX, DOCSDIR, and - so on. Directories should be created as part of the - post-install target. Avoid using - absolute paths whenever possible. + The preferred way to state "the distfiles for this port + must be fetched manually" is as follows: - When creating a symlink, STAGEDIR - should be prepended to the target path only. For - example: - - ${LN} -sf libfoo.so.42 ${STAGEDIR}${PREFIX}/lib/libfoo.so - - The source path - ${PREFIX}/lib/libfoo.so.42 looks fine but - could, in fact, be incorrect. Absolute paths can point to a - wrong location, like when a remote file system has been - mounted with NFS under a non-root mount - point. Relative paths are less fragile, and often much - shorter. - - Ports that install kernel modules must prepend the - STAGEDIR variable to - their destination, by default - /boot/modules. - - - - Shared Libraries - - If your port installs one or more shared libraries, define - a USE_LDCONFIG make variable, which will - instruct a bsd.port.mk to run - ${LDCONFIG} -m on the directory - where the new library is installed (usually - PREFIX/lib) during - post-install target to register it - into the shared library cache. This variable, when defined, - will also facilitate addition of an appropriate - @exec /sbin/ldconfig -m and - @unexec /sbin/ldconfig -R pair into your - pkg-plist file, so that a user who - installed the package can start using the shared library - immediately and de-installation will not cause the system to - still believe the library is there. - - USE_LDCONFIG= yes - - If you need, you can override the default directory by - setting the USE_LDCONFIG value to a list of - directories into which shared libraries are to be installed. - For example if your port installs shared libraries into - PREFIX/lib/foo and - PREFIX/lib/bar - directories you could use the following in your - Makefile: - - USE_LDCONFIG= ${PREFIX}/lib/foo ${PREFIX}/lib/bar - - Please double-check, often this is not necessary at all or - can be avoided through -rpath or setting - LD_RUN_PATH during linking (see - lang/moscow_ml for an - example), or through a shell-wrapper which sets - LD_LIBRARY_PATH before invoking the binary, - like www/seamonkey - does. - - When installing 32-bit libraries on 64-bit system, use - USE_LDCONFIG32 instead. - - Try to keep shared library version numbers in the - libfoo.so.0 format. Our runtime linker - only cares for the major (first) number. - - When the major library version number increments in the - update to the new port version, all other ports that link to - the affected library should have their - PORTREVISION incremented, to force - recompilation with the new library version. - - - - Ports with Distribution Restrictions or Legal - Concerns - - Licenses vary, and some of them place restrictions on how - the application can be packaged, whether it can be sold for - profit, and so on. - - - It is your responsibility as a porter to read the - licensing terms of the software and make sure that the - &os; project will not be held accountable for violating - them by redistributing the source or compiled binaries - either via FTP/HTTP or CD-ROM. If in doubt, please contact - the &a.ports;. - - - In situations like this, the variables described in the - following sections can be set. - - - <varname>NO_PACKAGE</varname> - - This variable indicates that we may not generate a - binary package of the application. For instance, the - license may disallow binary redistribution, or it may - prohibit distribution of packages created from patched - sources. - - However, the port's DISTFILES may be - freely mirrored on FTP/HTTP. They may also be distributed - on a CD-ROM (or similar media) unless - NO_CDROM is set as well. - - NO_PACKAGE should also be used if the - binary package is not generally useful, and the application - should always be compiled from the source code. For - example, if the application has configuration information - that is site specific hard coded in to it at compile time, - set NO_PACKAGE. - - NO_PACKAGE should be set to a string - describing the reason why the package should not be - generated. - - - - <varname>NO_CDROM</varname> - - This variable alone indicates that, although we are - allowed to generate binary packages, we may put neither - those packages nor the port's DISTFILES - onto a CD-ROM (or similar media) for resale. However, the - binary packages and the port's DISTFILES - will still be available via FTP/HTTP. - - If this variable is set along with - NO_PACKAGE, then only the port's - DISTFILES will be available, and only via - FTP/HTTP. - - NO_CDROM should be set to a string - describing the reason why the port cannot be redistributed - on CD-ROM. For instance, this should be used if the port's - license is for non-commercial use - only. - - - - <varname>NOFETCHFILES</varname> - - Files defined in the NOFETCHFILES - variable are not fetchable from any of the - MASTER_SITES. An example of such a file - is when the file is supplied on CD-ROM by the vendor. - - Tools which check for the availability of these files - on the MASTER_SITES should ignore these - files and not report about them. - - - - <varname>RESTRICTED</varname> - - Set this variable alone if the application's license - permits neither mirroring the application's - DISTFILES nor distributing the binary - package in any way. - - NO_CDROM or - NO_PACKAGE should not be set along with - RESTRICTED since the latter variable - implies the former ones. - - RESTRICTED should be set to a string - describing the reason why the port cannot be redistributed. - Typically, this indicates that the port contains proprietary - software and that the user will need to manually download - the DISTFILES, possibly after registering - for the software or agreeing to accept the terms of an - EULA. - - - - <varname>RESTRICTED_FILES</varname> - - When RESTRICTED or - NO_CDROM is set, this variable defaults - to ${DISTFILES} ${PATCHFILES}, otherwise - it is empty. If only some of the distribution files are - restricted, then set this variable to list them. - - - - - <varname>LEGAL_TEXT</varname> - - If the port has legal concerns not addressed by the - above variables, the variable LEGAL_TEXT - should be set to a string explaining the concern. For - example, if special permission was obtained for &os; to - redistribute the binary, this variable should indicate - so. - - - - <filename>/usr/ports/LEGAL</filename> and - <varname>LEGAL</varname> - - A port which sets any of the above variables must also - be added to /usr/ports/LEGAL. The - first column is a glob which matches the restricted - distfiles. The second column is the port's origin. The - third column is the output of - make -VLEGAL. - - - - Examples - - The preferred way to state "the distfiles for this port - must be fetched manually" is as follows: - - .if !exists(${DISTDIR}/${DISTNAME}${EXTRACT_SUFX}) + .if !exists(${DISTDIR}/${DISTNAME}${EXTRACT_SUFX}) IGNORE= may not be redistributed because of licensing reasons. Please visit some-website to accept their license and download ${DISTFILES} into ${DISTDIR} .endif - This both informs the user, and sets the proper metadata - on the user's machine for use by automated programs. - - Note that this stanza must be preceded by an inclusion - of bsd.port.pre.mk. - - - - - Building Mechanisms - - - Building Ports in Parallel - - The &os; ports framework supports parallel building - using multiple make sub-processes, which - allows SMP systems to utilize all of - their available CPU power, allowing port - builds to be faster and more effective. - - This is achieved by passing -jX flag - to &man.make.1; running on vendor code. This is the default - build behavior of ports. Unfortunately, not all ports - handle parallel building well and it may be required to - explicitly disable this feature by adding the - MAKE_JOBS_UNSAFE=yes variable. It is - used when a port is known to be broken with - -jX. - - - - - <command>make</command>, <command>gmake</command>, - <command>fmake</command>, and <command>imake</command> - - Several differing make - implementations exist. Ported software often requires a - particular implementation, like GNU - make, known in &os; as - gmake, or fmake, the - legacy &os; make. - - If the port uses GNU make, - add gmake to USES. If - the legacy &os; make is needed, add - fmake there. - - MAKE_CMD can be used to reference the - specific command configured by the USES - setting in the port's Makefile. In - rare cases when more than one make - implementation is listed in USES, the - variables GMAKE (for the - GNU version) or FMAKE - (for the legacy &os; version) are available. Most ports - should only use MAKE_CMD within the - application Makefiles in - WRKSRC to call the - make implementation expected by the - ported software. - - If your port is an X application that creates - Makefile files from - Imakefile files using - imake, then set - USES= imake. This will cause the - configure stage to automatically do an - xmkmf -a. If the - flag is a problem for your port, set - XMKMF=xmkmf. If the port uses - imake but does not understand the - install.man target, - NO_INSTALL_MANPAGES=yes should be - set. - - If your port's source Makefile has - something else than all as the - main build target, set ALL_TARGET - accordingly. Same goes for - install and - INSTALL_TARGET. - - - - <command>configure</command> Script - - If your port uses the configure - script to generate Makefile files from - Makefile.in files, set - GNU_CONFIGURE=yes. If you want to give - extra arguments to the configure script - (the default argument is --prefix=${PREFIX} - --infodir=${PREFIX}/${INFO_PATH} - --mandir=${MANPREFIX}/man - --build=${CONFIGURE_TARGET}), set those - extra arguments in CONFIGURE_ARGS. Extra - environment variables can be passed using - CONFIGURE_ENV variable. - - - Variables for Ports That Use - <command>configure</command> - - - - - Variable - Means - - - - - - GNU_CONFIGURE - The port uses configure - script to prepare build. - - - - HAS_CONFIGURE - Same as GNU_CONFIGURE, - except default configure target is not added to - CONFIGURE_ARGS. - - - - CONFIGURE_ARGS - Additional arguments passed to - configure script. - - - - CONFIGURE_ENV - Additional environment variables to be set - for configure script run. - - - - CONFIGURE_TARGET - Override default configure target. Default - value is - ${MACHINE_ARCH}-portbld-freebsd${OSREL}. - - - -
- - - - Using <command>cmake</command> - - For ports that use CMake, - define USES= cmake, or - USES= cmake:outsource to build in a - separate directory (see below). - - - Variables for Ports That Use - <command>cmake</command> - - - - - Variable - Means - - - - - - CMAKE_ARGS - Port specific CMake - flags to be passed to the cmake - binary. - - - - CMAKE_BUILD_TYPE - Type of build (CMake - predefined build profiles). Default is - Release, or - Debug if - WITH_DEBUG is set. - - - - CMAKE_ENV - Environment variables to be set for the - cmake binary. Default is - ${CONFIGURE_ENV}. - - - - CMAKE_SOURCE_PATH - Path to the source directory. Default is - ${WRKSRC}. - - - -
- - - Variables the Users can define for - <command>cmake</command> builds - - - - - Variable - Means - - - - - - CMAKE_VERBOSE - Enable verbose build output. Default not set, - unless BATCH or - PACKAGE_BUILDING are set. - - - - CMAKE_NOCOLOR - Disables colour build output. Default not set, - unless BATCH or - PACKAGE_BUILDING are set. - - - -
- - CMake supports the following - build profiles: Debug, - Release, - RelWithDebInfo and - MinSizeRel. Debug and - Release profiles respect system - *FLAGS, RelWithDebInfo - and MinSizeRel will set - CFLAGS to -O2 -g and - -Os -DNDEBUG correspondingly. The - lower-cased value of CMAKE_BUILD_TYPE is - exported to the PLIST_SUB and should be - used if port installs *.cmake files - depending on the build type (see - deskutils/strigi for an - example). Please note that some projects may define their - own build profiles and/or force particular build type by - setting CMAKE_BUILD_TYPE in - CMakeLists.txt files. In order to - make a port for such a project respect - CFLAGS and WITH_DEBUG, - the CMAKE_BUILD_TYPE definitions must be - removed from those files. - - Most CMake-based projects - support an out-of-source method of building. The - out-of-source build for a port can be requested by using the - :outsource suffix. When enabled, - CONFIGURE_WRKSRC, - BUILD_WRKSRC and - INSTALL_WRKSRC will be set to - ${WRKDIR}/.build and this - directory will be used to keep all files generated during - configuration and build stages, leaving the source directory - intact. - - - <literal>USES= cmake</literal> Example - - The following snippet demonstrates the use of - CMake for a port. - CMAKE_SOURCE_PATH is not usually - required, but can be set when the sources are not located - in the top directory, or if only a subset of the project - is intended to be built by the port. - - USES= cmake:outsource -CMAKE_SOURCE_PATH= ${WRKSRC}/subproject - - - - - Using <command>scons</command> + This both informs the user, and sets the proper metadata + on the user's machine for use by automated programs. - If your port uses SCons, - define USE_SCONS=yes. + Note that this stanza must be preceded by an inclusion + of bsd.port.pre.mk. + + + + + Building Mechanisms + + + Building Ports in Parallel + + The &os; ports framework supports parallel building + using multiple make sub-processes, which + allows SMP systems to utilize all of + their available CPU power, allowing port + builds to be faster and more effective. + + This is achieved by passing -jX flag + to &man.make.1; running on vendor code. This is the default + build behavior of ports. Unfortunately, not all ports + handle parallel building well and it may be required to + explicitly disable this feature by adding the + MAKE_JOBS_UNSAFE=yes variable. It is + used when a port is known to be broken with + -jX. + + + + <command>make</command>, <command>gmake</command>, + <command>fmake</command>, and <command>imake</command> + + Several differing make + implementations exist. Ported software often requires a + particular implementation, like GNU + make, known in &os; as + gmake, or fmake, the + legacy &os; make. + + If the port uses GNU make, + add gmake to USES. If + the legacy &os; make is needed, add + fmake there. + + MAKE_CMD can be used to reference the + specific command configured by the USES + setting in the port's Makefile. In + rare cases when more than one make + implementation is listed in USES, the + variables GMAKE (for the + GNU version) or FMAKE + (for the legacy &os; version) are available. Most ports + should only use MAKE_CMD within the + application Makefiles in + WRKSRC to call the + make implementation expected by the + ported software. + + If your port is an X application that creates + Makefile files from + Imakefile files using + imake, then set + USES= imake. This will cause the + configure stage to automatically do an + xmkmf -a. If the + flag is a problem for your port, set + XMKMF=xmkmf. If the port uses + imake but does not understand the + install.man target, + NO_INSTALL_MANPAGES=yes should be + set. + + If your port's source Makefile has + something else than all as the + main build target, set ALL_TARGET + accordingly. Same goes for + install and + INSTALL_TARGET. + + + + <command>configure</command> Script + + If your port uses the configure + script to generate Makefile files from + Makefile.in files, set + GNU_CONFIGURE=yes. If you want to give + extra arguments to the configure script + (the default argument is --prefix=${PREFIX} + --infodir=${PREFIX}/${INFO_PATH} + --mandir=${MANPREFIX}/man + --build=${CONFIGURE_TARGET}), set those + extra arguments in CONFIGURE_ARGS. Extra + environment variables can be passed using + CONFIGURE_ENV variable. - - Variables for Ports That Use - <command>scons</command> - - - - - Variable - Means - - - - - - SCONS_ARGS - Port specific SCons flags passed to the SCons - environment. - - - - SCONS_BUILDENV - Variables to be set in system - environment. - - - - SCONS_ENV - Variables to be set in SCons - environment. - - - - SCONS_TARGET - Last argument passed to SCons, similar to - MAKE_TARGET. - - - -
- - To make third party SConstruct - respect everything that is passed to SCons in - SCONS_ENV (that is, most importantly, - CC/CXX/CFLAGS/CXXFLAGS), patch the - SConstruct so build - Environment is constructed like - this: - - env = Environment(**ARGUMENTS) - - It may be then modified with - env.Append and - env.Replace. - - - - - Using GNU Autotools - - *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** From owner-svn-doc-head@FreeBSD.ORG Sun Feb 16 03:32:26 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AA33CD10; Sun, 16 Feb 2014 03:32:26 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9428B17A9; Sun, 16 Feb 2014 03:32:26 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1G3WQ9G079423; Sun, 16 Feb 2014 03:32:26 GMT (envelope-from wblock@svn.freebsd.org) Received: (from wblock@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1G3WQ9I079422; Sun, 16 Feb 2014 03:32:26 GMT (envelope-from wblock@svn.freebsd.org) Message-Id: <201402160332.s1G3WQ9I079422@svn.freebsd.org> From: Warren Block Date: Sun, 16 Feb 2014 03:32:26 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43957 - head/en_US.ISO8859-1/books/porters-handbook/testing X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 03:32:26 -0000 Author: wblock Date: Sun Feb 16 03:32:26 2014 New Revision: 43957 URL: http://svnweb.freebsd.org/changeset/doc/43957 Log: Whitespace-only fixes, translators please ignore. Modified: head/en_US.ISO8859-1/books/porters-handbook/testing/chapter.xml Modified: head/en_US.ISO8859-1/books/porters-handbook/testing/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/porters-handbook/testing/chapter.xml Sun Feb 16 03:25:22 2014 (r43956) +++ head/en_US.ISO8859-1/books/porters-handbook/testing/chapter.xml Sun Feb 16 03:32:26 2014 (r43957) @@ -4,198 +4,192 @@ $FreeBSD$ --> - - - Testing the Port - - - Running <command>make describe</command> - - Several of the &os; port maintenance tools, such as - &man.portupgrade.1;, rely on a database called - /usr/ports/INDEX which keeps track of - such items as port dependencies. INDEX - is created by the top-level - ports/Makefile via - make index, which descends into each port - subdirectory and executes make describe - there. Thus, if make describe fails in any - port, no one can generate INDEX, and many - people will quickly become unhappy. - - - It is important to be able to generate this file no - matter what options are present in - make.conf, so please avoid doing things - such as using .error statements when (for - instance) a dependency is not satisfied. (See - .) - - - If make describe produces a string - rather than an error message, you are probably safe. See - bsd.port.mk for the meaning of the - string produced. - - Also note that running a recent version of - portlint (as specified in the next section) - will cause make describe to be run - automatically. - - - - Portlint - - Do check your work with portlint - before you submit or commit it. portlint - warns you about many common errors, both functional and - stylistic. For a new (or repocopied) port, - portlint -A is the most thorough; for an - existing port, portlint -C is - sufficient. - - Since portlint uses heuristics to - try to figure out errors, it can produce false positive - warnings. In addition, occasionally something that is - flagged as a problem really cannot be done in any other - way due to limitations in the ports framework. When in - doubt, the best thing to do is ask on &a.ports;. - - - - Port Tools - - The - ports-mgmt/porttools - program is part of the Ports Collection. - - port is the front-end script, which can - help you simplify the testing job. Whenever you want to test - a new port or update an existing one, you can use - port test to test your port, including the - portlint - checking. This command also detects and lists any files that - are not listed in pkg-plist. See the - following example: - - &prompt.root; port test /usr/ports/net/csup - - - - <varname>PREFIX</varname> and - <varname>DESTDIR</varname> - - PREFIX determines where the port will - be installed. It defaults to /usr/local, - but can be set by the user to a custom path like - /opt. Your port must respect the value - of this variable. - - DESTDIR, if set by the user, determines - the complete alternative environment, usually a jail or an - installed system mounted somewhere other than - /. A port will actually install into - DESTDIR/PREFIX, - and register with the package database in - DESTDIR/var/db/pkg. - As DESTDIR is handled automatically by the - ports infrastructure with &man.chroot.8;, you do not need any - modifications or any extra care to write - DESTDIR-compliant ports. - - The value of PREFIX will be set to - LOCALBASE (defaulting to - /usr/local). If - USE_LINUX_PREFIX is set, - PREFIX will be LINUXBASE - (defaulting to /compat/linux). - - Avoiding hard-coded /usr/local paths - in the source makes the port much more flexible and able to - cater to the needs of other sites. Often, this can be - accomplished by simply replacing occurrences of - /usr/local in the port's various - Makefiles with - ${PREFIX}. This variable is - automatically passed down to every stage of the build and - install processes. - - Make sure your application is not installing things in - /usr/local instead of - PREFIX. A quick test for such hard-coded - paths is: - - &prompt.root; make clean; make package PREFIX=/var/tmp/`make -V PORTNAME` - - If anything is installed outside of - PREFIX, the package creation process will - complain that it cannot find the files. - - In addition, it is worth checking the same with the - stage directory support (see - ): - - &prompt.root; make stage && make check-orphans && make package - - These tests will not find hard-coded paths inside the - port's files, nor will it verify that - LOCALBASE is being used to correctly refer - to files from other ports. The temporarily-installed port in - /var/tmp/`make -V PORTNAME` should be - tested for proper operation to make sure there - are no problems with paths. - - PREFIX should not be set explicitly - in a port's Makefile. Users installing - the port may have set PREFIX to a custom - location, and the port should respect that setting. - - Refer to programs and files from other ports with the - variables mentioned above, not explicit pathnames. For - instance, if your port requires a macro - PAGER to have the full pathname of - less, do not use a literal path of - /usr/local/bin/less. Instead, use - ${LOCALBASE}: - - -DPAGER=\"${LOCALBASE}/bin/less\" - - The path with LOCALBASE is more likely - to still work if the system administrator has moved the whole - /usr/local tree somewhere else. - - - - Tinderbox - - If you are an avid ports contributor, you might want to - take a look at Tinderbox. It is a - powerful system for building and testing ports. - You can - install Tinderbox using - ports-mgmt/tinderbox port. - Be sure to read supplied documentation since the configuration - is not trivial. - - Visit the - Tinderbox - website for more details. - - - - Poudriere - - As a ports contributor, consider installing - poudriere. It is a powerful - system for building and testing ports. - Poudriere can be installed with - ports-mgmt/poudriere. - - Visit the Poudriere - website for more details. - - - + + + Testing the Port + + + Running <command>make describe</command> + + Several of the &os; port maintenance tools, such as + &man.portupgrade.1;, rely on a database called + /usr/ports/INDEX which keeps track of such + items as port dependencies. INDEX is + created by the top-level ports/Makefile via + make index, which descends into each port + subdirectory and executes make describe + there. Thus, if make describe fails in any + port, no one can generate INDEX, and many + people will quickly become unhappy. + + + It is important to be able to generate this file no matter + what options are present in make.conf, so + please avoid doing things such as using + .error statements when (for instance) a + dependency is not satisfied. (See + .) + + + If make describe produces a string rather + than an error message, you are probably safe. See + bsd.port.mk for the meaning of the string + produced. + + Also note that running a recent version of + portlint (as specified in the next section) + will cause make describe to be run + automatically. + + + + Portlint + + Do check your work with portlint + before you submit or commit it. portlint + warns you about many common errors, both functional and + stylistic. For a new (or repocopied) port, + portlint -A is the most thorough; for an + existing port, portlint -C is + sufficient. + + Since portlint uses heuristics to try to + figure out errors, it can produce false positive warnings. In + addition, occasionally something that is flagged as a problem + really cannot be done in any other way due to limitations in the + ports framework. When in doubt, the best thing to do is ask on + &a.ports;. + + + + Port Tools + + The ports-mgmt/porttools + program is part of the Ports Collection. + + port is the front-end script, which can + help you simplify the testing job. Whenever you want to test a + new port or update an existing one, you can use + port test to test your port, including the + portlint + checking. This command also detects and lists any files that + are not listed in pkg-plist. See the + following example: + + &prompt.root; port test /usr/ports/net/csup + + + + <varname>PREFIX</varname> and + <varname>DESTDIR</varname> + + PREFIX determines where the port will be + installed. It defaults to /usr/local, but + can be set by the user to a custom path like + /opt. Your port must respect the value of + this variable. + + DESTDIR, if set by the user, determines + the complete alternative environment, usually a jail or an + installed system mounted somewhere other than + /. A port will actually install into + DESTDIR/PREFIX, and register with the + package database in DESTDIR/var/db/pkg. As + DESTDIR is handled automatically by the ports + infrastructure with &man.chroot.8;, you do not need any + modifications or any extra care to write + DESTDIR-compliant ports. + + The value of PREFIX will be set to + LOCALBASE (defaulting to + /usr/local). If + USE_LINUX_PREFIX is set, + PREFIX will be LINUXBASE + (defaulting to /compat/linux). + + Avoiding hard-coded /usr/local paths in + the source makes the port much more flexible and able to cater + to the needs of other sites. Often, this can be accomplished by + simply replacing occurrences of /usr/local + in the port's various Makefiles with + ${PREFIX}. This variable is + automatically passed down to every stage of the build and + install processes. + + Make sure your application is not installing things in + /usr/local instead of + PREFIX. A quick test for such hard-coded + paths is: + + &prompt.root; make clean; make package PREFIX=/var/tmp/`make -V PORTNAME` + + If anything is installed outside of + PREFIX, the package creation process will + complain that it cannot find the files. + + In addition, it is worth checking the same with the stage + directory support (see ): + + &prompt.root; make stage && make check-orphans && make package + + These tests will not find hard-coded paths inside the port's + files, nor will it verify that LOCALBASE is + being used to correctly refer to files from other ports. The + temporarily-installed port in + /var/tmp/`make -V PORTNAME` should be + tested for proper operation to make sure there are no problems + with paths. + + PREFIX should not be set explicitly in a + port's Makefile. Users installing the port + may have set PREFIX to a custom location, and + the port should respect that setting. + + Refer to programs and files from other ports with the + variables mentioned above, not explicit pathnames. For + instance, if your port requires a macro PAGER + to have the full pathname of less, do not use + a literal path of /usr/local/bin/less. + Instead, use ${LOCALBASE}: + + -DPAGER=\"${LOCALBASE}/bin/less\" + + The path with LOCALBASE is more likely to + still work if the system administrator has moved the whole + /usr/local tree somewhere else. + + + + Tinderbox + + If you are an avid ports contributor, you might want to take + a look at Tinderbox. It is a + powerful system for building and testing ports. You can install + Tinderbox using + ports-mgmt/tinderbox port. Be + sure to read supplied documentation since the configuration is + not trivial. + + Visit the + Tinderbox + website for more details. + + + + Poudriere + + As a ports contributor, consider installing + poudriere. It is a powerful + system for building and testing ports. + Poudriere can be installed with + ports-mgmt/poudriere. + + Visit the Poudriere + website for more details. + + From owner-svn-doc-head@FreeBSD.ORG Sun Feb 16 04:57:46 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F6FC946; Sun, 16 Feb 2014 04:57:46 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 68B521CC6; Sun, 16 Feb 2014 04:57:46 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1G4vkFs014217; Sun, 16 Feb 2014 04:57:46 GMT (envelope-from wblock@svn.freebsd.org) Received: (from wblock@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1G4vk1C014216; Sun, 16 Feb 2014 04:57:46 GMT (envelope-from wblock@svn.freebsd.org) Message-Id: <201402160457.s1G4vk1C014216@svn.freebsd.org> From: Warren Block Date: Sun, 16 Feb 2014 04:57:46 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43958 - head/en_US.ISO8859-1/books/porters-handbook/makefiles X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 04:57:46 -0000 Author: wblock Date: Sun Feb 16 04:57:45 2014 New Revision: 43958 URL: http://svnweb.freebsd.org/changeset/doc/43958 Log: Whitespace-only fixes, translators please ignore. Modified: head/en_US.ISO8859-1/books/porters-handbook/makefiles/chapter.xml Modified: head/en_US.ISO8859-1/books/porters-handbook/makefiles/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/porters-handbook/makefiles/chapter.xml Sun Feb 16 03:32:26 2014 (r43957) +++ head/en_US.ISO8859-1/books/porters-handbook/makefiles/chapter.xml Sun Feb 16 04:57:45 2014 (r43958) @@ -4,2114 +4,2087 @@ $FreeBSD$ --> + + + Configuring the Makefile + + Configuring the Makefile is pretty + simple, and again we suggest that you look at existing examples + before starting. Also, there is a + sample Makefile in this + handbook, so take a look and please follow the ordering of + variables and sections in that template to make your port easier + for others to read. + + Now, consider the following problems in sequence as you + design your new Makefile: + + + The Original Source + + Does it live in DISTDIR as a standard + gzipped tarball named something like + foozolix-1.2.tar.gz? If so, you can go on + to the next step. If not, you should look at overriding any of + the DISTVERSION, DISTNAME, + EXTRACT_CMD, + EXTRACT_BEFORE_ARGS, + EXTRACT_AFTER_ARGS, + EXTRACT_SUFX, or DISTFILES + variables, depending on how alien a format your port's + distribution file is. + + In the worst case, you can simply create your own + do-extract target to override the + default, though this should be rarely, if ever, + necessary. + + + + Naming + + The first part of the port's Makefile + names the port, describes its version number, and lists it in + the correct category. + + + <varname>PORTNAME</varname> and + <varname>PORTVERSION</varname> + + You should set PORTNAME to the base + name of your port, and PORTVERSION to the + version number of the port. + + + + <varname>PORTREVISION</varname> and + <varname>PORTEPOCH</varname> + + + <varname>PORTREVISION</varname> + + The PORTREVISION variable is a + monotonically increasing value which is reset to 0 with + every increase of PORTVERSION (i.e., + every time a new official vendor release is made), and + appended to the package name if non-zero. Changes to + PORTREVISION are used by automated tools + (e.g., pkg version, see + &man.pkg-version.8;) to highlight the fact that a new + package is available. + + PORTREVISION should be increased each + time a change is made to the port that changes the generated + package in any way. That includes changes that only affect + a package built with non-default + options. - - Configuring the Makefile + Examples of when PORTREVISION + should be bumped: - Configuring the Makefile is pretty - simple, and again we suggest that you look at existing examples - before starting. Also, there is a - sample Makefile in this - handbook, so take a look and please follow the ordering of - variables and sections in that template to make your port easier - for others to read. - - Now, consider the following problems in sequence as you - design your new Makefile: - - - The Original Source - - Does it live in DISTDIR as a standard - gzipped tarball named something like - foozolix-1.2.tar.gz? If so, you can go on - to the next step. If not, you should look at overriding any - of the DISTVERSION, - DISTNAME, EXTRACT_CMD, - EXTRACT_BEFORE_ARGS, - EXTRACT_AFTER_ARGS, - EXTRACT_SUFX, or - DISTFILES variables, depending on how alien - a format your port's distribution file is. - - In the worst case, you can simply create your own - do-extract target to override the - default, though this should be rarely, if ever, - necessary. - - - - Naming - - The first part of the port's Makefile - names the port, describes its version number, and lists it - in the correct category. - - - <varname>PORTNAME</varname> and - <varname>PORTVERSION</varname> - - You should set PORTNAME to the - base name of your port, and PORTVERSION - to the version number of the port. - - - - <varname>PORTREVISION</varname> and - <varname>PORTEPOCH</varname> - - - <varname>PORTREVISION</varname> - - The PORTREVISION variable is a - monotonically increasing value which is reset to 0 with - every increase of PORTVERSION (i.e., - every time a new official vendor release is made), and - appended to the package name if non-zero. Changes to - PORTREVISION are used by automated - tools (e.g., pkg version, see - &man.pkg-version.8;) to highlight the fact that a new - package is available. - - PORTREVISION should be increased - each time a change is made to the port that changes the - generated package in any way. That includes changes that - only affect a package built with non-default options. - - Examples of when PORTREVISION - should be bumped: - - - - Addition of patches to correct security - vulnerabilities, bugs, or to add new functionality to - the port. - - - - Changes to the port Makefile - to enable or disable compile-time options in the - package. - - - - Changes in the packing list or the install-time - behavior of the package (e.g., change to a script - which generates initial data for the package, like ssh - host keys). - - - - Version bump of a port's shared library dependency - (in this case, someone trying to install the old - package after installing a newer version of the - dependency will fail since it will look for the old - libfoo.x instead of libfoo.(x+1)). - - - - Silent changes to the port distfile which have - significant functional differences, i.e., changes to - the distfile requiring a correction to - distinfo with no corresponding - change to PORTVERSION, where a - diff -ru of the old and new - versions shows non-trivial changes to the code. - - - - Examples of changes which do not require a - PORTREVISION bump: - - - - Style changes to the port skeleton with no - functional change to what appears in the resulting - package. - - - - Changes to MASTER_SITES or - other functional changes to the port which do not - affect the resulting package. - - - - Trivial patches to the distfile such as correction - of typos, which are not important enough that users of - the package should go to the trouble of - upgrading. - - - - Build fixes which cause a package to become - compilable where it was previously failing (as long as - the changes do not introduce any functional change on - any other platforms on which the port did previously - build). Since PORTREVISION - reflects the content of the package, if the package - was not previously buildable then there is no need to - increase PORTREVISION to mark a - change. - - - - A rule of thumb is to ask yourself whether a change - committed to a port is something which everyone would - benefit from having (either because of an enhancement, - fix, or by virtue that the new package will actually work - at all), and weigh that against that fact that it will - cause everyone who regularly updates their ports tree to - be compelled to update. If yes, the - PORTREVISION should be bumped. - - - - <varname>PORTEPOCH</varname> - - From time to time a software vendor or &os; porter - will do something silly and release a version of their - software which is actually numerically less than the - previous version. An example of this is a port which goes - from foo-20000801 to foo-1.0 (the former will be - incorrectly treated as a newer version since 20000801 is a - numerically greater value than 1). - - - The results of version number comparisons are not - always obvious. pkg version (see - &man.pkg-version.8;) can be used to test the comparison - of two version number strings. For example: - - &prompt.user; pkg version -t 0.031 0.29 -> - - The > output indicates that - version 0.031 is considered greater than version 0.29, - which may not have been obvious to the porter. - - - In situations such as this, the - PORTEPOCH version should be increased. - If PORTEPOCH is nonzero it is appended - to the package name as described in section 0 above. - PORTEPOCH must never be decreased or - reset to zero, because that would cause comparison to a - package from an earlier epoch to fail (i.e., the package - would not be detected as out of date): the new version - number (e.g., 1.0,1 in the above - example) is still numerically less than the previous - version (20000801), but the ,1 suffix - is treated specially by automated tools and found to be - greater than the implied suffix ,0 on - the earlier package. - - Dropping or resetting PORTEPOCH - incorrectly leads to no end of grief; if you do not - understand the above discussion, please keep after it - until you do, or ask questions on the mailing - lists. - - It is expected that PORTEPOCH will - not be used for the majority of ports, and that sensible - use of PORTVERSION can often preempt it - becoming necessary if a future release of the software - should change the version structure. However, care is - needed by &os; porters when a vendor release is made - without an official version number — such as a code - snapshot release. The temptation is to - label the release with the release date, which will cause - problems as in the example above when a new - official release is made. - - For example, if a snapshot release is made on the date - 20000917, and the previous version of the software was - version 1.2, the snapshot release should be given a - PORTVERSION of 1.2.20000917 or similar, - not 20000917, so that the succeeding release, say 1.3, is - still a numerically greater value. - - - - Example of <varname>PORTREVISION</varname> and - <varname>PORTEPOCH</varname> Usage - - The gtkmumble port, version - 0.10, is committed to the ports - collection: - - PORTNAME= gtkmumble -PORTVERSION= 0.10 - - PKGNAME becomes - gtkmumble-0.10. - - A security hole is discovered which requires a local - &os; patch. PORTREVISION is bumped - accordingly. - - PORTNAME= gtkmumble -PORTVERSION= 0.10 -PORTREVISION= 1 - - PKGNAME becomes - gtkmumble-0.10_1 - - A new version is released by the vendor, numbered - 0.2 (it turns out the author actually - intended 0.10 to actually mean - 0.1.0, not - what comes after 0.9 - oops, too late now). - Since the new minor version 2 is - numerically less than the previous version - 10, the PORTEPOCH - must be bumped to manually force the new package to be - detected as newer. Since it is a new - vendor release of the code, - PORTREVISION is reset to 0 (or removed - from the Makefile). - - PORTNAME= gtkmumble -PORTVERSION= 0.2 -PORTEPOCH= 1 - - PKGNAME becomes - gtkmumble-0.2,1 - - The next release is 0.3. Since - PORTEPOCH never decreases, the version - variables are now: - - PORTNAME= gtkmumble -PORTVERSION= 0.3 -PORTEPOCH= 1 - - PKGNAME becomes - gtkmumble-0.3,1 - - - If PORTEPOCH were reset to - 0 with this upgrade, someone who had - installed the gtkmumble-0.10_1 - package would not detect the - gtkmumble-0.3 package as newer, since - 3 is still numerically less than - 10. Remember, this is the whole - point of PORTEPOCH in the first - place. - - - - - - <varname>PKGNAMEPREFIX</varname> and - <varname>PKGNAMESUFFIX</varname> - - Two optional variables, PKGNAMEPREFIX - and PKGNAMESUFFIX, are combined with - PORTNAME and - PORTVERSION to form - PKGNAME as - ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}. - Make sure this conforms to our - guidelines for a good - package name. In particular, you are - not allowed to use a hyphen - (-) in PORTVERSION. - Also, if the package name has the - language- or the - -compiled.specifics part (see - below), use PKGNAMEPREFIX and - PKGNAMESUFFIX, respectively. Do not make - them part of PORTNAME. - - - - Package Naming Conventions - - The following are the conventions you should follow in - naming your packages. This is to have our package directory - easy to scan, as there are already thousands of packages and - users are going to turn away if they hurt their eyes! - - The package name should look like - language_region-name-compiled.specifics-version.numbers. - - The package name is defined as - ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}. - Make sure to set the variables to conform to that - format. - - + - &os; strives to support the native language of - its users. The language- - part should be a two letter abbreviation of the natural - language defined by ISO-639 if the port is specific to a - certain language. Examples are ja - for Japanese, ru for Russian, - vi for Vietnamese, - zh for Chinese, ko - for Korean and de for German. - - If the port is specific to a certain region within - the language area, add the two letter country code as - well. Examples are en_US for US - English and fr_CH for Swiss - French. - - The language- part should - be set in the PKGNAMEPREFIX - variable. + Addition of patches to correct security + vulnerabilities, bugs, or to add new functionality to + the port. - The first letter of the name - part should be lowercase. (The rest of the name may - contain capital letters, so use your own discretion when - you are converting a software name that has some capital - letters in it.) There is a tradition of naming - Perl 5 modules by prepending - p5- and converting the double-colon - separator to a hyphen; for example, the - Data::Dumper module becomes - p5-Data-Dumper. + Changes to the port Makefile to + enable or disable compile-time options in the + package. - Make sure that the port's name and version are - clearly separated and placed into the - PORTNAME and - PORTVERSION variables. The only - reason for PORTNAME to contain a - version part is if the upstream distribution is really - named that way, as in the - textproc/libxml2 or - japanese/kinput2-freewnn ports. - Otherwise, the PORTNAME should not - contain any version-specific information. It is quite - normal for several ports to have the same - PORTNAME, as the - www/apache* ports do; in that case, - different versions (and different index entries) are - distinguished by the PKGNAMEPREFIX - and PKGNAMESUFFIX values. + Changes in the packing list or the install-time + behavior of the package (e.g., change to a script which + generates initial data for the package, like ssh host + keys). - If the port can be built with different - hardcoded - defaults (usually part of the directory name in - a family of ports), the - -compiled.specifics part - should state the compiled-in defaults (the hyphen is - optional). Examples are paper size and font - units. - - The -compiled.specifics - part should be set in the - PKGNAMESUFFIX variable. + Version bump of a port's shared library dependency + (in this case, someone trying to install the old package + after installing a newer version of the dependency will + fail since it will look for the old libfoo.x instead of + libfoo.(x+1)). - The version string should follow a dash - (-) and be a period-separated list of - integers and single lowercase alphabetics. In - particular, it is not permissible to have another dash - inside the version string. The only exception is the - string pl (meaning - patchlevel), which can be used - only when there are no major and - minor version numbers in the software. If the software - version has strings like alpha, - beta, rc, or - pre, take the first letter and put it - immediately after a period. If the version string - continues after those names, the numbers should follow - the single alphabet without an extra period between - them. - - The idea is to make it easier to sort ports by - looking at the version string. In particular, make sure - version number components are always delimited by a - period, and if the date is part of the string, use the - 0.0.yyyy.mm.dd - format, not - dd.mm.yyyy - or the non-Y2K compliant - yy.mm.dd - format. It is important to prefix the version with - 0.0. in case a release with an actual - version number is made, which would of course be - numerically less than - yyyy. + Silent changes to the port distfile which have + significant functional differences, i.e., changes to the + distfile requiring a correction to + distinfo with no corresponding + change to PORTVERSION, where a + diff -ru of the old and new versions + shows non-trivial changes to the code. - - - Here are some (real) examples on how to convert the name - as called by the software authors to a suitable package - name: - - - - - - Distribution Name - PKGNAMEPREFIX - PORTNAME - PKGNAMESUFFIX - PORTVERSION - Reason - - - - - - mule-2.2.2 - (empty) - mule - (empty) - 2.2.2 - No changes required - - - - EmiClock-1.0.2 - (empty) - emiclock - (empty) - 1.0.2 - No uppercase names for single programs - - - - rdist-1.3alpha - (empty) - rdist - (empty) - 1.3.a - No strings like alpha - allowed - - - - es-0.9-beta1 - (empty) - es - (empty) - 0.9.b1 - No strings like beta - allowed - - - - mailman-2.0rc3 - (empty) - mailman - (empty) - 2.0.r3 - No strings like rc - allowed - - - - v3.3beta021.src - (empty) - tiff - (empty) - 3.3 - What the heck was that anyway? - - - - tvtwm - (empty) - tvtwm - (empty) - pl11 - Version string always required - - - - piewm - (empty) - piewm - (empty) - 1.0 - Version string always required - - - - xvgr-2.10pl1 - (empty) - xvgr - (empty) - 2.10.1 - pl allowed only when no - major/minor version numbers - - - - gawk-2.15.6 - ja- - gawk - (empty) - 2.15.6 - Japanese language version - - - - psutils-1.13 - (empty) - psutils - -letter - 1.13 - Paper size hardcoded at package build - time - - - - pkfonts - (empty) - pkfonts - 300 - 1.0 - Package for 300dpi fonts - - - - - - If there is absolutely no trace of version information - in the original source and it is unlikely that the original - author will ever release another version, just set the - version string to 1.0 (like the - piewm example above). Otherwise, ask the - original author or use the date string - (0.0.yyyy.mm.dd) - as the version. - - - - - Categorization - - - <varname>CATEGORIES</varname> - - When a package is created, it is put under - /usr/ports/packages/All and links are - made from one or more subdirectories of - /usr/ports/packages. The names of - these subdirectories are specified by the variable - CATEGORIES. It is intended to make life - easier for the user when he is wading through the pile of - packages on the FTP site or the CDROM. Please take a look - at the current list of - categories and pick the ones that are suitable for - your port. - - This list also determines where in the ports tree the - port is imported. If you put more than one category here, - it is assumed that the port files will be put in the - subdirectory with the name in the first category. See - below for more - discussion about how to pick the right categories. - - - - Current List of Categories - - Here is the current list of port categories. Those - marked with an asterisk (*) are - virtual categories—those that do - not have a corresponding subdirectory in the ports tree. - They are only used as secondary categories, and only for - search purposes. - - - For non-virtual categories, you will find a one-line - description in the COMMENT in that - subdirectory's Makefile. - - - - - - - Category - Description - Notes - - - - - - accessibility - Ports to help disabled users. - - - - - afterstep* - - Ports to support the AfterStep - window manager. - - - - - arabic - Arabic language support. - - - - - archivers - Archiving tools. - - - - - astro - Astronomical ports. - - - - - audio - Sound support. - - - - - benchmarks - Benchmarking utilities. - - - - - biology - Biology-related software. - - - - - cad - Computer aided design tools. - - - - - chinese - Chinese language support. - - - - - comms - Communication software. - Mostly software to talk to your serial - port. - - - - converters - Character code converters. - - - - - databases - Databases. - - - - - deskutils - Things that used to be on the desktop before - computers were invented. - - - - - devel - Development utilities. - Do not put libraries here just because they are - libraries—unless they truly do not belong - anywhere else, they should not be in this - category. - - - - dns - DNS-related software. - - - - - docs* - Meta-ports for &os; documentation. - - - - - editors - General editors. - Specialized editors go in the section for those - tools (e.g., a mathematical-formula editor will go - in math). - - - - elisp* - Emacs-lisp ports. - - - - - emulators - Emulators for other operating systems. - Terminal emulators do not - belong here—X-based ones should go to - x11 and text-based ones to - either comms or - misc, depending on the exact - functionality. - - - - finance - Monetary, financial and related - applications. - - - - - french - French language support. - - - - - ftp - FTP client and server utilities. - If your port speaks both FTP and HTTP, put it - in ftp with a secondary - category of www. - - - - games - Games. - - - - - geography* - Geography-related software. - - - - - german - German language support. - - - - - gnome* - Ports from the - GNOME - Project. - - - - - gnustep* - Software related to the GNUstep desktop - environment. - - - - - graphics - Graphics utilities. - - - - - hamradio* - Software for amateur radio. - - - - - haskell* - Software related to the Haskell - language. - - - - - hebrew - Hebrew language support. - - - - - hungarian - Hungarian language support. - - - - - ipv6* - IPv6 related software. - - - - - irc - Internet Relay Chat utilities. - - - - - japanese - Japanese language support. - - - - - java - Software related to the Java™ - language. - The java category must - not be the only one for a port. Save for ports - directly related to the Java language, porters are - also encouraged not to use java - as the main category of a port. - - - *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** From owner-svn-doc-head@FreeBSD.ORG Sun Feb 16 05:17:25 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C714FB74; Sun, 16 Feb 2014 05:17:25 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B04B51DE8; Sun, 16 Feb 2014 05:17:25 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1G5HP8u023285; Sun, 16 Feb 2014 05:17:25 GMT (envelope-from wblock@svn.freebsd.org) Received: (from wblock@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1G5HPNr023284; Sun, 16 Feb 2014 05:17:25 GMT (envelope-from wblock@svn.freebsd.org) Message-Id: <201402160517.s1G5HPNr023284@svn.freebsd.org> From: Warren Block Date: Sun, 16 Feb 2014 05:17:25 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43959 - head/en_US.ISO8859-1/books/porters-handbook/security X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 05:17:25 -0000 Author: wblock Date: Sun Feb 16 05:17:25 2014 New Revision: 43959 URL: http://svnweb.freebsd.org/changeset/doc/43959 Log: Whitespace-only fixes missed in earlier commits, translators please ignore. Modified: head/en_US.ISO8859-1/books/porters-handbook/security/chapter.xml Modified: head/en_US.ISO8859-1/books/porters-handbook/security/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/porters-handbook/security/chapter.xml Sun Feb 16 04:57:45 2014 (r43958) +++ head/en_US.ISO8859-1/books/porters-handbook/security/chapter.xml Sun Feb 16 05:17:25 2014 (r43959) @@ -71,11 +71,11 @@ Please make sure that the port's revision is bumped as soon - as the vulnerability has been closed. That is how the users who + as the vulnerability has been closed. That is how the users who upgrade installed packages on a regular basis will see they need - to run an update. Besides, a new package will be built and + to run an update. Besides, a new package will be built and distributed over FTP and WWW mirrors, replacing the vulnerable - one. PORTREVISION should be bumped unless + one. PORTREVISION should be bumped unless PORTVERSION has changed in the course of correcting the vulnerability. That is you should bump PORTREVISION if you have added a patch file @@ -150,7 +150,7 @@ similar to HTML. The major difference is that XML is eXtensible, i.e., based on defining custom tags. Due to its intrinsic structure XML puts - otherwise amorphous data into shape. VuXML is particularly + otherwise amorphous data into shape. VuXML is particularly tailored to mark up descriptions of security vulnerabilities. From owner-svn-doc-head@FreeBSD.ORG Sun Feb 16 05:19:20 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B0372BD2; Sun, 16 Feb 2014 05:19:20 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9B5841DEA; Sun, 16 Feb 2014 05:19:20 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1G5JKV5023590; Sun, 16 Feb 2014 05:19:20 GMT (envelope-from wblock@svn.freebsd.org) Received: (from wblock@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1G5JK8g023589; Sun, 16 Feb 2014 05:19:20 GMT (envelope-from wblock@svn.freebsd.org) Message-Id: <201402160519.s1G5JK8g023589@svn.freebsd.org> From: Warren Block Date: Sun, 16 Feb 2014 05:19:20 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43960 - head/en_US.ISO8859-1/books/porters-handbook/testing X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 05:19:20 -0000 Author: wblock Date: Sun Feb 16 05:19:20 2014 New Revision: 43960 URL: http://svnweb.freebsd.org/changeset/doc/43960 Log: Whitespace-only fixes missed in earlier commit, translators please ignore. Modified: head/en_US.ISO8859-1/books/porters-handbook/testing/chapter.xml Modified: head/en_US.ISO8859-1/books/porters-handbook/testing/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/porters-handbook/testing/chapter.xml Sun Feb 16 05:17:25 2014 (r43959) +++ head/en_US.ISO8859-1/books/porters-handbook/testing/chapter.xml Sun Feb 16 05:19:20 2014 (r43960) @@ -98,7 +98,7 @@ installed system mounted somewhere other than /. A port will actually install into DESTDIR/PREFIX, and register with the - package database in DESTDIR/var/db/pkg. As + package database in DESTDIR/var/db/pkg. As DESTDIR is handled automatically by the ports infrastructure with &man.chroot.8;, you do not need any modifications or any extra care to write @@ -168,7 +168,7 @@ If you are an avid ports contributor, you might want to take a look at Tinderbox. It is a - powerful system for building and testing ports. You can install + powerful system for building and testing ports. You can install Tinderbox using ports-mgmt/tinderbox port. Be sure to read supplied documentation since the configuration is From owner-svn-doc-head@FreeBSD.ORG Sun Feb 16 05:25:19 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5C4B4CAA; Sun, 16 Feb 2014 05:25:19 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 453AD1EE2; Sun, 16 Feb 2014 05:25:19 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1G5PJ9Y027180; Sun, 16 Feb 2014 05:25:19 GMT (envelope-from wblock@svn.freebsd.org) Received: (from wblock@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1G5PJBt027179; Sun, 16 Feb 2014 05:25:19 GMT (envelope-from wblock@svn.freebsd.org) Message-Id: <201402160525.s1G5PJBt027179@svn.freebsd.org> From: Warren Block Date: Sun, 16 Feb 2014 05:25:19 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43961 - head/en_US.ISO8859-1/books/porters-handbook X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 05:25:19 -0000 Author: wblock Date: Sun Feb 16 05:25:18 2014 New Revision: 43961 URL: http://svnweb.freebsd.org/changeset/doc/43961 Log: Whitespace-only fixes, translators please ignore. Modified: head/en_US.ISO8859-1/books/porters-handbook/uses.xml Modified: head/en_US.ISO8859-1/books/porters-handbook/uses.xml ============================================================================== --- head/en_US.ISO8859-1/books/porters-handbook/uses.xml Sun Feb 16 05:19:20 2014 (r43960) +++ head/en_US.ISO8859-1/books/porters-handbook/uses.xml Sun Feb 16 05:25:18 2014 (r43961) @@ -77,11 +77,11 @@ nestedfct, features Determines which compiler to use based on any given wishes. - Use c++11-lang if the port needs a C++11-capable - compiler, and c++11-lib if the port also needs - a C++11-ready standard library. If the port needs a compiler - understanding C++0X, C11, OpenMP, or nested functions, the - corresponding parameters can be used. Use + Use c++11-lang if the port needs a + C++11-capable compiler, and c++11-lib if the + port also needs a C++11-ready standard library. If the port needs + a compiler understanding C++0X, C11, OpenMP, or nested functions, + the corresponding parameters can be used. Use features to request a list of features supported by the default compiler. After including bsd.port.pre.mk the port can inspect the From owner-svn-doc-head@FreeBSD.ORG Sun Feb 16 07:19:26 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2103887; Sun, 16 Feb 2014 07:19:25 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D986115BE; Sun, 16 Feb 2014 07:19:25 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1G7JPVZ075396; Sun, 16 Feb 2014 07:19:25 GMT (envelope-from ryusuke@svn.freebsd.org) Received: (from ryusuke@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1G7JPMQ075395; Sun, 16 Feb 2014 07:19:25 GMT (envelope-from ryusuke@svn.freebsd.org) Message-Id: <201402160719.s1G7JPMQ075395@svn.freebsd.org> From: Ryusuke SUZUKI Date: Sun, 16 Feb 2014 07:19:25 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43962 - head/ja_JP.eucJP/books/handbook/preface X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 07:19:26 -0000 Author: ryusuke Date: Sun Feb 16 07:19:25 2014 New Revision: 43962 URL: http://svnweb.freebsd.org/changeset/doc/43962 Log: - Merge the following from the English version: r24930 -> r27853 head/ja_JP.eucJP/books/handbook/preface/preface.xml Modified: head/ja_JP.eucJP/books/handbook/preface/preface.xml Modified: head/ja_JP.eucJP/books/handbook/preface/preface.xml ============================================================================== --- head/ja_JP.eucJP/books/handbook/preface/preface.xml Sun Feb 16 05:25:18 2014 (r43961) +++ head/ja_JP.eucJP/books/handbook/preface/preface.xml Sun Feb 16 07:19:25 2014 (r43962) @@ -3,7 +3,7 @@ The FreeBSD Documentation Project The FreeBSD Japanese Documentation Project - Original revision: r24930 + Original revision: r27853 $FreeBSD$ --> @@ -355,6 +355,15 @@ ネットワークファイルシステムなどです。 + , 地域化 From owner-svn-doc-head@FreeBSD.ORG Sun Feb 16 07:34:11 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 74260960; Sun, 16 Feb 2014 07:34:11 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 42FDA16B7; Sun, 16 Feb 2014 07:34:11 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1G7YBxf082936; Sun, 16 Feb 2014 07:34:11 GMT (envelope-from ryusuke@svn.freebsd.org) Received: (from ryusuke@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1G7YB5C082935; Sun, 16 Feb 2014 07:34:11 GMT (envelope-from ryusuke@svn.freebsd.org) Message-Id: <201402160734.s1G7YB5C082935@svn.freebsd.org> From: Ryusuke SUZUKI Date: Sun, 16 Feb 2014 07:34:11 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43963 - head/ja_JP.eucJP/books/handbook/preface X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 07:34:11 -0000 Author: ryusuke Date: Sun Feb 16 07:34:10 2014 New Revision: 43963 URL: http://svnweb.freebsd.org/changeset/doc/43963 Log: - Merge the following from the English version: r27853 -> r29008 head/ja_JP.eucJP/books/handbook/preface/preface.xml Modified: head/ja_JP.eucJP/books/handbook/preface/preface.xml Modified: head/ja_JP.eucJP/books/handbook/preface/preface.xml ============================================================================== --- head/ja_JP.eucJP/books/handbook/preface/preface.xml Sun Feb 16 07:19:25 2014 (r43962) +++ head/ja_JP.eucJP/books/handbook/preface/preface.xml Sun Feb 16 07:34:10 2014 (r43963) @@ -3,7 +3,7 @@ The FreeBSD Documentation Project The FreeBSD Japanese Documentation Project - Original revision: r27853 + Original revision: r29008 $FreeBSD$ --> @@ -34,7 +34,7 @@ - に、ACPI 電源管理、クーロンシステムユーティリティ、 + に、ACPI 電源管理、cron システムユーティリティ、 およびカーネルチューニングオプションに関するより多くの情報が追加されました。 @@ -75,15 +75,19 @@ , に、 - 他のメール転送エージェント、SMTP の認証、UUCP, fetchmail, - procmail や他の高度な話題についての情報が追加されました。 + 他のメール転送エージェント、SMTP 認証、UUCP, + fetchmail, + procmail + や他の高度な話題についての情報が追加されました。 ネットワークサービスの章が、この版で新しく追加されました。 - この章では、Apache HTTP サーバ、FTPd および Samba を用いて - Microsoft Windows + この章では、Apache HTTP サーバ、 + fptd および + Samba を用いて + µsoft; &windows; クライアント用にサーバを設定する方法などを取り上げています。 再構成によりいくつかの節が、 @@ -92,7 +96,8 @@ に、 - FreeBSD での Bluetooth デバイスの使用、ワイヤレスネットワークの設定、 + FreeBSD での &bluetooth; デバイスの使用、 + ワイヤレスネットワークの設定、 Asynchronous Transfer Mode (ATM) ネットワークに関する情報が追加されました。 @@ -425,7 +430,7 @@ LAN 上の他のコンピュータとインターネット接続の共有、 高度なルーティングに関するトピックス、ワイヤレスネットワーク、 - bluetooth, ATM, IPv6 等々、 + &bluetooth;, ATM, IPv6 等々、 ネットワークに関するさまざまな話題を取り扱っています。 From owner-svn-doc-head@FreeBSD.ORG Sun Feb 16 14:22:22 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3B94418; Sun, 16 Feb 2014 14:22:22 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9550711B2; Sun, 16 Feb 2014 14:22:22 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1GEMMJE064390; Sun, 16 Feb 2014 14:22:22 GMT (envelope-from ryusuke@svn.freebsd.org) Received: (from ryusuke@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1GEMMpm064386; Sun, 16 Feb 2014 14:22:22 GMT (envelope-from ryusuke@svn.freebsd.org) Message-Id: <201402161422.s1GEMMpm064386@svn.freebsd.org> From: Ryusuke SUZUKI Date: Sun, 16 Feb 2014 14:22:22 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43964 - head/ja_JP.eucJP/articles/contributors X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 14:22:22 -0000 Author: ryusuke Date: Sun Feb 16 14:22:21 2014 New Revision: 43964 URL: http://svnweb.freebsd.org/changeset/doc/43964 Log: - Merge the following from the English version: r25717 -> r35386 head/ja_JP.eucJP/articles/contributors/Makefile r32675 -> r35368 head/ja_JP.eucJP/articles/contributors/article.xml Modified: head/ja_JP.eucJP/articles/contributors/Makefile head/ja_JP.eucJP/articles/contributors/article.xml Modified: head/ja_JP.eucJP/articles/contributors/Makefile ============================================================================== --- head/ja_JP.eucJP/articles/contributors/Makefile Sun Feb 16 07:34:10 2014 (r43963) +++ head/ja_JP.eucJP/articles/contributors/Makefile Sun Feb 16 14:22:21 2014 (r43964) @@ -3,7 +3,7 @@ # # Article: Contributors to FreeBSD # -# Original revision: 1.10 +# Original revision: r35386 DOC?= article @@ -22,6 +22,7 @@ SRCS+= ${ORGDIR}/contrib.additional.xml SRCS+= ${ORGDIR}/contrib.committers.xml SRCS+= ${ORGDIR}/contrib.corealumni.xml SRCS+= ${ORGDIR}/contrib.develalumni.xml +SRCS+= ${ORGDIR}/contrib.develinmemoriam.xml URL_RELPREFIX?= ../../../.. DOC_PREFIX?= ${.CURDIR}/../../.. Modified: head/ja_JP.eucJP/articles/contributors/article.xml ============================================================================== --- head/ja_JP.eucJP/articles/contributors/article.xml Sun Feb 16 07:34:10 2014 (r43963) +++ head/ja_JP.eucJP/articles/contributors/article.xml Sun Feb 16 14:22:21 2014 (r43964) @@ -8,7 +8,7 @@ The FreeBSD Documentation Project The FreeBSD Japanese Documentation Project - Original revision: r32675 + Original revision: r35368 $FreeBSD$ -->
@@ -396,6 +396,20 @@ &contrib.develalumni; + + 開発チーム : 亡くなられた開発者を悼んで + + 開発チーム (development team) + + FreeBSD プロジェクトがスタートしてからの長い年月の間に、 + 残念ながら亡くなられた開発者もいます。 + ここでは彼らの思い出を残します。 + + ほぼ亡くなられた逆年代順に: + + &contrib.develinmemoriam; + + BSD 派生ソフトウェアへの貢献者 From owner-svn-doc-head@FreeBSD.ORG Sun Feb 16 15:11:26 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5596483B; Sun, 16 Feb 2014 15:11:26 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3632015AE; Sun, 16 Feb 2014 15:11:26 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1GFBQSF086136; Sun, 16 Feb 2014 15:11:26 GMT (envelope-from ryusuke@svn.freebsd.org) Received: (from ryusuke@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1GFBPpD086134; Sun, 16 Feb 2014 15:11:25 GMT (envelope-from ryusuke@svn.freebsd.org) Message-Id: <201402161511.s1GFBPpD086134@svn.freebsd.org> From: Ryusuke SUZUKI Date: Sun, 16 Feb 2014 15:11:25 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43965 - head/ja_JP.eucJP/articles/contributors X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 15:11:26 -0000 Author: ryusuke Date: Sun Feb 16 15:11:25 2014 New Revision: 43965 URL: http://svnweb.freebsd.org/changeset/doc/43965 Log: - Merge the following from the English version: r35386 -> r36665 head/ja_JP.eucJP/articles/contributors/Makefile r35368 -> r38558 head/ja_JP.eucJP/articles/contributors/article.xml Modified: head/ja_JP.eucJP/articles/contributors/Makefile head/ja_JP.eucJP/articles/contributors/article.xml Modified: head/ja_JP.eucJP/articles/contributors/Makefile ============================================================================== --- head/ja_JP.eucJP/articles/contributors/Makefile Sun Feb 16 14:22:21 2014 (r43964) +++ head/ja_JP.eucJP/articles/contributors/Makefile Sun Feb 16 15:11:25 2014 (r43965) @@ -3,7 +3,7 @@ # # Article: Contributors to FreeBSD # -# Original revision: r35386 +# Original revision: r36665 DOC?= article @@ -23,6 +23,7 @@ SRCS+= ${ORGDIR}/contrib.committers.xml SRCS+= ${ORGDIR}/contrib.corealumni.xml SRCS+= ${ORGDIR}/contrib.develalumni.xml SRCS+= ${ORGDIR}/contrib.develinmemoriam.xml +SRCS+= ${ORGDIR}/contrib.portmgralumni.xml URL_RELPREFIX?= ../../../.. DOC_PREFIX?= ${.CURDIR}/../../.. Modified: head/ja_JP.eucJP/articles/contributors/article.xml ============================================================================== --- head/ja_JP.eucJP/articles/contributors/article.xml Sun Feb 16 14:22:21 2014 (r43964) +++ head/ja_JP.eucJP/articles/contributors/article.xml Sun Feb 16 15:11:25 2014 (r43965) @@ -8,7 +8,7 @@ The FreeBSD Documentation Project The FreeBSD Japanese Documentation Project - Original revision: r35368 + Original revision: r38558 $FreeBSD$ -->
@@ -34,6 +34,13 @@ 寄贈者ギャラリー + + 2010 年現在、この節は何年も前のものになっています。 + 数年前からの寄付については、 + ここ + にまとめられています。 + + FreeBSD プロジェクトは次の寄贈者に恩義を受けており、 ここに公表して感謝の意を表したいと思います。 @@ -268,7 +275,7 @@ - Ernst Winter ewinter@lobo.muc.de は、 + Ernst Winter (故人) は、 このプロジェクトへ 2.88 MB のフロッピードライブを提供してくださいました。 うまくいけば、 @@ -396,6 +403,20 @@ &contrib.develalumni; + + Ports Management チームの卒業生 + + portmgr チーム (portmgr team) + 次にあげる人々は () で記した期間、FreeBSD + portmgr チームのメンバーでした。FreeBSD + プロジェクトにおける彼らの努力に感謝の意を表します。 + + + だいたいの逆年代順 + + &contrib.portmgralumni; + + 開発チーム : 亡くなられた開発者を悼んで From owner-svn-doc-head@FreeBSD.ORG Sun Feb 16 15:21:33 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E7397C6F; Sun, 16 Feb 2014 15:21:33 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D1A6F1652; Sun, 16 Feb 2014 15:21:33 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1GFLXG3091174; Sun, 16 Feb 2014 15:21:33 GMT (envelope-from ryusuke@svn.freebsd.org) Received: (from ryusuke@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1GFLXsY091172; Sun, 16 Feb 2014 15:21:33 GMT (envelope-from ryusuke@svn.freebsd.org) Message-Id: <201402161521.s1GFLXsY091172@svn.freebsd.org> From: Ryusuke SUZUKI Date: Sun, 16 Feb 2014 15:21:33 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43966 - head/ja_JP.eucJP/articles/contributors X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 15:21:34 -0000 Author: ryusuke Date: Sun Feb 16 15:21:33 2014 New Revision: 43966 URL: http://svnweb.freebsd.org/changeset/doc/43966 Log: - Merge the following from the English version: r36665 -> r39631 head/ja_JP.eucJP/articles/contributors/Makefile r38558 -> r43184 head/ja_JP.eucJP/articles/contributors/article.xml Modified: head/ja_JP.eucJP/articles/contributors/Makefile head/ja_JP.eucJP/articles/contributors/article.xml Modified: head/ja_JP.eucJP/articles/contributors/Makefile ============================================================================== --- head/ja_JP.eucJP/articles/contributors/Makefile Sun Feb 16 15:11:25 2014 (r43965) +++ head/ja_JP.eucJP/articles/contributors/Makefile Sun Feb 16 15:21:33 2014 (r43966) @@ -3,7 +3,7 @@ # # Article: Contributors to FreeBSD # -# Original revision: r36665 +# Original revision: r39631 DOC?= article Modified: head/ja_JP.eucJP/articles/contributors/article.xml ============================================================================== --- head/ja_JP.eucJP/articles/contributors/article.xml Sun Feb 16 15:11:25 2014 (r43965) +++ head/ja_JP.eucJP/articles/contributors/article.xml Sun Feb 16 15:21:33 2014 (r43966) @@ -8,7 +8,7 @@ The FreeBSD Documentation Project The FreeBSD Japanese Documentation Project - Original revision: r38558 + Original revision: r43184 $FreeBSD$ -->
@@ -17,7 +17,6 @@ &tm-attrib.freebsd; - &tm-attrib.cvsup; &tm-attrib.sun; &tm-attrib.general; From owner-svn-doc-head@FreeBSD.ORG Sun Feb 16 19:45:09 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D27AF4D; Sun, 16 Feb 2014 19:45:09 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7678518E3; Sun, 16 Feb 2014 19:45:09 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1GJj9mO009417; Sun, 16 Feb 2014 19:45:09 GMT (envelope-from dim@svn.freebsd.org) Received: (from dim@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1GJj9Ka009416; Sun, 16 Feb 2014 19:45:09 GMT (envelope-from dim@svn.freebsd.org) Message-Id: <201402161945.s1GJj9Ka009416@svn.freebsd.org> From: Dimitry Andric Date: Sun, 16 Feb 2014 19:45:09 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43967 - head/en_US.ISO8859-1/books/porters-handbook X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 19:45:09 -0000 Author: dim (src committer) Date: Sun Feb 16 19:45:08 2014 New Revision: 43967 URL: http://svnweb.freebsd.org/changeset/doc/43967 Log: Document __FreeBSD_version value 1100009. Modified: head/en_US.ISO8859-1/books/porters-handbook/versions.xml Modified: head/en_US.ISO8859-1/books/porters-handbook/versions.xml ============================================================================== --- head/en_US.ISO8859-1/books/porters-handbook/versions.xml Sun Feb 16 15:21:33 2014 (r43966) +++ head/en_US.ISO8859-1/books/porters-handbook/versions.xml Sun Feb 16 19:45:08 2014 (r43967) @@ -4978,3 +4978,10 @@ it was never committed: 11.0-CURRENT after libc++ 3.4 ABI compatibility fix (rev 261801). + + + 1100009 + February 16, 2014 + 11.0-CURRENT after upgrade of llvm/clang to 3.4 release + (rev 261991). + From owner-svn-doc-head@FreeBSD.ORG Mon Feb 17 14:28:00 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 23543E74; Mon, 17 Feb 2014 14:28:00 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0FC2B173A; Mon, 17 Feb 2014 14:28:00 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1HERxFb084437; Mon, 17 Feb 2014 14:27:59 GMT (envelope-from ryusuke@svn.freebsd.org) Received: (from ryusuke@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1HERxxK084436; Mon, 17 Feb 2014 14:27:59 GMT (envelope-from ryusuke@svn.freebsd.org) Message-Id: <201402171427.s1HERxxK084436@svn.freebsd.org> From: Ryusuke SUZUKI Date: Mon, 17 Feb 2014 14:27:59 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43968 - head/en_US.ISO8859-1/articles/contributors X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 14:28:00 -0000 Author: ryusuke Date: Mon Feb 17 14:27:59 2014 New Revision: 43968 URL: http://svnweb.freebsd.org/changeset/doc/43968 Log: o was was -> was Modified: head/en_US.ISO8859-1/articles/contributors/contrib.develinmemoriam.xml Modified: head/en_US.ISO8859-1/articles/contributors/contrib.develinmemoriam.xml ============================================================================== --- head/en_US.ISO8859-1/articles/contributors/contrib.develinmemoriam.xml Sun Feb 16 19:45:08 2014 (r43967) +++ head/en_US.ISO8859-1/articles/contributors/contrib.develinmemoriam.xml Mon Feb 17 14:27:59 2014 (r43968) @@ -40,7 +40,7 @@ &a.itojun.email; (1997 - 2001; RIP 2008) Known to everyone as itojun, - Jun-ichiro Hagino was was a core researcher at the + Jun-ichiro Hagino was a core researcher at the KAME Project, which aimed to provide IPv6 and IPsec technology in freely redistributable form. Much of this code was incorporated From owner-svn-doc-head@FreeBSD.ORG Mon Feb 17 14:42:18 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using T