From owner-dev-commits-doc-all@freebsd.org Mon Jun 7 17:49:46 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9BF94651A11 for ; Mon, 7 Jun 2021 17:49:46 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FzLVL3ptfz3ldt; Mon, 7 Jun 2021 17:49:46 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 677C919C59; Mon, 7 Jun 2021 17:49:46 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 157Hnkd9097181; Mon, 7 Jun 2021 17:49:46 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 157Hnk9v097180; Mon, 7 Jun 2021 17:49:46 GMT (envelope-from git) Date: Mon, 7 Jun 2021 17:49:46 GMT Message-Id: <202106071749.157Hnk9v097180@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Rene Ladan Subject: git: ac97b35aee - main - contributors: move jlaffaye to developer alumni MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: rene X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: ac97b35aeeea83030963e3eb19c9501b7e02bf3f Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2021 17:49:46 -0000 The branch main has been updated by rene: URL: https://cgit.FreeBSD.org/doc/commit/?id=ac97b35aeeea83030963e3eb19c9501b7e02bf3f commit ac97b35aeeea83030963e3eb19c9501b7e02bf3f Author: Rene Ladan AuthorDate: 2021-06-07 17:49:07 +0000 Commit: Rene Ladan CommitDate: 2021-06-07 17:49:07 +0000 contributors: move jlaffaye to developer alumni --- documentation/content/en/articles/contributors/contrib-committers.adoc | 1 - documentation/content/en/articles/contributors/contrib-develalumni.adoc | 1 + 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/content/en/articles/contributors/contrib-committers.adoc b/documentation/content/en/articles/contributors/contrib-committers.adoc index 5f10bc5a4b..c9173fe9db 100644 --- a/documentation/content/en/articles/contributors/contrib-committers.adoc +++ b/documentation/content/en/articles/contributors/contrib-committers.adoc @@ -184,7 +184,6 @@ * {rajeshasp} * {kuriyama} * {rene} -* {jlaffaye} * {mich} * {dvl} * {erwin} diff --git a/documentation/content/en/articles/contributors/contrib-develalumni.adoc b/documentation/content/en/articles/contributors/contrib-develalumni.adoc index e11ce42ddf..65b8e9c31b 100644 --- a/documentation/content/en/articles/contributors/contrib-develalumni.adoc +++ b/documentation/content/en/articles/contributors/contrib-develalumni.adoc @@ -1,4 +1,5 @@ +* {jlaffaye} (2011 - 2021) * {kmoore} (2009 - 2021) * {lifanov} (2016 - 2021) * {miwi} (2006 - 2021) From owner-dev-commits-doc-all@freebsd.org Tue Jun 8 09:37:25 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C318B65C36E for ; Tue, 8 Jun 2021 09:37:25 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FzlWn4z7zz3pYT; Tue, 8 Jun 2021 09:37:25 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 930DF2637B; Tue, 8 Jun 2021 09:37:25 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 1589bP66054138; Tue, 8 Jun 2021 09:37:25 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 1589bPE4054137; Tue, 8 Jun 2021 09:37:25 GMT (envelope-from git) Date: Tue, 8 Jun 2021 09:37:25 GMT Message-Id: <202106080937.1589bPE4054137@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Mateusz Piotrowski <0mp@FreeBSD.org> Subject: git: 45db18365c - internal/admin - Release Fernando Apesteguía (fernape) from mentorship MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: 0mp X-Git-Repository: doc X-Git-Refname: refs/internal/admin X-Git-Reftype: branch X-Git-Commit: 45db18365c7be15bb8e0ae9215fae2df976ea020 Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 09:37:25 -0000 The branch internal/admin has been updated by 0mp: URL: https://cgit.FreeBSD.org/doc/commit/?id=45db18365c7be15bb8e0ae9215fae2df976ea020 commit 45db18365c7be15bb8e0ae9215fae2df976ea020 Author: Mateusz Piotrowski <0mp@FreeBSD.org> AuthorDate: 2021-06-08 09:34:50 +0000 Commit: Mateusz Piotrowski <0mp@FreeBSD.org> CommitDate: 2021-06-08 09:36:22 +0000 Release Fernando Apesteguía (fernape) from mentorship It's time to fly solo, Fernando. Keep up the good work! Discussed with: gbe Approved by: doceng (implicit) --- mentors | 1 - 1 file changed, 1 deletion(-) diff --git a/mentors b/mentors index ccaa57643f..e9bc1b0605 100644 --- a/mentors +++ b/mentors @@ -10,5 +10,4 @@ # Sort by mentee login name. # Mentee Mentor Optional comment -fernape 0mp co-mentors: gbe murray bcr From owner-dev-commits-doc-all@freebsd.org Tue Jun 8 10:28:23 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7EFC065CC7B for ; Tue, 8 Jun 2021 10:28:23 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fzmfb33BFz3tbm; Tue, 8 Jun 2021 10:28:23 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 463CF27294; Tue, 8 Jun 2021 10:28:23 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 158ASNLv022072; Tue, 8 Jun 2021 10:28:23 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 158ASNIr022069; Tue, 8 Jun 2021 10:28:23 GMT (envelope-from git) Date: Tue, 8 Jun 2021 10:28:23 GMT Message-Id: <202106081028.158ASNIr022069@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: "Danilo G. Baio" Subject: git: f80bbbf56d - main - Remove an extra space after '+' characters MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: dbaio X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: f80bbbf56d7b9f87e93e25545073b98603da9b81 Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 10:28:23 -0000 The branch main has been updated by dbaio: URL: https://cgit.FreeBSD.org/doc/commit/?id=f80bbbf56d7b9f87e93e25545073b98603da9b81 commit f80bbbf56d7b9f87e93e25545073b98603da9b81 Author: Danilo G. Baio AuthorDate: 2021-06-07 23:04:38 +0000 Commit: Danilo G. Baio CommitDate: 2021-06-08 10:27:12 +0000 Remove an extra space after '+' characters This is happening only on documentation/, basically in all places that attaches a block or a paragraph to a list [1]. Although this is working, it impacts our translation tool po4a, the '+' character is a difficult part when processing asciidoc[tor] files. 1 - https://docs.asciidoctor.org/asciidoc/latest/lists/continuation/#list-continuation Reviewed by: carlavilla Differential Revision: https://reviews.freebsd.org/D30688 --- .../en/articles/building-products/_index.adoc | 18 ++-- .../en/articles/committers-guide/_index.adoc | 90 ++++++++++---------- .../content/en/articles/contributing/_index.adoc | 42 +++++----- .../content/en/articles/contributors/_index.adoc | 4 +- .../contributors/contrib-develinmemoriam.adoc | 48 +++++------ .../content/en/articles/explaining-bsd/_index.adoc | 10 +-- .../content/en/articles/fonts/_index.adoc | 16 ++-- .../en/articles/freebsd-questions/_index.adoc | 16 ++-- .../content/en/articles/freebsd-releng/_index.adoc | 10 +-- .../en/articles/mailing-list-faq/_index.adoc | 10 +-- .../content/en/articles/nanobsd/_index.adoc | 2 +- .../en/articles/problem-reports/_index.adoc | 10 +-- .../content/en/articles/serial-uart/_index.adoc | 8 +- .../content/en/articles/solid-state/_index.adoc | 20 ++--- .../content/en/articles/vinum/_index.adoc | 10 +-- .../content/en/books/arch-handbook/isa/_index.adoc | 54 ++++++------ .../en/books/arch-handbook/jail/_index.adoc | 2 +- .../en/books/arch-handbook/scsi/_index.adoc | 96 +++++++++++----------- .../en/books/arch-handbook/sound/_index.adoc | 2 +- .../en/books/developers-handbook/ipv6/_index.adoc | 4 +- .../books/developers-handbook/policies/_index.adoc | 38 ++++----- .../books/developers-handbook/testing/_index.adoc | 4 +- .../en/books/developers-handbook/tools/_index.adoc | 8 +- .../en/books/developers-handbook/x86/_index.adoc | 2 +- documentation/content/en/books/faq/_index.adoc | 24 +++--- .../en/books/fdp-primer/overview/_index.adoc | 4 +- .../books/fdp-primer/po-translations/_index.adoc | 6 +- .../books/handbook/advanced-networking/_index.adoc | 14 ++-- .../en/books/handbook/bibliography/_index.adoc | 4 +- .../en/books/handbook/bsdinstall/_index.adoc | 18 ++-- .../en/books/handbook/cutting-edge/_index.adoc | 12 +-- .../content/en/books/handbook/disks/_index.adoc | 42 +++++----- .../en/books/handbook/firewalls/_index.adoc | 22 ++--- .../content/en/books/handbook/geom/_index.adoc | 20 ++--- .../content/en/books/handbook/jails/_index.adoc | 38 ++++----- .../content/en/books/handbook/mail/_index.adoc | 10 +-- .../en/books/handbook/network-servers/_index.adoc | 24 +++--- .../content/en/books/handbook/ports/_index.adoc | 22 ++--- .../en/books/handbook/ppp-and-slip/_index.adoc | 2 +- .../content/en/books/handbook/printing/_index.adoc | 4 +- .../en/books/handbook/serialcomms/_index.adoc | 30 +++---- .../en/books/handbook/virtualization/_index.adoc | 24 +++--- .../content/en/books/handbook/zfs/_index.adoc | 12 +-- .../books/porters-handbook/makefiles/_index.adoc | 16 ++-- .../porters-handbook/porting-dads/_index.adoc | 8 +- .../en/books/porters-handbook/special/_index.adoc | 2 +- 46 files changed, 441 insertions(+), 441 deletions(-) diff --git a/documentation/content/en/articles/building-products/_index.adoc b/documentation/content/en/articles/building-products/_index.adoc index cf50b55302..c88a93e0fb 100644 --- a/documentation/content/en/articles/building-products/_index.adoc +++ b/documentation/content/en/articles/building-products/_index.adoc @@ -118,26 +118,26 @@ For organizations, the benefits of using FreeBSD components in their products in Here are a few ways organizations have used FreeBSD: * As an upstream source for tested code for libraries and utilities. -+ ++ By being "downstream" of the project, organizations leverage the new features, bug fixes and testing that the upstream code receives. * As an embedded OS (for example, for an OEM router and firewall device). In this model, organizations use a customized FreeBSD kernel and application program set along with a proprietary management layer for their device. OEMs benefit from new hardware support being added by the FreeBSD project upstream, and from the testing that the base system receives. -+ ++ FreeBSD ships with a self-hosting development environment that allows easy creation of such configurations. * As a Unix compatible environment for the management functions of high-end storage and networking devices, running on a separate processor "blade". -+ ++ FreeBSD provides the tools for creating dedicated OS and application program images. Its implementation of a BSD unix API is mature and tested. FreeBSD can also provide a stable cross-development environment for the other components of the high-end device. * As a vehicle to get widespread testing and support from a worldwide team of developers for non-critical "intellectual property". -+ ++ In this model, organizations contribute useful infrastructural frameworks to the FreeBSD project (for example, see man:netgraph[3]). The widespread exposure that the code gets helps to quickly identify performance issues and bugs. The involvement of top-notch developers also leads to useful extensions to the infrastructure that the contributing organization also benefits from. * As a development environment supporting cross-development for embedded OSes like http://www.rtems.com/[RTEMS] and http://ecos.sourceware.org/[eCOS]. -+ ++ There are many full-fledged development environments in the {numports}-strong collection of applications ported and packaged with FreeBSD. * As a way to support a Unix-like API in an otherwise proprietary OS, increasing its palatability for application developers. -+ ++ Here parts of FreeBSD's kernel and application programs are "ported" to run alongside other tasks in the proprietary OS. The availability of a stable and well tested Unix(TM) API implementation can reduce the effort needed to port popular applications to the proprietary OS. As FreeBSD ships with high-quality documentation for its internals and has effective vulnerability management and release engineering processes, the costs of keeping up-to-date are kept low. @@ -154,12 +154,12 @@ A selection of these are listed below: * Libraries for many programming tasks: archivers, FTP and HTTP support, thread support, in addition to a full POSIX(TM) like programming environment. * Security features: Mandatory Access Control (man:mac[9]), jails (man:jail[2]), ACLs, and in-kernel cryptographic device support. * Networking features: firewall-ing, QoS management, high-performance TCP/IP networking with support for many extensions. -+ ++ FreeBSD's in-kernel Netgraph (man:netgraph[4]) framework allows kernel networking modules to be connected together in flexible ways. * Support for storage technologies: Fibre Channel, SCSI, software and hardware RAID, ATA and SATA. -+ ++ FreeBSD supports a number of filesystems, and its native UFS2 filesystem supports soft updates, snapshots and very large filesystem sizes (16TB per filesystem) <>. -+ ++ FreeBSD's in-kernel GEOM (man:geom[4]) framework allows kernel storage modules to be composed in flexible ways. * Over {numports} ported applications, both commercial and open-source, managed via the FreeBSD ports collection. diff --git a/documentation/content/en/articles/committers-guide/_index.adoc b/documentation/content/en/articles/committers-guide/_index.adoc index 1767095908..4d434552fd 100644 --- a/documentation/content/en/articles/committers-guide/_index.adoc +++ b/documentation/content/en/articles/committers-guide/_index.adoc @@ -183,7 +183,7 @@ You need a Passphrase to protect your secret key. <.> A three year key lifespan is short enough to obsolete keys weakened by advancing computer power, but long enough to reduce key management problems. <.> Use your real name here, preferably matching that shown on government-issued ID to make it easier for others to verify your identity. Text that may help others identify you can be entered in the `Comment` section. -+ ++ After the email address is entered, a passphrase is requested. Methods of creating a secure passphrase are contentious. Rather than suggest a single way, here are some links to sites that describe various methods: http://world.std.com/~reinhold/diceware.html[], http://www.iusmentis.com/security/passphrasefaq/[], http://xkcd.com/936/[], http://en.wikipedia.org/wiki/Passphrase[]. @@ -2307,22 +2307,22 @@ Those who have been given commit rights to the FreeBSD repositories must follow *Procedure 1. Steps for New Committers* . Add an Author Entity -+ ++ [.filename]#doc/shared/authors.adoc# - Add an author entity. Later steps depend on this entity, and missing this step will cause the [.filename]#doc/# build to fail. This is a relatively easy task, but remains a good first test of version control skills. . Update the List of Developers and Contributors -+ ++ [.filename]#doc/documentation/content/en/articles/contributors/contrib-committers.adoc# - Add an entry, which will then appear in the "Developers" section of the link:{contributors}#staff-committers[Contributors List]. Entries are sorted by last name. -+ ++ [.filename]#doc/documentation/content/en/articles/contributors/contrib-additional.adoc# - _Remove_ the entry. Entries are sorted by first name. . Add a News Item -+ ++ [.filename]#doc/website/data/en/news/news.toml# - Add an entry. Look for the other entries that announce new committers and follow the format. Use the date from the commit bit approval email from mailto:core@FreeBSD.org[core@FreeBSD.org]. . Add a PGP Key -+ ++ `{des}` has written a shell script ([.filename]#doc/documentation/tools/addkey.sh#) to make this easier. See the https://cgit.freebsd.org/doc/plain/documentation/static/pgpkeys/README[README] file for more information. -+ ++ Use [.filename]#doc/documentation/tools/checkkey.sh# to verify that keys meet minimal best-practices standards. -+ ++ After adding and checking a key, add both updated files to source control and then commit them. Entries in this file are sorted by last name. + [NOTE] @@ -2330,24 +2330,24 @@ After adding and checking a key, add both updated files to source control and th It is very important to have a current PGP/GnuPG key in the repository. The key may be required for positive identification of a committer. For example, the `{admins}` might need it for account recovery. A complete keyring of `FreeBSD.org` users is available for download from link:https://www.FreeBSD.org/doc/pgpkeyring.txt[https://www.FreeBSD.org/doc/pgpkeyring.txt]. ====== . Update Mentor and Mentee Information -+ ++ [.filename]#src/share/misc/committers-.dot# - Add an entry to the current committers section, where _repository_ is `doc`, `ports`, or `src`, depending on the commit privileges granted. -+ ++ Add an entry for each additional mentor/mentee relationship in the bottom section. . Generate a Kerberos Password -+ ++ See <> to generate or set a Kerberos for use with other FreeBSD services like the bug tracking database. . Optional: Enable Wiki Account -+ ++ https://wiki.freebsd.org[FreeBSD Wiki] Account - A wiki account allows sharing projects and ideas. Those who do not yet have an account can follow instructions on the https://wiki.freebsd.org/AboutWiki[AboutWiki Page] to obtain one. Contact mailto:wiki-admin@FreeBSD.org[wiki-admin@FreeBSD.org] if you need help with your Wiki account. . Optional: Update Wiki Information -+ ++ Wiki Information - After gaining access to the wiki, some people add entries to the https://wiki.freebsd.org/HowWeGotHere[How We Got Here], https://wiki.freebsd.org/IRC/Nicknames[IRC Nicks], and https://wiki.freebsd.org/Community/Dogs[Dogs of FreeBSD] pages. . Optional: Update Ports with Personal Information -+ ++ [.filename]#ports/astro/xearth/files/freebsd.committers.markers# and [.filename]#src/usr.bin/calendar/calendars/calendar.freebsd# - Some people add entries for themselves to these files to show where they are located or the date of their birthday. . Optional: Prevent Duplicate Mailings -+ ++ Subscribers to {dev-commits-doc-all}, {dev-commits-ports-all} or {dev-commits-src-all} might wish to unsubscribe to avoid receiving duplicate copies of commit messages and followups. ==== @@ -2364,7 +2364,7 @@ Subscribers to {dev-commits-doc-all}, {dev-commits-ports-all} or {dev-commits-sr ====== If your e-mail system uses SPF with strict rules, you should whitelist `mx2.FreeBSD.org` from SPF checks. ====== -+ ++ Due to the severe load dealing with SPAM places on the central mail servers that do the mailing list processing, the front-end server does do some basic checks and will drop some messages based on these checks. At the moment proper DNS information for the connecting host is the only check in place but that may change. Some people blame these checks for bouncing valid email. To have these checks turned off for your email, create a file named [.filename]#~/.spam_lover# on `freefall.FreeBSD.org`. + [NOTE] @@ -2509,7 +2509,7 @@ Sometimes code reviews will take longer than you would hope for, especially for * Ping the patch. If it is urgent, provide reasons why it is important to you to get this patch landed and ping it every couple of days. If it is not urgent, the common courtesy ping rate is one week. Remember that you are asking for valuable time from other professional developers. * Ask for help on mailing lists, IRC, etc. Others may be able to either help you directly, or suggest a reviewer. * Split your patch into multiple smaller patches that build on each other. The smaller your patch, the higher the probability that somebody will take a quick look at it. -+ ++ When making large changes, it is helpful to keep this in mind from the beginning of the effort as breaking large changes into smaller ones is often difficult after the fact. Developers should participate in code reviews as both reviewers and reviewees. @@ -3168,23 +3168,23 @@ As individuals, the core team members are all committers first and core second. [[respect]] . Respect other committers. -+ ++ This means that you need to treat other committers as the peer-group developers that they are. Despite our occasional attempts to prove the contrary, one does not get to be a committer by being stupid and nothing rankles more than being treated that way by one of your peers. Whether we always feel respect for one another or not (and everyone has off days), we still have to _treat_ other committers with respect at all times, on public forums and in private email. -+ ++ Being able to work together long term is this project's greatest asset, one far more important than any set of changes to the code, and turning arguments about code into issues that affect our long-term ability to work harmoniously together is just not worth the trade-off by any conceivable stretch of the imagination. -+ ++ To comply with this rule, do not send email when you are angry or otherwise behave in a manner which is likely to strike others as needlessly confrontational. First calm down, then think about how to communicate in the most effective fashion for convincing the other persons that your side of the argument is correct, do not just blow off some steam so you can feel better in the short term at the cost of a long-term flame war. Not only is this very bad "energy economics", but repeated displays of public aggression which impair our ability to work well together will be dealt with severely by the project leadership and may result in suspension or termination of your commit privileges. The project leadership will take into account both public and private communications brought before it. It will not seek the disclosure of private communications, but it will take it into account if it is volunteered by the committers involved in the complaint. -+ ++ All of this is never an option which the project's leadership enjoys in the slightest, but unity comes first. No amount of code or good advice is worth trading that away. . Respect other contributors. -+ ++ You were not always a committer. At one time you were a contributor. Remember that at all times. @@ -3196,40 +3196,40 @@ They are every bit as important to the project as committers. Their contributions are as valid and as important as your own. After all, you made many contributions before you became a committer. Always remember that. -+ ++ Consider the points raised under <> and apply them also to contributors. . Discuss any significant change _before_ committing. -+ ++ The repository is not where changes are initially submitted for correctness or argued over, that happens first in the mailing lists or by use of the Phabricator service. The commit will only happen once something resembling consensus has been reached. This does not mean that permission is required before correcting every obvious syntax error or manual page misspelling, just that it is good to develop a feel for when a proposed change is not quite such a no-brainer and requires some feedback first. People really do not mind sweeping changes if the result is something clearly better than what they had before, they just do not like being _surprised_ by those changes. The very best way of making sure that things are on the right track is to have code reviewed by one or more other committers. -+ ++ When in doubt, ask for review! . Respect existing maintainers if listed. -+ ++ Many parts of FreeBSD are not "owned" in the sense that any specific individual will jump up and yell if you commit a change to "their" area, but it still pays to check first. One convention we use is to put a maintainer line in the [.filename]#Makefile# for any package or subtree which is being actively maintained by one or more people; see link:{developers-handbook}#policies[Source Tree Guidelines and Policies] for documentation on this. Where sections of code have several maintainers, commits to affected areas by one maintainer need to be reviewed by at least one other maintainer. In cases where the "maintainer-ship" of something is not clear, look at the repository logs for the files in question and see if someone has been working recently or predominantly in that area. . Any disputed change must be backed out pending resolution of the dispute if requested by a maintainer. Security related changes may override a maintainer's wishes at the Security Officer's discretion. -+ ++ This may be hard to swallow in times of conflict (when each side is convinced that they are in the right, of course) but a version control system makes it unnecessary to have an ongoing dispute raging when it is far easier to simply reverse the disputed change, get everyone calmed down again and then try to figure out what is the best way to proceed. If the change turns out to be the best thing after all, it can be easily brought back. If it turns out not to be, then the users did not have to live with the bogus change in the tree while everyone was busily debating its merits. People _very_ rarely call for back-outs in the repository since discussion generally exposes bad or controversial changes before the commit even happens, but on such rare occasions the back-out should be done without argument so that we can get immediately on to the topic of figuring out whether it was bogus or not. . Changes go to FreeBSD-CURRENT before FreeBSD-STABLE unless specifically permitted by the release engineer or unless they are not applicable to FreeBSD-CURRENT. Any non-trivial or non-urgent change which is applicable should also be allowed to sit in FreeBSD-CURRENT for at least 3 days before merging so that it can be given sufficient testing. The release engineer has the same authority over the FreeBSD-STABLE branch as outlined in rule #5. -+ ++ This is another "do not argue about it" issue since it is the release engineer who is ultimately responsible (and gets beaten up) if a change turns out to be bad. Please respect this and give the release engineer your full cooperation when it comes to the FreeBSD-STABLE branch. The management of FreeBSD-STABLE may frequently seem to be overly conservative to the casual observer, but also bear in mind the fact that conservatism is supposed to be the hallmark of FreeBSD-STABLE and different rules apply there than in FreeBSD-CURRENT. There is also really no point in having FreeBSD-CURRENT be a testing ground if changes are merged over to FreeBSD-STABLE immediately. Changes need a chance to be tested by the FreeBSD-CURRENT developers, so allow some time to elapse before merging unless the FreeBSD-STABLE fix is critical, time sensitive or so obvious as to make further testing unnecessary (spelling fixes to manual pages, obvious bug/typo fixes, etc.) In other words, apply common sense. -+ ++ Changes to the security branches (for example, `releng/9.3`) must be approved by a member of the `{security-officer}`, or in some cases, by a member of the `{re}`. . Do not fight in public with other committers; it looks bad. -+ ++ This project has a public image to uphold and that image is very important to all of us, especially if we are to continue to attract new members. There will be occasions when, despite everyone's very best attempts at self-control, tempers are lost and angry words are exchanged. The best thing that can be done in such cases is to minimize the effects of this until everyone has cooled back down. @@ -3240,16 +3240,16 @@ If you feel you are being unfairly treated by another developer, and it is causi In cases where the dispute involves a change to the codebase and the participants do not appear to be reaching an amicable agreement, core may appoint a mutually-agreeable third party to resolve the dispute. All parties involved must then agree to be bound by the decision reached by this third party. . Respect all code freezes and read the `committers` and `developers` mailing list on a timely basis so you know when a code freeze is in effect. -+ ++ Committing unapproved changes during a code freeze is a really big mistake and committers are expected to keep up-to-date on what is going on before jumping in after a long absence and committing 10 megabytes worth of accumulated stuff. People who abuse this on a regular basis will have their commit privileges suspended until they get back from the FreeBSD Happy Reeducation Camp we run in Greenland. . When in doubt on any procedure, ask first! -+ ++ Many mistakes are made because someone is in a hurry and just assumes they know the right way of doing something. If you have not done it before, chances are good that you do not actually know the way we do things and really need to ask first or you are going to completely embarrass yourself in public. There is no shame in asking "how in the heck do I do this?" We already know you are an intelligent person; otherwise, you would not be a committer. . Test your changes before committing them. -+ ++ This may sound obvious, but if it really were so obvious then we probably would not see so many cases of people clearly not doing this. If your changes are to the kernel, make sure you can still compile both GENERIC and LINT. If your changes are anywhere else, make sure you can still make world. @@ -3258,18 +3258,18 @@ If you have a change which also may break another architecture, be sure and test Please refer to the https://www.FreeBSD.org/internal/[FreeBSD Internal Page] for a list of available resources. As other architectures are added to the FreeBSD supported platforms list, the appropriate shared testing resources will be made available. . Do not commit to contributed software without _explicit_ approval from the respective maintainers. -+ ++ Contributed software is anything under the [.filename]#src/contrib#, [.filename]#src/crypto#, or [.filename]#src/sys/contrib# trees. -+ ++ The trees mentioned above are for contributed software usually imported onto a vendor branch. Committing something there may cause unnecessary headaches when importing newer versions of the software. As a general consider sending patches upstream to the vendor. Patches may be committed to FreeBSD first with permission of the maintainer. -+ ++ Reasons for modifying upstream software range from wanting strict control over a tightly coupled dependency to lack of portability in the canonical repository's distribution of their code. Regardless of the reason, effort to minimize the maintenance burden of fork is helpful to fellow maintainers. Avoid committing trivial or cosmetic changes to files since it makes every merge thereafter more difficult: such patches need to be manually re-verified every import. -+ ++ If a particular piece of software lacks a maintainer, you are encouraged to take up ownership. If you are unsure of the current maintainership email {freebsd-arch} and ask. @@ -3315,42 +3315,42 @@ When it is necessary to remove functionality from software in the base system, f === Privacy and Confidentiality . Most FreeBSD business is done in public. -+ ++ FreeBSD is an _open_ project. Which means that not only can anyone use the source code, but that most of the development process is open to public scrutiny. . Certain sensitive matters must remain private or held under embargo. -+ ++ There unfortunately cannot be complete transparency. As a FreeBSD developer you will have a certain degree of privileged access to information. Consequently you are expected to respect certain requirements for confidentiality. Sometimes the need for confidentiality comes from external collaborators or has a specific time limit. Mostly though, it is a matter of not releasing private communications. . The Security Officer has sole control over the release of security advisories. -+ ++ Where there are security problems that affect many different operating systems, FreeBSD frequently depends on early access to be able to prepare advisories for coordinated release. Unless FreeBSD developers can be trusted to maintain security, such early access will not be made available. The Security Officer is responsible for controlling pre-release access to information about vulnerabilities, and for timing the release of all advisories. He may request help under condition of confidentiality from any developer with relevant knowledge to prepare security fixes. . Communications with Core are kept confidential for as long as necessary. -+ ++ Communications to core will initially be treated as confidential. Eventually however, most of Core's business will be summarized into the monthly or quarterly core reports. Care will be taken to avoid publicising any sensitive details. Records of some particularly sensitive subjects may not be reported on at all and will be retained only in Core's private archives. . Non-disclosure Agreements may be required for access to certain commercially sensitive data. -+ ++ Access to certain commercially sensitive data may only be available under a Non-Disclosure Agreement. The FreeBSD Foundation legal staff must be consulted before any binding agreements are entered into. . Private communications must not be made public without permission. -+ ++ Beyond the specific requirements above there is a general expectation not to publish private communications between developers without the consent of all parties involved. Ask permission before forwarding a message onto a public mailing list, or posting it to a forum or website that can be accessed by other than the original correspondents. . Communications on project-only or restricted access channels must be kept private. -+ ++ Similarly to personal communications, certain internal communications channels, including FreeBSD Committer only mailing lists and restricted access IRC channels are considered private communications. Permission is required to publish material from these sources. . Core may approve publication. -+ ++ Where it is impractical to obtain permission due to the number of correspondents or where permission to publish is unreasonably withheld, Core may approve release of such private matters that merit more general publication. [[archs]] diff --git a/documentation/content/en/articles/contributing/_index.adoc b/documentation/content/en/articles/contributing/_index.adoc index 2f4c6e20a5..4692420631 100644 --- a/documentation/content/en/articles/contributing/_index.adoc +++ b/documentation/content/en/articles/contributing/_index.adoc @@ -336,20 +336,20 @@ More information about upgrading a port is available in the link:{porters-handbo [.procedure] ==== . Watch for updates -+ ++ Monitor the upstream vendor for new versions, updates and security fixes for the software. Announcement mailing lists or news web pages are useful for doing this. Sometimes users will contact you and ask when your port will be updated. If you are busy with other things or for any reason just cannot update it at the moment, ask if they will help you by submitting an update. -+ ++ You may also receive automated email from the `FreeBSD Ports Version Check` informing you that a newer version of your port's distfile is available. More information about that system (including how to stop future emails) will be provided in the message. . Incorporate changes -+ ++ When they become available, incorporate the changes into the port. You need to be able to generate a patch between the original port and your updated port. . Review and test -+ ++ Thoroughly review and test your changes: ** Build, install and test your port on as many platforms and architectures as you can. It is common for a port to work on one branch or platform and fail on another. @@ -359,7 +359,7 @@ Thoroughly review and test your changes: ** Consider whether changes to your port might cause any other ports to break. If this is the case, coordinate the changes with the maintainers of those ports. This is especially important if your update changes the shared library version; in this case, at the very least, the dependent ports will need to get a `PORTREVISION` bump so that they will automatically be upgraded by automated tools such as portmaster or man:portupgrade[1]. . Submit changes -+ ++ Send your update by submitting a PR with an explanation of the changes and a patch containing the differences between the original port and the updated one. Please refer to link:{problem-reports}[Writing FreeBSD Problem Reports] for information on how to write a really good PR. + @@ -370,15 +370,15 @@ In this way, committers can much more easily see exactly what changes are being The Porter's Handbook section on link:{porters-handbook}#port-upgrading[Upgrading] has more information. ====== . Wait -+ ++ At some stage a committer will deal with your PR. It may take minutes, or it may take weeks - so please be patient. . Give feedback -+ ++ If a committer finds a problem with your changes, they will most likely refer it back to you. A prompt response will help get your PR committed faster, and is better for maintaining a thread of conversation when trying to resolve any problems. . And Finally -+ ++ Your changes will be committed and your port will have been updated. The PR will then be closed by the committer. That's it! ==== @@ -405,10 +405,10 @@ These are the tasks you need to perform to ensure your port is able to be built: [.procedure] ==== . Watch for build failures -+ ++ Check your mail for mail from `pkg-fallout@FreeBSD.org` and the http://portscout.FreeBSD.org[distfiles scanner] to see if any of the port which are failing to build are out of date. . Collect information -+ ++ Once you are aware of a problem, collect information to help you fix it. Build errors reported by `pkg-fallout` are accompanied by logs which will show you where the build failed. If the failure was reported to you by a user, ask them to send you information which may help in diagnosing the problem, such as: @@ -421,14 +421,14 @@ If the failure was reported to you by a user, ask them to send you information w ** When their ports tree and [.filename]#INDEX# was last updated . Investigate and find a solution -+ ++ Unfortunately there is no straightforward process to follow to do this. Remember, though: if you are stuck, ask for help! The {freebsd-ports} is a good place to start, and the upstream developers are often very helpful. . Submit changes -+ ++ Just as with updating a port, you should now incorporate changes, review and test, submit your changes in a PR, and provide feedback if required. . Send patches to upstream authors -+ ++ In some cases, you will have to make patches to the port to make it run on FreeBSD. Some (but not all) upstream authors will accept such patches back into their code for the next release. If so, this may even help their users on other BSD-based systems as well and perhaps save duplicated effort. @@ -447,18 +447,18 @@ These are the tasks you need to perform to ensure your port continues to work as [.procedure] ==== . Respond to bug reports -+ ++ Bugs may be reported to you through email via the https://bugs.FreeBSD.org/search/[Problem Report database]. Bugs may also be reported directly to you by users. -+ ++ You should respond to PRs and other reports within 14 days, but please try not to take that long. Try to respond as soon as possible, even if it is just to say you need some more time before you can work on the PR. -+ ++ If you have not responded after 14 days, any committer may commit from a PR that you have not responded to via a `maintainer-timeout`. . Collect information -+ ++ If the person reporting the bug has not also provided a fix, you need to collect the information that will allow you to generate one. -+ ++ If the bug is reproducible, you can collect most of the required information yourself. If not, ask the person who reported the bug to collect the information for you, such as: @@ -469,18 +469,18 @@ If not, ask the person who reported the bug to collect the information for you, ** Stack traces . Eliminate incorrect reports -+ ++ Some bug reports may be incorrect. For example, the user may have simply misused the program; or their installed packages may be out of date and require updating. Sometimes a reported bug is not specific to FreeBSD. In this case report the bug to the upstream developers. If the bug is within your capabilities to fix, you can also patch the port so that the fix is applied before the next upstream release. . Find a solution -+ ++ As with build errors, you will need to sort out a fix to the problem. Again, remember to ask if you are stuck! . Submit or approve changes -+ ++ Just as with updating a port, you should now incorporate changes, review and test, and submit your changes in a PR (or send a follow-up if a PR already exists for the problem). If another user has submitted changes in the PR, you can also send a follow-up saying whether or not you approve the changes. ==== diff --git a/documentation/content/en/articles/contributors/_index.adoc b/documentation/content/en/articles/contributors/_index.adoc index 5309b2b062..12ddc082bd 100644 --- a/documentation/content/en/articles/contributors/_index.adoc +++ b/documentation/content/en/articles/contributors/_index.adoc @@ -62,7 +62,7 @@ The following individuals and businesses made it possible for the FreeBSD Projec ** Ulf Zimmermann mailto:ulf@Alameda.net[ulf@Alameda.net] of http://www.Alameda.net/[Alameda Networks] donated _128MB of memory_, a _4 Gb disk drive and the case._ * _Direct funding:_ -+ ++ The following individuals and businesses have generously contributed direct funding to the project: ** Annelise Anderson mailto:ANDRSN@HOOVER.STANFORD.EDU[ANDRSN@HOOVER.STANFORD.EDU] @@ -88,7 +88,7 @@ The following individuals and businesses have generously contributed direct fund ** Chris Silva mailto:ras@interaccess.com[ras@interaccess.com] * _Hardware contributors:_ -+ ++ The following individuals and businesses have generously contributed hardware for testing and device driver development/support: ** BSDi for providing the Pentium P5-90 and 486/DX2-66 EISA/VL systems that are being used for our development work, to say nothing of the network access and other donations of hardware resources. diff --git a/documentation/content/en/articles/contributors/contrib-develinmemoriam.adoc b/documentation/content/en/articles/contributors/contrib-develinmemoriam.adoc index 943213810b..84c5e2af05 100644 --- a/documentation/content/en/articles/contributors/contrib-develinmemoriam.adoc +++ b/documentation/content/en/articles/contributors/contrib-develinmemoriam.adoc @@ -1,60 +1,60 @@ * Bruce D. Evans (1991 - 2019; RIP 2019) -+ ++ Bruce was a programming giant who made FreeBSD his home. -+ ++ Back before FreeBSD and Linux there was Minix, a toy "unix" written by Andy Tannenbaum, released in 1987, sold with complete sources on three floppy disks, for $99. -+ ++ Bruce ported Minix to the i386 around 1989. -+ ++ Linus Torvalds used Minix/386 to develop his own kernel, and Bruce was the first person he thanked in the release-announcement. -+ ++ When Bill Jolitz released 386BSD 0.1 in 1992, Bruce was listed as a contributor. -+ ++ Bruce co-founded the FreeBSD project, and served on core.0, but he was never partisan, and over the years many other projects have benefitted from his patches, advice and wisdom. -+ ++ Code reviews from Bruce came in three flavours, "mild", "brucified" and "brucifiction", but they were never personal: It was always only about the code, the mistakes, the sloppy thinking, the missing historical context, the ambiguous standards - and the style(9) transgressions. -+ ++ As Bruce gave more code reviews than anybody else in the history of the FreeBSD project, the commit logs hide the true scale of his impact until you pay attention to "Submitted by", "Reviewed by" and "Pointed out by". -+ ++ Being hard of hearing, Bruce did not attend conferences. -+ ++ The notable exception was the 1999 BSDcon in California, where his core team colleagues greeted him with "We're not worthy!" in Wayne's World fashion. -+ ++ Twenty years later we're still not. * Kurt Lidl (2015 - 2019; RIP 2019) -+ ++ Kurt first got involved with BSD while it was still a project at the University of California at Berkeley. Shortly after personalized license plates became available in Maryland, he got "BSDWZRD". -+ ++ He began contributing to FreeBSD shortly after the conception of the project. He became a FreeBSD source committer in October 2015. -+ ++ Kurt's most well known FreeBSD project was man:blacklistd[8] which blocks and releases ports on demand to avoid DoS abuse. He has also made many other bug fixes and enhancements to DTrace, boot loaders, and other bits and pieces of the FreeBSD infrastructure. -+ ++ Earlier work included the game XTank, an author on RFC 2516 https://tools.ietf.org/html/rfc2516["A Method for Transmitting PPP Over Ethernet (PPPoE)"], and the USENIX paper https://www.usenix.org/conference/usenix-winter-1994-technical-conference/drinking-firehose-multicast-usenet-news["Drinking from the Firehose: Multicast USENET News"]. * Frank Durda IV (1995 - 2003; RIP 2018) -+ ++ Frank had been around the project since the very early days, contributing code to the 1.x line before becoming a committer. * Andrey A. Chernov (1993 - 2017; RIP 2017) -+ ++ Andrey contributions to FreeBSD can not be overstated. Having been involved for a long there is hardly an area which he did not touch. * Jürgen Lock (2006 - 2015; RIP 2015) -+ ++ Jürgen made a number of contributions to FreeBSD, including work on libvirt, the graphics stack, and QEMU. Jürgen's contributions and helpfulness were appreciated by people around the world. That work continues to improve the lives of thousands every day. * {alexbl} (2006 - 2011; RIP 2012) -+ ++ http://www.legacy.com/obituaries/sfgate/obituary.aspx?pid=159801494[Alexander] was best known as a major contributor to FreeBSD's Python ports and a founding member of {python} as well as his work on XMMS2. * {jb} (1997 - 2009; RIP 2009) -+ ++ http://hub.opensolaris.org/bin/view/Community+Group+ogb/In+Memoriam[John] made major contributions to FreeBSD, the best known of which is the import of the man:dtrace[1] code. John's unique sense of humor and plain-spokenness either ruffled feathers or made him quick friends. At the end of his life, he had moved to a rural area and was attempting to live with as minimal impact to the planet as possible, while at the same time still working in the high-tech area. * {jmz} (1994 - 2009; RIP 2009) -+ ++ http://www.obs-besancon.fr/article.php3?id_article=323[Jean-Marc] was an astrophysicist who made important contributions to the modeling of the atmospheres of both planets and comets at http://www.obs-besancon.fr/[l'Observatoire de Besançon] in Besançon, France. While there, he participated in the conception and construction of the Vega tricanal spectrometer that studied Halley's Comet. He had also been a long-time contributor to FreeBSD. * {itojun} (1997 - 2001; RIP 2008) -+ ++ Known to everyone as http://astralblue.livejournal.com/350702.html[itojun], Jun-ichiro Hagino was a core researcher at the http://www.kame.net/[KAME Project], which aimed to provide IPv6 and IPsec technology in freely redistributable form. Much of this code was incorporated into FreeBSD. Without his efforts, the state of IPv6 on the Internet would be much different. * {cg} (1999 - 2005; RIP 2005) -+ ++ http://www.dbsi.org/cam/[Cameron] was a unique individual who contributed to the project despite serious physical disabilities. He was responsible for a complete rewrite of our sound system during the late 1990s. Many of those who corresponded with him had no idea of his limited mobility, due to his cheerful spirit and willingness to help others. * {alane} (2002 - 2003; RIP 2003) -+ ++ http://freebsd.kde.org/memoriam/alane.php[Alan] was a major contributor to the KDE on FreeBSD group. In addition, he maintained many other difficult and time-consuming ports such as autoconf, CUPS, and python. Alan's path was not an easy one but his passion for FreeBSD, and dedication to programming excellence, won him many friends. diff --git a/documentation/content/en/articles/explaining-bsd/_index.adoc b/documentation/content/en/articles/explaining-bsd/_index.adoc index ed3c4cd7a7..a8f6359fb7 100644 --- a/documentation/content/en/articles/explaining-bsd/_index.adoc +++ b/documentation/content/en/articles/explaining-bsd/_index.adoc @@ -42,13 +42,13 @@ The overall operating system comprises: * The BSD kernel, which handles process scheduling, memory management, symmetric multi-processing (SMP), device drivers, etc. * The C library, the base API for the system. -+ ++ __The BSD C library is based on code from Berkeley, not the GNU project.__ * Utilities such as shells, file utilities, compilers and linkers. -+ ++ __Some of the utilities are derived from the GNU project, others are not.__ * The X Window system, which handles graphical display. -+ ++ The X Window system used in most versions of BSD is maintained by the http://www.X.org/[X.Org project]. FreeBSD allows the user to choose from a variety of desktop environments, such as Gnome, KDE, or Xfce; and lightweight window managers like Openbox, Fluxbox, or Awesome. * Many other programs and utilities. @@ -96,7 +96,7 @@ For a number of reasons, BSD is relatively unknown: . The BSD developers are often more interested in polishing their code than marketing it. . Much of Linux's popularity is due to factors external to the Linux projects, such as the press, and to companies formed to provide Linux services. Until recently, the open source BSDs had no such proponents. . In 1992, AT&T sued http://www.bsdi.com/[BSDI], the vendor of BSD/386, alleging that the product contained AT&T-copyrighted code. The case was settled out of court in 1994, but the spectre of the litigation continues to haunt people. In March 2000 an article published on the web claimed that the court case had been "recently settled". -+ ++ One detail that the lawsuit did clarify is the naming: in the 1980s, BSD was known as "BSD UNIX(R)". With the elimination of the last vestige of AT&T code from BSD, it also lost the right to the name UNIX(R). Thus you will see references in book titles to "the 4.3BSD UNIX(R) operating system" and "the 4.4BSD operating system". @@ -126,7 +126,7 @@ They are divided into three kinds: * _Contributors_ write code or documentation. They are not permitted to commit (add code) directly to the source tree. In order for their code to be included in the system, it must be reviewed and checked in by a registered developer, known as a __committer__. * _Committers_ are developers with write access to the source tree. In order to become a committer, an individual must show ability in the area in which they are active. -+ ++ It is at the individual committer's discretion whether they should obtain authority before committing changes to the source tree. In general, an experienced committer may make changes which are obviously correct without obtaining consensus. For example, a documentation project committer may correct typographical or grammatical errors without review. diff --git a/documentation/content/en/articles/fonts/_index.adoc b/documentation/content/en/articles/fonts/_index.adoc index 10a72252b0..8ff9e387a9 100644 --- a/documentation/content/en/articles/fonts/_index.adoc +++ b/documentation/content/en/articles/fonts/_index.adoc @@ -495,12 +495,12 @@ Once all these utilities are in place, you are ready to commence: .... % gs -dNODISPLAY -q -- ttf2pf.ps TTF_name PS_font_name AFM_name .... -+ ++ Where, _TTF_name_ is your TrueType font file, _PS_font_name_ is the file name for [.filename]#.pfa#, _AFM_name_ is the name you wish for [.filename]#.afm#. If you do not specify output file names for the [.filename]#.pfa# or [.filename]#.afm# files, then default names will be generated from the TrueType font file name. -+ ++ This also produces a [.filename]#.pfa#, the ascii PostScript font metrics file ([.filename]#.pfb# is for the binary form). This will not be needed, but could (I think) be useful for a fontserver. -+ ++ For example, to convert the 30f9 Barcode font using the default file names, use the following command: + [source,shell] @@ -511,7 +511,7 @@ Copyright (C) 1997 Aladdin Enterprises, Menlo Park, CA. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Converting 3of9.ttf to 3of9.pfa and 3of9.afm. .... -+ ++ If you want the converted fonts to be stored in [.filename]#A.pfa# and [.filename]#B.afm#, then use this command: + [source,shell] @@ -524,7 +524,7 @@ Converting 3of9.ttf to A.pfa and B.afm. .... . Create the groff PostScript file: -+ ++ Change directories to [.filename]#/usr/share/groff_font/devps# so as to make the following command easier to execute. You will probably need root privileges for this. (Or, if you are paranoid about working there, make sure you reference the files [.filename]#DESC#, [.filename]#text.enc# and [.filename]#generate/textmap# as being in this directory.) @@ -533,7 +533,7 @@ You will probably need root privileges for this. .... % afmtodit -d DESC -e text.enc file.afm generate/textmap PS_font_name .... -+ ++ Where, [.filename]#file.afm# is the _AFM_name_ created by `ttf2pf.ps` above, and _PS_font_name_ is the font name used from that command, as well as the name that man:groff[1] will use for references to this font. For example, assuming you used the first `tiff2pf.ps` above, then the 3of9 Barcode font can be created using the command: + @@ -541,9 +541,9 @@ For example, assuming you used the first `tiff2pf.ps` above, then the 3of9 Barco .... % afmtodit -d DESC -e text.enc 3of9.afm generate/textmap 3of9 .... -+ ++ Ensure that the resulting _PS_font_name_ file (e.g., [.filename]#3of9# in the example above) is located in the directory [.filename]#/usr/share/groff_font/devps# by copying or moving it there. -+ ++ Note that if [.filename]#ttf2pf.ps# assigns a font name using the one it finds in the TrueType font file and you want to use a different name, you must edit the [.filename]#.afm# prior to running `afmtodit`. This name must also match the one used in the Fontmap file if you wish to pipe man:groff[1] into man:gs[1]. diff --git a/documentation/content/en/articles/freebsd-questions/_index.adoc b/documentation/content/en/articles/freebsd-questions/_index.adoc index 1edcd2ecf0..ba81c5ce28 100644 --- a/documentation/content/en/articles/freebsd-questions/_index.adoc +++ b/documentation/content/en/articles/freebsd-questions/_index.adoc @@ -165,10 +165,10 @@ When submitting a question to FreeBSD-questions, consider the following points: * Remember that nobody gets paid for answering a FreeBSD question. They do it of their own free will. You can influence this free will positively by submitting a well-formulated question supplying as much relevant information as possible. You can influence this free will negatively by submitting an incomplete, illegible, or rude question. It is perfectly possible to send a message to FreeBSD-questions and not get an answer even if you follow these rules. It is much more possible to not get an answer if you do not. In the rest of this document, we will look at how to get the most out of your question to FreeBSD-questions. * Not everybody who answers FreeBSD questions reads every message: they look at the subject line and decide whether it interests them. Clearly, it is in your interest to specify a subject. "FreeBSD problem" or "Help" are not enough. If you provide no subject at all, many people will not bother reading it. If your subject is not specific enough, the people who can answer it may not read it. * Format your message so that it is legible, and PLEASE DO NOT SHOUT!!!!!. We appreciate that a lot of people do not speak English as their first language, and we try to make allowances for that, but it is really painful to try to read a message written full of typos or without any line breaks. -+ ++ Do not underestimate the effect that a poorly formatted mail message has, not just on the FreeBSD-questions mailing list. Your mail message is all people see of you, and if it is poorly formatted, one line per paragraph, badly spelt, or full of errors, it will give people a poor impression of you. -+ ++ A lot of badly formatted messages come from http://www.lemis.com/email.html[bad mailers or badly configured mailers]. The following mailers are known to send out badly formatted messages without you finding out about them: @@ -176,7 +176,7 @@ The following mailers are known to send out badly formatted messages without you ** exmh ** Microsoft(R) Exchange ** Microsoft(R) Outlook(R) -+ ++ Try not to use MIME: a lot of people use mailers which do not get on very well with MIME. * Make sure your time and time zone are set correctly. This may seem a little silly, since your message still gets there, but many of the people you are trying to reach get several hundred messages a day. They frequently sort the incoming messages by subject and by date, and if your message does not come before the first answer, they may assume they missed it and not bother to look. * Do not include unrelated questions in the same message. Firstly, a long message tends to scare people off, and secondly, it is more difficult to get all the people who can answer all the questions to read the message. @@ -184,7 +184,7 @@ Try not to use MIME: a lot of people use mailers which do not get on very well w ** In nearly every case, it is important to know the version of FreeBSD you are running. This is particularly the case for FreeBSD-CURRENT, where you should also specify the date of the sources, though of course you should not be sending questions about -CURRENT to FreeBSD-questions. ** With any problem which _could_ be hardware related, tell us about your hardware. In case of doubt, assume it is possible that it is hardware. What kind of CPU are you using? How fast? What motherboard? How much memory? What peripherals? -+ ++ There is a judgement call here, of course, but the output of the man:dmesg[8] command can frequently be very useful, since it tells not just what hardware you are running, but what version of FreeBSD as well. ** If you get error messages, do not say "I get error messages", say (for example) "I get the error message 'No route to host'". ** If your system panics, do not say "My system panicked", say (for example) "my system panicked with the message 'free vnode isn't'". @@ -197,7 +197,7 @@ There is a judgement call here, of course, but the output of the man:dmesg[8] co .... % dmesg > /tmp/dmesg.out .... -+ ++ This redirects the information to the file [.filename]#/tmp/dmesg.out#. * If you do all this, and you still do not get an answer, there could be other reasons. For example, the problem is so complicated that nobody knows the answer, or the person who does know the answer was offline. If you do not get an answer after, say, a week, it might help to re-send the message. If you do not get an answer to your second message, though, you are probably not going to get one from this forum. Resending the same message again and again will only make you unpopular. @@ -249,7 +249,7 @@ Before you answer a question to FreeBSD-questions, consider: . A lot of the points on submitting questions also apply to answering questions. Read them. . Has somebody already answered the question? The easiest way to check this is to sort your incoming mail by subject: then (hopefully) you will see the question followed by any answers, all together. -+ ++ If somebody has already answered it, it does not automatically mean that you should not send another answer. But it makes sense to read all the other answers first. . Do you have something to contribute beyond what has already been said? In general, "Yeah, me too" answers do not help much, although there are exceptions, like when somebody is describing a problem they are having, and they do not know whether it is their fault or whether there is something wrong with the hardware or software. If you do send a "me too" answer, you should also include any further relevant information. @@ -261,9 +261,9 @@ But it makes sense to read all the other answers first. . Put your response in the correct place (after the text to which it replies). It is very difficult to read a thread of responses where each reply comes before the text to which it replies. . Most mailers change the subject line on a reply by prepending a text such as "Re: ". If your mailer does not do it automatically, you should do it manually. . If the submitter did not abide by format conventions (lines too long, inappropriate subject line) _please_ fix it. In the case of an incorrect subject line (such as "HELP!!??"), change the subject line to (say) "Re: Difficulties with sync PPP (was: HELP!!??)". That way other people trying to follow the thread will have less difficulty following it. -+ ++ In such cases, it is appropriate to say what you did and why you did it, but try not to be rude. If you find you can not answer without being rude, do not answer. -+ ++ If you just want to reply to a message because of its bad format, just reply to the submitter, not to the list. You can just send him this message in reply, if you like. diff --git a/documentation/content/en/articles/freebsd-releng/_index.adoc b/documentation/content/en/articles/freebsd-releng/_index.adoc index 728ec196c6..d133116fae 100644 --- a/documentation/content/en/articles/freebsd-releng/_index.adoc +++ b/documentation/content/en/articles/freebsd-releng/_index.adoc @@ -631,10 +631,10 @@ However, a given combination from the list will only be built if the respective There are two paths of file sourcing: * [.filename]#builds-12.conf# - [.filename]#main.conf# -+ ++ This controls [.filename]#thermite.sh# behavior * [.filename]#12-amd64-GENERIC-snap.conf# - [.filename]#defaults-12.conf# - [.filename]#main.conf# -+ ++ This controls [.filename]#release/release.sh# behavior within the build [NOTE] @@ -745,7 +745,7 @@ This section describes the procedure to publish FreeBSD development snapshots an Staging FreeBSD snapshots and releases is a two part process: * Creating the directory structure to match the hierarchy on `ftp-master` -+ ++ If `EVERYTHINGISFINE` is defined in the build configuration files, [.filename]#main.conf# in the case of the build scripts referenced above, this happens automatically in the after the build is complete, creating the directory structure in [.filename]#${DESTDIR}/R/ftp-stage# with a path structure matching what is expected on `ftp-master`. This is equivalent to running the following in the directly: + @@ -753,10 +753,10 @@ This is equivalent to running the following in the directly: .... # make -C /usr/src/release -f Makefile.mirrors EVERYTHINGISFINE=1 ftp-stage .... -+ ++ After each architecture is built, [.filename]#thermite.sh# will rsync the [.filename]#${DESTDIR}/R/ftp-stage# from the build to [.filename]#/snap/ftp/snapshots# or [.filename]#/snap/ftp/releases# on the build host, respectively. * Copying the files to a staging directory on `ftp-master` before moving the files into [.filename]#pub/# to begin propagation to the Project mirrors -+ ++ Once all builds have finished, [.filename]#/snap/ftp/snapshots#, or [.filename]#/snap/ftp/releases# for a release, is polled by `ftp-master` using rsync to [.filename]#/archive/tmp/snapshots# or [.filename]#/archive/tmp/releases#, respectively. + [NOTE] diff --git a/documentation/content/en/articles/mailing-list-faq/_index.adoc b/documentation/content/en/articles/mailing-list-faq/_index.adoc index 5f3322f29f..d70b735075 100644 --- a/documentation/content/en/articles/mailing-list-faq/_index.adoc +++ b/documentation/content/en/articles/mailing-list-faq/_index.adoc @@ -129,7 +129,7 @@ Always keep in mind that almost all of the work done on FreeBSD is done by volun * Please respect the fact that bandwidth is not infinite. Not everyone reads email through high-speed connections, so if your posting involves something like the content of [.filename]#config.log# or an extensive stack trace, please consider putting that information up on a website somewhere and just provide a URL to it. Remember, too, that these postings will be archived indefinitely, so huge postings will simply inflate the size of the archives long after their purpose has expired. * Format your message so that it is legible, and PLEASE DO NOT SHOUT!!!!!. Do not underestimate the effect that a poorly formatted mail message has, and not just on the FreeBSD mailing lists. Your mail message is all that people see of you, and if it is poorly formatted, badly spelled, full of errors, and/or has lots of exclamation points, it will give people a poor impression of you. * Please use an appropriate human language for a particular mailing list. Many non-English mailing lists are link:https://www.FreeBSD.org/community/mailinglists/[available]. -+ ++ For the ones that are not, we do appreciate that many people do not speak English as their first language, and we try to make allowances for that. It is considered particularly poor form to criticize non-native speakers for spelling or grammatical errors. FreeBSD has an excellent track record in this regard; please, help us to uphold that tradition. @@ -138,7 +138,7 @@ FreeBSD has an excellent track record in this regard; please, help us to uphold ** exmh ** Microsoft(R) Exchange ** Microsoft(R) Outlook(R) -+ ++ Try not to use MIME: a lot of people use mailers which do not get on very well with MIME. * Make sure your time and time zone are set correctly. This may seem a little silly, since your message still gets there, but many of the people on these mailing lists get several hundred messages a day. They frequently sort the incoming messages by subject and by date, and if your message does not come before the first answer, they may assume that they missed it and not bother to look. * A lot of the information you need to supply is the output of programs, such as man:dmesg[8], or console messages, which usually appear in [.filename]#/var/log/messages#. Do not try to copy this information by typing it in again; not only it is a real pain, but you are bound to make a mistake. To send log file contents, either make a copy of the file and use an editor to trim the information to what is relevant, or cut and paste into your message. For the output of programs like `dmesg`, redirect the output to a file and include that. For example, @@ -147,14 +147,14 @@ Try not to use MIME: a lot of people use mailers which do not get on very well w .... % dmesg > /tmp/dmesg.out .... -+ ++ This redirects the information to the file [.filename]#/tmp/dmesg.out#. * When using cut-and-paste, please be aware that some such operations badly mangle their messages. This is of particular concern when posting contents of [.filename]#Makefiles#, where `tab` is a significant character. This is a very common, and very annoying, problem with submissions to the link:https://www.FreeBSD.org/support/[Problem Reports database]. [.filename]#Makefiles# with tabs changed to either spaces, or the annoying `=3B` escape sequence, create a great deal of aggravation for committers. === What are the special etiquette consideration when replying to an existing posting on the mailing lists? * Please include relevant text from the original message. Trim it to the minimum, but do not overdo it. It should still be possible for somebody who did not read the original message to understand what you are talking about. -+ ++ This is especially important for postings of the type "yes, I see this too", where the initial posting was dozens or hundreds of lines. * Use some technique to identify which text came from the original message, and which text you add. A common convention is to prepend "`>`" to the original message. Leaving white space after the "`>`" and leaving empty lines between your text and the original text both make the result more readable. * Please ensure that the attributions of the text you are quoting is correct. People can become offended if you attribute words to them that they themselves did not write. @@ -162,7 +162,7 @@ This is especially important for postings of the type "yes, I see this too", whe + ** A: Because it reverses the logical flow of conversation. ** Q: Why is top posting frowned upon? -+ ++ (Thanks to Randy Bush for the joke.) [[recurring]] diff --git a/documentation/content/en/articles/nanobsd/_index.adoc b/documentation/content/en/articles/nanobsd/_index.adoc index b819e0ee10..b90ac20046 100644 --- a/documentation/content/en/articles/nanobsd/_index.adoc +++ b/documentation/content/en/articles/nanobsd/_index.adoc @@ -390,7 +390,7 @@ The update process of NanoBSD is relatively simple: ==== . Build a new NanoBSD image, as usual. . Upload the new image into an unused partition of a running NanoBSD appliance. -+ ++ The most important difference of this step from the initial NanoBSD installation is that now instead of using [.filename]#\_.disk.full# (which contains an image of the entire disk), the [.filename]#_.disk.image# image is installed (which contains an image of a single system partition). . Reboot, and start the system from the newly installed partition. . If all goes well, the upgrade is finished. diff --git a/documentation/content/en/articles/problem-reports/_index.adoc b/documentation/content/en/articles/problem-reports/_index.adoc index d92d95945e..42ada1e99a 100644 --- a/documentation/content/en/articles/problem-reports/_index.adoc +++ b/documentation/content/en/articles/problem-reports/_index.adoc @@ -108,10 +108,10 @@ For FreeBSD, this means: * Optionally, the entire web-use your favorite search engine to locate any references to the problem. You may even get hits from archived mailing lists or newsgroups you did not know of or had not thought to search through. * Next, the searchable https://bugs.freebsd.org/bugzilla/query.cgi[FreeBSD PR database] (Bugzilla). Unless the problem is recent or obscure, there is a fair chance it has already been reported. * Most importantly, attempt to see if existing documentation in the source base addresses your problem. -+ ++ For the base FreeBSD code, you should carefully study the contents of [.filename]#/usr/src/UPDATING# on your system or the latest version at https://cgit.freebsd.org/src/tree/UPDATING[https://cgit.freebsd.org/src/tree/UPDATING]. (This is vital information if you are upgrading from one version to another-especially if you are upgrading to the FreeBSD-CURRENT branch). -+ ++ However, if the problem is in something that was installed as a part of the FreeBSD Ports Collection, you should refer to [.filename]#/usr/ports/UPDATING# (for individual ports) or [.filename]#/usr/ports/CHANGES# (for changes that affect the entire Ports Collection). https://cgit.freebsd.org/ports/tree/UPDATING[https://cgit.freebsd.org/ports/tree/UPDATING] and https://cgit.freebsd.org/ports/tree/CHANGES[https://cgit.freebsd.org/ports/tree/CHANGES] are also available via cgit. @@ -196,12 +196,12 @@ When you file a bug, you will find the following fields: * _Summary:_ Fill this out with a short and accurate description of the problem. The synopsis is used as the subject of the problem report email, and is used in problem report listings and summaries; problem reports with obscure synopses tend to get ignored. * _Severity:_ One of `Affects only me`, `Affects some people` or `Affects many people`. Do not overreact; refrain from labeling your problem `Affects many people` unless it really does. FreeBSD developers will not necessarily work on your problem faster if you inflate its importance since there are so many other people who have done exactly that. * _Category:_ Choose an appropriate category. -+ ++ The first thing you need to do is to decide what part of the system your problem lies in. Remember, FreeBSD is a complete operating system, which installs both a kernel, the standard libraries, many peripheral drivers, and a large number of utilities (the "base system"). However, there are thousands of additional applications in the Ports Collection. You'll first need to decide if the problem is in the base system or something installed via the Ports Collection. -+ ++ Here is a description of the major categories: ** If a problem is with the kernel, the libraries (such as standard C library `libc`), or a peripheral driver in the base system, in general you will use the `kern` category. (There are a few exceptions; see below). In general these are things that are described in section 2, 3, or 4 of the manual pages. @@ -213,7 +213,7 @@ Here is a description of the major categories: ==== if you are having a problem with something from a port named `www/_someportname_`, this nevertheless goes in the `ports` category. ==== -+ ++ There are a few more specialized categories. ** If the problem would otherwise be filed in `kern` but has to do with the USB subsystem, the correct choice is `usb`. diff --git a/documentation/content/en/articles/serial-uart/_index.adoc b/documentation/content/en/articles/serial-uart/_index.adoc index 084f4493d6..60ee8c73b4 100644 --- a/documentation/content/en/articles/serial-uart/_index.adoc +++ b/documentation/content/en/articles/serial-uart/_index.adoc @@ -897,7 +897,7 @@ device sio4 at isa? port 0x118 flags 0x1005 device sio15 at isa? port 0x170 flags 0x1005 device sio16 at isa? port 0x178 flags 0x1005 irq 3 .... -+ ++ The flags entry _must_ be changed from this example unless you are using the exact same sio assignments. Flags are set according to 0x``__MYY__`` where _M_ indicates the minor number of the master port (the last port on a Boca 16) and _YY_ indicates if FIFO is enabled or disabled(enabled), IRQ sharing is used(yes) and if there is an AST/4 compatible IRQ control register(no). In this example, @@ -947,7 +947,7 @@ sio15: type 16550A (multiport) sio16 at 0x178-0x17f irq 3 flags 0x1005 on isa sio16: type 16550A (multiport master) .... -+ ++ If the messages go by too fast to see, + [source,shell] @@ -956,7 +956,7 @@ If the messages go by too fast to see, .... will show you the boot messages. . Next, appropriate entries in [.filename]#/dev# for the devices must be made using the [.filename]#/dev/MAKEDEV# script. This step can be omitted if you are running FreeBSD 5.X with a kernel that has man:devfs[5] support compiled in. -+ ++ If you do need to create the [.filename]#/dev# entries, run the following as `root`: + [source,shell] @@ -969,7 +969,7 @@ If you do need to create the [.filename]#/dev# entries, run the following as `ro # ./MAKEDEV ttyg # ./MAKEDEV cuag .... -+ ++ If you do not want or need call-out devices for some reason, you can dispense with making the [.filename]#cua*# devices. . If you want a quick and sloppy way to make sure the devices are working, you can simply plug a modem into each port and (as root) + diff --git a/documentation/content/en/articles/solid-state/_index.adoc b/documentation/content/en/articles/solid-state/_index.adoc index 0ae410fcdf..ca2ddad07e 100644 --- a/documentation/content/en/articles/solid-state/_index.adoc +++ b/documentation/content/en/articles/solid-state/_index.adoc @@ -135,7 +135,7 @@ In addition to the kern and mfsroot floppy disks, you will also need to use the [.procedure] ==== . Partitioning Your Flash Media Device -+ *** 2305 LINES SKIPPED *** From owner-dev-commits-doc-all@freebsd.org Tue Jun 8 11:37:06 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 06B0E65DDF3 for ; Tue, 8 Jun 2021 11:37:06 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fzp9s6sBfz4YRP; Tue, 8 Jun 2021 11:37:05 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id D407B387; Tue, 8 Jun 2021 11:37:05 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 158Bb5oM014942; Tue, 8 Jun 2021 11:37:05 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 158Bb5W9014941; Tue, 8 Jun 2021 11:37:05 GMT (envelope-from git) Date: Tue, 8 Jun 2021 11:37:05 GMT Message-Id: <202106081137.158Bb5W9014941@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Ceri Davies Subject: git: c07f22064d - main - handbook/mirrors: fix typos. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: ceri X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: c07f22064ddcee36820a5e7b32e45ca90e02cb3e Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 11:37:06 -0000 The branch main has been updated by ceri: URL: https://cgit.FreeBSD.org/doc/commit/?id=c07f22064ddcee36820a5e7b32e45ca90e02cb3e commit c07f22064ddcee36820a5e7b32e45ca90e02cb3e Author: Ceri Davies AuthorDate: 2021-06-08 08:47:57 +0000 Commit: Ceri Davies CommitDate: 2021-06-08 11:37:00 +0000 handbook/mirrors: fix typos. --- documentation/content/en/books/handbook/mirrors/_index.adoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/documentation/content/en/books/handbook/mirrors/_index.adoc b/documentation/content/en/books/handbook/mirrors/_index.adoc index 7be01c8ea6..b709efaadf 100644 --- a/documentation/content/en/books/handbook/mirrors/_index.adoc +++ b/documentation/content/en/books/handbook/mirrors/_index.adoc @@ -457,12 +457,12 @@ Cloning over an existing non-git directory will fail. Git uses URLs to designate a repository, taking the form of _protocol://hostname/path_. The first component of the path is the FreeBSD repository to access. -There are three different repositories, `src` for the FreeBSD systerm source code, `doc` for documentation, and `ports` for the FreeBSD Ports Collection. +There are three different repositories, `src` for the FreeBSD system source code, `doc` for documentation, and `ports` for the FreeBSD Ports Collection. For example, the URL `https://git.FreeBSD.org/src.git` specifies the main branch of the src repository, using the `https` protocol. [[git-url-table]] .FreeBSD Git Repository URL Table -[options="header,foooter"] +[options="header,footer"] |======================================================= |Item | Git URL | Web-based repository browser src | `https://cgit.freebsd.org/src` @@ -562,7 +562,7 @@ These are also published as SSHFP records in DNS. === Web-based repository browser The FreeBSD project currently uses cgit as the web-based repository browser: https://cgit.freebsd.org/. -The URLs of indivirual repositories are listed in <>. +The URLs of individual repositories are listed in <>. === For Users From owner-dev-commits-doc-all@freebsd.org Tue Jun 8 11:38:50 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 68B4B65DDF5 for ; Tue, 8 Jun 2021 11:38:50 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FzpCt2Wzbz4Ycc; Tue, 8 Jun 2021 11:38:50 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 3ED862A1; Tue, 8 Jun 2021 11:38:50 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 158BcoJa015157; Tue, 8 Jun 2021 11:38:50 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 158Bcois015156; Tue, 8 Jun 2021 11:38:50 GMT (envelope-from git) Date: Tue, 8 Jun 2021 11:38:50 GMT Message-Id: <202106081138.158Bcois015156@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Mateusz Piotrowski <0mp@FreeBSD.org> Subject: git: 6f15c144c1 - internal/admin - Fix the path to committer-doc.dot MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: 0mp X-Git-Repository: doc X-Git-Refname: refs/internal/admin X-Git-Reftype: branch X-Git-Commit: 6f15c144c1f6f27e3280af83bb2824c79853f7c7 Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 11:38:50 -0000 The branch internal/admin has been updated by 0mp: URL: https://cgit.FreeBSD.org/doc/commit/?id=6f15c144c1f6f27e3280af83bb2824c79853f7c7 commit 6f15c144c1f6f27e3280af83bb2824c79853f7c7 Author: Mateusz Piotrowski <0mp@FreeBSD.org> AuthorDate: 2021-06-08 11:38:02 +0000 Commit: Mateusz Piotrowski <0mp@FreeBSD.org> CommitDate: 2021-06-08 11:38:02 +0000 Fix the path to committer-doc.dot Approved by: doceng (implicit) --- mentors | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mentors b/mentors index e9bc1b0605..7cd5cdb364 100644 --- a/mentors +++ b/mentors @@ -5,7 +5,7 @@ # "release" a mentee from mentorship since svn cannot do forced commits. # The full list of mentor->mentee relationships including historical -# entries is in head/share/misc/committers-src.dot +# entries is in src/share/misc/committers-doc.dot # Sort by mentee login name. From owner-dev-commits-doc-all@freebsd.org Tue Jun 8 22:55:03 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0656363FE91 for ; Tue, 8 Jun 2021 22:55:03 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G05D65Nrgz3MHM; Tue, 8 Jun 2021 22:55:02 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 875E911B0B; Tue, 8 Jun 2021 22:55:02 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 158Mt2dv063287; Tue, 8 Jun 2021 22:55:02 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 158Mt24a063286; Tue, 8 Jun 2021 22:55:02 GMT (envelope-from git) Date: Tue, 8 Jun 2021 22:55:02 GMT Message-Id: <202106082255.158Mt24a063286@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: "Danilo G. Baio" Subject: git: c9c4fc4628 - main - hugo server: Fix bind and hostname parameters MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: dbaio X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: c9c4fc4628a0d18d41fffb66a7f930f81653ef6b Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 22:55:03 -0000 The branch main has been updated by dbaio: URL: https://cgit.FreeBSD.org/doc/commit/?id=c9c4fc4628a0d18d41fffb66a7f930f81653ef6b commit c9c4fc4628a0d18d41fffb66a7f930f81653ef6b Author: Danilo G. Baio AuthorDate: 2021-06-05 20:25:46 +0000 Commit: Danilo G. Baio CommitDate: 2021-06-08 22:52:50 +0000 hugo server: Fix bind and hostname parameters When BIND variable is defined, baseURL/.HOST should not be set to localhost by default. Reported by: imp Reviewed by: imp, ceri, blackend Differential Revision: https://reviews.freebsd.org/D30656 --- documentation/Makefile | 8 ++++++-- website/Makefile | 8 ++++++-- 2 files changed, 12 insertions(+), 4 deletions(-) diff --git a/documentation/Makefile b/documentation/Makefile index 606d79c30f..0c4725d19e 100644 --- a/documentation/Makefile +++ b/documentation/Makefile @@ -39,9 +39,13 @@ RUN_DEPENDS= ${PYTHON_CMD} \ ${LOCALBASE}/bin/rougify .ifndef HOSTNAME -.HOST+=localhost +. ifdef BIND +.HOST=$(BIND) +. else +.HOST=localhost +. endif .else -.HOST+=$(HOSTNAME) +.HOST=$(HOSTNAME) .endif .ORDER: all run diff --git a/website/Makefile b/website/Makefile index fbee771541..dd650f501a 100644 --- a/website/Makefile +++ b/website/Makefile @@ -22,9 +22,13 @@ RUBYLIB = ../shared/lib .export RUBYLIB .ifndef HOSTNAME -.HOST+=localhost +. ifdef BIND +.HOST=$(BIND) +. else +.HOST=localhost +. endif .else -.HOST+=$(HOSTNAME) +.HOST=$(HOSTNAME) .endif .ORDER: all run From owner-dev-commits-doc-all@freebsd.org Wed Jun 9 21:26:25 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 91556653DFE for ; Wed, 9 Jun 2021 21:26:25 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G0gCP3g4Yz3p6n; Wed, 9 Jun 2021 21:26:25 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 60FEB235BC; Wed, 9 Jun 2021 21:26:25 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 159LQPHn056986; Wed, 9 Jun 2021 21:26:25 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 159LQPvP056985; Wed, 9 Jun 2021 21:26:25 GMT (envelope-from git) Date: Wed, 9 Jun 2021 21:26:25 GMT Message-Id: <202106092126.159LQPvP056985@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Jason Helfman Subject: git: d07101f00f - main - articles/committers-guide: remove 'work in progres' note MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: jgh X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: d07101f00fbe2888a7d7efa897fe37abc3eea58f Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2021 21:26:25 -0000 The branch main has been updated by jgh: URL: https://cgit.FreeBSD.org/doc/commit/?id=d07101f00fbe2888a7d7efa897fe37abc3eea58f commit d07101f00fbe2888a7d7efa897fe37abc3eea58f Author: Jason Helfman AuthorDate: 2021-06-09 21:23:06 +0000 Commit: Jason Helfman CommitDate: 2021-06-09 21:24:59 +0000 articles/committers-guide: remove 'work in progres' note Reviewed by: imp@ --- documentation/content/en/articles/committers-guide/_index.adoc | 5 ----- 1 file changed, 5 deletions(-) diff --git a/documentation/content/en/articles/committers-guide/_index.adoc b/documentation/content/en/articles/committers-guide/_index.adoc index 4d434552fd..835f28cf99 100644 --- a/documentation/content/en/articles/committers-guide/_index.adoc +++ b/documentation/content/en/articles/committers-guide/_index.adoc @@ -275,11 +275,6 @@ Mentored committers can provide a "Reviewed by" but not an "Approved by". [[git-primer]] == Git Primer -[NOTE] -==== -this section is a work in progress... -==== - [[git-basics]] === Git basics From owner-dev-commits-doc-all@freebsd.org Thu Jun 10 13:32:05 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 88B6464BE0A for ; Thu, 10 Jun 2021 13:32:05 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G14dd3DS6z4lwD; Thu, 10 Jun 2021 13:32:05 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 5699010C72; Thu, 10 Jun 2021 13:32:05 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 15ADW5mP052802; Thu, 10 Jun 2021 13:32:05 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 15ADW5O8052801; Thu, 10 Jun 2021 13:32:05 GMT (envelope-from git) Date: Thu, 10 Jun 2021 13:32:05 GMT Message-Id: <202106101332.15ADW5O8052801@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: =?utf-8?Q?Fernando Apestegu=C3=ADa=?= Subject: git: 7b75a889eb - main - [freebsd-releng]: s/shared/share where appropriate MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: fernape X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 7b75a889eb666fe3cdbae4de6a98ed8701d854b1 Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2021 13:32:05 -0000 The branch main has been updated by fernape: URL: https://cgit.FreeBSD.org/doc/commit/?id=7b75a889eb666fe3cdbae4de6a98ed8701d854b1 commit 7b75a889eb666fe3cdbae4de6a98ed8701d854b1 Author: Fernando Apesteguía AuthorDate: 2021-05-27 07:03:08 +0000 Commit: Fernando Apesteguía CommitDate: 2021-06-10 13:27:39 +0000 [freebsd-releng]: s/shared/share where appropriate Fix a couple of paths. Differential Revision: https://reviews.freebsd.org/D30489 --- documentation/content/en/articles/freebsd-releng/_index.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/documentation/content/en/articles/freebsd-releng/_index.adoc b/documentation/content/en/articles/freebsd-releng/_index.adoc index d133116fae..b2e78048ba 100644 --- a/documentation/content/en/articles/freebsd-releng/_index.adoc +++ b/documentation/content/en/articles/freebsd-releng/_index.adoc @@ -402,10 +402,10 @@ a| |[.filename]#stable/12/sys/conf/newvers.sh# |Update the `BRANCH` value to reflect `BETA1` -|[.filename]#stable/12/shared/mk/src.opts.mk# +|[.filename]#stable/12/share/mk/src.opts.mk# |Move `REPRODUCIBLE_BUILD` from `\__DEFAULT_NO_OPTIONS` to `__DEFAULT_YES_OPTIONS` -|[.filename]#stable/12/shared/mk/src.opts.mk# +|[.filename]#stable/12/share/mk/src.opts.mk# |Move `LLVM_ASSERTIONS` from `\__DEFAULT_YES_OPTIONS` to `__DEFAULT_NO_OPTIONS` (FreeBSD 13.x and later only) |[.filename]#stable/12/libexec/rc/rc.conf# From owner-dev-commits-doc-all@freebsd.org Thu Jun 10 14:47:40 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 893F864CEC5 for ; Thu, 10 Jun 2021 14:47:40 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G16Jp5JXxz4v2B; Thu, 10 Jun 2021 14:47:35 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4A37411A9D; Thu, 10 Jun 2021 14:47:34 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 15AElXac047865; Thu, 10 Jun 2021 14:47:33 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 15AElXnc047864; Thu, 10 Jun 2021 14:47:33 GMT (envelope-from git) Date: Thu, 10 Jun 2021 14:47:33 GMT Message-Id: <202106101447.15AElXnc047864@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Marc Fonvieille Subject: git: 23f022e21c - main - ko/articles: Fix include links MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: blackend X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 23f022e21ccb9ceca9693eb7942d822baff5ca20 Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2021 14:47:40 -0000 The branch main has been updated by blackend: URL: https://cgit.FreeBSD.org/doc/commit/?id=23f022e21ccb9ceca9693eb7942d822baff5ca20 commit 23f022e21ccb9ceca9693eb7942d822baff5ca20 Author: Marc Fonvieille AuthorDate: 2021-06-10 14:47:00 +0000 Commit: Marc Fonvieille CommitDate: 2021-06-10 14:47:00 +0000 ko/articles: Fix include links --- documentation/content/ko/articles/contributing/_index.adoc | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/documentation/content/ko/articles/contributing/_index.adoc b/documentation/content/ko/articles/contributing/_index.adoc index 17f7ae8477..5802e87a60 100644 --- a/documentation/content/ko/articles/contributing/_index.adoc +++ b/documentation/content/ko/articles/contributing/_index.adoc @@ -22,7 +22,17 @@ trademarks: ["freebsd", "ieee", "general"] :figure-caption: 그림 :example-caption: 예시 +ifeval::["{backend}" == "html5"] include::shared/ko/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/ko/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/ko/urls.adoc[] +endif::[] [.abstract-title] 초록 From owner-dev-commits-doc-all@freebsd.org Thu Jun 10 23:24:34 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9E081655472 for ; Thu, 10 Jun 2021 23:24:34 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G1KnG3qvqz4sjR; Thu, 10 Jun 2021 23:24:34 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 679B118905; Thu, 10 Jun 2021 23:24:34 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 15ANOYcJ042044; Thu, 10 Jun 2021 23:24:34 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 15ANOYRW042043; Thu, 10 Jun 2021 23:24:34 GMT (envelope-from git) Date: Thu, 10 Jun 2021 23:24:34 GMT Message-Id: <202106102324.15ANOYRW042043@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: "Danilo G. Baio" Subject: git: 9a26bed4f8 - main - pt-br/articles/explaining-bsd: Sync with en f80bbbf MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: dbaio X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 9a26bed4f8d271d962fdb1799abce012a94cb006 Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2021 23:24:34 -0000 The branch main has been updated by dbaio: URL: https://cgit.FreeBSD.org/doc/commit/?id=9a26bed4f8d271d962fdb1799abce012a94cb006 commit 9a26bed4f8d271d962fdb1799abce012a94cb006 Author: Danilo G. Baio AuthorDate: 2021-06-10 23:21:35 +0000 Commit: Danilo G. Baio CommitDate: 2021-06-10 23:21:35 +0000 pt-br/articles/explaining-bsd: Sync with en f80bbbf This is a resync with po4a. Obtained from: https://translate-dev.freebsd.org --- .../pt-br/articles/explaining-bsd/_index.adoc | 28 +- .../pt-br/articles/explaining-bsd/_index.po | 973 +++++++++++++++++++++ 2 files changed, 988 insertions(+), 13 deletions(-) diff --git a/documentation/content/pt-br/articles/explaining-bsd/_index.adoc b/documentation/content/pt-br/articles/explaining-bsd/_index.adoc index 4f8b8d76c6..cb76a33dc3 100644 --- a/documentation/content/pt-br/articles/explaining-bsd/_index.adoc +++ b/documentation/content/pt-br/articles/explaining-bsd/_index.adoc @@ -1,10 +1,12 @@ --- -title: Explicando o BSD authors: - - author: Greg Lehey + - + author: 'Greg Lehey' email: grog@FreeBSD.org -releaseinfo: "$FreeBSD$" -trademarks: ["freebsd", "amd", "apple", "intel", "linux", "opengroup", "sparc", "sun", "unix", "general"] +description: 'Breve explicação sobre BSD' +tags: '["Explaining BSD", "BSD", "FreeBSD", "operating system"]' +title: 'Explicando o BSD' +trademarks: '["freebsd", "amd", "apple", "intel", "linux", "opengroup", "sun", "unix", "general"]' --- = Explicando o BSD @@ -31,7 +33,7 @@ No mundo do código aberto, a palavra "Linux" é praticamente sinônimo de "Sist Então, qual é o segredo? Por que o BSD não é mais conhecido? Este artigo aborda esta e outras questões. -Ao longo deste artigo as diferenças entre o BSD e o Linux serão destacadas __desta forma__. +Ao longo deste artigo, as diferenças entre BSD e Linux serão destacadas __desta forma__. ''' @@ -44,14 +46,14 @@ BSD é a sigla para "Berkeley Software Distribution". É o nome do código fonte * O kernel BSD, que lida com o agendamento de processos, gerenciamento de memória, multi processamento simétrico (symmetric multi-processing ou SMP), drivers de dispositivos, etc. * A biblioteca C, a API base do sistema. -+ ++ __A biblioteca C do BSD é baseada no código de Berkeley, não no projeto GNU.__ * Utilitários como shells, gerenciadores de arquivos, compiladores e linkers (conversores de arquivos compilados em executáveis). -+ ++ __Alguns utilitários são derivados do projeto GNU, outros não são.__ * O sistema X Window, que gerencia a interface gráfica. -+ -O sistema X Window usado na maioria das versões do BSD é mantido pelo http://www.X.org/[Projeto X.Org]. O FreeBSD permite ao usuário escolher a partir de uma variedade de ambientes de desktop, tais como o Gnome, KDE, ou Xfce; e gerenciadores gráficos (gerenciadores de janelas) mais leves, como Openbox, Fluxbox, ou Awesome. ++ +O sistema X Window usado na maioria das versões do BSD é mantido pelo http://www.X.org/[Projeto X.Org]. O FreeBSD permite ao usuário escolher a partir de uma variedade de ambientes de desktop, tais como o Gnome, KDE ou Xfce; e gerenciadores gráficos (gerenciadores de janelas) mais leves, como Openbox, Fluxbox ou Awesome. * Diversos outros programas e utilitários. [[what-a-real-unix]] @@ -77,8 +79,8 @@ Por uma série de razões, o BSD é relativamente desconhecido: . Os desenvolvedores do BSD estão mais interessados em aprimorar o seu código do que em divulgá-lo. . Grande parte da popularidade do Linux se deve a fatores externos ao projeto Linux, como a mídia e empresas que foram criadas para prover serviços Linux. Até pouco tempo atrás os BSD de código aberto não tinham este tipo de proposta. . Em 1992 a AT&T processou a http://www.bsdi.com/[BSDI], que comercializava o BSD/386, alegando que o produto continha código protegido por direitos autorais da AT&T. O caso foi encerrado fora dos tribunais em 1994, mas o fantasma do litígio continua assombrando. Em março de 2000 um artigo publicado na web afirma que o caso foi "recentemente encerrado". -+ -Um detalhe que o processo civil não deixa claro refere-se ao nome: nos anos 80 o BSD era conhecido como "BSDUNIX(R)". Com a eliminação dos últimos vestígios do código da AT&T do BSD, ele também perdeu o direito ao nome UNIX(R). Desta forma você verá referências em livros para o "sistema operacional 4.3BSD UNIX(R)" e o "sistema operacional 4.4BSD". ++ +Um detalhe que o processo civil não deixa claro refere-se ao nome: nos anos 80 o BSD era conhecido como "BSD UNIX(R)". Com a eliminação dos últimos vestígios do código da AT&T do BSD, ele também perdeu o direito ao nome UNIX(R). Desta forma você verá referências em livros para o "sistema operacional 4.3BSD UNIX(R)" e o "sistema operacional 4.4BSD". [[comparing-bsd-and-linux]] == Comparando BSD e Linux @@ -97,7 +99,7 @@ Um grande número de desenvolvedores por todo o mundo contribuem com melhorias a * _Contributors_ escrevem código ou documentação. Eles não têm permissão para adicionar código diretamente ao repositório principal de código fonte. Para que seu código seja incluído no sistema, ele deve ser revisado e verificado por um desenvolvedor registrado, conhecido como __committer__. * _Committers_ são desenvolvedores com acesso de gravação no repositório principal de código fonte. Para se tornar um committer, um indivíduo deve mostrar habilidade na área em que está ativo. -+ ++ Fica a critério do bom senso individual de cada committer a decisão se eles devem obter ou não um consenso antes de enviar alterações para o repositório de código fonte. Em geral, um committer experiente pode fazer alterações que sejam inquestionavelmente corretas sem obter consenso. Por exemplo, um committer do projeto de documentação pode corrigir erros tipográficos ou gramaticais sem revisão. Por outro lado, espera-se que os desenvolvedores que realizam mudanças complexas ou muito extensas enviem suas alterações para revisão antes de enviá-las para o repositório de código fonte. Em casos extremos, um membro do Core Team com uma função tal como a de arquiteto principal, pode ordenar que as alterações sejam removidas do repositório, num processo conhecido como _backing out_. Todos os committers recebem emails que descrevem cada commit individual, portanto não é possível enviar alterações para o repositório de código fonte em segredo. * O _Core Team_. O FreeBSD e o NetBSD possuem uma equipe principal (Core team) que gerenciam o projeto. As equipes principais evoluíram ao longo dos projeto e a sua função nem sempre está bem definida. Não é necessário ser um desenvolvedor para ser um membro da equipe principal, embora isto seja normal. As regras para a equipe principal variam de um projeto para o outro, mas no geral elas têm mais voz ativa sobre a direção do projeto do que os demais membros tem. @@ -161,4 +163,4 @@ Esta é uma pergunta muito difícil de responder. Aqui estão algumas diretrizes A BSDi / http://www.freebsdmall.com[FreeBSD Mall, Inc.] fornece contratos de suporte para o FreeBSD já há quase uma década. -Além disso, o website de cada um dos projetos possui uma lista de consultores disponíveis para contratação: link:www.FreeBSD.org/commercial/consult_bycat/[FreeBSD], http://www.netbsd.org/gallery/consultants.html[NetBSD], and http://www.openbsd.org/support.html[OpenBSD]. +Além disso, o website de cada um dos projetos possui uma lista de consultores disponíveis para contratação: link:www.FreeBSD.org/commercial/consult_bycat/[FreeBSD], http://www.netbsd.org/gallery/consultants.html[NetBSD], e http://www.openbsd.org/support.html[OpenBSD]. diff --git a/documentation/content/pt-br/articles/explaining-bsd/_index.po b/documentation/content/pt-br/articles/explaining-bsd/_index.po new file mode 100644 index 0000000000..c090545b64 --- /dev/null +++ b/documentation/content/pt-br/articles/explaining-bsd/_index.po @@ -0,0 +1,973 @@ +# SOME DESCRIPTIVE TITLE +# Copyright (C) YEAR The FreeBSD Project +# This file is distributed under the same license as the FreeBSD Documentation package. +# Danilo G. Baio , 2021. +msgid "" +msgstr "" +"Project-Id-Version: FreeBSD Documentation VERSION\n" +"POT-Creation-Date: 2021-06-08 07:32-0300\n" +"PO-Revision-Date: 2021-06-10 23:03+0000\n" +"Last-Translator: Danilo G. Baio \n" +"Language-Team: Portuguese (Brazil) \n" +"Language: pt_BR\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Plural-Forms: nplurals=2; plural=n > 1;\n" +"X-Generator: Weblate 4.6.2\n" + +#. type: YAML Front Matter: description +#: documentation/content/en/articles/explaining-bsd/_index.adoc:1 +#, no-wrap +msgid "Brief explanation about BSD" +msgstr "Breve explicação sobre BSD" + +#. type: Title = +#: documentation/content/en/articles/explaining-bsd/_index.adoc:1 +#: documentation/content/en/articles/explaining-bsd/_index.adoc:11 +#, no-wrap +msgid "Explaining BSD" +msgstr "Explicando o BSD" + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:23 +msgid "Abstract" +msgstr "Resumo" + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:25 +msgid "" +"In the open source world, the word \"Linux\" is almost synonymous with " +"\"Operating System\", but it is not the only open source UNIX(R) operating " +"system." +msgstr "" +"No mundo do código aberto, a palavra \"Linux\" é praticamente sinônimo de " +"\"Sistema Operacional\", mas ele não é o único sistema operacional UNIX(R) " +"de código aberto." + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:27 +msgid "" +"So what is the secret? Why is BSD not better known? This white paper " +"addresses these and other questions." +msgstr "" +"Então, qual é o segredo? Por que o BSD não é mais conhecido? Este artigo " +"aborda esta e outras questões." + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:29 +msgid "" +"Throughout this paper, differences between BSD and Linux will be noted " +"__like this__." +msgstr "" +"Ao longo deste artigo, as diferenças entre BSD e Linux serão destacadas " +"__desta forma__." + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:31 +msgid "'''" +msgstr "'''" + +#. type: Title == +#: documentation/content/en/articles/explaining-bsd/_index.adoc:35 +#, no-wrap +msgid "What is BSD?" +msgstr "O que é o BSD?" + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:42 +msgid "" +"BSD stands for \"Berkeley Software Distribution\". It is the name of " +"distributions of source code from the University of California, Berkeley, " +"which were originally extensions to AT&T's Research UNIX(R) operating " +"system. Several open source operating system projects are based on a " +"release of this source code known as 4.4BSD-Lite. In addition, they " +"comprise a number of packages from other Open Source projects, including " +"notably the GNU project. The overall operating system comprises:" +msgstr "" +"BSD é a sigla para \"Berkeley Software Distribution\". É o nome do código " +"fonte distribuído pela Universidade da Califórnia, Berkeley, que era " +"originalmente uma extensão do UNIX(R) desenvolvido pela área de pesquisa da " +"AT&T. Diversos projetos de sistemas operacionais de código aberto foram " +"baseados em uma versão deste código, conhecido como 4.4BSD-Lite. Além disso, " +"eles incluem vários pacotes de outros projetos de código aberto, com " +"destaque para os do projeto GNU. O sistema operacional geralmente abrange:" + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:44 +msgid "" +"The BSD kernel, which handles process scheduling, memory management, " +"symmetric multi-processing (SMP), device drivers, etc." +msgstr "" +"O kernel BSD, que lida com o agendamento de processos, gerenciamento de " +"memória, multi processamento simétrico (symmetric multi-processing ou SMP), " +"drivers de dispositivos, etc." + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:45 +msgid "The C library, the base API for the system." +msgstr "A biblioteca C, a API base do sistema." + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:47 +msgid "" +"__The BSD C library is based on code from Berkeley, not the GNU project.__" +msgstr "" +"__A biblioteca C do BSD é baseada no código de Berkeley, não no projeto GNU." +"__" + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:48 +msgid "Utilities such as shells, file utilities, compilers and linkers." +msgstr "" +"Utilitários como shells, gerenciadores de arquivos, compiladores e linkers " +"(conversores de arquivos compilados em executáveis)." + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:50 +msgid "" +"__Some of the utilities are derived from the GNU project, others are not.__" +msgstr "__Alguns utilitários são derivados do projeto GNU, outros não são.__" + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:51 +msgid "The X Window system, which handles graphical display." +msgstr "O sistema X Window, que gerencia a interface gráfica." + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:54 +msgid "" +"The X Window system used in most versions of BSD is maintained by the http://" +"www.X.org/[X.Org project]. FreeBSD allows the user to choose from a variety " +"of desktop environments, such as Gnome, KDE, or Xfce; and lightweight window " +"managers like Openbox, Fluxbox, or Awesome." +msgstr "" +"O sistema X Window usado na maioria das versões do BSD é mantido pelo " +"http://www.X.org/[Projeto X.Org]. O FreeBSD permite ao usuário escolher a " +"partir de uma variedade de ambientes de desktop, tais como o Gnome, KDE ou " +"Xfce; e gerenciadores gráficos (gerenciadores de janelas) mais leves, como " +"Openbox, Fluxbox ou Awesome." + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:55 +msgid "Many other programs and utilities." +msgstr "Diversos outros programas e utilitários." + +#. type: Title == +#: documentation/content/en/articles/explaining-bsd/_index.adoc:57 +#, no-wrap +msgid "What, a real UNIX(R)?" +msgstr "O que, um verdadeiro UNIX(R)?" + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:62 +msgid "" +"The BSD operating systems are not clones, but open source derivatives of " +"AT&T's Research UNIX(R) operating system, which is also the ancestor of the " +"modern UNIX(R) System V. This may surprise you. How could that happen when " +"AT&T has never released its code as open source?" +msgstr "" +"Os sistemas operacionais BSD não são cópias ou clones, mas sim derivações de " +"código aberto do sistema operacional UNIX(R) da AT&T, que também é o " +"ancestral do moderno UNIX(R) System V. Isto pode surpreendê-lo. Como isto é " +"possível, uma vez que a AT&T nunca liberou seu código como código aberto?" + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:64 +msgid "" +"It is true that AT&T UNIX(R) is not open source, and in a copyright sense " +"BSD is very definitely _not_ UNIX(R), but on the other hand, AT&T has " +"imported sources from other projects, noticeably the Computer Sciences " +"Research Group (CSRG) of the University of California in Berkeley, CA. " +"Starting in 1976, the CSRG started releasing tapes of their software, " +"calling them _Berkeley Software Distribution_ or __BSD__." +msgstr "" +"É verdade que o UNIX(R) da AT&T não é um sistema de código aberto e no " +"sentido de licenciamento o BSD definitivamente _não é_ UNIX(R), mas por " +"outro lado a AT&T importou fontes de outros projetos, principalmente do " +"Grupo de Pesquisa de Ciências da Computação (Computer Sciences Research " +"Group ou CSRG) da Universidade da Califórnia em Berkeley, CA. A partir de " +"1976, o CSRG começou a liberar fitas de seu software, chamando ele de " +"_Berkeley Software Distribution_ ou __BSD__." + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:68 +msgid "" +"Initial BSD releases consisted mainly of user programs, but that changed " +"dramatically when the CSRG landed a contract with the Defense Advanced " +"Research Projects Agency (DARPA) to upgrade the communications protocols on " +"their network, ARPANET. The new protocols were known as the __Internet " +"Protocols__, later _TCP/IP_ after the most important protocols. The first " +"widely distributed implementation was part of 4.2BSD, in 1982." +msgstr "" +"As primeiras distribuições do BSD consistiam principalmente em programas de " +"usuários mas isso mudou radicalmente quando o CSRG firmou um contrato com a " +"Agência de Pesquisa de Projetos de Defesa Avançados (Defense Advanced " +"Research Projects Agency ou DARPA) para atualizar os protocolos de " +"comunicação de sua rede, a ARPANET. Os novos protocolos ficaram conhecidos " +"como __Internet Protocols__, posteriormente _TCP/IP_ em virtude dos " +"protocolos mais importantes. A primeira implementação amplamente distribuída " +"foi parte do 4.2BSD, em 1982." + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:75 +msgid "" +"In the course of the 1980s, a number of new workstation companies sprang " +"up. Many preferred to license UNIX(R) rather than developing operating " +"systems for themselves. In particular, Sun Microsystems licensed UNIX(R) " +"and implemented a version of 4.2BSD, which they called SunOS(TM). When AT&T " +"themselves were allowed to sell UNIX(R) commercially, they started with a " +"somewhat bare-bones implementation called System III, to be quickly followed " +"by System V. The System V code base did not include networking, so all " +"implementations included additional software from the BSD, including the TCP/" +"IP software, but also utilities such as the _csh_ shell and the _vi_ " +"editor. Collectively, these enhancements were known as the __Berkeley " +"Extensions__." +msgstr "" +"Durante a década de 80 surgiram muitas empresas produtoras de estações de " +"trabalho. A maioria preferiu licenciar o UNIX(R) ao invés de desenvolver " +"seus próprios sistemas operacionais. Em particular, a Sun Microsystems " +"licenciou o UNIX(R) e implementou uma versão do 4.2BSD, a qual eles chamaram " +"de SunOS(TM). Quando a própria AT&T começou a comercializar o UNIX(R), eles " +"começaram com uma implementação de certa forma simples chamada de System " +"III, que logo transformou-se no System V. O código base do System V não " +"incluía comunicação em rede, então todas as implementações incluíram " +"software adicional do BSD, inclusive o software TCP/IP, e também utilitários " +"como o shell _csh_ e o editor __vi__. Estes aprimoramentos ficaram " +"conhecidos como __Berkeley Extensions__." + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:84 +msgid "" +"The BSD tapes contained AT&T source code and thus required a UNIX(R) source " +"license. By 1990, the CSRG's funding was running out, and it faced " +"closure. Some members of the group decided to release the BSD code, which " +"was Open Source, without the AT&T proprietary code. This finally happened " +"with the __Networking Tape 2__, usually known as __Net/2__. Net/2 was not a " +"complete operating system: about 20% of the kernel code was missing. One of " +"the CSRG members, William F. Jolitz, wrote the remaining code and released " +"it in early 1992 as __386BSD__. At the same time, another group of ex-CSRG " +"members formed a commercial company called http://www.bsdi.com/[Berkeley " +"Software Design Inc.] and released a beta version of an operating system " +"called http://www.bsdi.com/[BSD/386], which was based on the same sources. " +"The name of the operating system was later changed to BSD/OS." +msgstr "" +"As fitas do BSD continham código fonte da AT&T e portanto necessitavam da " +"licença dos fontes do UNIX(R). Por volta de 1990, os recursos financeiros do " +"CSRG's estavam acabando, e ele foi encerrado. Alguns membros do grupo " +"decidiram liberar o código do BSD, que era código aberto, sem o código " +"proprietário da AT&T. Isso finalmente aconteceu com a fita __Networking Tape " +"2__, também conhecida como __Net/2__. O Net/2 não era um sistema operacional " +"completo: faltava cerca de 20% do código fonte do kernel. Um dos membros do " +"CSRG, William F. Jolitz, escreveu o código que faltava e o liberou no início " +"de 1992 sob o nome de __386BSD__. Ao mesmo tempo, um outro grupo de ex " +"integrantes do CSRG formaram uma empresa comercial chamada http://www.bsdi." +"com/[Berkeley Software Design Inc.] e liberaram uma versão beta de um " +"sistema operacional chamado http://www.bsdi.com/[BSD/386], o qual era " +"baseado nos mesmos fontes. Mais tarde o nome deste sistema operacional foi " +"alterado para BSD/OS." + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:90 +msgid "" +"386BSD never became a stable operating system. Instead, two other projects " +"split off from it in 1993: http://www.NetBSD.org/[NetBSD] and link:https://" +"www.FreeBSD.org/[FreeBSD]. The two projects originally diverged due to " +"differences in patience waiting for improvements to 386BSD: the NetBSD " +"people started early in the year, and the first version of FreeBSD was not " +"ready until the end of the year. In the meantime, the code base had " +"diverged sufficiently to make it difficult to merge. In addition, the " +"projects had different aims, as we will see below. In 1996, http://www." +"OpenBSD.org/[OpenBSD] split off from NetBSD, and in 2003, http://www." +"dragonflybsd.org/[DragonFlyBSD] split off from FreeBSD." +msgstr "" +"O 386BSD nunca chegou a ser um sistema operacional estável. Ao invés disso, " +"dois outros projetos surgiram a partir dele em 1993: http://www.NetBSD.org/" +"[NetBSD] e link:www.FreeBSD.org[FreeBSD]. Este dois projetos divergiam " +"originalmente na questão da espera pelas melhorias no 386BSD: o pessoal do " +"NetBSD iniciou no começo daquele ano, e a primeira versão do FreeBSD não " +"ficou pronta antes do final do ano. Neste meio tempo o código base ficou " +"diferente um do outro o suficiente para tornar difícil sua fusão. Além " +"disso, os projetos tinham objetivos diferentes, como veremos adiante. Em " +"1996, o http://www.OpenBSD.org/[OpenBSD] surgiu a partir do NetBSD, e em " +"2003, o http://www.dragonflybsd.org/[DragonFlyBSD] surgiu a partir do " +"FreeBSD." + +#. type: Title == +#: documentation/content/en/articles/explaining-bsd/_index.adoc:92 +#, no-wrap +msgid "Why is BSD not better known?" +msgstr "Por que o BSD não é mais conhecido?" + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:95 +msgid "For a number of reasons, BSD is relatively unknown:" +msgstr "Por uma série de razões, o BSD é relativamente desconhecido:" + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:97 +msgid "" +"The BSD developers are often more interested in polishing their code than " +"marketing it." +msgstr "" +"Os desenvolvedores do BSD estão mais interessados em aprimorar o seu código " +"do que em divulgá-lo." + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:98 +msgid "" +"Much of Linux's popularity is due to factors external to the Linux projects, " +"such as the press, and to companies formed to provide Linux services. Until " +"recently, the open source BSDs had no such proponents." +msgstr "" +"Grande parte da popularidade do Linux se deve a fatores externos ao projeto " +"Linux, como a mídia e empresas que foram criadas para prover serviços Linux. " +"Até pouco tempo atrás os BSD de código aberto não tinham este tipo de " +"proposta." + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:99 +msgid "" +"In 1992, AT&T sued http://www.bsdi.com/[BSDI], the vendor of BSD/386, " +"alleging that the product contained AT&T-copyrighted code. The case was " +"settled out of court in 1994, but the spectre of the litigation continues to " +"haunt people. In March 2000 an article published on the web claimed that the " +"court case had been \"recently settled\"." +msgstr "" +"Em 1992 a AT&T processou a http://www.bsdi.com/[BSDI], que comercializava o " +"BSD/386, alegando que o produto continha código protegido por direitos " +"autorais da AT&T. O caso foi encerrado fora dos tribunais em 1994, mas o " +"fantasma do litígio continua assombrando. Em março de 2000 um artigo " +"publicado na web afirma que o caso foi \"recentemente encerrado\"." + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:103 +msgid "" +"One detail that the lawsuit did clarify is the naming: in the 1980s, BSD was " +"known as \"BSD UNIX(R)\". With the elimination of the last vestige of AT&T " +"code from BSD, it also lost the right to the name UNIX(R). Thus you will " +"see references in book titles to \"the 4.3BSD UNIX(R) operating system\" and " +"\"the 4.4BSD operating system\"." +msgstr "" +"Um detalhe que o processo civil não deixa claro refere-se ao nome: nos anos " +"80 o BSD era conhecido como \"BSD UNIX(R)\". Com a eliminação dos últimos " +"vestígios do código da AT&T do BSD, ele também perdeu o direito ao nome " +"UNIX(R). Desta forma você verá referências em livros para o \"sistema " +"operacional 4.3BSD UNIX(R)\" e o \"sistema operacional 4.4BSD\"." + +#. type: Title == +#: documentation/content/en/articles/explaining-bsd/_index.adoc:105 +#, no-wrap +msgid "Comparing BSD and Linux" +msgstr "Comparando BSD e Linux" + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:111 +msgid "" +"So what is really the difference between, say, Debian Linux and FreeBSD? For " +"the average user, the difference is surprisingly small: Both are UNIX(R) " +"like operating systems. Both are developed by non-commercial projects (this " +"does not apply to many other Linux distributions, of course). In the " +"following section, we will look at BSD and compare it to Linux. The " +"description applies most closely to FreeBSD, which accounts for an estimated " +"80% of the BSD installations, but the differences from NetBSD, OpenBSD and " +"DragonFlyBSD are small." +msgstr "" +"Então, qual é realmente a diferença entre, digamos, o Debian Linux e o " +"FreeBSD? Para a maioria dos usuários, a diferença é surpreendentemente " +"pequena: Ambos são sistemas operacionais estilo UNIX(R). Ambos são " +"desenvolvidos por projetos não comerciais (isto não se aplica a diversas " +"outras distribuições Linux, é claro). Nas próximas sessões vamos olhar para " +"o BSD e compará-lo ao Linux. As descrições se aplicam principalmente ao " +"FreeBSD, que representa aproximadamente 80% das instalações de BSD, mas as " +"diferenças do NetBSD, OpenBSD e Dragon FlyBSD são pequenas." + +#. type: Title === +#: documentation/content/en/articles/explaining-bsd/_index.adoc:112 +#, no-wrap +msgid "Who owns BSD?" +msgstr "Quem é o dono do BSD?" + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:117 +msgid "" +"No one person or corporation owns BSD. It is created and distributed by a " +"community of highly technical and committed contributors all over the " +"world. Some of the components of BSD are Open Source projects in their own " +"right and managed by different project maintainers." +msgstr "" +"Nenhuma pessoa ou empresa é proprietária do BSD. Ele é criado e distribuído " +"por uma comunidade de colaboradores altamente técnica e comprometida " +"espalhada ao redor do mundo. Alguns dos componentes do BSD são projetos de " +"código aberto com seus próprios licenciamentos e gerenciados por diferentes " +"mantenedores." + +#. type: Title === +#: documentation/content/en/articles/explaining-bsd/_index.adoc:118 +#, no-wrap +msgid "How is BSD developed and updated?" +msgstr "Como o BSD é desenvolvido e atualizado?" + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:123 +msgid "" +"The BSD kernels are developed and updated following the Open Source " +"development model. Each project maintains a publicly accessible _source " +"tree_ which contains all source files for the project, including " +"documentation and other incidental files. Users can obtain a complete copy " +"of any version." +msgstr "" +"Os kernels dos BSDs são desenvolvidos e atualizados seguindo o modelo de " +"desenvolvimento Open Source. Cada projeto mantém uma _árvore com código " +"fonte_ publicamente acessível, que contém todo o código fonte do projeto, " +"incluindo documentação e outros arquivos incidentais. Os usuários podem " +"obter uma cópia completa de qualquer versão." + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:126 +msgid "" +"A large number of developers worldwide contribute to improvements to BSD. " +"They are divided into three kinds:" +msgstr "" +"Um grande número de desenvolvedores por todo o mundo contribuem com " +"melhorias ao BSD. Eles estão divididos em três categorias:" + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:128 +msgid "" +"_Contributors_ write code or documentation. They are not permitted to commit " +"(add code) directly to the source tree. In order for their code to be " +"included in the system, it must be reviewed and checked in by a registered " +"developer, known as a __committer__." +msgstr "" +"_Contributors_ escrevem código ou documentação. Eles não têm permissão para " +"adicionar código diretamente ao repositório principal de código fonte. Para " +"que seu código seja incluído no sistema, ele deve ser revisado e verificado " +"por um desenvolvedor registrado, conhecido como __committer__." + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:129 +msgid "" +"_Committers_ are developers with write access to the source tree. In order " +"to become a committer, an individual must show ability in the area in which " +"they are active." +msgstr "" +"_Committers_ são desenvolvedores com acesso de gravação no repositório " +"principal de código fonte. Para se tornar um committer, um indivíduo deve " +"mostrar habilidade na área em que está ativo." + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:136 +msgid "" +"It is at the individual committer's discretion whether they should obtain " +"authority before committing changes to the source tree. In general, an " +"experienced committer may make changes which are obviously correct without " +"obtaining consensus. For example, a documentation project committer may " +"correct typographical or grammatical errors without review. On the other " +"hand, developers making far-reaching or complicated changes are expected to " +"submit their changes for review before committing them In extreme cases, a " +"core team member with a function such as Principal Architect may order that " +"changes be removed from the tree, a process known as _backing out_. All " +"committers receive mail describing each individual commit, so it is not " +"possible to commit secretly." +msgstr "" +"Fica a critério do bom senso individual de cada committer a decisão se eles " +"devem obter ou não um consenso antes de enviar alterações para o repositório " +"de código fonte. Em geral, um committer experiente pode fazer alterações que " +"sejam inquestionavelmente corretas sem obter consenso. Por exemplo, um " +"committer do projeto de documentação pode corrigir erros tipográficos ou " +"gramaticais sem revisão. Por outro lado, espera-se que os desenvolvedores " +"que realizam mudanças complexas ou muito extensas enviem suas alterações " +"para revisão antes de enviá-las para o repositório de código fonte. Em casos " +"extremos, um membro do Core Team com uma função tal como a de arquiteto " +"principal, pode ordenar que as alterações sejam removidas do repositório, " +"num processo conhecido como _backing out_. Todos os committers recebem " +"emails que descrevem cada commit individual, portanto não é possível enviar " +"alterações para o repositório de código fonte em segredo." + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:137 +msgid "" +"The _Core team_. FreeBSD and NetBSD each have a core team which manages the " +"project. The core teams developed in the course of the projects, and their " +"role is not always well-defined. It is not necessary to be a developer in " +"order to be a core team member, though it is normal. The rules for the core " +"team vary from one project to the other, but in general they have more say " +"in the direction of the project than non-core team members have." +msgstr "" +"O _Core Team_. O FreeBSD e o NetBSD possuem uma equipe principal (Core team) " +"que gerenciam o projeto. As equipes principais evoluíram ao longo dos " +"projeto e a sua função nem sempre está bem definida. Não é necessário ser um " +"desenvolvedor para ser um membro da equipe principal, embora isto seja " +"normal. As regras para a equipe principal variam de um projeto para o outro, " +"mas no geral elas têm mais voz ativa sobre a direção do projeto do que os " +"demais membros tem." + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:139 +msgid "This arrangement differs from Linux in a number of ways:" +msgstr "Esse arranjo difere do Linux de várias maneiras:" + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:141 +msgid "" +"No one person controls the content of the system. In practice, this " +"difference is overrated, since the Principal Architect can require that code " +"be backed out, and even in the Linux project several people are permitted to " +"make changes." +msgstr "" +"Ninguém controla o conteúdo do sistema. Na prática, essa diferença é " +"superestimada, uma vez que o arquiteto principal pode exigir que o código " +"seja removido ou substituído, e mesmo no projeto Linux, várias pessoas podem " +"fazer alterações." + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:142 +msgid "" +"On the other hand, there _is_ a central repository, a single place where you " +"can find the entire operating system sources, including all older versions." +msgstr "" +"Por outro lado, _existe_ um repositório central, um lugar único no qual você " +"pode encontrar todo o código fonte do sistema operacional, incluindo todas " +"as versões mais antigas." + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:143 +msgid "" +"BSD projects maintain the entire \"Operating System\", not only the kernel. " +"This distinction is only marginally useful: neither BSD nor Linux is useful " +"without applications. The applications used under BSD are frequently the " +"same as the applications used under Linux." +msgstr "" +"Os projetos BSDs mantêm todo o \"Sistema Operacional\", e não apenas o " +"kernel. Essa distinção é apenas marginalmente útil: nem o BSD e nem o Linux " +"são úteis sem aplicativos. Os aplicativos usados no BSD são frequentemente " +"os mesmos aplicativos usados no Linux." + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:144 +msgid "" +"As a result of the formalized maintenance of a single SVN source tree, BSD " +"development is clear, and it is possible to access any version of the system " +"by release number or by date. SVN also allows incremental updates to the " +"system: for example, the FreeBSD repository is updated about 100 times a " +"day. Most of these changes are small." +msgstr "" +"Como resultado da manutenção formal de um único repositório SVN com o código " +"fonte, o desenvolvimento do BSD é claro e é possível acessar qualquer versão " +"do sistema por número de release ou por data. O SVN também permite " +"atualizações incrementais no sistema: por exemplo, o repositório do FreeBSD " +"é atualizado cerca de 100 vezes por dia. A maioria dessas mudanças é pequena." + +#. type: Title === +#: documentation/content/en/articles/explaining-bsd/_index.adoc:145 +#, no-wrap +msgid "BSD releases" +msgstr "Releases do BSD" + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:150 +msgid "" +"FreeBSD, NetBSD and OpenBSD provide the system in three different \"releases" +"\". As with Linux, releases are assigned a number such as 1.4.1 or 3.5. In " +"addition, the version number has a suffix indicating its purpose:" +msgstr "" +"O FreeBSD, o NetBSD e o OpenBSD fornecem o sistema em três diferentes " +"\"releases\". Como no Linux, os releases recebem um número como 1.4.1 ou " +"3.5. Além disso, o número da versão tem um sufixo indicando sua finalidade:" + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:152 +msgid "" +"The development version of the system is called _CURRENT_. FreeBSD assigns a " +"number to CURRENT, for example FreeBSD 5.0-CURRENT. NetBSD uses a slightly " +"different naming scheme and appends a single-letter suffix which indicates " +"changes in the internal interfaces, for example NetBSD 1.4.3G. OpenBSD does " +"not assign a number (\"OpenBSD-current\"). All new development on the system " +"goes into this branch." +msgstr "" +"A versão de desenvolvimento do sistema é chamada de _CURRENT_. O FreeBSD " +"atribui um número a CURRENT, por exemplo, FreeBSD 5.0-CURRENT. O NetBSD usa " +"um esquema de nomenclatura ligeiramente diferente e acrescenta um sufixo de " +"uma única letra que indica mudanças nas interfaces internas, por exemplo, o " +"NetBSD 1.4.3G. O OpenBSD não atribui um número (\"OpenBSD-current\"). Todo " +"novo desenvolvimento no sistema entra neste branch." + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:153 +msgid "" +"At regular intervals, between two and four times a year, the projects bring " +"out a _RELEASE_ version of the system, which is available on CD-ROM and for " +"free download from FTP sites, for example OpenBSD 2.6-RELEASE or NetBSD 1.4-" +"RELEASE. The RELEASE version is intended for end users and is the normal " +"version of the system. NetBSD also provides _patch releases_ with a third " +"digit, for example NetBSD 1.4.2." +msgstr "" +"Em intervalos regulares, entre duas e quatro vezes por ano, os projetos " +"lançam uma versão _RELEASE_ do sistema, a qual é disponibilizada por meio de " +"CD-ROMs e por meio de download gratuito em sites FTP, por exemplo, OpenBSD " +"2.6-RELEASE ou NetBSD 1.4-RELEASE. A versão RELEASE destina-se a usuários " +"finais e é a versão normal do sistema. O NetBSD também fornece _versões de " +"correção_ (Patch Releases) com um terceiro dígito, por exemplo, o NetBSD " +"1.4.2." + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:154 +msgid "" +"As bugs are found in a RELEASE version, they are fixed, and the fixes are " +"added to the SVN tree. In FreeBSD, the resultant version is called the " +"_STABLE_ version, while in NetBSD and OpenBSD it continues to be called the " +"RELEASE version. Smaller new features can also be added to this branch after " +"a period of test in the CURRENT branch. Security and other important bug " +"fixes are also applied to all supported RELEASE versions." +msgstr "" +"A medida que os erros são encontrados em uma versão RELEASE, eles são " +"corrigidos e as correções são adicionadas ao repositório SVN. No FreeBSD, a " +"versão resultante é chamada de _STABLE_, enquanto no NetBSD e OpenBSD " +"continua sendo chamada de versão RELEASE. Novos recursos menores também " +"podem ser adicionados a essa branch após um período de teste na branch " +"CURRENT. Patches de segurança e outras correções de bugs importantes também " +"são aplicadas a todas as versões RELEASE suportadas." + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:161 +msgid "" +"_By contrast, Linux maintains two separate code trees: the stable version " +"and the development version. Stable versions have an even minor version " +"number, such as 2.0, 2.2 or 2.4. Development versions have an odd minor " +"version number, such as 2.1, 2.3 or 2.5. In each case, the number is " +"followed by a further number designating the exact release. In addition, " +"each vendor adds their own userland programs and utilities, so the name of " +"the distribution is also important. Each distribution vendor also assigns " +"version numbers to the distribution, so a complete description might be " +"something like \"TurboLinux 6.0 with kernel 2.2.14\"_" +msgstr "" +"_Por outro lado, o Linux mantém duas árvores de código separadas: a versão " +"estável e a versão de desenvolvimento. Versões estáveis têm um número de " +"versão menor par, como por exemplo 2.0, 2.2 ou 2.4. Versões de " +"desenvolvimento têm um número de versão menor ímpar, como por exemplo 2.1, " +"2.3 ou 2.5. Em cada caso, o número é seguido por um outro número que designa " +"a release exata. Além disso, cada fornecedor adiciona seus próprios " +"programas e utilitários de área de usuário, portanto, o nome da distribuição " +"também é importante. Cada fornecedor de distribuição também atribui números " +"de versão à distribuição, portanto, uma descrição completa seria algo como " +"\"TurboLinux 6.0 com kernel 2.2.14 \"._" + +#. type: Title === +#: documentation/content/en/articles/explaining-bsd/_index.adoc:162 +#, no-wrap +msgid "What versions of BSD are available?" +msgstr "Quais versões do BSD estão disponíveis?" + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:165 +msgid "" +"In contrast to the numerous Linux distributions, there are only four major " +"open source BSDs. Each BSD project maintains its own source tree and its own " +"kernel. In practice, though, there appear to be fewer divergences between " +"the userland code of the projects than there is in Linux." +msgstr "" +"Em contraste com as numerosas distribuições do Linux, existem apenas quatro " +"grandes distribuições BSD de código aberto. Cada projeto BSD mantém seu " +"próprio repositório de código fonte e o seu próprio kernel. Porém na " +"prática, parece haver menos divergências do código entre os projetos BSD do " +"que no Linux." + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:167 +msgid "" +"It is difficult to categorize the goals of each project: the differences are " +"very subjective. Basically," +msgstr "" +"É difícil categorizar os objetivos de cada projeto: as diferenças são muito " +"subjetivas. Basicamente," + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:169 +msgid "" +"FreeBSD aims for high performance and ease of use by end users, and is a " +"favourite of web content providers. It runs on a link:https://www.FreeBSD." +"org/platforms/[number of platforms] and has significantly more users than " +"the other projects." +msgstr "" +"O FreeBSD visa o alto desempenho e a facilidade de uso pelos usuários " +"finais, e é um dos favoritos dos provedores de conteúdo da web. Ele pode ser " +"executado em link:www.FreeBSD.org/platforms/[diversas plataformas] e tem " +"significativamente mais usuários do que os outros projetos." + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:170 +msgid "" +"NetBSD aims for maximum portability: \"of course it runs NetBSD\". It runs " +"on machines from palmtops to large servers, and has even been used on NASA " +"space missions. It is a particularly good choice for running on old non-" +"Intel(R) hardware." +msgstr "" +"O NetBSD visa a máxima portabilidade: \"é claro que roda o NetBSD\". Ele " +"pode ser executado em diversas plataformas de hardware, de palmtops até " +"grandes servidores, e até mesmo já foi usado em missões espaciais da NASA. É " +"uma escolha particularmente boa para rodar em hardware antigo que não seja " +"Intel(R)." + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:171 +msgid "" +"OpenBSD aims for security and code purity: it uses a combination of the open " +"source concept and rigorous code reviews to create a system which is " +"demonstrably correct, making it the choice of security-conscious " +"organizations such as banks, stock exchanges and US Government departments. " +"Like NetBSD, it runs on a number of platforms." +msgstr "" +"O OpenBSD visa a segurança e a pureza de código: ele usa uma combinação do " +"conceito de código aberto ao de revisões rigorosas de código para criar um " +"sistema que seja comprovadamente correto, tornando-o a escolha preferida de " +"organizações preocupadas com segurança, tais como bancos, bolsas de valores " +"e departamentos do governo dos EUA. Tal como o NetBSD, ele pode ser " +"executado em várias plataformas." + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:172 +msgid "" +"DragonFlyBSD aims for high performance and scalability under everything from " +"a single-node UP system to a massively clustered system. DragonFlyBSD has " +"several long-range technical goals, but focus lies on providing a SMP-" +"capable infrastructure that is easy to understand, maintain and develop for." +msgstr "" +"O DragonFlyBSD tem como objetivo o alto desempenho e a escalabilidade sob " +"todos os aspectos, desde um sistema de um único nó até um sistema altamente " +"clusterizado. O DragonFlyBSD tem várias metas técnicas de longo prazo, mas o " +"foco está em fornecer uma infraestrutura compatível com SMP que seja fácil " +"de entender, manter e desenvolver." + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:174 +msgid "" +"There are also two additional BSD UNIX(R) operating systems which are not " +"open source, BSD/OS and Apple's Mac OS(R) X:" +msgstr "" +"Também existem dois sistemas operacionais BSD UNIX(R) que não são de código " +"aberto, o BSD/OS e Mac OS(R) X da Apple:" + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:176 +msgid "" +"BSD/OS was the oldest of the 4.4BSD derivatives. It was not open source, " +"though source code licenses were available at relatively low cost. It " +"resembled FreeBSD in many ways. Two years after the acquisition of BSDi by " +"Wind River Systems, BSD/OS failed to survive as an independent product. " +"Support and source code may still be available from Wind River, but all new " +"development is focused on the VxWorks embedded operating system." +msgstr "" +"O BSD/OS foi o mais antigo dos sistemas derivados do 4.4BSD. Não era um " +"sistema de código aberto, embora as licenças do código-fonte estivessem " +"disponíveis a um custo relativamente baixo. Assemelhava-se ao FreeBSD de " +"várias maneiras. Dois anos após a aquisição da BSDi pela Wind River Systems, " +"o BSD/OS não conseguiu sobreviver como um produto independente. O suporte e " +"o código-fonte ainda podem estar disponíveis por parte da Wind River, mas " +"todo desenvolvimento novo está focado no sistema operacional embarcado " +"VxWorks." + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:177 +msgid "" +"http://www.apple.com/macosx/server/[Mac OS(R) X] is the latest version of " +"the operating system for Apple(R)'s Mac(R) line. The BSD core of this " +"operating system, http://developer.apple.com/darwin/[Darwin], is available " +"as a fully functional open source operating system for x86 and PPC " +"computers. The Aqua/Quartz graphics system and many other proprietary " +"aspects of Mac OS(R) X remain closed-source, however. Several Darwin " +"developers are also FreeBSD committers, and vice-versa." +msgstr "" +"O http://www.apple.com/macosx/server/[Mac OS(R) X] é a versão mais recente " +"do sistema operacional para os equipamentos Mac(R) da Apple(R). O núcleo BSD " +"deste sistema operacional, http://developer.apple.com/darwin/[Darwin], está " +"disponível como um sistema operacional de código aberto totalmente funcional " +"para computadores x86 e PPC. No entanto, o sistema gráfico Aqua/Quartz e " +"muitos outros aspectos proprietários do Mac OS(R) X continuam fechados. " +"Vários desenvolvedores do Darwin também são committers do FreeBSD, e vice-" +"versa." + +#. type: Title === +#: documentation/content/en/articles/explaining-bsd/_index.adoc:178 +#, no-wrap +msgid "How does the BSD license differ from the GNU Public license?" +msgstr "Como a licença BSD difere da licença GNU Publica?" + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:184 +msgid "" +"Linux is available under the http://www.fsf.org/copyleft/gpl.html[GNU " +"General Public License] (GPL), which is designed to eliminate closed source " +"software. In particular, any derivative work of a product released under " +"the GPL must also be supplied with source code if requested. By contrast, " +"the http://www.opensource.org/licenses/bsd-license.html[BSD license] is less " +"restrictive: binary-only distributions are allowed. This is particularly " +"attractive for embedded applications." +msgstr "" +"O Linux está disponível sob a http://www.fsf.org/copyleft/gpl.html[Licença " +"Pública Geral GNU] (GPL), que é projetada para eliminar o software de código " +"fechado. Em particular, qualquer trabalho derivado de um produto lançado sob " +"a GPL também deve ser fornecido com o código fonte, se solicitado. Por outro " +"lado, a http://www.opensource.org/licenses/bsd-license.html[licença BSD] é " +"menos restritiva: é permitida a distribuição somente dos binários. O que é " +"particularmente atraente para aplicativos embarcados." + +#. type: Title === +#: documentation/content/en/articles/explaining-bsd/_index.adoc:185 +#, no-wrap +msgid "What else should I know?" +msgstr "O que mais eu deveria saber?" + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:190 +msgid "" +"Since fewer applications are available for BSD than Linux, the BSD " +"developers created a Linux compatibility package, which allows Linux " +"programs to run under BSD. The package includes both kernel modifications, " +"in order to correctly perform Linux system calls, and Linux compatibility " +"files such as the C library. There is no noticeable difference in execution " +"speed between a Linux application running on a Linux machine and a Linux " +"application running on a BSD machine of the same speed." +msgstr "" +"Como menos aplicativos estão disponíveis para o BSD do que para o Linux, os " +"desenvolvedores do BSD criaram um pacote de compatibilidade com o Linux, o " +"qual permite que os programas Linux sejam executados sob o BSD. O pacote " +"inclui tanto as modificações do kernel, necessárias para executar " +"corretamente as chamadas do sistema Linux e quanto os arquivos de " +"compatibilidade do Linux, como a biblioteca C. Não há diferença perceptível " +"na velocidade de execução entre um aplicativo Linux em execução em uma " +"máquina Linux nativa e um aplicativo Linux em execução em uma máquina BSD, " +"contanto que ambas tenham o mesmo hardware." + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:193 +msgid "" +"The \"all from one supplier\" nature of BSD means that upgrades are much " +"easier to handle than is frequently the case with Linux. BSD handles " +"library version upgrades by providing compatibility modules for earlier " +"library versions, so it is possible to run binaries which are several years " +"old with no problems." +msgstr "" +"A natureza do BSD de ser um sistema em que tudo é provido por \"um único " +"fornecedor\" significa que as atualizações são muito mais fáceis de se lidar " +"do que frequentemente ocorre no caso no Linux. O BSD lida com as " +"atualizações das versões das bibliotecas fornecendo módulos de " +"compatibilidade para as versões anteriores, portanto, é possível executar " +"binários bastante antigos sem problemas." + +#. type: Title === +#: documentation/content/en/articles/explaining-bsd/_index.adoc:194 +#, no-wrap +msgid "Which should I use, BSD or Linux?" +msgstr "Qual devo usar, BSD ou Linux?" + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:197 +msgid "" +"What does this all mean in practice? Who should use BSD, who should use " +"Linux?" +msgstr "" +"O que tudo isso significa na prática? Quem deve usar o BSD, quem deve usar o " +"Linux?" + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:200 +msgid "This is a very difficult question to answer. Here are some guidelines:" +msgstr "" +"Esta é uma pergunta muito difícil de responder. Aqui estão algumas " +"diretrizes:" + +#. type: Plain text +#: documentation/content/en/articles/explaining-bsd/_index.adoc:202 +msgid "" +"\"If it ain't broke, don't fix it\": If you already use an open source " +"operating system, and you are happy with it, there is probably no good " +"reason to change." *** 87 LINES SKIPPED *** From owner-dev-commits-doc-all@freebsd.org Fri Jun 11 05:56:43 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D0AF76592D8 for ; Fri, 11 Jun 2021 05:56:43 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G1VTl5M7Gz3lps; Fri, 11 Jun 2021 05:56:43 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 9C4D11D376; Fri, 11 Jun 2021 05:56:43 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 15B5uhCe057812; Fri, 11 Jun 2021 05:56:43 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 15B5uhof057811; Fri, 11 Jun 2021 05:56:43 GMT (envelope-from git) Date: Fri, 11 Jun 2021 05:56:43 GMT Message-Id: <202106110556.15B5uhof057811@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Ruey-Cherng Yu Subject: git: 93ddb27724 - main - - Traditional Chinese Translation of the news items (April and May 2021 ) - fix typo. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: rcyu X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 93ddb277241a05f2de3b6f193a2325f045d14967 Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2021 05:56:43 -0000 The branch main has been updated by rcyu: URL: https://cgit.FreeBSD.org/doc/commit/?id=93ddb277241a05f2de3b6f193a2325f045d14967 commit 93ddb277241a05f2de3b6f193a2325f045d14967 Author: Ruey-Cherng Yu AuthorDate: 2021-06-11 05:55:04 +0000 Commit: Ruey-Cherng Yu CommitDate: 2021-06-11 05:55:04 +0000 - Traditional Chinese Translation of the news items (April and May 2021 ) - fix typo. --- website/data/zh-tw/news/news.toml | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/website/data/zh-tw/news/news.toml b/website/data/zh-tw/news/news.toml index 396f3977b4..b8d1b7da5b 100644 --- a/website/data/zh-tw/news/news.toml +++ b/website/data/zh-tw/news/news.toml @@ -1,6 +1,23 @@ # Sort news by year, month and day # $FreeBSD$ +[[news]] +date = "2021-05-17" +description = "增加提交權限: Guangyuan Yang (doc, ports)" + +[[news]] +date = "2021-05-06" +title = "2021 第一季開發進度報告發布" +description = "2021 第一季開發進度報告 28 則條目現已發布。" + +[[news]] +date = "2021-04-29" +description = "新任 committer: Charlie Li (ports)" + +[[news]] +date = "2021-04-21" +description = "新任 committer: Oskar Holmlund (src)" + [[news]] date = "2021-04-13" title = "FreeBSD 13.0-RELEASE 發布了" @@ -83,7 +100,7 @@ description = "新任 committer: Lewis Cook [[news]] date = "2021-01-16" title = "2020 第四季開發進度報告發布" -description = "The 2020 第四季開發進度報告 42 則條目現已發布。" +description = " 2020 第四季開發進度報告 42 則條目現已發布。" [[news]] date = "2021-01-14" From owner-dev-commits-doc-all@freebsd.org Fri Jun 11 20:53:37 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9FCB7664C8B for ; Fri, 11 Jun 2021 20:53:37 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G1tNd3vVzz4h4P; Fri, 11 Jun 2021 20:53:37 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 6E2D729C13; Fri, 11 Jun 2021 20:53:37 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 15BKrbJ6056905; Fri, 11 Jun 2021 20:53:37 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 15BKrbrd056904; Fri, 11 Jun 2021 20:53:37 GMT (envelope-from git) Date: Fri, 11 Jun 2021 20:53:37 GMT Message-Id: <202106112053.15BKrbrd056904@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Brad Davis Subject: git: a65739f26e - main - Update links and wording referencing the arm mailing list MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: brd X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: a65739f26ed1ac1f2a69220ce36c74db14263346 Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2021 20:53:37 -0000 The branch main has been updated by brd: URL: https://cgit.FreeBSD.org/doc/commit/?id=a65739f26ed1ac1f2a69220ce36c74db14263346 commit a65739f26ed1ac1f2a69220ce36c74db14263346 Author: Brad Davis AuthorDate: 2021-06-11 20:52:14 +0000 Commit: Brad Davis CommitDate: 2021-06-11 20:52:14 +0000 Update links and wording referencing the arm mailing list --- website/content/en/platforms/arm.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/website/content/en/platforms/arm.adoc b/website/content/en/platforms/arm.adoc index 6531aa353e..f9a92a806e 100644 --- a/website/content/en/platforms/arm.adoc +++ b/website/content/en/platforms/arm.adoc @@ -10,7 +10,7 @@ include::shared/en/urls.adoc[] == Introduction -This page contains information about the FreeBSD port to the 32- and 64-bit ARM architectures and hardware. Discussion of the ARM ports takes place on the https://lists.freebsd.org/mailman/listinfo/freebsd-arm[freebsd-arm] mailing list. +This page contains information about the FreeBSD port to the 32- and 64-bit ARM architectures and hardware. Discussion of the ARM ports takes place on the https://lists.freebsd.org/archives/freebsd-arm[freebsd-arm] mailing list. == Table Of Contents @@ -120,4 +120,4 @@ Note that not all peripherals are supported on all boards. [[list]] == FreeBSD/ARM mailing list -To subscribe to this list, send mail to `` or visit http://lists.FreeBSD.org/mailman/listinfo/freebsd-arm[mailman interface]. +To subscribe to this list, send mail to `` or visit the http://lists.FreeBSD.org/subscription/freebsd-arm[web interface]. From owner-dev-commits-doc-all@freebsd.org Fri Jun 11 20:56:54 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E2266664AC4 for ; Fri, 11 Jun 2021 20:56:54 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G1tSQ5tYbz4h74; Fri, 11 Jun 2021 20:56:54 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id AE82B29C18; Fri, 11 Jun 2021 20:56:54 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 15BKusfH057254; Fri, 11 Jun 2021 20:56:54 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 15BKusd6057253; Fri, 11 Jun 2021 20:56:54 GMT (envelope-from git) Date: Fri, 11 Jun 2021 20:56:54 GMT Message-Id: <202106112056.15BKusd6057253@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Brad Davis Subject: git: 102c8449c1 - main - Update the status to reflect the changes in tier status for some of the different ARM platforms MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: brd X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 102c8449c17b6e47c13634f4ac6f54c54a0a0990 Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2021 20:56:54 -0000 The branch main has been updated by brd: URL: https://cgit.FreeBSD.org/doc/commit/?id=102c8449c17b6e47c13634f4ac6f54c54a0a0990 commit 102c8449c17b6e47c13634f4ac6f54c54a0a0990 Author: Brad Davis AuthorDate: 2021-06-11 20:56:43 +0000 Commit: Brad Davis CommitDate: 2021-06-11 20:56:43 +0000 Update the status to reflect the changes in tier status for some of the different ARM platforms --- website/content/en/platforms/arm.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/website/content/en/platforms/arm.adoc b/website/content/en/platforms/arm.adoc index f9a92a806e..1140e73c3f 100644 --- a/website/content/en/platforms/arm.adoc +++ b/website/content/en/platforms/arm.adoc @@ -24,9 +24,9 @@ This page contains information about the FreeBSD port to the 32- and 64-bit ARM [[status]] == Status -32-bit ARM is officially a link:{committers-guide}#archs[Tier 2] architecture, as the link:../../[FreeBSD] project does not provide official releases or pre-built packages for this platform due to it primarily targeting the embedded arena. However, FreeBSD/ARM is being actively developed and maintained, is well supported, and provides an excellent framework for building ARM-based systems. FreeBSD/arm supports ARMv4 and ARMv5 processors. FreeBSD/armv6 supports ARMv6 and ARMv7 processors, including SMP on the latter. +32-bit ARMv6 and ARMv7 is officially a link:{committers-guide}#archs[Tier 2] architecture, as the link:../../[FreeBSD] project does not provide official releases or pre-built packages for this platform due to it primarily targeting the embedded arena. However, FreeBSD/ARM is being actively developed and maintained, is well supported, and provides an excellent framework for building ARM-based systems. FreeBSD/arm supported ARMv4 and ARMv5 processors, and is deprecated as of 13.0. FreeBSD/armv7 includes SMP support. -Initial support for 64-bit ARM is complete. 64-bit ARM platforms follow a set of standard conventions, and a single FreeBSD build will work on hardware from multiple vendors. As a result, FreeBSD will provide official releases for FreeBSD/arm64 and packages will be available. FreeBSD/arm64 is on the path to becoming a link:{committers-guide}#archs[Tier 1] architecture. +FreeBSD/arm64 supports 64-bit ARMv8 processors and is a link:{committers-guide}#archs[Tier 1] architecture as of 13.0. 64-bit ARM platforms follow a set of standard conventions, and a single FreeBSD build will work on hardware from multiple vendors. As a result, FreeBSD provides official releases for FreeBSD/arm64 and packages are available. [[hw]] == FreeBSD/ARM Hardware Notes From owner-dev-commits-doc-all@freebsd.org Fri Jun 11 22:14:31 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 86F70665A2C for ; Fri, 11 Jun 2021 22:14:31 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G1w9z357Jz4lPb; Fri, 11 Jun 2021 22:14:31 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 51BA72ADA4; Fri, 11 Jun 2021 22:14:31 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 15BMEVAi063803; Fri, 11 Jun 2021 22:14:31 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 15BMEVGX063802; Fri, 11 Jun 2021 22:14:31 GMT (envelope-from git) Date: Fri, 11 Jun 2021 22:14:31 GMT Message-Id: <202106112214.15BMEVGX063802@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Warner Losh Subject: git: bcbdcf52ce - main - Move the developer-centric bits from handbook/mirrors to committers-guide MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: imp X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: bcbdcf52ce6535afa5da0cb48b1575ab8d071990 Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2021 22:14:31 -0000 The branch main has been updated by imp: URL: https://cgit.FreeBSD.org/doc/commit/?id=bcbdcf52ce6535afa5da0cb48b1575ab8d071990 commit bcbdcf52ce6535afa5da0cb48b1575ab8d071990 Author: Warner Losh AuthorDate: 2021-06-11 18:10:07 +0000 Commit: Warner Losh CommitDate: 2021-06-11 22:13:39 +0000 Move the developer-centric bits from handbook/mirrors to committers-guide The developer centric bits of how to interact with the project belong in the committer's guide, not in the handbook, so move it there. Reviewed by: gjb,debdrup Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D30739 --- .../en/articles/committers-guide/_index.adoc | 101 +++++++++++++++++++- .../content/en/books/handbook/mirrors/_index.adoc | 102 +-------------------- 2 files changed, 101 insertions(+), 102 deletions(-) diff --git a/documentation/content/en/articles/committers-guide/_index.adoc b/documentation/content/en/articles/committers-guide/_index.adoc index 835f28cf99..63f2db466e 100644 --- a/documentation/content/en/articles/committers-guide/_index.adoc +++ b/documentation/content/en/articles/committers-guide/_index.adoc @@ -302,6 +302,105 @@ The goal of this section is to highlight those bits of Git needed to track sourc They assume a basic understanding of Git. There are many primers for Git on the web, but the https://git-scm.com/book/en/v2[Git Book] provides one of the better treatments. +[[git-mini-primer-getting-started]] +==== Getting Started For Developers + +This section describes the read-write access for committers to push the commits from developers or contributors. + +===== Daily use + +* Clone the repository: ++ +[source,shell] +.... +% git clone -o freebsd --config remote.freebsd.fetch='+refs/notes/*:refs/notes/*' https://git.freebsd.org/${repo}.git +.... ++ +Then you should have the official mirrors as your remote: ++ +[source,shell] +.... +% git remote -v +freebsd https://git.freebsd.org/${repo}.git (fetch) +freebsd https://git.freebsd.org/${repo}.git (push) +.... + +* Configure the FreeBSD committer data: ++ +The commit hook in repo.freebsd.org checks the "Commit" field matches the committer's information in FreeBSD.org. +The easiest way to get the suggested config is by executing `/usr/local/bin/gen-gitconfig.sh` script on freefall: ++ +[source,shell] +.... +% gen-gitconfig.sh +[...] +% git config user.name (your name in gecos) +% git config user.email (your login)@FreeBSD.org +.... + +* Set the push URL: ++ +[source,shell] +.... +% git remote set-url --push freebsd git@gitrepo.freebsd.org:${repo}.git +.... ++ +Then you should have separated fetch and push URLs as the most efficient setup: ++ +[source,shell] +.... +% git remote -v +freebsd https://git.freebsd.org/${repo}.git (fetch) +freebsd git@gitrepo.freebsd.org:${repo}.git (push) +.... ++ +Again, note that `gitrepo.freebsd.org` will be canonicalized to `repo.freebsd.org` in the future. + +* Install commit message template hook: ++ +[source,shell] +.... +% fetch https://cgit.freebsd.org/src/plain/tools/tools/git/hooks/prepare-commit-msg -o .git/hooks +% chmod 755 .git/hooks/prepare-commit-msg +.... + +[[admin-branch]] +===== "admin" branch + +The `access` and `mentors` files are stored in an orphan branch, `internal/admin`, in each repository. + +Following example is how to check out the `internal/admin` branch to a local branch named `admin`: + +[source,shell] +.... +% git config --add remote.freebsd.fetch '+refs/internal/*:refs/internal/*' +% git fetch +% git checkout -b admin internal/admin +.... +Alternatively, you can add a worktree for the `admin` branch: + +[source,shell] +.... +git worktree add -b admin ../${repo}-admin internal/admin +.... + +For browsing `internal/admin` branch on web: +https://cgit.freebsd.org/${repo}/log/?h=internal/admin + +For pushing, either specify the full refspec: + +[source,shell] +.... +git push freebsd HEAD:refs/internal/admin +.... + +Or set `push.default` to `freebsd` which will make `git push` to push the current branch back to its upstream by default, which is more suitable for our workflow: + +[source,shell] +.... +git config push.default freebsd +.... + ==== Keeping Current With The FreeBSD src Tree [[keeping_current]] First step: cloning a tree. @@ -2483,7 +2582,7 @@ Document that approval with an `Approved by:` line in the commit message. When the mentor decides that a mentee has learned the ropes and is ready to commit on their own, the mentor announces it with a commit to [.filename]#mentors#. This file is in the [.filename]#admin# orphan branch of each repository. -Detailed information on how to access these branches can be found in link:{handbook}mirror/#admin-branch["admin" branch]. +Detailed information on how to access these branches can be found in <>. [[pre-commit-review]] == Pre-Commit Review diff --git a/documentation/content/en/books/handbook/mirrors/_index.adoc b/documentation/content/en/books/handbook/mirrors/_index.adoc index b709efaadf..501a30f77a 100644 --- a/documentation/content/en/books/handbook/mirrors/_index.adoc +++ b/documentation/content/en/books/handbook/mirrors/_index.adoc @@ -571,107 +571,7 @@ The GeoDNS should direct you to the nearest mirror to you. === For Developers -This section describes the read-write access for committers to push the commits from developers or contributors. -For read-only access, please refer to the users section above. - -==== Daily use - -* Clone the repository: -+ -[source,shell] -.... -% git clone -o freebsd --config remote.freebsd.fetch='+refs/notes/*:refs/notes/*' https://git.freebsd.org/${repo}.git -.... -+ -Then you should have the official mirrors as your remote: -+ -[source,shell] -.... -% git remote -v -freebsd https://git.freebsd.org/${repo}.git (fetch) -freebsd https://git.freebsd.org/${repo}.git (push) -.... - -* Configure the FreeBSD committer data: -+ -The commit hook in repo.freebsd.org checks the "Commit" field matches the committer's information in FreeBSD.org. -The easiest way to get the suggested config is by executing `/usr/local/bin/gen-gitconfig.sh` script on freefall: -+ -[source,shell] -.... -% gen-gitconfig.sh -[...] -% git config user.name (your name in gecos) -% git config user.email (your login)@FreeBSD.org -.... - -* Set the push URL: -+ -[source,shell] -.... -% git remote set-url --push freebsd git@gitrepo.freebsd.org:${repo}.git -.... -+ -Then you should have separated fetch and push URLs as the most efficient setup: -+ -[source,shell] -.... -% git remote -v -freebsd https://git.freebsd.org/${repo}.git (fetch) -freebsd git@gitrepo.freebsd.org:${repo}.git (push) -.... -+ -Again, note that `gitrepo.freebsd.org` will be canonicalized to `repo.freebsd.org` in the future. - -* Install commit message template hook: -+ -[source,shell] -.... -% fetch https://cgit.freebsd.org/src/plain/tools/tools/git/hooks/prepare-commit-msg -o .git/hooks -% chmod 755 .git/hooks/prepare-commit-msg -.... - -[[admin-branch]] -==== "admin" branch - -The `access` and `mentors` files are stored in an orphan branch, `internal/admin`, in each repository. - -Following example is how to check out the `internal/admin` branch to a local branch named `admin`: - -[source,shell] -.... -% git config --add remote.freebsd.fetch '+refs/internal/*:refs/internal/*' -% git fetch -% git checkout -b admin internal/admin -.... -Alternatively, you can add a worktree for the `admin` branch: - -[source,shell] -.... -git worktree add -b admin ../${repo}-admin internal/admin -.... - -For browsing `internal/admin` branch on web: -https://cgit.freebsd.org/${repo}/log/?h=internal/admin - -For pushing, either specify the full refspec: - -[source,shell] -.... -git push freebsd HEAD:refs/internal/admin -.... - -Or set `push.default` to `upstream` which will make `git push` to push the current branch back to its upstream by default, which is more suitable for our workflow: - -[source,shell] -.... -git config push.default upstream -.... - -[WARNING] -==== -These internal details may change often. -==== +Please see the link:{committers-guide}#git-mini-primer[Committer's Guide]. [[external-mirrors]] === External mirrors From owner-dev-commits-doc-all@freebsd.org Sat Jun 12 12:28:42 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9868864AD60 for ; Sat, 12 Jun 2021 12:28:42 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G2H7Z3QXHz4k4m; Sat, 12 Jun 2021 12:28:42 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 57EFE61EC; Sat, 12 Jun 2021 12:28:42 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 15CCSgJR092412; Sat, 12 Jun 2021 12:28:42 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 15CCSgcF092411; Sat, 12 Jun 2021 12:28:42 GMT (envelope-from git) Date: Sat, 12 Jun 2021 12:28:42 GMT Message-Id: <202106121228.15CCSgcF092411@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: "Danilo G. Baio" Subject: git: aaa5068963 - main - hugo: Ignore gettext po files when building MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: dbaio X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: aaa5068963ef84e55bc9c24229741719cb76648b Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2021 12:28:42 -0000 The branch main has been updated by dbaio: URL: https://cgit.FreeBSD.org/doc/commit/?id=aaa5068963ef84e55bc9c24229741719cb76648b commit aaa5068963ef84e55bc9c24229741719cb76648b Author: Danilo G. Baio AuthorDate: 2021-06-12 12:27:12 +0000 Commit: Danilo G. Baio CommitDate: 2021-06-12 12:27:12 +0000 hugo: Ignore gettext po files when building --- documentation/config/_default/config.toml | 2 +- website/config/_default/config.toml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/documentation/config/_default/config.toml b/documentation/config/_default/config.toml index 9fbd8c26a0..6a2b641c73 100644 --- a/documentation/config/_default/config.toml +++ b/documentation/config/_default/config.toml @@ -11,7 +11,7 @@ theme = "beastie" disableKinds = [ "taxonomy", "taxonomyTerm" ] authors = [ "carlavilla@FreeBSD.org" ] preserveTOC = true -ignoreFiles = [ "chapters-order.adoc$", "toc.adoc$", "toc-tables.adoc$", "toc-figures.adoc$", "toc-examples.adoc$", "toc-1.adoc$", "toc-2.adoc$", "toc-3.adoc$", "toc-4.adoc$", "toc-5.adoc$", "books.adoc$", "chapter.adoc$" ] +ignoreFiles = [ "chapters-order.adoc$", "toc.adoc$", "toc-tables.adoc$", "toc-figures.adoc$", "toc-examples.adoc$", "toc-1.adoc$", "toc-2.adoc$", "toc-3.adoc$", "toc-4.adoc$", "toc-5.adoc$", "books.adoc$", "chapter.adoc$", "\\.po$" ] enableRobotsTXT = true [params] diff --git a/website/config/_default/config.toml b/website/config/_default/config.toml index cc754900b3..272afe11ed 100644 --- a/website/config/_default/config.toml +++ b/website/config/_default/config.toml @@ -10,7 +10,7 @@ disableKinds = [ "taxonomy", "taxonomyTerm" ] disableLanguages = ["tr", "el"] disablePathToLower = true authors = [ "carlavilla@FreeBSD.org" ] -ignoreFiles = [ "report-sample.md$" ] +ignoreFiles = [ "\\.po$" ] enableRobotsTXT = true preserveTOC = true From owner-dev-commits-doc-all@freebsd.org Sat Jun 12 15:02:15 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5912564D215 for ; Sat, 12 Jun 2021 15:02:15 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G2LXl1tc6z4tdl; Sat, 12 Jun 2021 15:02:15 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 2855D103EC; Sat, 12 Jun 2021 15:02:15 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 15CF2FZd005088; Sat, 12 Jun 2021 15:02:15 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 15CF2Fm6005087; Sat, 12 Jun 2021 15:02:15 GMT (envelope-from git) Date: Sat, 12 Jun 2021 15:02:15 GMT Message-Id: <202106121502.15CF2Fm6005087@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Sergio Carlavilla Delgado Subject: git: b766aad819 - main - Use One Sentence Per Line in the FAQ MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: carlavilla X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: b766aad81955ca8746248a67b3fa85148f0134ae Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2021 15:02:15 -0000 The branch main has been updated by carlavilla: URL: https://cgit.FreeBSD.org/doc/commit/?id=b766aad81955ca8746248a67b3fa85148f0134ae commit b766aad81955ca8746248a67b3fa85148f0134ae Author: Sergio Carlavilla Delgado AuthorDate: 2021-06-12 15:01:13 +0000 Commit: Sergio Carlavilla Delgado CommitDate: 2021-06-12 15:01:13 +0000 Use One Sentence Per Line in the FAQ --- documentation/content/en/books/faq/_index.adoc | 1204 ++++++++++++++++++------ 1 file changed, 896 insertions(+), 308 deletions(-) diff --git a/documentation/content/en/books/faq/_index.adoc b/documentation/content/en/books/faq/_index.adoc index 5f5554c60f..852fbf7ce6 100644 --- a/documentation/content/en/books/faq/_index.adoc +++ b/documentation/content/en/books/faq/_index.adoc @@ -73,9 +73,11 @@ endif::[] [.abstract-title] Abstract -This is the Frequently Asked Questions (FAQ) for FreeBSD versions {rel-relx}, {rel2-relx}, and {rel3-relx}. Every effort has been made to make this FAQ as informative as possible; if you have any suggestions as to how it may be improved, send them to the {freebsd-doc}. +This is the Frequently Asked Questions (FAQ) for FreeBSD versions {rel-relx}, {rel2-relx}, and {rel3-relx}. +Every effort has been made to make this FAQ as informative as possible; if you have any suggestions as to how it may be improved, send them to the {freebsd-doc}. -The latest version of this document is always available from the link:{faq}[FreeBSD website]. It may also be downloaded as one large link:.[HTML] file with HTTP or as a variety of other formats from the https://download.freebsd.org/ftp/doc/[FreeBSD FTP server]. +The latest version of this document is always available from the link:{faq}[FreeBSD website]. +It may also be downloaded as one large link:.[HTML] file with HTTP or as a variety of other formats from the https://download.freebsd.org/ftp/doc/[FreeBSD FTP server]. ''' @@ -89,7 +91,9 @@ toc::[] FreeBSD is a modern operating system for desktops, laptops, servers, and embedded systems with support for a large number of https://www.FreeBSD.org/platforms/[platforms]. -It is based on U.C. Berkeley's "4.4BSD-Lite" release, with some "4.4BSD-Lite2" enhancements. It is also based indirectly on William Jolitz's port of U.C. Berkeley's "Net/2" to the i386(TM), known as "386BSD", though very little of the 386BSD code remains. +It is based on U.C. Berkeley's "4.4BSD-Lite" release, with some "4.4BSD-Lite2" enhancements. +It is also based indirectly on William Jolitz's port of U.C. Berkeley's "Net/2" to the i386(TM), known as "386BSD", +though very little of the 386BSD code remains. FreeBSD is used by companies, Internet Service Providers, researchers, computer professionals, students and home users all over the world in their work, education and recreation. @@ -103,26 +107,42 @@ The goal of the FreeBSD Project is to provide a stable and fast general purpose [[bsd-license-restrictions]] === Does the FreeBSD license have any restrictions? -Yes. Those restrictions do not control how the code is used, but how to treat the FreeBSD Project itself. The license itself is available at https://www.FreeBSD.org/copyright/freebsd-license/[license] and can be summarized like this: +Yes. Those restrictions do not control how the code is used, but how to treat the FreeBSD Project itself. +The license itself is available at https://www.FreeBSD.org/copyright/freebsd-license/[license] and can be summarized like this: * Do not claim that you wrote this. * Do not sue us if it breaks. * Do not remove or modify the license. -Many of us have a significant investment in the project and would certainly not mind a little financial compensation now and then, but we definitely do not insist on it. We believe that our first and foremost "mission" is to provide code to any and all comers, and for whatever purpose, so that the code gets the widest possible use and provides the widest possible benefit. This, we believe, is one of the most fundamental goals of Free Software and one that we enthusiastically support. +Many of us have a significant investment in the project and would certainly not mind a little financial compensation now and then, +but we definitely do not insist on it. +We believe that our first and foremost "mission" is to provide code to any and all comers, and for whatever purpose, so that the code gets the widest possible use and provides the widest possible benefit. +This, we believe, is one of the most fundamental goals of Free Software and one that we enthusiastically support. -Code in our source tree which falls under the https://www.FreeBSD.org/copyright/COPYING[GNU General Public License (GPL)] or https://www.FreeBSD.org/copyright/COPYING.LIB[GNU Library General Public License (LGPL)] comes with slightly more strings attached, though at least on the side of enforced access rather than the usual opposite. Due to the additional complexities that can evolve in the commercial use of GPL software, we do, however, endeavor to replace such software with submissions under the more relaxed https://www.FreeBSD.org/copyright/freebsd-license/[FreeBSD license] whenever possible. +Code in our source tree which falls under the https://www.FreeBSD.org/copyright/COPYING[GNU General Public License (GPL)] or https://www.FreeBSD.org/copyright/COPYING.LIB[GNU Library General Public License (LGPL)] comes with slightly more strings attached, though at least on the side of enforced access rather than the usual opposite. +Due to the additional complexities that can evolve in the commercial use of GPL software, we do, however, endeavor to replace such software with submissions under the more relaxed https://www.FreeBSD.org/copyright/freebsd-license/[FreeBSD license] whenever possible. [[replace-current-OS]] === Can FreeBSD replace my current operating system? For most people, yes. But this question is not quite that cut-and-dried. -Most people do not actually use an operating system. They use applications. The applications are what really use the operating system. FreeBSD is designed to provide a robust and full-featured environment for applications. It supports a wide variety of web browsers, office suites, email readers, graphics programs, programming environments, network servers, and much more. Most of these applications can be managed through the https://www.FreeBSD.org/ports/[Ports Collection]. +Most people do not actually use an operating system. +They use applications. +The applications are what really use the operating system. +FreeBSD is designed to provide a robust and full-featured environment for applications. +It supports a wide variety of web browsers, office suites, email readers, graphics programs, programming environments, network servers, and much more. +Most of these applications can be managed through the https://www.FreeBSD.org/ports/[Ports Collection]. -If an application is only available on one operating system, that operating system cannot just be replaced. Chances are, there is a very similar application on FreeBSD, however. As a solid office or Internet server or a reliable workstation, FreeBSD will almost certainly do everything you need. Many computer users across the world, including both novices and experienced UNIX(R) administrators, use FreeBSD as their only desktop operating system. +If an application is only available on one operating system, that operating system cannot just be replaced. +Chances are, there is a very similar application on FreeBSD, however. +As a solid office or Internet server or a reliable workstation, FreeBSD will almost certainly do everything you need. +Many computer users across the world, including both novices and experienced UNIX(R) administrators, use FreeBSD as their only desktop operating system. -Users migrating to FreeBSD from another UNIX(R)-like environment will find FreeBSD to be similar. Windows(R) and Mac OS(R) users may be interested in instead using https://www.ghostbsd.org/[GhostBSD], https://www.midnightbsd.org/[MidnightBSD] or https://www.nomadbsd.org/[NomadBSD] three FreeBSD-based desktop distributions. Non-UNIX(R) users should expect to invest some additional time learning the UNIX(R) way of doing things. This FAQ and the link:{handbook}[FreeBSD Handbook] are excellent places to start. +Users migrating to FreeBSD from another UNIX(R)-like environment will find FreeBSD to be similar. +Windows(R) and Mac OS(R) users may be interested in instead using https://www.ghostbsd.org/[GhostBSD], https://www.midnightbsd.org/[MidnightBSD] or https://www.nomadbsd.org/[NomadBSD] three FreeBSD-based desktop distributions. +Non-UNIX(R) users should expect to invest some additional time learning the UNIX(R) way of doing things. +This FAQ and the link:{handbook}[FreeBSD Handbook] are excellent places to start. [[why-called-FreeBSD]] === Why is it called FreeBSD? @@ -131,16 +151,21 @@ Users migrating to FreeBSD from another UNIX(R)-like environment will find FreeB * Full source for the operating system is freely available, and the minimum possible restrictions have been placed upon its use, distribution and incorporation into other work (commercial or non-commercial). * Anyone who has an improvement or bug fix is free to submit their code and have it added to the source tree (subject to one or two obvious provisions). -It is worth pointing out that the word "free" is being used in two ways here: one meaning "at no cost" and the other meaning "do whatever you like". Apart from one or two things you _cannot_ do with the FreeBSD code, for example pretending you wrote it, you can really do whatever you like with it. +It is worth pointing out that the word "free" is being used in two ways here: one meaning "at no cost" and the other meaning "do whatever you like". +Apart from one or two things you _cannot_ do with the FreeBSD code, for example pretending you wrote it, you can really do whatever you like with it. [[differences-to-other-bsds]] === What are the differences between FreeBSD and NetBSD, OpenBSD, and other open source BSD operating systems? -James Howard wrote a good explanation of the history and differences between the various projects, called https://jameshoward.us/archive/bsd-family-tree/[The BSD Family Tree] which goes a fair way to answering this question. Some of the information is out of date, but the history portion in particular remains accurate. +James Howard wrote a good explanation of the history and differences between the various projects, +called https://jameshoward.us/archive/bsd-family-tree/[The BSD Family Tree] which goes a fair way to answering this question. +Some of the information is out of date, but the history portion in particular remains accurate. -Most of the BSDs share patches and code, even today. All of the BSDs have common ancestry. +Most of the BSDs share patches and code, even today. +All of the BSDs have common ancestry. -The design goals of FreeBSD are described in <>, above. The design goals of the other most popular BSDs may be summarized as follows: +The design goals of FreeBSD are described in <>, above. +The design goals of the other most popular BSDs may be summarized as follows: * OpenBSD aims for operating system security above all else. The OpenBSD team wrote man:ssh[1] and man:pf[4], which have both been ported to FreeBSD. * NetBSD aims to be easily ported to other hardware platforms. @@ -149,34 +174,51 @@ The design goals of FreeBSD are described in <>, above. The desig [[latest-version]] === What is the latest version of FreeBSD? -At any point in the development of FreeBSD, there can be multiple parallel branches. {rel-relx} releases are made from the {rel-stable} branch, and {rel2-relx} releases are made from the {rel2-stable} branch. +At any point in the development of FreeBSD, there can be multiple parallel branches. +{rel-relx} releases are made from the {rel-stable} branch, and {rel2-relx} releases are made from the {rel2-stable} branch. -Up until the release of 12.0, the {rel2-relx} series was the one known as _-STABLE_. However, as of {rel-head-relx}, the {rel2-relx} branch will be designated for an "extended support" status and receive only fixes for major problems, such as security-related fixes. +Up until the release of 12.0, the {rel2-relx} series was the one known as _-STABLE_. +However, as of {rel-head-relx}, the {rel2-relx} branch will be designated for an "extended support" status and receive only fixes for major problems, such as security-related fixes. -Releases are made <>. While many people stay more up-to-date with the FreeBSD sources (see the questions on <> and <>) than that, doing so is more of a commitment, as the sources are a moving target. +Releases are made <>. +While many people stay more up-to-date with the FreeBSD sources (see the questions on <> and <>) than that, doing so is more of a commitment, as the sources are a moving target. More information on FreeBSD releases can be found on the https://www.FreeBSD.org/releng/#release-build[Release Engineering page] and in man:release[7]. [[current]] === What is _FreeBSD-CURRENT_? -link:{handbook}#current[FreeBSD-CURRENT] is the development version of the operating system, which will in due course become the new FreeBSD-STABLE branch. As such, it is really only of interest to developers working on the system and die-hard hobbyists. See the link:{handbook}#current[relevant section] in the link:{handbook}[Handbook] for details on running _-CURRENT_. +link:{handbook}#current[FreeBSD-CURRENT] is the development version of the operating system, which will in due course become the new FreeBSD-STABLE branch. +As such, it is really only of interest to developers working on the system and die-hard hobbyists. +See the link:{handbook}#current[relevant section] in the link:{handbook}[Handbook] for details on running _-CURRENT_. -Users not familiar with FreeBSD should not use FreeBSD-CURRENT. This branch sometimes evolves quite quickly and due to mistake can be un-buildable at times. People that use FreeBSD-CURRENT are expected to be able to analyze, debug, and report problems. +Users not familiar with FreeBSD should not use FreeBSD-CURRENT. +This branch sometimes evolves quite quickly and due to mistake can be un-buildable at times. +People that use FreeBSD-CURRENT are expected to be able to analyze, debug, and report problems. [[stable]] === What is the FreeBSD-STABLE concept? -_FreeBSD-STABLE_ is the development branch from which major releases are made. Changes go into this branch at a slower pace and with the general assumption that they have first been tested in FreeBSD-CURRENT. However, at any given time, the sources for FreeBSD-STABLE may or may not be suitable for general use, as it may uncover bugs and corner cases that were not yet found in FreeBSD-CURRENT. Users who do not have the resources to perform testing should instead run the most recent release of FreeBSD. _FreeBSD-CURRENT_, on the other hand, has been one unbroken line since 2.0 was released. +_FreeBSD-STABLE_ is the development branch from which major releases are made. +Changes go into this branch at a slower pace and with the general assumption that they have first been tested in FreeBSD-CURRENT. +However, at any given time, the sources for FreeBSD-STABLE may or may not be suitable for general use, +as it may uncover bugs and corner cases that were not yet found in FreeBSD-CURRENT. +Users who do not have the resources to perform testing should instead run the most recent release of FreeBSD. +_FreeBSD-CURRENT_, on the other hand, has been one unbroken line since 2.0 was released. -For more detailed information on branches see "link:{releng}#rel-branch[FreeBSD Release Engineering: Creating the Release Branch]", the status of the branches and the upcoming release schedule can be found on the https://www.FreeBSD.org/releng[Release Engineering Information] page. +For more detailed information on branches see "link:{releng}#rel-branch[FreeBSD Release Engineering: Creating the Release Branch]", +the status of the branches and the upcoming release schedule can be found on the https://www.FreeBSD.org/releng[Release Engineering Information] page. -Version https://download.FreeBSD.org/ftp/releases/amd64/amd64/{rel121-current}-RELEASE/[{rel121-current}] is the latest release from the {rel-stable} branch; it was released in {rel121-current-date}. Version https://download.FreeBSD.org/ftp/releases/amd64/amd64/{rel113-current}-RELEASE/[{rel113-current}] is the latest release from the {rel2-stable} branch; it was released in {rel113-current-date}. +Version https://download.FreeBSD.org/ftp/releases/amd64/amd64/{rel121-current}-RELEASE/[{rel121-current}] is the latest release from the {rel-stable} branch; it was released in {rel121-current-date}. +Version https://download.FreeBSD.org/ftp/releases/amd64/amd64/{rel113-current}-RELEASE/[{rel113-current}] is the latest release from the {rel2-stable} branch; it was released in {rel113-current-date}. [[release-freq]] === When are FreeBSD releases made? -The {re} releases a new major version of FreeBSD about every 18 months and a new minor version about every 8 months, on average. Release dates are announced well in advance, so that the people working on the system know when their projects need to be finished and tested. A testing period precedes each release, to ensure that the addition of new features does not compromise the stability of the release. Many users regard this caution as one of the best things about FreeBSD, even though waiting for all the latest goodies to reach _-STABLE_ can be a little frustrating. +The {re} releases a new major version of FreeBSD about every 18 months and a new minor version about every 8 months, on average. +Release dates are announced well in advance, so that the people working on the system know when their projects need to be finished and tested. +A testing period precedes each release, to ensure that the addition of new features does not compromise the stability of the release. +Many users regard this caution as one of the best things about FreeBSD, even though waiting for all the latest goodies to reach _-STABLE_ can be a little frustrating. More information on the release engineering process (including a schedule of upcoming releases) can be found on the https://www.FreeBSD.org/releng/[release engineering] pages on the FreeBSD Web site. @@ -185,14 +227,16 @@ For people who need or want a little more excitement, binary snapshots are made [[snapshot-freq]] === When are FreeBSD snapshots made? -FreeBSD link:https://www.FreeBSD.org/snapshots/[snapshot] releases are made based on the current state of the _-CURRENT_ and _-STABLE_ branches. The goals behind each snapshot release are: +FreeBSD link:https://www.FreeBSD.org/snapshots/[snapshot] releases are made based on the current state of the _-CURRENT_ and _-STABLE_ branches. +The goals behind each snapshot release are: * To test the latest version of the installation software. * To give people who would like to run _-CURRENT_ or _-STABLE_ but who do not have the time or bandwidth to follow it on a day-to-day basis an easy way of bootstrapping it onto their systems. * To preserve a fixed reference point for the code in question, just in case we break something really badly later. (Although Subversion normally prevents anything horrible like this happening.) * To ensure that all new features and fixes in need of testing have the greatest possible number of potential testers. -No claims are made that any _-CURRENT_ snapshot can be considered "production quality" for any purpose. If a stable and fully tested system is needed, stick to full releases. +No claims are made that any _-CURRENT_ snapshot can be considered "production quality" for any purpose. +If a stable and fully tested system is needed, stick to full releases. Snapshot releases are directly available from link:https://www.FreeBSD.org/snapshots/[snapshot]. @@ -201,9 +245,12 @@ Official snapshots are generated on a regular basis for all actively developed b [[responsible]] === Who is responsible for FreeBSD? -The key decisions concerning the FreeBSD project, such as the overall direction of the project and who is allowed to add code to the source tree, are made by a link:https://www.FreeBSD.org/administration#t-core[core team] of 9 people. There is a much larger team of more than 350 link:{contributors}#staff-committers[committers] who are authorized to make changes directly to the FreeBSD source tree. +The key decisions concerning the FreeBSD project, such as the overall direction of the project and who is allowed to add code to the source tree, +are made by a link:https://www.FreeBSD.org/administration#t-core[core team] of 9 people. +There is a much larger team of more than 350 link:{contributors}#staff-committers[committers] who are authorized to make changes directly to the FreeBSD source tree. -However, most non-trivial changes are discussed in advance in the <>, and there are no restrictions on who may take part in the discussion. +However, most non-trivial changes are discussed in advance in the <>, +and there are no restrictions on who may take part in the discussion. [[where-get]] === Where can I get FreeBSD? @@ -236,9 +283,11 @@ The project produces a wide range of documentation, available online from this l [[doc-formats]] === Is the documentation available in other formats, such as plain text (ASCII), or PDF? -Yes. The documentation is available in a number of different formats and compression schemes on the FreeBSD FTP site, in the https://download.freebsd.org/ftp/doc/[/ftp/doc/] directory. +Yes. The documentation is available in a number of different formats and compression schemes on the FreeBSD FTP site, +in the https://download.freebsd.org/ftp/doc/[/ftp/doc/] directory. -The documentation is categorized in a number of different ways. These include: +The documentation is categorized in a number of different ways. +These include: * The document's name, such as `faq`, or `handbook`. * The document's language and encoding. These are based on the locale names found under [.filename]#/usr/share/locale# on a FreeBSD system. The current languages and encodings are as follows: @@ -336,13 +385,15 @@ Some documents may not be available in all languages. .. Where the format is `html-split`, the files are bundled up using man:tar[1]. The resulting [.filename]#.tar# is then compressed using the compression schemes detailed in the next point. .. All the other formats generate one file. For example, [.filename]#article.pdf#, [.filename]#book.html#, and so on. + -These files are then compressed using either the `zip` or `bz2` compression schemes. man:tar[1] can be used to uncompress these files. +These files are then compressed using either the `zip` or `bz2` compression schemes. +man:tar[1] can be used to uncompress these files. + So the PDF version of the Handbook, compressed using `bzip2` will be stored in a file called [.filename]#book.pdf.bz2# in the [.filename]#handbook/# directory. After choosing the format and compression mechanism, download the compressed files, uncompress them, and then copy the appropriate documents into place. -For example, the split HTML version of the FAQ, compressed using man:bzip2[1], can be found in [.filename]#doc/en_US.ISO8859-1/books/faq/book.html-split.tar.bz2# To download and uncompress that file, type: +For example, the split HTML version of the FAQ, compressed using man:bzip2[1], +can be found in [.filename]#doc/en_US.ISO8859-1/books/faq/book.html-split.tar.bz2# To download and uncompress that file, type: [source,shell] .... @@ -350,7 +401,9 @@ For example, the split HTML version of the FAQ, compressed using man:bzip2[1], c # tar xvf book.html-split.tar.bz2 .... -If the file is compressed, tar will automatically detect the appropriate format and decompress it correctly, resulting in a collection of [.filename]#.html# files. The main one is called [.filename]#index.html#, which will contain the table of contents, introductory material, and links to the other parts of the document. +If the file is compressed, tar will automatically detect the appropriate format and decompress it correctly, +resulting in a collection of [.filename]#.html# files. +The main one is called [.filename]#index.html#, which will contain the table of contents, introductory material, and links to the other parts of the document. [[mailing]] === Where do I find info on the FreeBSD mailing lists? What FreeBSD news groups are available? @@ -371,7 +424,8 @@ Yes, most major IRC networks host a FreeBSD chat channel: The FreeBSD wiki has a https://wiki.freebsd.org/IRC/Channels[good list] of IRC channels. -Each of these channels are distinct and are not connected to each other. Since their chat styles differ, try each to find one suited to your chat style. +Each of these channels are distinct and are not connected to each other. +Since their chat styles differ, try each to find one suited to your chat style. [[forums]] === Are there any web based forums to discuss FreeBSD? @@ -381,9 +435,12 @@ The official FreeBSD forums are located at https://forums.FreeBSD.org/[https://f [[training]] === Where can I get commercial FreeBSD training and support? -http://www.ixsystems.com[iXsystems, Inc.], parent company of the http://www.freebsdmall.com/[FreeBSD Mall], provides commercial FreeBSD and TrueOS software http://www.ixsystems.com/support[support], in addition to FreeBSD development and tuning solutions. +http://www.ixsystems.com[iXsystems, Inc.], parent company of the http://www.freebsdmall.com/[FreeBSD Mall], +provides commercial FreeBSD and TrueOS software http://www.ixsystems.com/support[support], +in addition to FreeBSD development and tuning solutions. -BSD Certification Group, Inc. provides system administration certifications for DragonFly BSD, FreeBSD, NetBSD, and OpenBSD. Refer to http://www.BSDCertification.org[their site] for more information. +BSD Certification Group, Inc. provides system administration certifications for DragonFly BSD, FreeBSD, NetBSD, and OpenBSD. +Refer to http://www.BSDCertification.org[their site] for more information. Any other organizations providing training and support should contact the Project to be listed here. @@ -393,7 +450,10 @@ Any other organizations providing training and support should contact the Projec [[which-architecture]] === Which platform should I download? I have a 64 bit capable Intel(R) CPU, but I only see amd64. -amd64 is the term FreeBSD uses for 64-bit compatible x86 architectures (also known as "x86-64" or "x64"). Most modern computers should use amd64. Older hardware should use i386. When installing on a non-x86-compatible architecture, select the platform which best matches the hardware. +amd64 is the term FreeBSD uses for 64-bit compatible x86 architectures (also known as "x86-64" or "x64"). +Most modern computers should use amd64. +Older hardware should use i386. +When installing on a non-x86-compatible architecture, select the platform which best matches the hardware. [[floppy-download]] === Which file do I download to get FreeBSD? @@ -428,7 +488,9 @@ Full instructions on this procedure and a little bit more about installation iss This can be caused by not downloading the image in _binary_ mode when using FTP. -Some FTP clients default their transfer mode to _ascii_ and attempt to change any end-of-line characters received to match the conventions used by the client's system. This will almost invariably corrupt the boot image. Check the SHA-256 checksum of the downloaded boot image: if it is not _exactly_ that on the server, then the download process is suspect. +Some FTP clients default their transfer mode to _ascii_ and attempt to change any end-of-line characters received to match the conventions used by the client's system. +This will almost invariably corrupt the boot image. +Check the SHA-256 checksum of the downloaded boot image: if it is not _exactly_ that on the server, then the download process is suspect. When using a command line FTP client, type _binary_ at the FTP command prompt after getting connected to the server and before starting the download of the image. @@ -440,17 +502,23 @@ Installation instructions can be found at link:{handbook}#bsdinstall/[Handbook e [[custom-boot-floppy]] === How can I make my own custom release or install disk? -Customized FreeBSD installation media can be created by building a custom release. Follow the instructions in the link:{releng}[Release Engineering] article. +Customized FreeBSD installation media can be created by building a custom release. +Follow the instructions in the link:{releng}[Release Engineering] article. [[windows-coexist]] === Can Windows(R) co-exist with FreeBSD? (x86-specific) -If Windows(R) is installed first, then yes. FreeBSD's boot manager will then manage to boot Windows(R) and FreeBSD. If Windows(R) is installed afterwards, it will overwrite the boot manager. If that happens, see the next section. +If Windows(R) is installed first, then yes. +FreeBSD's boot manager will then manage to boot Windows(R) and FreeBSD. +If Windows(R) is installed afterwards, it will overwrite the boot manager. +If that happens, see the next section. [[bootmanager-restore]] === Another operating system destroyed my Boot Manager. How do I get it back? (x86-specific) -This depends upon the boot manager. The FreeBSD boot selection menu can be reinstalled using man:boot0cfg[8]. For example, to restore the boot menu onto the disk _ada0_: +This depends upon the boot manager. +The FreeBSD boot selection menu can be reinstalled using man:boot0cfg[8]. +For example, to restore the boot menu onto the disk _ada0_: [source,shell] .... @@ -469,38 +537,59 @@ For more complex situations, including GPT disks, see man:gpart[8]. [[need-complete-sources]] === Do I need to install the source? -In general, no. There is nothing in the base system which requires the presence of the source to operate. Some ports, like package:sysutils/lsof[], will not build unless the source is installed. In particular, if the port builds a kernel module or directly operates on kernel structures, the source must be installed. +In general, no. +There is nothing in the base system which requires the presence of the source to operate. +Some ports, like package:sysutils/lsof[], will not build unless the source is installed. +In particular, if the port builds a kernel module or directly operates on kernel structures, the source must be installed. [[need-kernel]] === Do I need to build a kernel? -Usually not. The supplied `GENERIC` kernel contains the drivers an ordinary computer will need. man:freebsd-update[8], the FreeBSD binary upgrade tool, cannot upgrade custom kernels, another reason to stick with the `GENERIC` kernel when possible. For computers with very limited RAM, such as embedded systems, it may be worthwhile to build a smaller custom kernel containing just the required drivers. +Usually not. +The supplied `GENERIC` kernel contains the drivers an ordinary computer will need. +man:freebsd-update[8], the FreeBSD binary upgrade tool, cannot upgrade custom kernels, +another reason to stick with the `GENERIC` kernel when possible. +For computers with very limited RAM, such as embedded systems, +it may be worthwhile to build a smaller custom kernel containing just the required drivers. [[password-encryption]] === Should I use DES, Blowfish, or MD5 passwords and how do I specify which form my users receive? -FreeBSD uses _SHA512_ by default. DES passwords are still available for backwards compatibility with operating systems that still use the less secure password format. FreeBSD also supports the Blowfish and MD5 password formats. Which password format to use for new passwords is controlled by the `passwd_format` login capability in [.filename]#/etc/login.conf#, which takes values of `des`, `blf` (if these are available) or `md5`. See the man:login.conf[5] manual page for more information about login capabilities. +FreeBSD uses _SHA512_ by default. +DES passwords are still available for backwards compatibility with operating systems that still use the less secure password format. +FreeBSD also supports the Blowfish and MD5 password formats. +Which password format to use for new passwords is controlled by the `passwd_format` login capability in [.filename]#/etc/login.conf#, +which takes values of `des`, `blf` (if these are available) or `md5`. +See the man:login.conf[5] manual page for more information about login capabilities. [[ffs-limits]] === What are the limits for FFS file systems? -For FFS file systems, the largest file system is practically limited by the amount of memory required to man:fsck[8] the file system. man:fsck[8] requires one bit per fragment, which with the default fragment size of 4 KB equates to 32 MB of memory per TB of disk. This does mean that on architectures which limit userland processes to 2 GB (e.g., i386(TM)), the maximum man:fsck[8]'able filesystem is ~60 TB. +For FFS file systems, the largest file system is practically limited by the amount of memory required to man:fsck[8] the file system. +man:fsck[8] requires one bit per fragment, which with the default fragment size of 4 KB equates to 32 MB of memory per TB of disk. +This does mean that on architectures which limit userland processes to 2 GB (e.g., i386(TM)), the maximum man:fsck[8]'able filesystem is ~60 TB. If there was not a man:fsck[8] memory limit the maximum filesystem size would be 2 ^ 64 (blocks) * 32 KB => 16 Exa * 32 KB => 512 ZettaBytes. -The maximum size of a single FFS file is approximately 2 PB with the default block size of 32 KB. Each 32 KB block can point to 4096 blocks. With triple indirect blocks, the calculation is 32 KB * 12 + 32 KB * 4096 + 32 KB * 4096^2 + 32 KB * 4096^3. Increasing the block size to 64 KB will increase the max file size by a factor of 16. +The maximum size of a single FFS file is approximately 2 PB with the default block size of 32 KB. +Each 32 KB block can point to 4096 blocks. +With triple indirect blocks, the calculation is 32 KB * 12 + 32 KB * 4096 + 32 KB * 4096^2 + 32 KB * 4096^3. +Increasing the block size to 64 KB will increase the max file size by a factor of 16. [[archsw-readin-failed-error]] === Why do I get an error message, readin failed after compiling and booting a new kernel? -The world and kernel are out of sync. This is not supported. Be sure to use `make buildworld` and `make buildkernel` to update the kernel. +The world and kernel are out of sync. +This is not supported. +Be sure to use `make buildworld` and `make buildkernel` to update the kernel. Boot the system by specifying the kernel directly at the second stage, pressing any key when the `|` shows up before loader is started. [[general-configuration-tool]] === Is there a tool to perform post-installation configuration tasks? -Yes. bsdconfig provides a nice interface to configure FreeBSD post-installation. +Yes. +bsdconfig provides a nice interface to configure FreeBSD post-installation. [[hardware]] == Hardware Compatibility @@ -511,30 +600,51 @@ Yes. bsdconfig provides a nice interface to configure FreeBSD post-installation. [[which-hardware-to-get]] ==== I want to get a piece of hardware for my FreeBSD system. Which model/brand/type is best? -This is discussed continually on the FreeBSD mailing lists but is to be expected since hardware changes so quickly. Read through the Hardware Notes for FreeBSD link:{u-rel121-hardware}[{rel121-current}] or link:{u-rel113-hardware}[{rel113-current}] and search the mailing list https://www.FreeBSD.org/search/#mailinglists[archives] before asking about the latest and greatest hardware. Chances are a discussion about that type of hardware took place just last week. +This is discussed continually on the FreeBSD mailing lists but is to be expected since hardware changes so quickly. +Read through the Hardware Notes for FreeBSD link:{u-rel121-hardware}[{rel121-current}] or link:{u-rel113-hardware}[{rel113-current}] and search the mailing list https://www.FreeBSD.org/search/#mailinglists[archives] before asking about the latest and greatest hardware. +Chances are a discussion about that type of hardware took place just last week. -Before purchasing a laptop, check the archives for {freebsd-questions}, or possibly a specific mailing list for a particular hardware type. +Before purchasing a laptop, check the archives for {freebsd-questions}, +or possibly a specific mailing list for a particular hardware type. [[memory-upper-limitation]] ==== What are the limits for memory? -FreeBSD as an operating system generally supports as much physical memory (RAM) as the platform it is running on does. Keep in mind that different platforms have different limits for memory; for example i386(TM) without PAE supports at most 4 GB of memory (and usually less than that because of PCI address space) and i386(TM) with PAE supports at most 64 GB memory. As of FreeBSD 10, AMD64 platforms support up to 4 TB of physical memory. +FreeBSD as an operating system generally supports as much physical memory (RAM) as the platform it is running on does. +Keep in mind that different platforms have different limits for memory; +for example i386(TM) without PAE supports at most 4 GB of memory (and usually less than that because of PCI address space) and i386(TM) with PAE supports at most 64 GB memory. +As of FreeBSD 10, AMD64 platforms support up to 4 TB of physical memory. [[memory-i386-over-4gb]] ==== Why does FreeBSD report less than 4 GB memory when installed on an i386(TM) machine? -The total address space on i386(TM) machines is 32-bit, meaning that at most 4 GB of memory is addressable (can be accessed). Furthermore, some addresses in this range are reserved by hardware for different purposes, for example for using and controlling PCI devices, for accessing video memory, and so on. Therefore, the total amount of memory usable by the operating system for its kernel and applications is limited to significantly less than 4 GB. Usually, 3.2 GB to 3.7 GB is the maximum usable physical memory in this configuration. - -To access more than 3.2 GB to 3.7 GB of installed memory (meaning up to 4 GB but also more than 4 GB), a special tweak called PAE must be used. PAE stands for Physical Address Extension and is a way for 32-bit x86 CPUs to address more than 4 GB of memory. It remaps the memory that would otherwise be overlaid by address reservations for hardware devices above the 4 GB range and uses it as additional physical memory (see man:pae[4]). Using PAE has some drawbacks; this mode of memory access is a little bit slower than the normal (without PAE) mode and loadable modules (see man:kld[4]) are not supported. This means all drivers must be compiled into the kernel. - -The most common way to enable PAE is to build a new kernel with the special ready-provided kernel configuration file called [.filename]#PAE#, which is already configured to build a safe kernel. Note that some entries in this kernel configuration file are too conservative and some drivers marked as unready to be used with PAE are actually usable. A rule of thumb is that if the driver is usable on 64-bit architectures (like AMD64), it is also usable with PAE. When creating a custom kernel configuration file, PAE can be enabled by adding the following line: +The total address space on i386(TM) machines is 32-bit, meaning that at most 4 GB of memory is addressable (can be accessed). +Furthermore, some addresses in this range are reserved by hardware for different purposes, +for example for using and controlling PCI devices, for accessing video memory, and so on. +Therefore, the total amount of memory usable by the operating system for its kernel and applications is limited to significantly less than 4 GB. +Usually, 3.2 GB to 3.7 GB is the maximum usable physical memory in this configuration. + +To access more than 3.2 GB to 3.7 GB of installed memory (meaning up to 4 GB but also more than 4 GB), +a special tweak called PAE must be used. +PAE stands for Physical Address Extension and is a way for 32-bit x86 CPUs to address more than 4 GB of memory. +It remaps the memory that would otherwise be overlaid by address reservations for hardware devices above the 4 GB range and uses it as additional physical memory (see man:pae[4]). +Using PAE has some drawbacks; this mode of memory access is a little bit slower than the normal (without PAE) mode and loadable modules (see man:kld[4]) are not supported. +This means all drivers must be compiled into the kernel. + +The most common way to enable PAE is to build a new kernel with the special ready-provided kernel configuration file called [.filename]#PAE#, +which is already configured to build a safe kernel. +Note that some entries in this kernel configuration file are too conservative and some drivers marked as unready to be used with PAE are actually usable. +A rule of thumb is that if the driver is usable on 64-bit architectures (like AMD64), it is also usable with PAE. +When creating a custom kernel configuration file, PAE can be enabled by adding the following line: [.programlisting] .... options PAE .... -PAE is not much used nowadays because most new x86 hardware also supports running in 64-bit mode, known as AMD64 or Intel(R) 64. It has a much larger address space and does not need such tweaks. FreeBSD supports AMD64 and it is recommended that this version of FreeBSD be used instead of the i386(TM) version if 4 GB or more memory is required. +PAE is not much used nowadays because most new x86 hardware also supports running in 64-bit mode, known as AMD64 or Intel(R) 64. +It has a much larger address space and does not need such tweaks. +FreeBSD supports AMD64 and it is recommended that this version of FreeBSD be used instead of the i386(TM) version if 4 GB or more memory is required. [[compatibility-processors]] === Architectures and Processors @@ -542,21 +652,28 @@ PAE is not much used nowadays because most new x86 hardware also supports runnin [[architectures]] ==== Does FreeBSD support architectures other than the x86? -Yes. FreeBSD divides support into multiple tiers. Tier 1 architectures, such as i386 or amd64; are fully supported. Tiers 2 and 3 are supported on a best-effort basis. A full explanation of the tier system is available in the link:{committers-guide}#archs/[Committer's Guide.] +Yes. +FreeBSD divides support into multiple tiers. +Tier 1 architectures, such as i386 or amd64; are fully supported. +Tiers 2 and 3 are supported on a best-effort basis. +A full explanation of the tier system is available in the link:{committers-guide}#archs/[Committer's Guide.] A complete list of supported architectures can be found on the https://www.FreeBSD.org/platforms/[platforms page.] [[smp-support]] ==== Does FreeBSD support Symmetric Multiprocessing (SMP)? -FreeBSD supports symmetric multi-processor (SMP) on all non-embedded platforms (e.g, i386, amd64, etc.). SMP is also supported in arm and MIPS kernels, although some CPUs may not support this. FreeBSD's SMP implementation uses fine-grained locking, and performance scales nearly linearly with number of CPUs. +FreeBSD supports symmetric multi-processor (SMP) on all non-embedded platforms (e.g, i386, amd64, etc.). +SMP is also supported in arm and MIPS kernels, although some CPUs may not support this. +FreeBSD's SMP implementation uses fine-grained locking, and performance scales nearly linearly with number of CPUs. man:smp[4] has more details. [[microcode]] ==== What is microcode? How do I install Intel(R) CPU microcode updates? -Microcode is a method of programmatically implementing hardware level instructions. This allows for CPU bugs to be fixed without replacing the on board chip. +Microcode is a method of programmatically implementing hardware level instructions. +This allows for CPU bugs to be fixed without replacing the on board chip. Install package:sysutils/devcpu-data[], then add: @@ -581,7 +698,8 @@ See the complete list in the Hardware Notes for FreeBSD link:{u-rel121-hardware} [[moused]] ==== Is it possible to use a mouse outside the X Window system? -The default console driver, man:vt[4], provides the ability to use a mouse pointer in text consoles to cut & paste text. Run the mouse daemon, man:moused[8], and turn on the mouse pointer in the virtual console: +The default console driver, man:vt[4], provides the ability to use a mouse pointer in text consoles to cut & paste text. +Run the mouse daemon, man:moused[8], and turn on the mouse pointer in the virtual console: [source,shell] .... @@ -589,37 +707,53 @@ The default console driver, man:vt[4], provides the ability to use a mouse point # vidcontrol -m on .... -Where _xxxx_ is the mouse device name and _yyyy_ is a protocol type for the mouse. The mouse daemon can automatically determine the protocol type of most mice, except old serial mice. Specify the `auto` protocol to invoke automatic detection. If automatic detection does not work, see the man:moused[8] manual page for a list of supported protocol types. +Where _xxxx_ is the mouse device name and _yyyy_ is a protocol type for the mouse. +The mouse daemon can automatically determine the protocol type of most mice, except old serial mice. +Specify the `auto` protocol to invoke automatic detection. +If automatic detection does not work, see the man:moused[8] manual page for a list of supported protocol types. -For a PS/2 mouse, add `moused_enable="YES"` to [.filename]#/etc/rc.conf# to start the mouse daemon at boot time. Additionally, to use the mouse daemon on all virtual terminals instead of just the console, add `allscreens_flags="-m on"` to [.filename]#/etc/rc.conf#. +For a PS/2 mouse, add `moused_enable="YES"` to [.filename]#/etc/rc.conf# to start the mouse daemon at boot time. +Additionally, to use the mouse daemon on all virtual terminals instead of just the console, add `allscreens_flags="-m on"` to [.filename]#/etc/rc.conf#. -When the mouse daemon is running, access to the mouse must be coordinated between the mouse daemon and other programs such as X Windows. Refer to the FAQ<> for more details on this issue. +When the mouse daemon is running, access to the mouse must be coordinated between the mouse daemon and other programs such as X Windows. +Refer to the FAQ <> for more details on this issue. [[text-mode-cut-paste]] ==== How do I cut and paste text with a mouse in the text console? -It is not possible to remove data using the mouse. However, it is possible to copy and paste. Once the mouse daemon is running as described in the <>, hold down button 1 (left button) and move the mouse to select a region of text. Then, press button 2 (middle button) to paste it at the text cursor. Pressing button 3 (right button) will "extend" the selected region of text. +It is not possible to remove data using the mouse. +However, it is possible to copy and paste. +Once the mouse daemon is running as described in the <>, +hold down button 1 (left button) and move the mouse to select a region of text. +Then, press button 2 (middle button) to paste it at the text cursor. +Pressing button 3 (right button) will "extend" the selected region of text. -If the mouse does not have a middle button, it is possible to emulate one or remap buttons using mouse daemon options. See the man:moused[8] manual page for details. +If the mouse does not have a middle button, it is possible to emulate one or remap buttons using mouse daemon options. +See the man:moused[8] manual page for details. [[mouse-wheel-buttons]] ==== My mouse has a fancy wheel and buttons. Can I use them in FreeBSD? -The answer is, unfortunately, "It depends". These mice with additional features require specialized driver in most cases. Unless the mouse device driver or the user program has specific support for the mouse, it will act just like a standard two, or three button mouse. +The answer is, unfortunately, "It depends". +These mice with additional features require specialized driver in most cases. +Unless the mouse device driver or the user program has specific support for the mouse, +it will act just like a standard two, or three button mouse. For the possible usage of wheels in the X Window environment, refer to <>. [[keyboard-delete-key]] ==== How do I use my delete key in sh and csh? -For the Bourne Shell, add the following lines to [.filename]#~/.shrc#. See man:sh[1] and man:editrc[5]. +For the Bourne Shell, add the following lines to [.filename]#~/.shrc#. +See man:sh[1] and man:editrc[5]. [.programlisting] .... bind ^[[3~ ed-delete-next-char # for xterm .... -For the C Shell, add the following lines to [.filename]#~/.cshrc#. See man:csh[1]. +For the C Shell, add the following lines to [.filename]#~/.cshrc#. +See man:csh[1]. [.programlisting] .... @@ -632,7 +766,8 @@ bindkey ^[[3~ delete-char # for xterm [[es1370-silent-pcm]] ==== Workarounds for no sound from my man:pcm[4] sound card? -Some sound cards set their output volume to 0 at every boot. Run the following command every time the machine boots: +Some sound cards set their output volume to 0 at every boot. +Run the following command every time the machine boots: [source,shell] .... @@ -642,7 +777,8 @@ Some sound cards set their output volume to 0 at every boot. Run the following c [[power-management-support]] ==== Does FreeBSD support power management on my laptop? -FreeBSD supports the ACPI features found in modern hardware. Further information can be found in man:acpi[4]. +FreeBSD supports the ACPI features found in modern hardware. +Further information can be found in man:acpi[4]. [[troubleshoot]] == Troubleshooting @@ -652,20 +788,29 @@ FreeBSD supports the ACPI features found in modern hardware. Further information The most likely reason is the difference between physical memory addresses and virtual addresses. -The convention for most PC hardware is to use the memory area between 3.5 GB and 4 GB for a special purpose (usually for PCI). This address space is used to access PCI hardware. As a result real, physical memory cannot be accessed by that address space. +The convention for most PC hardware is to use the memory area between 3.5 GB and 4 GB for a special purpose (usually for PCI). +This address space is used to access PCI hardware. +As a result real, physical memory cannot be accessed by that address space. -What happens to the memory that should appear in that location is hardware dependent. Unfortunately, some hardware does nothing and the ability to use that last 500 MB of RAM is entirely lost. +What happens to the memory that should appear in that location is hardware dependent. +Unfortunately, some hardware does nothing and the ability to use that last 500 MB of RAM is entirely lost. -Luckily, most hardware remaps the memory to a higher location so that it can still be used. However, this can cause some confusion when watching the boot messages. +Luckily, most hardware remaps the memory to a higher location so that it can still be used. +However, this can cause some confusion when watching the boot messages. -On a 32-bit version of FreeBSD, the memory appears lost, since it will be remapped above 4 GB, which a 32-bit kernel is unable to access. In this case, the solution is to build a PAE enabled kernel. See the entry on memory limits for more information. +On a 32-bit version of FreeBSD, the memory appears lost, since it will be remapped above 4 GB, which a 32-bit kernel is unable to access. +In this case, the solution is to build a PAE enabled kernel. +See the entry on memory limits for more information. -On a 64-bit version of FreeBSD, or when running a PAE-enabled kernel, FreeBSD will correctly detect and remap the memory so it is usable. During boot, however, it may seem as if FreeBSD is detecting more memory than the system really has, due to the described remapping. This is normal and the available memory will be corrected as the boot process completes. +On a 64-bit version of FreeBSD, or when running a PAE-enabled kernel, FreeBSD will correctly detect and remap the memory so it is usable. +During boot, however, it may seem as if FreeBSD is detecting more memory than the system really has, due to the described remapping. +This is normal and the available memory will be corrected as the boot process completes. [[signal11]] === Why do my programs occasionally die with Signal 11 errors? -Signal 11 errors are caused when a process has attempted to access memory which the operating system has not granted it access to. If something like this is happening at seemingly random intervals, start investigating the cause. +Signal 11 errors are caused when a process has attempted to access memory which the operating system has not granted it access to. +If something like this is happening at seemingly random intervals, start investigating the cause. These problems can usually be attributed to either: @@ -674,7 +819,9 @@ These problems can usually be attributed to either: It is probably not a FreeBSD bug if the problem occurs compiling a program, but the activity that the compiler is carrying out changes each time. -For example, if `make buildworld` fails while trying to compile [.filename]#ls.c# into [.filename]#ls.o# and, when run again, it fails in the same place, this is a broken build. Try updating source and try again. If the compile fails elsewhere, it is almost certainly due to hardware. +For example, if `make buildworld` fails while trying to compile [.filename]#ls.c# into [.filename]#ls.o# and, when run again, it fails in the same place, this is a broken build. +Try updating source and try again. +If the compile fails elsewhere, it is almost certainly due to hardware. In the first case, use a debugger such as man:gdb[1] to find the point in the program which is attempting to access a bogus address and fix it. @@ -690,61 +837,93 @@ Regarding overclocking, it is far cheaper to have a slow system than a fried sys . Over-optimistic motherboard settings: the BIOS settings, and some motherboard jumpers, provide options to set various timings. The defaults are often sufficient, but sometimes setting the wait states on RAM too low, or setting the "RAM Speed: Turbo" option will cause strange behavior. A possible idea is to set to BIOS defaults, after noting the current settings first. . Unclean or insufficient power to the motherboard. Remove any unused I/O boards, hard disks, or CD-ROMs, or disconnect the power cable from them, to see if the power supply can manage a smaller load. Or try another power supply, preferably one with a little more power. For instance, if the current power supply is rated at 250 Watts, try one rated at 300 Watts. -Read the section on <> for a further explanation and a discussion on how memory testing software or hardware can still pass faulty memory. There is an extensive FAQ on this at http://www.bitwizard.nl/sig11/[the SIG11 problem FAQ]. +Read the section on <> for a further explanation and a discussion on how memory testing software or hardware can still pass faulty memory. +There is an extensive FAQ on this at http://www.bitwizard.nl/sig11/[the SIG11 problem FAQ]. -Finally, if none of this has helped, it is possibly a bug in FreeBSD. Follow <> to send a problem report. +Finally, if none of this has helped, it is possibly a bug in FreeBSD. +Follow <> to send a problem report. [[trap-12-panic]] === My system crashes with either Fatal trap 12: page fault in kernel mode, or panic:, and spits out a bunch of information. What should I do? -The FreeBSD developers are interested in these errors, but need more information than just the error message. Copy the full crash message. Then consult the FAQ section on <>, build a debugging kernel, and get a backtrace. This might sound difficult, but does not require any programming skills. Just follow the instructions. +The FreeBSD developers are interested in these errors, but need more information than just the error message. +Copy the full crash message. +Then consult the FAQ section on <>, build a debugging kernel, and get a backtrace. +This might sound difficult, but does not require any programming skills. +Just follow the instructions. [[proc-table-full]] === What is the meaning of the error maxproc limit exceeded by uid %i, please see tuning(7) and login.conf(5)? -The FreeBSD kernel will only allow a certain number of processes to exist at one time. The number is based on the `kern.maxusers` man:sysctl[8] variable. `kern.maxusers` also affects various other in-kernel limits, such as network buffers. If the machine is heavily loaded, increase `kern.maxusers`. This will increase these other system limits in addition to the maximum number of processes. +The FreeBSD kernel will only allow a certain number of processes to exist at one time. +The number is based on the `kern.maxusers` man:sysctl[8] variable. +`kern.maxusers` also affects various other in-kernel limits, such as network buffers. +If the machine is heavily loaded, increase `kern.maxusers`. +This will increase these other system limits in addition to the maximum number of processes. -To adjust the `kern.maxusers` value, see the link:{handbook}#kern-maxfiles[File/Process Limits] section of the Handbook. While that section refers to open files, the same limits apply to processes. +To adjust the `kern.maxusers` value, see the link:{handbook}#kern-maxfiles[File/Process Limits] section of the Handbook. +While that section refers to open files, the same limits apply to processes. -If the machine is lightly loaded but running a very large number of processes, adjust the `kern.maxproc` tunable by defining it in [.filename]#/boot/loader.conf#. The tunable will not get adjusted until the system is rebooted. For more information about tuning tunables, see man:loader.conf[5]. If these processes are being run by a single user, adjust `kern.maxprocperuid` to be one less than the new `kern.maxproc` value. It must be at least one less because one system program, man:init[8], must always be running. +If the machine is lightly loaded but running a very large number of processes, adjust the `kern.maxproc` tunable by defining it in [.filename]#/boot/loader.conf#. +The tunable will not get adjusted until the system is rebooted. +For more information about tuning tunables, see man:loader.conf[5]. +If these processes are being run by a single user, adjust `kern.maxprocperuid` to be one less than the new `kern.maxproc` value. +It must be at least one less because one system program, man:init[8], must always be running. [[remote-fullscreen]] === Why do full screen applications on remote machines misbehave? -The remote machine may be setting the terminal type to something other than `xterm` which is required by the FreeBSD console. Alternatively the kernel may have the wrong values for the width and height of the terminal. +The remote machine may be setting the terminal type to something other than `xterm` which is required by the FreeBSD console. +Alternatively the kernel may have the wrong values for the width and height of the terminal. -Check the value of the `TERM` environment variable is `xterm`. If the remote machine does not support that try `vt100`. +Check the value of the `TERM` environment variable is `xterm`. +If the remote machine does not support that try `vt100`. -Run `stty -a` to check what the kernel thinks the terminal dimensions are. If they are incorrect, they can be changed by running `stty rows _RR_ cols _CC_`. +Run `stty -a` to check what the kernel thinks the terminal dimensions are. +If they are incorrect, they can be changed by running `stty rows _RR_ cols _CC_`. -Alternatively, if the client machine has package:x11/xterm[] installed, then running `resize` will query the terminal for the correct dimensions and set them. +Alternatively, if the client machine has package:x11/xterm[] installed, +then running `resize` will query the terminal for the correct dimensions and set them. [[connection-delay]] === Why does it take so long to connect to my computer via ssh or telnet? The symptom: there is a long delay between the time the TCP connection is established and the time when the client software asks for a password (or, in man:telnet[1]'s case, when a login prompt appears). -The problem: more likely than not, the delay is caused by the server software trying to resolve the client's IP address into a hostname. Many servers, including the Telnet and SSH servers that come with FreeBSD, do this to store the hostname in a log file for future reference by the administrator. +The problem: more likely than not, the delay is caused by the server software trying to resolve the client's IP address into a hostname. +Many servers, including the Telnet and SSH servers that come with FreeBSD, +do this to store the hostname in a log file for future reference by the administrator. -The remedy: if the problem occurs whenever connecting the client computer to any server, the problem is with the client. If the problem only occurs when someone connects to the server computer, the problem is with the server. +The remedy: if the problem occurs whenever connecting the client computer to any server, the problem is with the client. +If the problem only occurs when someone connects to the server computer, the problem is with the server. -If the problem is with the client, the only remedy is to fix the DNS so the server can resolve it. If this is on a local network, consider it a server problem and keep reading. If this is on the Internet, contact your ISP. +If the problem is with the client, the only remedy is to fix the DNS so the server can resolve it. +If this is on a local network, consider it a server problem and keep reading. +If this is on the Internet, contact your ISP. -If the problem is with the server on a local network, configure the server to resolve address-to-hostname queries for the local address range. See man:hosts[5] and man:named[8] for more information. If this is on the Internet, the problem may be that the local server's resolver is not functioning correctly. To check, try to look up another host such as `www.yahoo.com`. If it does not work, that is the problem. +If the problem is with the server on a local network, configure the server to resolve address-to-hostname queries for the local address range. +See man:hosts[5] and man:named[8] for more information. +If this is on the Internet, the problem may be that the local server's resolver is not functioning correctly. +To check, try to look up another host such as `www.yahoo.com`. +If it does not work, that is the problem. -Following a fresh install of FreeBSD, it is also possible that domain and name server information is missing from [.filename]#/etc/resolv.conf#. This will often cause a delay in SSH, as the option `UseDNS` is set to `yes` by default in [.filename]#/etc/ssh/sshd_config#. If this is causing the problem, either fill in the missing information in [.filename]#/etc/resolv.conf# or set `UseDNS` to `no` in [.filename]#sshd_config# as a temporary workaround. +Following a fresh install of FreeBSD, it is also possible that domain and name server information is missing from [.filename]#/etc/resolv.conf#. +This will often cause a delay in SSH, as the option `UseDNS` is set to `yes` by default in [.filename]#/etc/ssh/sshd_config#. +If this is causing the problem, either fill in the missing information in [.filename]#/etc/resolv.conf# or set `UseDNS` to `no` in [.filename]#sshd_config# as a temporary workaround. [[file-table-full]] === Why does file: table is full show up repeatedly in man:dmesg[8]? -This error message indicates that the number of available file descriptors have been exhausted on the system. Refer to the link:{handbook}#kern-maxfiles[kern.maxfiles] section of the link:{handbook}#configtuning-kernel-limits/[Tuning Kernel Limits] section of the Handbook for a discussion and solution. +This error message indicates that the number of available file descriptors have been exhausted on the system. +Refer to the link:{handbook}#kern-maxfiles[kern.maxfiles] section of the link:{handbook}#configtuning-kernel-limits/[Tuning Kernel Limits] section of the Handbook for a discussion and solution. [[computer-clock-skew]] === Why does the clock on my computer keep incorrect time? The computer has two or more clocks, and FreeBSD has chosen to use the wrong one. -Run man:dmesg[8], and check for lines that contain `Timecounter`. The one with the highest quality value that FreeBSD chose. +Run man:dmesg[8], and check for lines that contain `Timecounter`. +The one with the highest quality value that FreeBSD chose. [source,shell] .... @@ -763,14 +942,16 @@ Confirm this by checking the `kern.timecounter.hardware` man:sysctl[3]. kern.timecounter.hardware: ACPI-fast .... -It may be a broken ACPI timer. The simplest solution is to disable the ACPI timer in [.filename]#/boot/loader.conf#: +It may be a broken ACPI timer. +The simplest solution is to disable the ACPI timer in [.filename]#/boot/loader.conf#: [.programlisting] .... debug.acpi.disabled="timer" .... -Or the BIOS may modify the TSC clock-perhaps to change the speed of the processor when running from batteries, or going into a power saving mode, but FreeBSD is unaware of these adjustments, and appears to gain or lose time. +Or the BIOS may modify the TSC clock-perhaps to change the speed of the processor when running from batteries, +or going into a power saving mode, but FreeBSD is unaware of these adjustments, and appears to gain or lose time. In this example, the `i8254` clock is also available, and can be selected by writing its name to the `kern.timecounter.hardware` man:sysctl[3]. @@ -792,16 +973,27 @@ kern.timecounter.hardware=i8254 [[indefinite-wait-buffer]] === What does the error swap_pager: indefinite wait buffer: mean? -This means that a process is trying to page memory from disk, and the page attempt has hung trying to access the disk for more than 20 seconds. It might be caused by bad blocks on the disk drive, disk wiring, cables, or any other disk I/O-related hardware. If the drive itself is bad, disk errors will appear in [.filename]#/var/log/messages# and in the output of `dmesg`. Otherwise, check the cables and connections. +This means that a process is trying to page memory from disk, and the page attempt has hung trying to access the disk for more than 20 seconds. +It might be caused by bad blocks on the disk drive, disk wiring, cables, or any other disk I/O-related hardware. +If the drive itself is bad, disk errors will appear in [.filename]#/var/log/messages# and in the output of `dmesg`. +Otherwise, check the cables and connections. [[lock-order-reversal]] === What is a lock order reversal? -The FreeBSD kernel uses a number of resource locks to arbitrate contention for certain resources. When multiple kernel threads try to obtain multiple resource locks, there's always the potential for a deadlock, where two threads have each obtained one of the locks and blocks forever waiting for the other thread to release one of the other locks. This sort of locking problem can be avoided if all threads obtain the locks in the same order. +The FreeBSD kernel uses a number of resource locks to arbitrate contention for certain resources. +When multiple kernel threads try to obtain multiple resource locks, there's always the potential for a deadlock, +where two threads have each obtained one of the locks and blocks forever waiting for the other thread to release one of the other locks. +This sort of locking problem can be avoided if all threads obtain the locks in the same order. -A run-time lock diagnostic system called man:witness[4], enabled in FreeBSD-CURRENT and disabled by default for stable branches and releases, detects the potential for deadlocks due to locking errors, including errors caused by obtaining multiple resource locks with a different order from different parts of the kernel. The man:witness[4] framework tries to detect this problem as it happens, and reports it by printing a message to the system console about a `lock order reversal` (often referred to also as LOR). +A run-time lock diagnostic system called man:witness[4], enabled in FreeBSD-CURRENT and disabled by default for stable branches and releases, +detects the potential for deadlocks due to locking errors, including errors caused by obtaining multiple resource locks with a different order from different parts of the kernel. +The man:witness[4] framework tries to detect this problem as it happens, +and reports it by printing a message to the system console about a `lock order reversal` (often referred to also as LOR). -It is possible to get false positives, as man:witness[4] is conservative. A true positive report _does not_ mean that a system is dead-locked; instead it should be understood as a warning that a deadlock could have happened here. +It is possible to get false positives, as man:witness[4] is conservative. +A true positive report _does not_ mean that a system is dead-locked; +instead it should be understood as a warning that a deadlock could have happened here. [NOTE] ==== @@ -813,18 +1005,25 @@ Problematic LORs tend to get fixed quickly, so check the {freebsd-current} befor This means that a function that may sleep was called while a mutex (or other unsleepable) lock was held. -The reason this is an error is because mutexes are not intended to be held for long periods of time; they are supposed to only be held to maintain short periods of synchronization. This programming contract allows device drivers to use mutexes to synchronize with the rest of the kernel during interrupts. Interrupts (under FreeBSD) may not sleep. Hence it is imperative that no subsystem in the kernel block for an extended period while holding a mutex. +The reason this is an error is because mutexes are not intended to be held for long periods of time; +they are supposed to only be held to maintain short periods of synchronization. +This programming contract allows device drivers to use mutexes to synchronize with the rest of the kernel during interrupts. +Interrupts (under FreeBSD) may not sleep. +Hence it is imperative that no subsystem in the kernel block for an extended period while holding a mutex. To catch such errors, assertions may be added to the kernel that interact with the man:witness[4] subsystem to emit a warning or fatal error (depending on the system configuration) when a potentially blocking call is made while holding a mutex. -In summary, such warnings are non-fatal, however with unfortunate timing they could cause undesirable effects ranging from a minor blip in the system's responsiveness to a complete system lockup. +In summary, such warnings are non-fatal, +however with unfortunate timing they could cause undesirable effects ranging from a minor blip in the system's responsiveness to a complete system lockup. For additional information about locking in FreeBSD see man:locking[9]. [[touch-not-found]] === Why does buildworld/installworld die with the message touch: not found? -This error does not mean that the man:touch[1] utility is missing. The error is instead probably due to the dates of the files being set sometime in the future. If the CMOS clock is set to local time, run `adjkerntz -i` to adjust the kernel clock when booting into single-user mode. +This error does not mean that the man:touch[1] utility is missing. +The error is instead probably due to the dates of the files being set sometime in the future. +If the CMOS clock is set to local time, run `adjkerntz -i` to adjust the kernel clock when booting into single-user mode. [[applications]] == User Applications @@ -834,9 +1033,12 @@ This error does not mean that the man:touch[1] utility is missing. The error is Refer to link:https://www.FreeBSD.org/ports/[the ports page] for info on software packages ported to FreeBSD. -Most ports should work on all supported versions of FreeBSD. Those that do not are specifically marked as such. Each time a FreeBSD release is made, a snapshot of the ports tree at the time of release is also included in the [.filename]#ports/# directory. +Most ports should work on all supported versions of FreeBSD. +Those that do not are specifically marked as such. +Each time a FreeBSD release is made, a snapshot of the ports tree at the time of release is also included in the [.filename]#ports/# directory. -FreeBSD supports compressed binary packages to easily install and uninstall ports. Use man:pkg[7] to control the installation of packages. +FreeBSD supports compressed binary packages to easily install and uninstall ports. +Use man:pkg[7] to control the installation of packages. [[how-do-download-ports-tree]] === How do I download the Ports tree? Should I be using Git? @@ -846,40 +1048,54 @@ See crossref:handbook[ports-using-installation-methods,Installing the Ports Coll [[ports-4x]] === Why can I not build this port on my {rel2-relx} -, or {rel-relx} -STABLE machine? -If the installed FreeBSD version lags significantly behind _-CURRENT_ or _-STABLE_, update the Ports Collection using the instructions in link:{handbook}#ports-using/[Using the Ports Collection]. If the system is up-to-date, someone might have committed a change to the port which works for _-CURRENT_ but which broke the port for _-STABLE_. https://bugs.FreeBSD.org/submit/[Submit] a bug report, since the Ports Collection is supposed to work for both the _-CURRENT_ and _-STABLE_ branches. +If the installed FreeBSD version lags significantly behind _-CURRENT_ or _-STABLE_, update the Ports Collection using the instructions in link:{handbook}#ports-using/[Using the Ports Collection]. +If the system is up-to-date, someone might have committed a change to the port which works for _-CURRENT_ but which broke the port for _-STABLE_. +https://bugs.FreeBSD.org/submit/[Submit] a bug report, since the Ports Collection is supposed to work for both the _-CURRENT_ and _-STABLE_ branches. [[make-index]] === I just tried to build INDEX using make index, and it failed. Why? -First, make sure that the Ports Collection is up-to-date. Errors that affect building [.filename]#INDEX# from an up-to-date copy of the Ports Collection are high-visibility and are thus almost always fixed immediately. +First, make sure that the Ports Collection is up-to-date. +Errors that affect building [.filename]#INDEX# from an up-to-date copy of the Ports Collection are high-visibility and are thus almost always fixed immediately. -There are rare cases where [.filename]#INDEX# will not build due to odd cases involving `OPTIONS_SET` being set in [.filename]#make.conf#. If you suspect that this is the case, try to make [.filename]#INDEX# with those variables turned off before reporting it to {freebsd-ports}. +There are rare cases where [.filename]#INDEX# will not build due to odd cases involving `OPTIONS_SET` being set in [.filename]#make.conf#. +If you suspect that this is the case, try to make [.filename]#INDEX# with those variables turned off before reporting it to {freebsd-ports}. [[ports-update]] === I updated the sources, now how do I update my installed ports? -FreeBSD does not include a port upgrading tool, but it does have some tools to make the upgrade process somewhat easier. Additional tools are available to simplify port handling and are described the link:{handbook}#ports-using/[Upgrading Ports] section in the FreeBSD Handbook. +FreeBSD does not include a port upgrading tool, but it does have some tools to make the upgrade process somewhat easier. +Additional tools are available to simplify port handling and are described the link:{handbook}#ports-using/[Upgrading Ports] section in the FreeBSD Handbook. [[ports-major-upgrade]] === Do I need to recompile every port each time I perform a major version update? -Yes! While a recent system will run with software compiled under an older release, things will randomly crash and fail to work once other ports are installed or updated. +Yes! While a recent system will run with software compiled under an older release, +things will randomly crash and fail to work once other ports are installed or updated. -When the system is upgraded, various shared libraries, loadable modules, and other parts of the system will be replaced with newer versions. Applications linked against the older versions may fail to start or, in other cases, fail to function properly. +When the system is upgraded, various shared libraries, loadable modules, and other parts of the system will be replaced with newer versions. +Applications linked against the older versions may fail to start or, in other cases, fail to function properly. For more information, see link:{handbook}#freebsdupdate-upgrade[the section on upgrades] in the FreeBSD Handbook. [[ports-minor-upgrade]] === Do I need to recompile every port each time I perform a minor version update? -In general, no. FreeBSD developers do their utmost to guarantee binary compatibility across all releases with the same major version number. Any exceptions will be documented in the Release Notes, and advice given there should be followed. +In general, no. FreeBSD developers do their utmost to guarantee binary compatibility across all releases with the same major version number. +Any exceptions will be documented in the Release Notes, and advice given there should be followed. [[minimal-sh]] === Why is /bin/sh so minimal? Why does FreeBSD not use bash or another shell? -Many people need to write shell scripts which will be portable across many systems. That is why POSIX(R) specifies the shell and utility commands in great detail. Most scripts are written in Bourne shell (man:sh[1]), and because several important programming interfaces (man:make[1], man:system[3], man:popen[3], and analogues in higher-level scripting languages like Perl and Tcl) are specified to use the Bourne shell to interpret commands. As the Bourne shell is so often and widely used, it is important for it to be quick to start, be deterministic in its behavior, and have a small memory footprint. +Many people need to write shell scripts which will be portable across many systems. +That is why POSIX(R) specifies the shell and utility commands in great detail. +Most scripts are written in Bourne shell (man:sh[1]), and because several important programming interfaces (man:make[1], man:system[3], man:popen[3], and analogues in higher-level scripting languages like Perl and Tcl) are specified to use the Bourne shell to interpret commands. +As the Bourne shell is so often and widely used, it is important for it to be quick to start, be deterministic in its behavior, and have a small memory footprint. -The existing implementation is our best effort at meeting as many of these requirements simultaneously as we can. To keep `/bin/sh` small, we have not provided many of the convenience features that other shells have. That is why other more featureful shells like `bash`, `scsh`, man:tcsh[1], and `zsh` are available. Compare the memory utilization of these shells by looking at the "VSZ" and "RSS" columns in a `ps -u` listing. +The existing implementation is our best effort at meeting as many of these requirements simultaneously as we can. +To keep `/bin/sh` small, we have not provided many of the convenience features that other shells have. +That is why other more featureful shells like `bash`, `scsh`, man:tcsh[1], and `zsh` are available. +Compare the memory utilization of these shells by looking at the "VSZ" and "RSS" columns in a `ps -u` listing. [[kernelconfig]] == Kernel Configuration @@ -891,13 +1107,19 @@ Not at all! Check out the link:{handbook}#kernelconfig/[kernel config section of [NOTE] ==== -The new [.filename]#kernel# will be installed to the [.filename]#/boot/kernel# directory along with its modules, while the old kernel and its modules will be moved to the [.filename]#/boot/kernel.old# directory. If a mistake is made in the configuration, simply boot the previous version of the kernel. +The new [.filename]#kernel# will be installed to the [.filename]#/boot/kernel# directory along with its modules, +while the old kernel and its modules will be moved to the [.filename]#/boot/kernel.old# directory. +If a mistake is made in the configuration, simply boot the previous version of the kernel. ==== [[why-kernel-big]] === Why is my kernel so big? -`GENERIC` kernels shipped with FreeBSD are compiled in _debug mode_. Kernels built in debug mode contain debug data in separate files that are used for debugging. FreeBSD releases prior to 11.0 store these debug files in the same directory as the kernel itself, [.filename]#/boot/kernel/#. In FreeBSD 11.0 and later the debug files are stored in [.filename]#/usr/lib/debug/boot/kernel/#. Note that there will be little or no performance loss from running a debug kernel, and it is useful to keep one around in case of a system panic. +`GENERIC` kernels shipped with FreeBSD are compiled in _debug mode_. +Kernels built in debug mode contain debug data in separate files that are used for debugging. +FreeBSD releases prior to 11.0 store these debug files in the same directory as the kernel itself, [.filename]#/boot/kernel/#. +In FreeBSD 11.0 and later the debug files are stored in [.filename]#/usr/lib/debug/boot/kernel/#. +Note that there will be little or no performance loss from running a debug kernel, and it is useful to keep one around in case of a system panic. When running low on disk space, there are different options to reduce the size of [.filename]#/boot/kernel/# and [.filename]#/usr/lib/debug/#. @@ -930,9 +1152,13 @@ To build and install only the specified modules, list them in [.filename]#/etc/m MODULES_OVERRIDE= accf_http ipfw .... -Replace _accf_httpd ipfw_ with a list of needed modules. Only the listed modules will be built. This reduces the size of the kernel directory and decreases the amount of time needed to build the kernel. For more information, read [.filename]#/usr/share/examples/etc/make.conf#. +Replace _accf_httpd ipfw_ with a list of needed modules. +Only the listed modules will be built. +This reduces the size of the kernel directory and decreases the amount of time needed to build the kernel. +For more information, read [.filename]#/usr/share/examples/etc/make.conf#. -Unneeded devices can be removed from the kernel to further reduce the size. See <> for more information. +Unneeded devices can be removed from the kernel to further reduce the size. +See <> for more information. To put any of these options into effect, follow the instructions to link:{handbook}#kernelconfig-building/[build and install] the new kernel. @@ -974,13 +1200,21 @@ See the link:{handbook}#disks-adding/[Adding Disks] section in the FreeBSD Handb [[new-huge-disk]] === How do I move my system over to my huge new disk? -The best way is to reinstall the operating system on the new disk, then move the user data over. This is highly recommended when tracking _-STABLE_ for more than one release or when updating a release instead of installing a new one. Install booteasy on both disks with man:boot0cfg[8] and dual boot until you are happy with the new configuration. Skip the next paragraph to find out how to move the data after doing this. +The best way is to reinstall the operating system on the new disk, then move the user data over. +This is highly recommended when tracking _-STABLE_ for more than one release or when updating a release instead of installing a new one. +Install booteasy on both disks with man:boot0cfg[8] and dual boot until you are happy with the new configuration. +Skip the next paragraph to find out how to move the data after doing this. -Alternatively, partition and label the new disk with either man:sade[8] or man:gpart[8]. If the disks are MBR-formatted, booteasy can be installed on both disks with man:boot0cfg[8] so that the computer can dual boot to the old or new system after the copying is done. +Alternatively, partition and label the new disk with either man:sade[8] or man:gpart[8]. +If the disks are MBR-formatted, booteasy can be installed on both disks with man:boot0cfg[8] so that the computer can dual boot to the old or new system after the copying is done. -Once the new disk set up, the data cannot just be copied. Instead, use tools that understand device files and system flags, such as man:dump[8]. Although it is recommended to move the data while in single-user mode, it is not required. +Once the new disk set up, the data cannot just be copied. +Instead, use tools that understand device files and system flags, such as man:dump[8]. +Although it is recommended to move the data while in single-user mode, it is not required. -When the disks are formatted with UFS, never use anything but man:dump[8] and man:restore[8] to move the root file system. These commands should also be used when moving a single partition to another empty partition. The sequence of steps to use `dump` to move the data from one UFS partitions to a new partition is: +When the disks are formatted with UFS, never use anything but man:dump[8] and man:restore[8] to move the root file system. +These commands should also be used when moving a single partition to another empty partition. +The sequence of steps to use `dump` to move the data from one UFS partitions to a new partition is: [.procedure] ==== @@ -1000,7 +1234,8 @@ For example, to move [.filename]#/dev/ada1s1a# with [.filename]#/mnt# as the tem # dump 0af - / | restore rf - .... -Rearranging partitions with `dump` takes a bit more work. To merge a partition like [.filename]#/var# into its parent, create the new partition large enough for both, move the parent partition as described above, then move the child partition into the empty directory that the first move created: +Rearranging partitions with `dump` takes a bit more work. +To merge a partition like [.filename]#/var# into its parent, create the new partition large enough for both, move the parent partition as described above, then move the child partition into the empty directory that the first move created: [source,shell] .... @@ -1025,24 +1260,41 @@ To split a directory from its parent, say putting [.filename]#/var# on its own p # dump 0af - / | restore rf - .... -The man:cpio[1] and man:pax[1] utilities are also available for moving user data. These are known to lose file flag information, so use them with caution. +The man:cpio[1] and man:pax[1] utilities are also available for moving user data. +These are known to lose file flag information, so use them with caution. [[safe-softupdates]] === Which partitions can safely use Soft Updates? I have heard that Soft Updates on / can cause problems. What about Journaled Soft Updates? Short answer: Soft Updates can usually be safely used on all partitions. *** 1508 LINES SKIPPED *** From owner-dev-commits-doc-all@freebsd.org Sat Jun 12 15:10:51 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CCE1864CD3F for ; Sat, 12 Jun 2021 15:10:51 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G2Lkg58Drz4tqR; Sat, 12 Jun 2021 15:10:51 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 98D50103F8; Sat, 12 Jun 2021 15:10:51 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 15CFAp1O013916; Sat, 12 Jun 2021 15:10:51 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 15CFAp1G013915; Sat, 12 Jun 2021 15:10:51 GMT (envelope-from git) Date: Sat, 12 Jun 2021 15:10:51 GMT Message-Id: <202106121510.15CFAp1G013915@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Sergio Carlavilla Delgado Subject: git: af2add0e2c - main - Use One Sentence Per Line in the Porter's Handbook MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: carlavilla X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: af2add0e2cc2a2d92451693f40b7c94192d4937e Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2021 15:10:51 -0000 The branch main has been updated by carlavilla: URL: https://cgit.FreeBSD.org/doc/commit/?id=af2add0e2cc2a2d92451693f40b7c94192d4937e commit af2add0e2cc2a2d92451693f40b7c94192d4937e Author: Sergio Carlavilla Delgado AuthorDate: 2021-06-12 15:10:24 +0000 Commit: Sergio Carlavilla Delgado CommitDate: 2021-06-12 15:10:24 +0000 Use One Sentence Per Line in the Porter's Handbook --- .../en/books/porters-handbook/flavors/_index.adoc | 26 +- .../books/porters-handbook/keeping-up/_index.adoc | 51 +- .../books/porters-handbook/makefiles/_index.adoc | 971 +++++++++++++++------ .../en/books/porters-handbook/new-port/_index.adoc | 12 +- .../en/books/porters-handbook/order/_index.adoc | 52 +- .../books/porters-handbook/pkg-files/_index.adoc | 68 +- .../en/books/porters-handbook/plist/_index.adoc | 200 +++-- .../porters-handbook/porting-dads/_index.adoc | 155 +++- .../porters-handbook/porting-samplem/_index.adoc | 7 +- .../books/porters-handbook/porting-why/_index.adoc | 7 +- .../porters-handbook/quick-porting/_index.adoc | 90 +- .../en/books/porters-handbook/security/_index.adoc | 77 +- .../porters-handbook/slow-porting/_index.adoc | 129 ++- .../en/books/porters-handbook/special/_index.adoc | 626 +++++++++---- .../en/books/porters-handbook/testing/_index.adoc | 251 ++++-- .../books/porters-handbook/upgrading/_index.adoc | 85 +- .../en/books/porters-handbook/uses/_index.adoc | 501 ++++++++--- 17 files changed, 2420 insertions(+), 888 deletions(-) diff --git a/documentation/content/en/books/porters-handbook/flavors/_index.adoc b/documentation/content/en/books/porters-handbook/flavors/_index.adoc index 8499801376..5ac688fdb4 100644 --- a/documentation/content/en/books/porters-handbook/flavors/_index.adoc +++ b/documentation/content/en/books/porters-handbook/flavors/_index.adoc @@ -34,7 +34,8 @@ toc::[] [[flavors-intro]] == An Introduction to Flavors -Flavors are a way to have multiple variations of a port. The port is built multiple times, with variations. +Flavors are a way to have multiple variations of a port. +The port is built multiple times, with variations. For example, a port can have a normal version with many features and quite a few dependencies, and a light "lite" version with only basic features and minimal dependencies. @@ -43,7 +44,8 @@ Another example could be, a port can have a GTK flavor and a QT flavor, dependin [[flavors-using]] == Using FLAVORS -To declare a port having multiple flavors, add `FLAVORS` to its [.filename]#Makefile#. The first flavor in `FLAVORS` is the default flavor. +To declare a port having multiple flavors, add `FLAVORS` to its [.filename]#Makefile#. +The first flavor in `FLAVORS` is the default flavor. [TIP] ==== @@ -101,7 +103,8 @@ nox11_PKGNAMESUFFIX= -nox11 .More Complex Flavors Usage [example] ==== -Here is a slightly edited excerpt of what is present in package:devel/libpeas[], a port that uses the <>. With the default Python 2 and 3 versions being 2.7 and 3.6, it will automatically get `FLAVORS=py27 py36` +Here is a slightly edited excerpt of what is present in package:devel/libpeas[], a port that uses the <>. +With the default Python 2 and 3 versions being 2.7 and 3.6, it will automatically get `FLAVORS=py27 py36` [.programlisting] .... @@ -182,7 +185,8 @@ lite_PKGNAMESUFFIX= -lite [[flavors-auto-php]] == `USES=php` and Flavors -When using crossref:uses[uses-php,`php`] with one of these arguments, `phpize`, `ext`, `zend`, or `pecl`, the port will automatically have `FLAVORS` filled in with the PHP versions it supports. +When using crossref:uses[uses-php,`php`] with one of these arguments, `phpize`, `ext`, `zend`, or `pecl`, +the port will automatically have `FLAVORS` filled in with the PHP versions it supports. [[flavors-auto-php-ex1]] .Simple `USES=php` Extension @@ -242,13 +246,15 @@ USES= php:flavors [TIP] ==== -When adding a dependency on a PHP flavored port, use `@${PHP_FLAVOR}`. _Never_ use `FLAVOR` directly. +When adding a dependency on a PHP flavored port, use `@${PHP_FLAVOR}`. +_Never_ use `FLAVOR` directly. ==== [[flavors-auto-python]] == `USES=python` and Flavors -When using crossref:uses[uses-python,`python`] and `USE_PYTHON=distutils`, the port will automatically have `FLAVORS` filled in with the Python versions it supports. +When using crossref:uses[uses-python,`python`] and `USE_PYTHON=distutils`, +the port will automatically have `FLAVORS` filled in with the Python versions it supports. [[flavors-auto-python-ex1]] .Simple `USES=python` @@ -312,7 +318,8 @@ USE_PYTHON= distutils allflavors Will get these flavors: `py34`, `py35`, and `py36`. ==== -`PY_FLAVOR` is available to depend on the correct version of Python modules. All dependencies on flavored Python ports should use `PY_FLAVOR`, and not `FLAVOR` directly.. +`PY_FLAVOR` is available to depend on the correct version of Python modules. +All dependencies on flavored Python ports should use `PY_FLAVOR`, and not `FLAVOR` directly.. [[flavors-auto-python-ex3]] .For a Port Not Using `distutils` @@ -332,7 +339,10 @@ USES= python:3.5+ [[flavors-auto-lua]] == `USES=lua` and Flavors -When using crossref:uses[uses-lua,`lua:module`] or crossref:uses[uses-lua,`lua:flavors`], the port will automatically have `FLAVORS` filled in with the Lua versions it supports. However, it is not expected that ordinary applications (rather than Lua modules) should use this feature; most applications that embed or otherwise use Lua should simply use `USES=lua`. +When using crossref:uses[uses-lua,`lua:module`] or crossref:uses[uses-lua,`lua:flavors`], +the port will automatically have `FLAVORS` filled in with the Lua versions it supports. +However, it is not expected that ordinary applications (rather than Lua modules) should use this feature; +most applications that embed or otherwise use Lua should simply use `USES=lua`. `LUA_FLAVOR` is available (and must be used) to depend on the correct version of dependencies regardless of whether the port used the `flavors` or `module` parameters. diff --git a/documentation/content/en/books/porters-handbook/keeping-up/_index.adoc b/documentation/content/en/books/porters-handbook/keeping-up/_index.adoc index fb5143e781..d998432c5d 100644 --- a/documentation/content/en/books/porters-handbook/keeping-up/_index.adoc +++ b/documentation/content/en/books/porters-handbook/keeping-up/_index.adoc @@ -31,26 +31,39 @@ include::shared/en/urls.adoc[] toc::[] -The FreeBSD Ports Collection is constantly changing. Here is some information on how to keep up. +The FreeBSD Ports Collection is constantly changing. +Here is some information on how to keep up. [[freshports]] == FreshPorts -One of the easiest ways to learn about updates that have already been committed is by subscribing to http://www.FreshPorts.org/[FreshPorts]. Multiple ports can be monitored. Maintainers are strongly encouraged to subscribe, because they will receive notification of not only their own changes, but also any changes that any other FreeBSD committer has made. (These are often necessary to keep up with changes in the underlying ports framework-although it would be most polite to receive an advance heads-up from those committing such changes, sometimes this is overlooked or impractical. Also, in some cases, the changes are very minor in nature. We expect everyone to use their best judgement in these cases.) +One of the easiest ways to learn about updates that have already been committed is by subscribing to http://www.FreshPorts.org/[FreshPorts]. +Multiple ports can be monitored. +Maintainers are strongly encouraged to subscribe, because they will receive notification of not only their own changes, but also any changes that any other FreeBSD committer has made. +(These are often necessary to keep up with changes in the underlying ports framework-although it would be most polite to receive an advance heads-up from those committing such changes, sometimes this is overlooked or impractical. +Also, in some cases, the changes are very minor in nature. +We expect everyone to use their best judgement in these cases.) -To use FreshPorts, an account is required. Those with registered email addresses at `@FreeBSD.org` will see the opt-in link on the right-hand side of the web pages. Those who already have a FreshPorts account but are not using a `@FreeBSD.org` email address can change the email to `@FreeBSD.org`, subscribe, then change it back again. +To use FreshPorts, an account is required. +Those with registered email addresses at `@FreeBSD.org` will see the opt-in link on the right-hand side of the web pages. +Those who already have a FreshPorts account but are not using a `@FreeBSD.org` email address can change the email to `@FreeBSD.org`, subscribe, then change it back again. -FreshPorts also has a sanity test feature which automatically tests each commit to the FreeBSD ports tree. If subscribed to this service, a committer will receive notifications of any errors which FreshPorts detects during sanity testing of their commits. +FreshPorts also has a sanity test feature which automatically tests each commit to the FreeBSD ports tree. +If subscribed to this service, a committer will receive notifications of any errors which FreshPorts detects during sanity testing of their commits. [[cgit]] == The Web Interface to the Source Repository -It is possible to browse the files in the source repository by using a web interface. Changes that affect the entire port system are now documented in the https://cgit.freebsd.org/ports/tree/CHANGES[CHANGES] file. Changes that affect individual ports are now documented in the https://cgit.FreeBSD.org/ports/tree/UPDATING[UPDATING] file. However, the definitive answer to any question is undoubtedly to read the source code of https://cgit.FreeBSD.org/ports/tree/Mk/bsd.port.mk[bsd.port.mk], and associated files. +It is possible to browse the files in the source repository by using a web interface. +Changes that affect the entire port system are now documented in the https://cgit.freebsd.org/ports/tree/CHANGES[CHANGES] file. +Changes that affect individual ports are now documented in the https://cgit.FreeBSD.org/ports/tree/UPDATING[UPDATING] file. +However, the definitive answer to any question is undoubtedly to read the source code of https://cgit.FreeBSD.org/ports/tree/Mk/bsd.port.mk[bsd.port.mk], and associated files. [[ports-mailing-list]] == The FreeBSD Ports Mailing List -As a ports maintainer, consider subscribing to {freebsd-ports}. Important changes to the way ports work will be announced there, and then committed to [.filename]#CHANGES#. +As a ports maintainer, consider subscribing to {freebsd-ports}. +Important changes to the way ports work will be announced there, and then committed to [.filename]#CHANGES#. If the volume of messages on this mailing list is too high, consider following {freebsd-ports-announce} which contains only announcements. @@ -59,16 +72,24 @@ If the volume of messages on this mailing list is too high, consider following { One of the least-publicized strengths of FreeBSD is that an entire cluster of machines is dedicated to continually building the Ports Collection, for each of the major OS releases and for each Tier-1 architecture. -Individual ports are built unless they are specifically marked with `IGNORE`. Ports that are marked with `BROKEN` will still be attempted, to see if the underlying problem has been resolved. (This is done by passing `TRYBROKEN` to the port's [.filename]#Makefile#.) +Individual ports are built unless they are specifically marked with `IGNORE`. +Ports that are marked with `BROKEN` will still be attempted, to see if the underlying problem has been resolved. +(This is done by passing `TRYBROKEN` to the port's [.filename]#Makefile#.) [[distfile-survey]] == Portscout: the FreeBSD Ports Distfile Scanner -The build cluster is dedicated to building the latest release of each port with distfiles that have already been fetched. However, as the Internet continually changes, distfiles can quickly go missing. http://portscout.FreeBSD.org[Portscout], the FreeBSD Ports distfile scanner, attempts to query every download site for every port to find out if each distfile is still available. Portscout can generate HTML reports and send emails about newly available ports to those who request them. Unless not otherwise subscribed, maintainers are asked to check periodically for changes, either by hand or using the RSS feed. +The build cluster is dedicated to building the latest release of each port with distfiles that have already been fetched. +However, as the Internet continually changes, distfiles can quickly go missing. +http://portscout.FreeBSD.org[Portscout], the FreeBSD Ports distfile scanner, attempts to query every download site for every port to find out if each distfile is still available. +Portscout can generate HTML reports and send emails about newly available ports to those who request them. +Unless not otherwise subscribed, maintainers are asked to check periodically for changes, either by hand or using the RSS feed. -Portscout's first page gives the email address of the port maintainer, the number of ports the maintainer is responsible for, the number of those ports with new distfiles, and the percentage of those ports that are out-of-date. The search function allows for searching by email address for a specific maintainer, and for selecting whether only out-of-date ports are shown. +Portscout's first page gives the email address of the port maintainer, the number of ports the maintainer is responsible for, the number of those ports with new distfiles, and the percentage of those ports that are out-of-date. +The search function allows for searching by email address for a specific maintainer, and for selecting whether only out-of-date ports are shown. -Upon clicking on a maintainer's email address, a list of all of their ports is displayed, along with port category, current version number, whether or not there is a new version, when the port was last updated, and finally when it was last checked. A search function on this page allows the user to search for a specific port. +Upon clicking on a maintainer's email address, a list of all of their ports is displayed, along with port category, current version number, whether or not there is a new version, when the port was last updated, and finally when it was last checked. +A search function on this page allows the user to search for a specific port. Clicking on a port name in the list displays the http://freshports.org[FreshPorts] port information. @@ -77,11 +98,17 @@ Additional documentation is available in the https://github.com/freebsd/portscou [[portsmon]] == The FreeBSD Ports Monitoring System -Another handy resource is the http://portsmon.FreeBSD.org[FreeBSD Ports Monitoring System] (also known as `portsmon`). This system comprises a database that processes information from several sources and allows it to be browsed via a web interface. Currently, the ports Problem Reports (PRs), the error logs from the build cluster, and individual files from the ports collection are used. In the future, this will be expanded to include the distfile survey, as well as other sources. +Another handy resource is the http://portsmon.FreeBSD.org[FreeBSD Ports Monitoring System] (also known as `portsmon`). +This system comprises a database that processes information from several sources and allows it to be browsed via a web interface. +Currently, the ports Problem Reports (PRs), the error logs from the build cluster, and individual files from the ports collection are used. +In the future, this will be expanded to include the distfile survey, as well as other sources. To get started, use the http://portsmon.FreeBSD.org/portoverview.py[Overview of One Port] search page to find all the information about a port. -This is the only resource available that maps PR entries to portnames. PR submitters do not always include the portname in their Synopsis, although we would prefer that they did. So, `portsmon` is a good place to find out whether an existing port has any PRs filed against it, any build errors, or if a new port the porter is considering creating has already been submitted. +This is the only resource available that maps PR entries to portnames. +PR submitters do not always include the portname in their Synopsis, although we would prefer that they did. +So, `portsmon` is a good place to find out whether an existing port has any PRs filed against it, any build errors, +or if a new port the porter is considering creating has already been submitted. [NOTE] ====== diff --git a/documentation/content/en/books/porters-handbook/makefiles/_index.adoc b/documentation/content/en/books/porters-handbook/makefiles/_index.adoc index 60c878dbac..269ee28dca 100644 --- a/documentation/content/en/books/porters-handbook/makefiles/_index.adoc +++ b/documentation/content/en/books/porters-handbook/makefiles/_index.adoc @@ -32,16 +32,20 @@ include::shared/en/urls.adoc[] toc::[] -Configuring the [.filename]#Makefile# is pretty simple, and again we suggest looking at existing examples before starting. Also, there is a crossref:porting-samplem[porting-samplem,sample Makefile] in this handbook, so take a look and please follow the ordering of variables and sections in that template to make the port easier for others to read. +Configuring the [.filename]#Makefile# is pretty simple, and again we suggest looking at existing examples before starting. +Also, there is a crossref:porting-samplem[porting-samplem,sample Makefile] in this handbook, +so take a look and please follow the ordering of variables and sections in that template to make the port easier for others to read. Consider these problems in sequence during the design of the new [.filename]#Makefile#: [[makefile-source]] == The Original Source -Does it live in `DISTDIR` as a standard ``gzip``ped tarball named something like [.filename]#foozolix-1.2.tar.gz#? If so, go on to the next step. If not, the distribution file format might require overriding one or more of `DISTVERSION`, `DISTNAME`, `EXTRACT_CMD`, `EXTRACT_BEFORE_ARGS`, `EXTRACT_AFTER_ARGS`, `EXTRACT_SUFX`, or `DISTFILES`. +Does it live in `DISTDIR` as a standard ``gzip``ped tarball named something like [.filename]#foozolix-1.2.tar.gz#? If so, go on to the next step. +If not, the distribution file format might require overriding one or more of `DISTVERSION`, `DISTNAME`, `EXTRACT_CMD`, `EXTRACT_BEFORE_ARGS`, `EXTRACT_AFTER_ARGS`, `EXTRACT_SUFX`, or `DISTFILES`. -In the worst case, create a custom `do-extract` target to override the default. This is rarely, if ever, necessary. +In the worst case, create a custom `do-extract` target to override the default. +This is rarely, if ever, necessary. [[makefile-naming]] == Naming @@ -51,11 +55,14 @@ The first part of the port's [.filename]#Makefile# names the port, describes its [[makefile-portname]] === `PORTNAME` -Set `PORTNAME` to the base name of the software. It is used as the base for the FreeBSD package, and for <>. +Set `PORTNAME` to the base name of the software. +It is used as the base for the FreeBSD package, and for <>. [IMPORTANT] ==== -The package name must be unique across the entire ports tree. Make sure that the `PORTNAME` is not already in use by an existing port, and that no other port already has the same `PKGBASE`. If the name has already been used, add either <>. +The package name must be unique across the entire ports tree. +Make sure that the `PORTNAME` is not already in use by an existing port, and that no other port already has the same `PKGBASE`. +If the name has already been used, add either <>. ==== [[makefile-versions]] @@ -63,7 +70,9 @@ The package name must be unique across the entire ports tree. Make sure that the Set `DISTVERSION` to the version number of the software. -`PORTVERSION` is the version used for the FreeBSD package. It will be automatically derived from `DISTVERSION` to be compatible with FreeBSD's package versioning scheme. If the version contains _letters_, it might be needed to set `PORTVERSION` and not `DISTVERSION`. +`PORTVERSION` is the version used for the FreeBSD package. +It will be automatically derived from `DISTVERSION` to be compatible with FreeBSD's package versioning scheme. +If the version contains _letters_, it might be needed to set `PORTVERSION` and not `DISTVERSION`. [IMPORTANT] ==== @@ -74,8 +83,8 @@ From time to time, some software will use a version scheme that is not compatibl [TIP] ==== - -When updating a port, it is possible to use man:pkg-version[8]'s `-t` argument to check if the new version is greater or lesser than before. See <>. +When updating a port, it is possible to use man:pkg-version[8]'s `-t` argument to check if the new version is greater or lesser than before. +See <>. ==== [[makefile-versions-ex-pkg-version]] @@ -109,7 +118,8 @@ When updating a port, it is possible to use man:pkg-version[8]'s `-t` argument t [NOTE] **** -In here, the `a`, `b`, and `p` are used as if meaning "alpha", "beta" or "pre-release" and "patch level", but they are only letters and are sorted alphabetically, so any letter can be used, and they will be sorted appropriately. +In here, the `a`, `b`, and `p` are used as if meaning "alpha", "beta" or "pre-release" and "patch level", +but they are only letters and are sorted alphabetically, so any letter can be used, and they will be sorted appropriately. **** ==== @@ -163,7 +173,8 @@ DISTVERSIONPREFIX= v DISTVERSION= 1_2_4 .... -Some of the time, projects using GitHub will use their name in their versions. For example, the version could be `nekoto-1.2-4`: +Some of the time, projects using GitHub will use their name in their versions. +For example, the version could be `nekoto-1.2-4`: [.programlisting] .... @@ -236,7 +247,8 @@ PORTNAME= nekoto PORTVERSION= 1.2p4 .... -In this case, using `DISTVERSION` is not possible because it would generate a version of `1.2.p4` which would be before `1.2` and not after. man:pkg-version[8] will verify this: +In this case, using `DISTVERSION` is not possible because it would generate a version of `1.2.p4` which would be before `1.2` and not after. +man:pkg-version[8] will verify this: [source,shell] .... @@ -258,9 +270,11 @@ For some more advanced examples of setting `PORTVERSION`, when the software's ve [[makefile-portrevision]] ==== `PORTREVISION` -`PORTREVISION` is a monotonically increasing value which is reset to 0 with every increase of `DISTVERSION`, typically every time there is a new official vendor release. If `PORTREVISION` is non-zero, the value is appended to the package name. Changes to `PORTREVISION` are used by automated tools like man:pkg-version[8] to determine that a new package is available. +`PORTREVISION` is a monotonically increasing value which is reset to 0 with every increase of `DISTVERSION`, typically every time there is a new official vendor release. If `PORTREVISION` is non-zero, the value is appended to the package name. +Changes to `PORTREVISION` are used by automated tools like man:pkg-version[8] to determine that a new package is available. -`PORTREVISION` must 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 <>. +`PORTREVISION` must 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 <>. Examples of when `PORTREVISION` must be bumped: @@ -277,22 +291,28 @@ Examples of changes which do not require a `PORTREVISION` bump: * Trivial patches to the distfile such as correction of typos, which are not important enough that users of the package have to 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 decide whether a change committed to a port is something which _some_ people would benefit from having. Either because of an enhancement, fix, or by virtue that the new package will actually work at all. Then weigh that against that fact that it will cause everyone who regularly updates their ports tree to be compelled to update. If yes, `PORTREVISION` must be bumped. +A rule of thumb is to decide whether a change committed to a port is something which _some_ people would benefit from having. +Either because of an enhancement, fix, or by virtue that the new package will actually work at all. +Then weigh that against that fact that it will cause everyone who regularly updates their ports tree to be compelled to update. +If yes, `PORTREVISION` must be bumped. [NOTE] ==== -People using binary packages will _never_ see the update if `PORTREVISION` is not bumped. Without increasing `PORTREVISION`, the package builders have no way to detect the change and thus, will not rebuild the package. +People using binary packages will _never_ see the update if `PORTREVISION` is not bumped. +Without increasing `PORTREVISION`, the package builders have no way to detect the change and thus, will not rebuild the package. ==== [[makefile-portepoch]] ==== `PORTEPOCH` -From time to time a software vendor or FreeBSD 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). +From time to time a software vendor or FreeBSD 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). [TIP] ==== - -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: +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: [source,shell] .... @@ -303,13 +323,21 @@ The results of version number comparisons are not always obvious. `pkg version` 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, `PORTEPOCH` must 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. For example, the package would not be detected as out of date. The new version number, `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. +In situations such as this, `PORTEPOCH` must 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. +For example, the package would not be detected as out of date. +The new version number, `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 the discussion above was not clear enough, please consult the {freebsd-ports}. +Dropping or resetting `PORTEPOCH` incorrectly leads to no end of grief. +If the discussion above was not clear enough, please consult the {freebsd-ports}. -It is expected that `PORTEPOCH` will not be used for the majority of ports, and that sensible use of `DISTVERSION`, or that use `PORTVERSION` carefully, can often preempt it becoming necessary if a future release of the software changes the version structure. However, care is needed by FreeBSD 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. +It is expected that `PORTEPOCH` will not be used for the majority of ports, and that sensible use of `DISTVERSION`, or that use `PORTVERSION` carefully, can often preempt it becoming necessary if a future release of the software changes the version structure. +However, care is needed by FreeBSD 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`, do not use `20000917` for `DISTVERSION`. The correct way is a `DISTVERSION` of `1.2.20000917`, or similar, so that the succeeding release, say `1.3`, is still a numerically greater value. +For example, if a snapshot release is made on the date `20000917`, and the previous version of the software was version `1.2`, do not use `20000917` for `DISTVERSION`. +The correct way is a `DISTVERSION` of `1.2.20000917`, or similar, so that the succeeding release, say `1.3`, is still a numerically greater value. [[makefile-portrevision-example]] ==== Example of `PORTREVISION` and `PORTEPOCH` Usage @@ -324,7 +352,8 @@ DISTVERSION= 0.10 `PKGNAME` becomes `gtkmumble-0.10`. -A security hole is discovered which requires a local FreeBSD patch. `PORTREVISION` is bumped accordingly. +A security hole is discovered which requires a local FreeBSD patch. +`PORTREVISION` is bumped accordingly. [.programlisting] .... @@ -335,7 +364,9 @@ 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`, `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 [.filename]#Makefile#). +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`, `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 [.filename]#Makefile#). [.programlisting] .... @@ -346,7 +377,8 @@ PORTEPOCH= 1 `PKGNAME` becomes `gtkmumble-0.2,1` -The next release is 0.3. Since `PORTEPOCH` never decreases, the version variables are now: +The next release is 0.3. +Since `PORTEPOCH` never decreases, the version variables are now: [.programlisting] .... @@ -359,47 +391,69 @@ PORTEPOCH= 1 [NOTE] ==== -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. +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. ==== [[porting-pkgnameprefix-suffix]] === `PKGNAMEPREFIX` and `PKGNAMESUFFIX` -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 <>. In particular, the use of a hyphen (`-`) in `PORTVERSION` is _not_ allowed. 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`. +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 <>. +In particular, the use of a hyphen (`-`) in `PORTVERSION` is _not_ allowed. +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`. [[porting-pkgname]] === Package Naming Conventions -These are the conventions to follow when naming packages. This is to make the package directory easy to scan, as there are already thousands of packages and users are going to turn away if they hurt their eyes! +These are the conventions to follow when naming packages. +This is to make the package directory easy to scan, as there are already thousands of packages and users are going to turn away if they hurt their eyes! Package names take the form of [.filename]#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. +The package name is defined as `${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}`. +Make sure to set the variables to conform to that format. [[porting-pkgname-language]] [.filename]#language_region-#:: -FreeBSD strives to support the native language of its users. The _language-_ part is a two letter abbreviation of the natural language defined by ISO-639 when 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. +FreeBSD strives to support the native language of its users. +The _language-_ part is a two letter abbreviation of the natural language defined by ISO-639 when 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. +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 is set in `PKGNAMEPREFIX`. [[porting-pkgname-name]] [.filename]#name#:: -Make sure that the port's name and version are clearly separated and placed into `PORTNAME` and `DISTVERSION`. The only reason for `PORTNAME` to contain a version part is if the upstream distribution is really named that way, as in the package:textproc/libxml2[] or package:japanese/kinput2-freewnn[] ports. Otherwise, `PORTNAME` cannot contain any version-specific information. It is quite normal for several ports to have the same `PORTNAME`, as the package:www/apache*[] ports do; in that case, different versions (and different index entries) are distinguished by `PKGNAMEPREFIX` and `PKGNAMESUFFIX` values. +Make sure that the port's name and version are clearly separated and placed into `PORTNAME` and `DISTVERSION`. +The only reason for `PORTNAME` to contain a version part is if the upstream distribution is really named that way, as in the package:textproc/libxml2[] or package:japanese/kinput2-freewnn[] ports. +Otherwise, `PORTNAME` cannot contain any version-specific information. +It is quite normal for several ports to have the same `PORTNAME`, as the package:www/apache*[] ports do; in that case, different versions (and different index entries) are distinguished by `PKGNAMEPREFIX` and `PKGNAMESUFFIX` values. + -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`. +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`. [[porting-pkgname-compiled-specifics]] [.filename]#-compiled.specifics#:: -If the port can be built with different <> (usually part of the directory name in a family of ports), the _-compiled.specifics_ part states the compiled-in defaults. The hyphen is optional. Examples are paper size and font units. +If the port can be built with different <> (usually part of the directory name in a family of ports), the _-compiled.specifics_ part states the compiled-in defaults. +The hyphen is optional. +Examples are paper size and font units. + The _-compiled.specifics_ part is set in `PKGNAMESUFFIX`. [[porting-pkgname-version-numbers]] [.filename]#-version.numbers#:: -The version string follows a dash (`-`) and is 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 follow the single alphabet without an extra period between them (for example, `1.0b2`). +The version string follows a dash (`-`) and is 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 follow the single alphabet without an extra period between them (for example, `1.0b2`). + -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 `d__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 a letter, here `d` (for date), in case a release with an actual version number is made, which would be numerically less than `_yyyy_`. +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 `d__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 a letter, here `d` (for date), in case a release with an actual version number is made, which would be numerically less than `_yyyy_`. [IMPORTANT] ==== @@ -524,12 +578,13 @@ Here are some (real) examples on how to convert the name as called by the softwa |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 the source file was released on (`d__yyyy.mm.dd__`, or `d__yyyymmdd__`) as the version. +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 the source file was released on (`d__yyyy.mm.dd__`, or `d__yyyymmdd__`) as the version. [TIP] ==== - -Use any letter. Here, `d` here stands for date, if the source is a Git repository, `g` followed by the commit date is commonly used, using `s` for snapshot is also common. +Use any letter. +Here, `d` here stands for date, if the source is a Git repository, `g` followed by the commit date is commonly used, using `s` for snapshot is also common. ==== [[makefile-categories]] @@ -538,14 +593,21 @@ Use any letter. Here, `d` here stands for date, if the source is a Git repositor [[makefile-categories-definition]] === `CATEGORIES` -When a package is created, it is put under [.filename]#/usr/ports/packages/All# and links are made from one or more subdirectories of [.filename]#/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 <> and pick the ones that are suitable for the port. +When a package is created, it is put under [.filename]#/usr/ports/packages/All# and links are made from one or more subdirectories of [.filename]#/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 <> and pick the ones that are suitable for the port. -This list also determines where in the ports tree the port is imported. If there is more than one category here, the port files must be put in the subdirectory with the name of the first category. See <> for more discussion about how to pick the right categories. +This list also determines where in the ports tree the port is imported. +If there is more than one category here, the port files must be put in the subdirectory with the name of the first category. +See <> for more discussion about how to pick the right categories. [[porting-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. +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. [NOTE] ==== @@ -947,7 +1009,9 @@ For non-virtual categories, there is a one-line description in `COMMENT` in that [[choosing-categories]] === Choosing the Right Category -As many of the categories overlap, choosing which of the categories will be the primary category of the port can be tedious. There are several rules that govern this issue. Here is the list of priorities, in decreasing order of precedence: +As many of the categories overlap, choosing which of the categories will be the primary category of the port can be tedious. +There are several rules that govern this issue. +Here is the list of priorities, in decreasing order of precedence: * The first category must be a physical category (see <>). This is necessary to make the packaging work. Virtual categories and physical categories may be intermixed after that. * Language specific categories always come first. For example, if the port installs Japanese X11 fonts, then the `CATEGORIES` line would read [.filename]#japanese x11-fonts#. @@ -958,16 +1022,22 @@ As many of the categories overlap, choosing which of the categories will be the * [.filename]#misc# does not appear with any other non-virtual category. If there is `misc` with something else in `CATEGORIES`, that means `misc` can safely be deleted and the port placed only in the other subdirectory. * If the port truly does not belong anywhere else, put it in [.filename]#misc#. -If the category is not clearly defined, please put a comment to that effect in the https://bugs.freebsd.org/submit/[port submission] in the bug database so we can discuss it before we import it. As a committer, send a note to the {freebsd-ports} so we can discuss it first. Too often, new ports are imported to the wrong category only to be moved right away. +If the category is not clearly defined, please put a comment to that effect in the https://bugs.freebsd.org/submit/[port submission] in the bug database so we can discuss it before we import it. +As a committer, send a note to the {freebsd-ports} so we can discuss it first. +Too often, new ports are imported to the wrong category only to be moved right away. [[proposing-categories]] === Proposing a New Category -As the Ports Collection has grown over time, various new categories have been introduced. New categories can either be _virtual_ categories-those that do not have a corresponding subdirectory in the ports tree- or _physical_ categories-those that do. This section discusses the issues involved in creating a new physical category. Read it thouroughly before proposing a new one. +As the Ports Collection has grown over time, various new categories have been introduced. +New categories can either be _virtual_ categories-those that do not have a corresponding subdirectory in the ports tree- or _physical_ categories-those that do. This section discusses the issues involved in creating a new physical category. +Read it thouroughly before proposing a new one. Our existing practice has been to avoid creating a new physical category unless either a large number of ports would logically belong to it, or the ports that would belong to it are a logically distinct group that is of limited general interest (for instance, categories related to spoken human languages), or preferably both. -The rationale for this is that such a change creates a link:{committers-guide}#ports[fair amount of work] for both the committers and also for all users who track changes to the Ports Collection. In addition, proposed category changes just naturally seem to attract controversy. (Perhaps this is because there is no clear consensus on when a category is "too big", nor whether categories should lend themselves to browsing (and thus what number of categories would be an ideal number), and so forth.) +The rationale for this is that such a change creates a link:{committers-guide}#ports[fair amount of work] for both the committers and also for all users who track changes to the Ports Collection. +In addition, proposed category changes just naturally seem to attract controversy. +(Perhaps this is because there is no clear consensus on when a category is "too big", nor whether categories should lend themselves to browsing (and thus what number of categories would be an ideal number), and so forth.) Here is the procedure: @@ -985,12 +1055,16 @@ Here is the procedure: . Since it affects the ports infrastructure and involves moving and patching many ports but also possibly running regression tests on the build cluster, assign the PR to the {portmgr}. . If that PR is approved, a committer will need to follow the rest of the procedure that is link:{committers-guide}#PORTS[outlined in the Committer's Guide]. -Proposing a new virtual category is similar to the above but much less involved, since no ports will actually have to move. In this case, the only patches to include in the PR would be those to add the new category to `CATEGORIES` of the affected ports. +Proposing a new virtual category is similar to the above but much less involved, since no ports will actually have to move. +In this case, the only patches to include in the PR would be those to add the new category to `CATEGORIES` of the affected ports. [[proposing-reorg]] === Proposing Reorganizing All the Categories -Occasionally someone proposes reorganizing the categories with either a 2-level structure, or some other kind of keyword structure. To date, nothing has come of any of these proposals because, while they are very easy to make, the effort involved to retrofit the entire existing ports collection with any kind of reorganization is daunting to say the very least. Please read the history of these proposals in the mailing list archives before posting this idea. Furthermore, be prepared to be challenged to offer a working prototype. +Occasionally someone proposes reorganizing the categories with either a 2-level structure, or some other kind of keyword structure. +To date, nothing has come of any of these proposals because, while they are very easy to make, the effort involved to retrofit the entire existing ports collection with any kind of reorganization is daunting to say the very least. +Please read the history of these proposals in the mailing list archives before posting this idea. +Furthermore, be prepared to be challenged to offer a working prototype. [[makefile-distfiles]] == The Distribution Files @@ -1000,16 +1074,23 @@ The second part of the [.filename]#Makefile# describes the files that must be do [[makefile-distname]] === `DISTNAME` -`DISTNAME` is the name of the port as called by the authors of the software. `DISTNAME` defaults to `${PORTNAME}-${DISTVERSIONPREFIX}${DISTVERSION}${DISTVERSIONSUFFIX}`, and if not set, `DISTVERSION` defaults to `${PORTVERSION}` so override `DISTNAME` only if necessary. `DISTNAME` is only used in two places. First, the distribution file list (`DISTFILES`) defaults to `${DISTNAME}${EXTRACT_SUFX}`. Second, the distribution file is expected to extract into a subdirectory named `WRKSRC`, which defaults to [.filename]#work/${DISTNAME}#. +`DISTNAME` is the name of the port as called by the authors of the software. +`DISTNAME` defaults to `${PORTNAME}-${DISTVERSIONPREFIX}${DISTVERSION}${DISTVERSIONSUFFIX}`, and if not set, `DISTVERSION` defaults to `${PORTVERSION}` so override `DISTNAME` only if necessary. +`DISTNAME` is only used in two places. +First, the distribution file list (`DISTFILES`) defaults to `${DISTNAME}${EXTRACT_SUFX}`. +Second, the distribution file is expected to extract into a subdirectory named `WRKSRC`, which defaults to [.filename]#work/${DISTNAME}#. -Some vendor's distribution names which do not fit into the `${PORTNAME}-${PORTVERSION}`-scheme can be handled automatically by setting `DISTVERSIONPREFIX`, `DISTVERSION`, and `DISTVERSIONSUFFIX`. `PORTVERSION` will be derived from `DISTVERSION` automatically. +Some vendor's distribution names which do not fit into the `${PORTNAME}-${PORTVERSION}`-scheme can be handled automatically by setting `DISTVERSIONPREFIX`, `DISTVERSION`, and `DISTVERSIONSUFFIX`. +`PORTVERSION` will be derived from `DISTVERSION` automatically. [IMPORTANT] ==== -Only one of `PORTVERSION` and `DISTVERSION` can be set at a time. If `DISTVERSION` does not derive a correct `PORTVERSION`, do not use `DISTVERSION`. +Only one of `PORTVERSION` and `DISTVERSION` can be set at a time. +If `DISTVERSION` does not derive a correct `PORTVERSION`, do not use `DISTVERSION`. ==== -If the upstream version scheme can be derived into a ports-compatible version scheme, set some variable to the upstream version, _do not_ use `DISTVERSION` as the variable name. Set `PORTVERSION` to the computed version based on the variable you created, and set `DISTNAME` accordingly. +If the upstream version scheme can be derived into a ports-compatible version scheme, set some variable to the upstream version, _do not_ use `DISTVERSION` as the variable name. +Set `PORTVERSION` to the computed version based on the variable you created, and set `DISTNAME` accordingly. If the upstream version scheme cannot easily be coerced into a ports-compatible value, set `PORTVERSION` to a sensible value, and set `DISTNAME` with `PORTNAME` with the verbatim upstream version. @@ -1017,7 +1098,9 @@ If the upstream version scheme cannot easily be coerced into a ports-compatible .Deriving `PORTVERSION` Manually [example] ==== -BIND9 uses a version scheme that is not compatible with the ports versions (it has `-` in its versions) and cannot be derived using `DISTVERSION` because after the 9.9.9 release, it will release a "patchlevels" in the form of `9.9.9-P1`. DISTVERSION would translate that into `9.9.9.p1`, which, in the ports versioning scheme means 9.9.9 pre-release 1, which is before 9.9.9 and not after. So `PORTVERSION` is manually derived from an `ISCVERSION` variable to output `9.9.9p1`. +BIND9 uses a version scheme that is not compatible with the ports versions (it has `-` in its versions) and cannot be derived using `DISTVERSION` because after the 9.9.9 release, it will release a "patchlevels" in the form of `9.9.9-P1`. +DISTVERSION would translate that into `9.9.9.p1`, which, in the ports versioning scheme means 9.9.9 pre-release 1, which is before 9.9.9 and not after. +So `PORTVERSION` is manually derived from an `ISCVERSION` variable to output `9.9.9p1`. The order into which the ports framework, and pkg, will sort versions is checked using the `-t` argument of man:pkg-version[8]: @@ -1075,7 +1158,8 @@ MASTER_SITES= ftp://ftp.kermitproject.org/kermit/test/tar/ DISTNAME= cku${PORTVERSION:E}-dev20 .... -The `:E` man:make[1] modifier returns the suffix of the variable, in this case, `304`. The distribution file is correctly generated as `cku304-dev20.tar.gz`. +The `:E` man:make[1] modifier returns the suffix of the variable, in this case, `304`. +The distribution file is correctly generated as `cku304-dev20.tar.gz`. ==== [[makefile-distname-ex3]] @@ -1117,21 +1201,28 @@ DIST_SUBDIR= ${PORTNAME}-${PORTVERSION} [NOTE] ==== -`PKGNAMEPREFIX` and `PKGNAMESUFFIX` do not affect `DISTNAME`. Also note that if `WRKSRC` is equal to [.filename]#${WRKDIR}/${DISTNAME}# while the original source archive is named something other than `${PORTNAME}-${PORTVERSION}${EXTRACT_SUFX}`, leave `DISTNAME` alone- defining only `DISTFILES` is easier than both `DISTNAME` and `WRKSRC` (and possibly `EXTRACT_SUFX`). +`PKGNAMEPREFIX` and `PKGNAMESUFFIX` do not affect `DISTNAME`. +Also note that if `WRKSRC` is equal to [.filename]#${WRKDIR}/${DISTNAME}# while the original source archive is named something other than `${PORTNAME}-${PORTVERSION}${EXTRACT_SUFX}`, leave `DISTNAME` alone- defining only `DISTFILES` is easier than both `DISTNAME` and `WRKSRC` (and possibly `EXTRACT_SUFX`). ==== [[makefile-master_sites]] === `MASTER_SITES` -Record the directory part of the FTP/HTTP-URL pointing at the original tarball in `MASTER_SITES`. Do not forget the trailing slash ([.filename]#/#)! +Record the directory part of the FTP/HTTP-URL pointing at the original tarball in `MASTER_SITES`. +Do not forget the trailing slash ([.filename]#/#)! The `make` macros will try to use this specification for grabbing the distribution file with `FETCH` if they cannot find it already on the system. -It is recommended that multiple sites are included on this list, preferably from different continents. This will safeguard against wide-area network problems. +It is recommended that multiple sites are included on this list, preferably from different continents. +This will safeguard against wide-area network problems. [IMPORTANT] ==== -`MASTER_SITES` must not be blank. It must point to the actual site hosting the distribution files. It cannot point to web archives, or the FreeBSD distribution files cache sites. The only exception to this rule is ports that do not have any distribution files. For example, meta-ports do not have any distribution files, so `MASTER_SITES` does not need to be set. +`MASTER_SITES` must not be blank. +It must point to the actual site hosting the distribution files. +It cannot point to web archives, or the FreeBSD distribution files cache sites. +The only exception to this rule is ports that do not have any distribution files. +For example, meta-ports do not have any distribution files, so `MASTER_SITES` does not need to be set. ==== [[makefile-master_sites-shorthand]] @@ -1144,7 +1235,8 @@ Shortcut abbreviations are available for popular archives like SourceForge (`SOU MASTER_SITES= GNU/make .... -The older expanded format still works, but all ports have been converted to the compact format. The expanded format looks like this: +The older expanded format still works, but all ports have been converted to the compact format. +The expanded format looks like this: [.programlisting] .... @@ -1152,12 +1244,13 @@ MASTER_SITES= ${MASTER_SITE_GNU} MASTER_SITE_SUBDIR= make .... -These values and variables are defined in https://cgit.freebsd.org/ports/tree/Mk/bsd.sites.mk[Mk/bsd.sites.mk]. New entries are added often, so make sure to check the latest version of this file before submitting a port. +These values and variables are defined in https://cgit.freebsd.org/ports/tree/Mk/bsd.sites.mk[Mk/bsd.sites.mk]. +New entries are added often, so make sure to check the latest version of this file before submitting a port. [TIP] ==== - -For any `MASTER_SITE_FOO` variable, the shorthand `_FOO_` can be used. For example, use: +For any `MASTER_SITE_FOO` variable, the shorthand `_FOO_` can be used. +For example, use: [.programlisting] .... @@ -1210,14 +1303,17 @@ Some `MASTER_SITE_*` names are quite long, and for ease of use, shortcuts have b [[makefile-master_sites-magic]] ==== Magic MASTER_SITES Macros -Several "magic" macros exist for popular sites with a predictable directory structure. For these, just use the abbreviation and the system will choose a subdirectory automatically. For a port named `Stardict`, of version `1.2.3`, and hosted on SourceForge, adding this line: +Several "magic" macros exist for popular sites with a predictable directory structure. +For these, just use the abbreviation and the system will choose a subdirectory automatically. +For a port named `Stardict`, of version `1.2.3`, and hosted on SourceForge, adding this line: [.programlisting] .... MASTER_SITES= SF .... -infers a subdirectory named `/project/stardict/stardict/1.2.3`. If the inferred directory is incorrect, it can be overridden: +infers a subdirectory named `/project/stardict/stardict/1.2.3`. +If the inferred directory is incorrect, it can be overridden: [.programlisting] .... @@ -1324,7 +1420,9 @@ MASTER_SITE_SUBDIR= stardict/WyabdcRealPeopleTTS/${PORTVERSION} [[makefile-master_sites-github]] === `USE_GITHUB` -If the distribution file comes from a specific commit or tag on https://github.com[GitHub] for which there is no officially released file, there is an easy way to set the right `DISTNAME` and `MASTER_SITES` automatically. These variables are available: +If the distribution file comes from a specific commit or tag on https://github.com[GitHub] for which there is no officially released file, +there is an easy way to set the right `DISTNAME` and `MASTER_SITES` automatically. +These variables are available: [[makefile-master_sites-github-description]] .`USE_GITHUB` Description @@ -1399,7 +1497,6 @@ It will automatically have `MASTER_SITES` set to `GH` and `WRKSRC` to `${WRKDIR} [TIP] **** - `20140411` is the date of the commit referenced in `GH_TAGNAME`, not the date the [.filename]#Makefile# is edited, or the date the commit is made. **** @@ -1409,7 +1506,9 @@ It will automatically have `MASTER_SITES` set to `GH` and `WRKSRC` to `${WRKDIR} .Use of `USE_GITHUB` with `DISTVERSIONPREFIX` [example] ==== -From time to time, `GH_TAGNAME` is a slight variation from `DISTVERSION`. For example, if the version is `1.0.2`, the tag is `v1.0.2`. In those cases, it is possible to use `DISTVERSIONPREFIX` or `DISTVERSIONSUFFIX`: +From time to time, `GH_TAGNAME` is a slight variation from `DISTVERSION`. +For example, if the version is `1.0.2`, the tag is `v1.0.2`. +In those cases, it is possible to use `DISTVERSIONPREFIX` or `DISTVERSIONSUFFIX`: [.programlisting] .... @@ -1427,7 +1526,8 @@ It will automatically set `GH_TAGNAME` to `v1.0.2`, while `WRKSRC` will be kept .Using `USE_GITHUB` When Upstream Does Not Use Versions [example] ==== -If there never was a version upstream, do not invent one like `0.1` or `1.0`. Create the port with a `DISTVERSION` of `g__YYYYMMDD__`, where `g` is for Git, and `_YYYYMMDD_` represents the date the commit referenced in `GH_TAGNAME`. +If there never was a version upstream, do not invent one like `0.1` or `1.0`. +Create the port with a `DISTVERSION` of `g__YYYYMMDD__`, where `g` is for Git, and `_YYYYMMDD_` represents the date the commit referenced in `GH_TAGNAME`. [.programlisting] .... @@ -1453,7 +1553,6 @@ Which means using `PORTEPOCH` will not be needed in case upstream decides to cut .Using `USE_GITHUB` to Access a Commit Between Two Versions [example] ==== - If the current version of the software uses a Git tag, and the port needs to be updated to a newer, intermediate version, without a tag, use man:git-describe[1] to find out the version to use: [source,shell] @@ -1483,7 +1582,8 @@ DISTVERSIONSUFFIX= -gf0038b1 USE_GITHUB= yes .... -This creates a versioning scheme that increases over time (well, over commits), and does not conflict with the creation of a `0.7.4` version. (See <> for details on man:pkg-version[8]): +This creates a versioning scheme that increases over time (well, over commits), and does not conflict with the creation of a `0.7.4` version. +(See <> for details on man:pkg-version[8]): [source,shell] .... @@ -1495,7 +1595,8 @@ This creates a versioning scheme that increases over time (well, over commits), [NOTE] **** -If the requested commit is the same as a tag, a shorter description is shown by default. The longer version is equivalent: +If the requested commit is the same as a tag, a shorter description is shown by default. +The longer version is equivalent: [source,shell] .... @@ -1513,18 +1614,24 @@ v0.7.3-0-gc66c71d [[makefile-master_sites-github-multiple]] ==== Fetching Multiple Files from GitHub -The `USE_GITHUB` framework also supports fetching multiple distribution files from different places in GitHub. It works in a way very similar to <>. +The `USE_GITHUB` framework also supports fetching multiple distribution files from different places in GitHub. +It works in a way very similar to <>. -Multiple values are added to `GH_ACCOUNT`, `GH_PROJECT`, and `GH_TAGNAME`. Each different value is assigned a group. The main value can either have no group, or the `:DEFAULT` group. A value can be omitted if it is the same as the default as listed in <>. +Multiple values are added to `GH_ACCOUNT`, `GH_PROJECT`, and `GH_TAGNAME`. +Each different value is assigned a group. +The main value can either have no group, or the `:DEFAULT` group. +A value can be omitted if it is the same as the default as listed in <>. -`GH_TUPLE` can also be used when there are a lot of distribution files. It helps keep the account, project, tagname, and group information at the same place. +`GH_TUPLE` can also be used when there are a lot of distribution files. +It helps keep the account, project, tagname, and group information at the same place. -For each group, a `${WRKSRC_group}` helper variable is created, containing the directory into which the file has been extracted. The `${WRKSRC_group}` variables can be used to move directories around during `post-extract`, or add to `CONFIGURE_ARGS`, or whatever is needed so that the software builds correctly. +For each group, a `${WRKSRC_group}` helper variable is created, containing the directory into which the file has been extracted. +The `${WRKSRC_group}` variables can be used to move directories around during `post-extract`, or add to `CONFIGURE_ARGS`, or whatever is needed so that the software builds correctly. [CAUTION] ==== - -The `:__group__` part _must_ be used for _only one_ distribution file. It is used as a unique key and using it more than once will overwrite the previous values. +The `:__group__` part _must_ be used for _only one_ distribution file. +It is used as a unique key and using it more than once will overwrite the previous values. ==== [NOTE] @@ -1532,7 +1639,8 @@ The `:__group__` part _must_ be used for _only one_ distribution file. It is use As this is only syntactic sugar above `DISTFILES` and `MASTER_SITES`, the group names must adhere to the restrictions on group names outlined in <> ==== -When fetching multiple files from GitHub, sometimes the default distribution file is not fetched from GitHub. To disable fetching the default distribution, set: +When fetching multiple files from GitHub, sometimes the default distribution file is not fetched from GitHub. +To disable fetching the default distribution, set: [.programlisting] .... @@ -1554,7 +1662,9 @@ DISTFILES= ${DISTNAME}${EXTRACT_SUFX} .Use of `USE_GITHUB` with Multiple Distribution Files [example] ==== -From time to time, there is a need to fetch more than one distribution file. For example, when the upstream git repository uses submodules. This can be done easily using groups in the `GH_*` variables: +From time to time, there is a need to fetch more than one distribution file. +For example, when the upstream git repository uses submodules. +This can be done easily using groups in the `GH_*` variables: [.programlisting] .... @@ -1570,11 +1680,21 @@ GH_SUBDIR= ext/icons:icons CONFIGURE_ARGS= --with-contrib=${WRKSRC_contrib} .... -This will fetch three distribution files from github. The default one comes from [.filename]#foo/foo# and is version `1.0.2`. The second one, with the `icons` group, comes from [.filename]#bar/foo-icons# and is in version `1.0`. The third one comes from [.filename]#bar/foo-contrib# and uses the Git commit `fa579bc`. The distribution files are named [.filename]#foo-foo-1.0.2_GH0.tar.gz#, [.filename]#bar-foo-icons-1.0_GH0.tar.gz#, and [.filename]#bar-foo-contrib-fa579bc_GH0.tar.gz#. +This will fetch three distribution files from github. +The default one comes from [.filename]#foo/foo# and is version `1.0.2`. +The second one, with the `icons` group, comes from [.filename]#bar/foo-icons# and is in version `1.0`. +The third one comes from [.filename]#bar/foo-contrib# and uses the Git commit `fa579bc`. +The distribution files are named [.filename]#foo-foo-1.0.2_GH0.tar.gz#, [.filename]#bar-foo-icons-1.0_GH0.tar.gz#, and [.filename]#bar-foo-contrib-fa579bc_GH0.tar.gz#. -All the distribution files are extracted in `${WRKDIR}` in their respective subdirectories. The default file is still extracted in `${WRKSRC}`, in this case, [.filename]#${WRKDIR}/foo-1.0.2#. Each additional distribution file is extracted in `${WRKSRC_group}`. Here, for the `icons` group, it is called `${WRKSRC_icons}` and it contains [.filename]#${WRKDIR}/foo-icons-1.0#. The file with the `contrib` group is called `${WRKSRC_contrib}` and contains `${WRKDIR}/foo-contrib-fa579bc`. +All the distribution files are extracted in `${WRKDIR}` in their respective subdirectories. +The default file is still extracted in `${WRKSRC}`, in this case, [.filename]#${WRKDIR}/foo-1.0.2#. +Each additional distribution file is extracted in `${WRKSRC_group}`. +Here, for the `icons` group, it is called `${WRKSRC_icons}` and it contains [.filename]#${WRKDIR}/foo-icons-1.0#. +The file with the `contrib` group is called `${WRKSRC_contrib}` and contains `${WRKDIR}/foo-contrib-fa579bc`. -The software's build system expects to find the icons in a [.filename]#ext/icons# subdirectory in its sources, so `GH_SUBDIR` is used. `GH_SUBDIR` makes sure that [.filename]#ext# exists, but that [.filename]#ext/icons# does not already exist. Then it does this: +The software's build system expects to find the icons in a [.filename]#ext/icons# subdirectory in its sources, so `GH_SUBDIR` is used. +`GH_SUBDIR` makes sure that [.filename]#ext# exists, but that [.filename]#ext/icons# does not already exist. +Then it does this: [.programlisting] .... @@ -1603,18 +1723,24 @@ GH_TUPLE= bar:foo-icons:1.0:icons/ext/icons \ CONFIGURE_ARGS= --with-contrib=${WRKSRC_contrib} .... -Grouping was used in the previous example with `bar:icons,contrib`. Some redundant information is present with `GH_TUPLE` because grouping is not possible. +Grouping was used in the previous example with `bar:icons,contrib`. +Some redundant information is present with `GH_TUPLE` because grouping is not possible. ==== [[makefile-master_sites-github-submodules]] .How to Use `USE_GITHUB` with Git Submodules? [example] ==== -Ports with GitHub as an upstream repository sometimes use submodules. See man:git-submodule[1] for more information. +Ports with GitHub as an upstream repository sometimes use submodules. +See man:git-submodule[1] for more information. -The problem with submodules is that each is a separate repository. As such, they each must be fetched separately. +The problem with submodules is that each is a separate repository. +As such, they each must be fetched separately. -Using package:finance/moneymanagerex[] as an example, its GitHub repository is https://github.com/moneymanagerex/moneymanagerex[]. It has a https://github.com/moneymanagerex/moneymanagerex/blob/master/.gitmodules[.gitmodules] file at the root. This file describes all the submodules used in this repository, and lists additional repositories needed. This file will tell what additional repositories are needed: +Using package:finance/moneymanagerex[] as an example, its GitHub repository is https://github.com/moneymanagerex/moneymanagerex[]. +It has a https://github.com/moneymanagerex/moneymanagerex/blob/master/.gitmodules[.gitmodules] file at the root. +This file describes all the submodules used in this repository, and lists additional repositories needed. +This file will tell what additional repositories are needed: [.programlisting] .... @@ -1633,7 +1759,8 @@ Using package:finance/moneymanagerex[] as an example, its GitHub repository is h [...] .... -The only information missing from that file is the commit hash or tag to use as a version. This information is found after cloning the repository: +The only information missing from that file is the commit hash or tag to use as a version. +This information is found after cloning the repository: [source,shell] .... @@ -1665,11 +1792,14 @@ Submodule path 'lib/wxsqlite3': checked out 'fb66eb230d8aed21dec273b38c7c054dcb7 [...] .... -It can also be found on GitHub. Each subdirectory that is a submodule is shown as `_directory @ hash_`, for example, `mongoose @ 2140e59`. +It can also be found on GitHub. +Each subdirectory that is a submodule is shown as `_directory @ hash_`, for example, `mongoose @ 2140e59`. [NOTE] **** -While getting the information from GitHub seems more straightforward, the information found using `git submodule status` will provide more meaningful information. For example, here, ``lib/wxsqlite3``'s commit hash `fb66eb2` correspond to `v3.4.0`. Both can be used interchangeably, but when a tag is available, use it. +While getting the information from GitHub seems more straightforward, the information found using `git submodule status` will provide more meaningful information. +For example, here, ``lib/wxsqlite3``'s commit hash `fb66eb2` correspond to `v3.4.0`. +Both can be used interchangeably, but when a tag is available, use it. **** Now that all the required information has been gathered, the [.filename]#Makefile# can be written (only GitHub-related lines are shown): @@ -1768,28 +1898,36 @@ GL_COMMIT= 9c1669ce60c3f4f5eb43df874d7314483fb3f8a6 It will have `MASTER_SITES` set to `"https://gitlab.example.com"` and `WRKSRC` to `${WRKDIR}/bar-9c1669ce60c3f4f5eb43df874d7314483fb3f8a6-9c1669ce60c3f4f5eb43df874d7314483fb3f8a6`. [TIP] +====== `20170906` is the date of the commit referenced in `GL_COMMIT`, not the date the [.filename]#Makefile# is edited, or the date the commit to the FreeBSD ports tree is made. +====== [NOTE] +====== ``GL_SITE``'s protocol, port and webroot can all be modified in the same variable. +====== ==== [[makefile-master_sites-gitlab-multiple]] ==== Fetching Multiple Files from GitLab -The `USE_GITLAB` framework also supports fetching multiple distribution files from different places from GitLab and GitLab hosted sites. It works in a way very similar to <> and <>. +The `USE_GITLAB` framework also supports fetching multiple distribution files from different places from GitLab and GitLab hosted sites. +It works in a way very similar to <> and <>. -Multiple values are added to `GL_SITE`, `GL_ACCOUNT`, `GL_PROJECT` and `GL_COMMIT`. Each different value is assigned a group. <>. +Multiple values are added to `GL_SITE`, `GL_ACCOUNT`, `GL_PROJECT` and `GL_COMMIT`. +Each different value is assigned a group. <>. -`GL_TUPLE` can also be used when there are a lot of distribution files. It helps keep the site, account, project, commit, and group information at the same place. +`GL_TUPLE` can also be used when there are a lot of distribution files. +It helps keep the site, account, project, commit, and group information at the same place. -For each group, a `${WRKSRC_group}` helper variable is created, containing the directory into which the file has been extracted. The `${WRKSRC_group}` variables can be used to move directories around during `post-extract`, or add to `CONFIGURE_ARGS`, or whatever is needed so that the software builds correctly. +For each group, a `${WRKSRC_group}` helper variable is created, containing the directory into which the file has been extracted. +The `${WRKSRC_group}` variables can be used to move directories around during `post-extract`, or add to `CONFIGURE_ARGS`, or whatever is needed so that the software builds correctly. [CAUTION] ==== - -The `:__group__` part _must_ be used for _only one_ distribution file. It is used as a unique key and using it more than once will overwrite the previous values. +The `:__group__` part _must_ be used for _only one_ distribution file. +It is used as a unique key and using it more than once will overwrite the previous values. ==== [NOTE] @@ -1797,7 +1935,8 @@ The `:__group__` part _must_ be used for _only one_ distribution file. It is use As this is only syntactic sugar above `DISTFILES` and `MASTER_SITES`, the group names must adhere to the restrictions on group names outlined in <> ==== -When fetching multiple files using GitLab, sometimes the default distribution file is not fetched from a GitLab site. To disable fetching the default distribution, set: +When fetching multiple files using GitLab, sometimes the default distribution file is not fetched from a GitLab site. +To disable fetching the default distribution, set: [.programlisting] .... @@ -1806,7 +1945,8 @@ USE_GITLAB= nodefault [IMPORTANT] ==== -When using `USE_GITLAB=nodefault`, the [.filename]#Makefile# must set `DISTFILES` in its <>. The definition should be: +When using `USE_GITLAB=nodefault`, the [.filename]#Makefile# must set `DISTFILES` in its <>. +The definition should be: [.programlisting] *** 6678 LINES SKIPPED *** From owner-dev-commits-doc-all@freebsd.org Sun Jun 13 12:49:41 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0892165C95E for ; Sun, 13 Jun 2021 12:49:41 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G2vYJ6Z9xz3LyW; Sun, 13 Jun 2021 12:49:40 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id C94872160E; Sun, 13 Jun 2021 12:49:40 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 15DCneeh029016; Sun, 13 Jun 2021 12:49:40 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 15DCnerM029015; Sun, 13 Jun 2021 12:49:40 GMT (envelope-from git) Date: Sun, 13 Jun 2021 12:49:40 GMT Message-Id: <202106131249.15DCnerM029015@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Ceri Davies Subject: git: 1c8e08bc68 - main - Improve English terms. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: ceri X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 1c8e08bc687f675074651b8caf0d5df743b0ef48 Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2021 12:49:41 -0000 The branch main has been updated by ceri: URL: https://cgit.FreeBSD.org/doc/commit/?id=1c8e08bc687f675074651b8caf0d5df743b0ef48 commit 1c8e08bc687f675074651b8caf0d5df743b0ef48 Author: Ceri Davies AuthorDate: 2021-06-13 12:43:32 +0000 Commit: Ceri Davies CommitDate: 2021-06-13 12:43:32 +0000 Improve English terms. --- .../en/articles/committers-guide/_index.adoc | 2 +- .../en/articles/filtering-bridges/_index.adoc | 2 +- .../en/articles/linux-emulation/_index.adoc | 2 +- .../content/en/books/handbook/disks/_index.adoc | 18 ++++----- .../en/books/handbook/firewalls/_index.adoc | 43 +++++++++++----------- 5 files changed, 33 insertions(+), 34 deletions(-) diff --git a/documentation/content/en/articles/committers-guide/_index.adoc b/documentation/content/en/articles/committers-guide/_index.adoc index 63f2db466e..8cc8a8beeb 100644 --- a/documentation/content/en/articles/committers-guide/_index.adoc +++ b/documentation/content/en/articles/committers-guide/_index.adoc @@ -2456,7 +2456,7 @@ Subscribers to {dev-commits-doc-all}, {dev-commits-ports-all} or {dev-commits-sr + [NOTE] ====== -If your e-mail system uses SPF with strict rules, you should whitelist `mx2.FreeBSD.org` from SPF checks. +If your e-mail system uses SPF with strict rules, you should exclude `mx2.FreeBSD.org` from SPF checks. ====== + Due to the severe load dealing with SPAM places on the central mail servers that do the mailing list processing, the front-end server does do some basic checks and will drop some messages based on these checks. At the moment proper DNS information for the connecting host is the only check in place but that may change. Some people blame these checks for bouncing valid email. To have these checks turned off for your email, create a file named [.filename]#~/.spam_lover# on `freefall.FreeBSD.org`. diff --git a/documentation/content/en/articles/filtering-bridges/_index.adoc b/documentation/content/en/articles/filtering-bridges/_index.adoc index c729c8f934..4f54b24ace 100644 --- a/documentation/content/en/articles/filtering-bridges/_index.adoc +++ b/documentation/content/en/articles/filtering-bridges/_index.adoc @@ -216,7 +216,7 @@ add pass ip from any to any in via xl0 add pass tcp from any to any 22 in via fxp0 setup keep-state # Allow SMTP only towards the mail server add pass tcp from any to relay 25 in via fxp0 setup keep-state -# Allow zone transfers only by the slave name server [dns2.nic.it] +# Allow zone transfers only by the secondary name server [dns2.nic.it] add pass tcp from 193.205.245.8 to ns 53 in via fxp0 setup keep-state # Pass ident probes. It is better than waiting for them to timeout add pass tcp from any to any 113 in via fxp0 setup keep-state diff --git a/documentation/content/en/articles/linux-emulation/_index.adoc b/documentation/content/en/articles/linux-emulation/_index.adoc index 6512d55b80..e9d86ae201 100644 --- a/documentation/content/en/articles/linux-emulation/_index.adoc +++ b/documentation/content/en/articles/linux-emulation/_index.adoc @@ -1399,7 +1399,7 @@ DragonflyBSD has expressed some interest in porting the 2.6 improvements. Generally, as Linux(R) develops we would like to keep up with their development, implementing newly added syscalls. Splice comes to mind first. -Some already implemented syscalls are also heavily crippled, for example `mremap` and others. +Some already implemented syscalls are also suboptimal, for example `mremap` and others. Some performance improvements can also be made, finer grained locking and others. [[team]] diff --git a/documentation/content/en/books/handbook/disks/_index.adoc b/documentation/content/en/books/handbook/disks/_index.adoc index 238c075973..5390274807 100644 --- a/documentation/content/en/books/handbook/disks/_index.adoc +++ b/documentation/content/en/books/handbook/disks/_index.adoc @@ -2228,7 +2228,7 @@ The HAST project was sponsored by The FreeBSD Foundation with support from http: === HAST Operation -HAST provides synchronous block-level replication between two physical machines: the _primary_, also known as the _master_ node, and the _secondary_, or _slave_ node. +HAST provides synchronous block-level replication between two physical machines: the _primary_ nodeand the _secondary_ node. These two machines together are referred to as a cluster. Since HAST works in a primary-secondary configuration, it allows only one of the cluster nodes to be active at any given time. @@ -2271,7 +2271,7 @@ Users who prefer to statically build `GEOM_GATE` support into the kernel should options GEOM_GATE .... -The following example describes how to configure two nodes in master-slave/primary-secondary operation using HAST to replicate the data between the two. +The following example describes how to configure two nodes in primary-secondary operation using HAST to replicate the data between the two. The nodes will be called `hasta`, with an IP address of `172.16.0.1`, and `hastb`, with an IP address of `172.16.0.2`. Both nodes will have a dedicated hard drive [.filename]#/dev/ad6# of the same size for HAST operation. The HAST pool, sometimes referred to as a resource or the GEOM provider in [.filename]#/dev/hast/#, will be called `test`. @@ -2372,7 +2372,7 @@ To accomplish this task, the Common Address Redundancy Protocol (CARP) is used t CARP allows multiple hosts on the same network segment to share an IP address. Set up CARP on both nodes of the cluster according to the documentation available in crossref:advanced-networking[carp,“Common Address Redundancy Protocol (CARP)”]. In this example, each node will have its own management IP address and a shared IP address of _172.16.0.254_. -The primary HAST node of the cluster must be the master CARP node. +The primary HAST node of the cluster must be the primary CARP node. The HAST pool created in the previous section is now ready to be exported to the other hosts on the network. This can be accomplished by exporting it through NFS or Samba, using the shared IP address _172.16.0.254_. @@ -2390,14 +2390,14 @@ notify 30 { match "system" "IFNET"; match "subsystem" "carp0"; match "type" "LINK_UP"; - action "/usr/local/sbin/carp-hast-switch master"; + action "/usr/local/sbin/carp-hast-switch primary"; }; notify 30 { match "system" "IFNET"; match "subsystem" "carp0"; match "type" "LINK_DOWN"; - action "/usr/local/sbin/carp-hast-switch slave"; + action "/usr/local/sbin/carp-hast-switch secondary"; }; .... @@ -2429,7 +2429,7 @@ Here is an example of an automated failover script: # The names of the HAST resources, as listed in /etc/hast.conf resources="test" -# delay in mounting HAST resource after becoming master +# delay in mounting HAST resource after becoming primary # make your best guess delay=3 @@ -2440,7 +2440,7 @@ name="carp-hast" # end of user configurable stuff case "$1" in - master) + primary) logger -p $log -t $name "Switching to primary provider for ${resources}." sleep ${delay} @@ -2482,7 +2482,7 @@ case "$1" in ;; - slave) + secondary) logger -p $log -t $name "Switching to secondary provider for ${resources}." # Switch roles for the HAST resources @@ -2504,7 +2504,7 @@ case "$1" in esac .... -In a nutshell, the script takes these actions when a node becomes master: +In a nutshell, the script takes these actions when a node becomes primary: * Promotes the HAST pool to primary on the other node. * Checks the file system under the HAST pool. diff --git a/documentation/content/en/books/handbook/firewalls/_index.adoc b/documentation/content/en/books/handbook/firewalls/_index.adoc index 47429914bc..a70334c309 100644 --- a/documentation/content/en/books/handbook/firewalls/_index.adoc +++ b/documentation/content/en/books/handbook/firewalls/_index.adoc @@ -795,13 +795,13 @@ This example removes all entries older than 24 hours: Not to be confused with the spamd daemon which comes bundled with spamassassin, package:mail/spamd[] can be configured with PF to provide an outer defense against SPAM. This spamd hooks into the PF configuration using a set of redirections. -Spammers tend to send a large number of messages, and SPAM is mainly sent from a few spammer friendly networks and a large number of hijacked machines, both of which are reported to _blacklists_ fairly quickly. +Spammers tend to send a large number of messages, and SPAM is mainly sent from a few spammer friendly networks and a large number of hijacked machines, both of which are reported to _blocklists_ fairly quickly. -When an SMTP connection from an address in a blacklist is received, spamd presents its banner and immediately switches to a mode where it answers SMTP traffic one byte at a time. +When an SMTP connection from an address in a blocklist is received, spamd presents its banner and immediately switches to a mode where it answers SMTP traffic one byte at a time. This technique, which is intended to waste as much time as possible on the spammer's end, is called _tarpitting_. The specific implementation which uses one byte SMTP replies is often referred to as _stuttering_. -This example demonstrates the basic procedure for setting up spamd with automatically updated blacklists. +This example demonstrates the basic procedure for setting up spamd with automatically updated blocklists. Refer to the man pages which are installed with package:mail/spamd[] for more information. [.procedure] @@ -845,13 +845,12 @@ One of the first lines in the configuration file that does not begin with a `#` [.programlisting] .... all:\ - :traplist:whitelist: + :traplist:allowlist: .... + -This entry adds the desired blacklists, separated by colons (`:`). -To use a whitelist to subtract addresses from a blacklist, add the name of the whitelist _immediately_ after the name of that blacklist. For example: `:blacklist:whitelist:`. +This entry adds the desired blocklists, separated by colons (`:`). To use an allowlist to subtract addresses from a blocklist, add the name of the allowlist _immediately_ after the name of that blocklist. For example: `:blocklist:allowlist:`. + -This is followed by the specified blacklist's definition: +This is followed by the specified blocklist's definition: + [.programlisting] .... @@ -862,26 +861,26 @@ traplist:\ :file=www.openbsd.org/spamd/traplist.gz .... + -where the first line is the name of the blacklist and the second line specifies the list type. -The `msg` field contains the message to display to blacklisted senders during the SMTP dialogue. +where the first line is the name of the blocklist and the second line specifies the list type. +The `msg` field contains the message to display to blocklisted senders during the SMTP dialogue. The `method` field specifies how spamd-setup fetches the list data; supported methods are `http`, `ftp`, from a `file` in a mounted file system, and via `exec` of an external program. Finally, the `file` field specifies the name of the file spamd expects to receive. + -The definition of the specified whitelist is similar, but omits the `msg` field since a message is not needed: +The definition of the specified allowlist is similar, but omits the `msg` field since a message is not needed: + [.programlisting] .... -whitelist:\ +allowlist:\ :white:\ :method=file:\ - :file=/var/mail/whitelist.txt + :file=/var/mail/allowlist.txt .... + [TIP] ==== *Choose Data Sources with Care:* + -Using all the blacklists in the sample [.filename]#spamd.conf# will blacklist large blocks of the Internet. +Using all the blocklists in the sample [.filename]#spamd.conf# will block large blocks of the Internet. Administrators need to edit the file to create an optimal configuration which uses applicable data sources and, when necessary, uses custom lists. ==== + @@ -929,7 +928,7 @@ Refer to the spamd man page for descriptions of additional related parameters. .... Behind the scenes, the spamdb database tool and the spamlogd whitelist updater perform essential functions for the greylisting feature. -spamdb is the administrator's main interface to managing the black, grey, and white lists via the contents of the [.filename]#/var/db/spamdb# database. +spamdb is the administrator's main interface to managing the block, grey, and allow lists via the contents of the [.filename]#/var/db/spamdb# database. [[pftut-hygiene]] ==== Network Hygiene @@ -2493,7 +2492,7 @@ All rules that follow the `[local]` section are treated as local rules (which is When a `[remote]` section is encountered, all rules that follow it are handled as remote machine rules. Seven fields define a rule separated by either tabs or spaces. -The first four fields identify the traffic that should be blacklisted. +The first four fields identify the traffic that should be blocklisted. The three fields that follow define backlistd's behavior. Wildcards are denoted as asterisks (`*`), matching anything in this field. The first field defines the location. @@ -2529,7 +2528,7 @@ block in pass out .... -For separate blacklists, an anchor name can be used in this field. +For separate blocklists, an anchor name can be used in this field. In other cases, the wildcard will suffice. When a name starts with a hyphen (`-`) it means that an anchor with the default rule name prepended should be used. A modified example from the above using the hyphen would look like this: @@ -2539,7 +2538,7 @@ A modified example from the above using the hyphen would look like this: ssh stream * * -ssh 3 24h .... -With such a rule, any new blacklist rules are added to an anchor called `blacklistd-ssh`. +With such a rule, any new blocklist rules are added to an anchor called `blacklistd-ssh`. To block whole subnets for a single rule violation, a `/` in the rule name can be used. This causes the remaining portion of the name to be interpreted as the mask to be applied to the address specified in the rule. @@ -2558,11 +2557,11 @@ IPv4 and IPv6 treat /24 differently, that is the reason why `*` cannot be used i This rule defines that if any one host in that network is misbehaving, everything else on that network will be blocked, too. -The sixth field, called `nfail`, sets the number of login failures required to blacklist the remote IP in question. +The sixth field, called `nfail`, sets the number of login failures required to blocklist the remote IP in question. When a wildcard is used at this position, it means that blocks will never happen. In the example rule above, a limit of three is defined meaning that after three attempts to log into SSH on one connection, the IP is blocked. -The last field in a blacklistd rule definition specifies how long a host is blacklisted. +The last field in a blacklistd rule definition specifies how long a host is blocklisted. The default unit is seconds, but suffixes like `m`, `h`, and `d` can also be specified for minutes, hours, and days, respectively. The example rule in its entirety means that after three times authenticating to SSH will result in a new PF block rule for that host. @@ -2588,7 +2587,7 @@ The fields for type, protocol and owner are identically interpreted as in the lo The name fields is different though: the equal sign (`=`) in a remote rule tells blacklistd to use the value from the matching local rule. It means that the firewall rule entry is taken and the `/25` prefix (a netmask of `255.255.255.128`) is added. -When a connection from that address range is blacklisted, the entire subnet is affected. +When a connection from that address range is blocklisted, the entire subnet is affected. A PF anchor name can also be used here, in which case blacklistd will add rules for this address block to the anchor of that name. The default table is used when a wildcard is specified. @@ -2623,7 +2622,7 @@ That is all that is needed to make these programs talk to blacklistd. === Blacklistd Management Blacklistd provides the user with a management utility called man:blacklistctl[8]. -It displays blocked addresses and networks that are blacklisted by the rules defined in man:blacklistd.conf[5]. +It displays blocked addresses and networks that are blocklisted by the rules defined in man:blacklistd.conf[5]. To see the list of currently blocked hosts, use `dump` combined with `-b` like this. [source,shell] @@ -2638,7 +2637,7 @@ There are more attempts listed than are allowed because SSH allows a client to t A connection that is currently going on is not stopped by blacklistd. The last connection attempt is listed in the `last access` column of the output. -To see the remaining time that this host will be on the blacklist, add `-r` to the previous command. +To see the remaining time that this host will be on the blocklist, add `-r` to the previous command. [source,shell] .... From owner-dev-commits-doc-all@freebsd.org Sun Jun 13 12:49:42 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2A7CD65C95F for ; Sun, 13 Jun 2021 12:49:42 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G2vYL0PLGz3Lfm; Sun, 13 Jun 2021 12:49:42 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id EA509210FE; Sun, 13 Jun 2021 12:49:41 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 15DCnfbJ029040; Sun, 13 Jun 2021 12:49:41 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 15DCnf0b029039; Sun, 13 Jun 2021 12:49:41 GMT (envelope-from git) Date: Sun, 13 Jun 2021 12:49:41 GMT Message-Id: <202106131249.15DCnf0b029039@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Ceri Davies Subject: git: c4db9c153e - main - tools/books*py: improve argument handling of DOC_LANG, and others MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: ceri X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: c4db9c153e4664a3eec66a68de305a57845c4a5a Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2021 12:49:42 -0000 The branch main has been updated by ceri: URL: https://cgit.FreeBSD.org/doc/commit/?id=c4db9c153e4664a3eec66a68de305a57845c4a5a commit c4db9c153e4664a3eec66a68de305a57845c4a5a Author: Ceri Davies AuthorDate: 2021-06-13 12:45:07 +0000 Commit: Ceri Davies CommitDate: 2021-06-13 12:45:07 +0000 tools/books*py: improve argument handling of DOC_LANG, and others 1) fix shebang lines; 2) add a -o option that makes no changes but prints the files that would be updated/created; 3) allow the -l argument (and therefore DOC_LANG) to be whitespace separated, comma separated, or a mixture of both Item 2 allows us to start tracking dependencies in Makefiles if we wish and therefore reintroduce incremental builds, reducing the amount of .PHONY targets that are not truly phony. Item 3 restores compability with the documented DOC_LANG variable, which was previously whitespace separated. Reviewed by: dbaio, blackend Differential Revision: https://reviews.freebsd.org/D30732 --- documentation/tools/books-toc-creator.py | 30 +++++++++++----- documentation/tools/books-toc-examples-creator.py | 31 +++++++++++----- documentation/tools/books-toc-figures-creator.py | 33 +++++++++++------ documentation/tools/books-toc-parts-creator.py | 43 ++++++++++++++++------- documentation/tools/books-toc-tables-creator.py | 30 +++++++++++----- 5 files changed, 117 insertions(+), 50 deletions(-) diff --git a/documentation/tools/books-toc-creator.py b/documentation/tools/books-toc-creator.py index 340deec339..bd85b7e923 100644 --- a/documentation/tools/books-toc-creator.py +++ b/documentation/tools/books-toc-creator.py @@ -1,11 +1,11 @@ +#!/usr/bin/env python3 # -*- coding: utf-8 -*- """ BSD 2-Clause License Copyright (c) 2020-2021, The FreeBSD Project Copyright (c) 2020-2021, Sergio Carlavilla -This script will generate the Table of Contents of the Handbook +This script will generate the Table of Contents of the books. """ -#!/usr/bin/env python3 import sys, getopt import re @@ -124,19 +124,28 @@ def checkIsAppendix(chapterContent): def main(argv): + justPrintOutput = False + langargs = [] try: - opts, args = getopt.getopt(argv,"hl:",["language="]) + opts, args = getopt.gnu_getopt(argv,"hl:o",["language="]) except getopt.GetoptError: - print('books-toc-creator.py -l ') + print('books-toc-creator.py [-o] -l ') sys.exit(2) for opt, arg in opts: if opt == '-h': - print('books-toc-creator.py -l ') + print('books-toc-creator.py [-o] -l ') sys.exit() + elif opt == '-o': + justPrintOutput = True elif opt in ("-l", "--language"): - languages = arg.split(',') + langargs = arg.replace(" ",",").split(',') + + # treat additional arguments as languages, but check if they + # contain ',' + for l in args: + langargs.extend(l.replace(" ",",").split(',')) - for language in languages: + for language in langargs: with open('./content/{}/books/books.adoc'.format(language), 'r', encoding = 'utf-8') as booksFile: books = [line.strip() for line in booksFile] @@ -199,8 +208,11 @@ def main(argv): toc += "--\n" - with open('./content/{0}/books/{1}/toc.adoc'.format(language, book), 'w', encoding = 'utf-8') as tocFile: - tocFile.write(toc) + if justPrintOutput == False: + with open('./content/{0}/books/{1}/toc.adoc'.format(language, book), 'w', encoding = 'utf-8') as tocFile: + tocFile.write(toc) + else: + print('./content/{0}/books/{1}/toc.adoc'.format(language, book)) if __name__ == "__main__": main(sys.argv[1:]) diff --git a/documentation/tools/books-toc-examples-creator.py b/documentation/tools/books-toc-examples-creator.py index f72ffa945e..423239c30d 100644 --- a/documentation/tools/books-toc-examples-creator.py +++ b/documentation/tools/books-toc-examples-creator.py @@ -1,3 +1,4 @@ +#!/usr/bin/env python3 # -*- coding: utf-8 -*- """ BSD 2-Clause License @@ -5,9 +6,9 @@ BSD 2-Clause License Copyright (c) 2020-2021, The FreeBSD Project Copyright (c) 2020-2021, Sergio Carlavilla -This script will generate the Table of Contents of the Handbook +This script will generate the Table of Contents of any [example]s in the +books. """ -#!/usr/bin/env python3 import sys, getopt import re @@ -54,19 +55,28 @@ def setTOCTitle(language): def main(argv): + justPrintOutput = False + langargs = [] try: - opts, args = getopt.getopt(argv,"hl:",["language="]) + opts, args = getopt.gnu_getopt(argv,"hl:o",["language="]) except getopt.GetoptError: - print('books-toc-examples-creator.py -l ') + print('books-toc-examples-creator.py [-o] -l ') sys.exit(2) for opt, arg in opts: if opt == '-h': - print('books-toc-examples-creator.py -l ') + print('books-toc-examples-creator.py [-o] -l ') sys.exit() + if opt == '-o': + justPrintOutput = True elif opt in ("-l", "--language"): - languages = arg.split(',') + langargs = arg.replace(" ",",").split(',') + + # treat additional arguments as languages, but check if they + # contain ',' + for l in args: + langargs.extend(l.replace(" ",",").split(',')) - for language in languages: + for language in langargs: with open('./content/{}/books/books.adoc'.format(language), 'r', encoding = 'utf-8') as booksFile: books = [line.strip() for line in booksFile] @@ -115,8 +125,11 @@ def main(argv): toc += "--\n" - with open('./content/{0}/books/{1}/toc-examples.adoc'.format(language, book), 'w', encoding = 'utf-8') as tocFile: - tocFile.write(toc) + if justPrintOutput == False: + with open('./content/{0}/books/{1}/toc-examples.adoc'.format(language, book), 'w', encoding = 'utf-8') as tocFile: + tocFile.write(toc) + else: + print('./content/{0}/books/{1}/toc-examples.adoc'.format(language, book)) if __name__ == "__main__": main(sys.argv[1:]) diff --git a/documentation/tools/books-toc-figures-creator.py b/documentation/tools/books-toc-figures-creator.py index 46bea6226b..fbe1d62c65 100644 --- a/documentation/tools/books-toc-figures-creator.py +++ b/documentation/tools/books-toc-figures-creator.py @@ -1,3 +1,4 @@ +#!/usr/bin/env python3 # -*- coding: utf-8 -*- """ BSD 2-Clause License @@ -5,9 +6,9 @@ BSD 2-Clause License Copyright (c) 2020-2021, The FreeBSD Project Copyright (c) 2020-2021, Sergio Carlavilla -This script will generate the Table of Contents of the Handbook +This script will generate the Table of Contents for any figures/images +in the books. """ -#!/usr/bin/env python3 import sys, getopt import re @@ -53,20 +54,29 @@ def setTOCTitle(language): return languages.get(language) def main(argv): - + + justPrintOutput = False + langargs = [] try: - opts, args = getopt.getopt(argv,"hl:",["language="]) + opts, args = getopt.gnu_getopt(argv,"hl:o",["language="]) except getopt.GetoptError: - print('books-toc-figures-creator.py -l ') + print('books-toc-figures-creator.py [-o] -l ') sys.exit(2) for opt, arg in opts: if opt == '-h': - print('books-toc-figures-creator.py -l ') + print('books-toc-figures-creator.py [-o] -l ') sys.exit() + if opt == '-o': + justPrintOutput = True elif opt in ("-l", "--language"): - languages = arg.split(',') + langargs = arg.replace(" ",",").split(',') + + # treat additional arguments as languages, but check if they + # contain ',' + for l in args: + langargs.extend(l.replace(" ",",").split(',')) - for language in languages: + for language in langargs: with open('./content/{}/books/books.adoc'.format(language), 'r', encoding = 'utf-8') as booksFile: books = [line.strip() for line in booksFile] @@ -114,8 +124,11 @@ def main(argv): toc += "--\n" - with open('./content/{0}/books/{1}/toc-figures.adoc'.format(language, book), 'w', encoding = 'utf-8') as tocFile: - tocFile.write(toc) + if justPrintOutput == False: + with open('./content/{0}/books/{1}/toc-figures.adoc'.format(language, book), 'w', encoding = 'utf-8') as tocFile: + tocFile.write(toc) + else: + print('./content/{0}/books/{1}/toc-figures.adoc'.format(language, book)) if __name__ == "__main__": main(sys.argv[1:]) diff --git a/documentation/tools/books-toc-parts-creator.py b/documentation/tools/books-toc-parts-creator.py index b05aeb9dc5..aeb035b8cb 100644 --- a/documentation/tools/books-toc-parts-creator.py +++ b/documentation/tools/books-toc-parts-creator.py @@ -1,11 +1,12 @@ +#!/usr/bin/env python3 # -*- coding: utf-8 -*- """ BSD 2-Clause License Copyright (c) 2020-2021, The FreeBSD Project Copyright (c) 2020-2021, Sergio Carlavilla -This script will generate the Table of Contents of the Handbook +This script will generate the Table of Contents for any [preface], +[appendix] or other "parts" as defined by asciidoc. """ -#!/usr/bin/env python3 import sys, getopt import re @@ -14,12 +15,18 @@ import os.path languages = [] def cleanTocFile(language, tocCounter, book): - path = './content/{0}/books/{1}/toc-{2}.adoc'.format(language, book, tocCounter) + path = './content/{0}/books/{1}/toc-{2}.adoc'.format(language, book, tocCounter) + if justPrintOutput == True: + print(path) + else: if os.path.exists(path): - tocFile = open(path, 'r+', encoding = 'utf-8') - tocFile.truncate(0) + tocFile = open(path, 'r+', encoding = 'utf-8') + tocFile.truncate(0) + +def prependCommentAndTitle(language, tocCounter, tocContent, book): + if justPrintOutput == True: + return True -def appendCommendAndTitle(language, tocCounter, tocContent, book): toc = "// Code generated by the FreeBSD Documentation toolchain. DO NOT EDIT.\n" toc += "// Please don't change this file manually but run `make` to update it.\n" toc += "// For more information, please read the FreeBSD Documentation Project Primer\n\n" @@ -112,20 +119,30 @@ def setTOCTitle(language): return languages.get(language) def main(argv): + global justPrintOutput + justPrintOutput = False + langargs=[] try: - opts, args = getopt.getopt(argv,"hl:",["language="]) + opts, args = getopt.gnu_getopt(argv,"hl:o",["language="]) except getopt.GetoptError: - print('books-toc-creator.py -l ') + print('books-toc-creator.py [-o] -l ') sys.exit(2) for opt, arg in opts: if opt == '-h': - print('books-toc-creator.py -l ') + print('books-toc-creator.py [-o] -l ') sys.exit() + elif opt == '-o': + justPrintOutput = True elif opt in ("-l", "--language"): - languages = arg.split(',') + langargs = arg.replace(" ",",").split(',') + + # treat additional arguments as languages, but check if they + # contain ',' + for l in args: + langargs.extend(l.replace(" ",",").split(',')) - for language in languages: + for language in langargs: with open('./content/{}/books/books.adoc'.format(language), 'r', encoding = 'utf-8') as booksFile: books = [line.strip() for line in booksFile] @@ -149,7 +166,7 @@ def main(argv): if partCounter > 0: cleanTocFile(language, partCounter, book) - appendCommendAndTitle(language, partCounter, toc, book) + prependCommentAndTitle(language, partCounter, toc, book) toc = "" # Clean toc content partCounter += 1 @@ -181,7 +198,7 @@ def main(argv): if partCounter > 0: cleanTocFile(language, partCounter, book) - appendCommendAndTitle(language, partCounter, toc, book) # For the last part + prependCommentAndTitle(language, partCounter, toc, book) # For the last part if __name__ == "__main__": main(sys.argv[1:]) diff --git a/documentation/tools/books-toc-tables-creator.py b/documentation/tools/books-toc-tables-creator.py index 592330b7a4..67f1733d45 100644 --- a/documentation/tools/books-toc-tables-creator.py +++ b/documentation/tools/books-toc-tables-creator.py @@ -1,3 +1,4 @@ +#!/usr/bin/env python3 # -*- coding: utf-8 -*- """ BSD 2-Clause License @@ -5,9 +6,8 @@ BSD 2-Clause License Copyright (c) 2020-2021, The FreeBSD Project Copyright (c) 2020-2021, Sergio Carlavilla -This script will generate the Table of Contents of the Handbook +This script will generate the Table of Contents for tables in the books. """ -#!/usr/bin/env python3 import sys, getopt import re @@ -54,19 +54,28 @@ def setTOCTitle(language): def main(argv): + justPrintOutput = False + langargs= [] try: - opts, args = getopt.getopt(argv,"hl:",["language="]) + opts, args = getopt.gnu_getopt(argv,"hl:o",["language="]) except getopt.GetoptError: - print('books-toc-tables-creator.py -l ') + print('books-toc-tables-creator.py [-o] -l ') sys.exit(2) for opt, arg in opts: if opt == '-h': - print('books-toc-tables-creator.py -l ') + print('books-toc-tables-creator.py [-o] -l ') sys.exit() + if opt == '-o': + justPrintOutput = True elif opt in ("-l", "--language"): - languages = arg.split(',') + langargs = arg.replace(" ",",").split(',') + + # treat additional arguments as languages, but check if they + # contain ',' + for l in args: + langargs.extend(l.replace(" ",",").split(',')) - for language in languages: + for language in langargs: with open('./content/{}/books/books.adoc'.format(language), 'r', encoding = 'utf-8') as booksFile: books = [line.strip() for line in booksFile] @@ -114,8 +123,11 @@ def main(argv): toc += "--\n" - with open('./content/{0}/books/{1}/toc-tables.adoc'.format(language, book), 'w', encoding = 'utf-8') as tocFile: - tocFile.write(toc) + if justPrintOutput == False: + with open('./content/{0}/books/{1}/toc-tables.adoc'.format(language, book), 'w', encoding = 'utf-8') as tocFile: + tocFile.write(toc) + else: + print('./content/{0}/books/{1}/toc-tables.adoc'.format(language, book)) if __name__ == "__main__": main(sys.argv[1:]) From owner-dev-commits-doc-all@freebsd.org Sun Jun 13 18:02:27 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DE132640540 for ; Sun, 13 Jun 2021 18:02:27 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G32VC5mcgz4Vfn; Sun, 13 Jun 2021 18:02:27 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id AE70625740; Sun, 13 Jun 2021 18:02:27 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 15DI2RgC054263; Sun, 13 Jun 2021 18:02:27 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 15DI2R2M054262; Sun, 13 Jun 2021 18:02:27 GMT (envelope-from git) Date: Sun, 13 Jun 2021 18:02:27 GMT Message-Id: <202106131802.15DI2R2M054262@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: "Danilo G. Baio" Subject: git: 9c01631b9a - main - pt-br/books/handbook/virtualization: Fix vbox instructions MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: dbaio X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 9c01631b9a2db4cf825704bb4650fd8c0caa3535 Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2021 18:02:27 -0000 The branch main has been updated by dbaio: URL: https://cgit.FreeBSD.org/doc/commit/?id=9c01631b9a2db4cf825704bb4650fd8c0caa3535 commit 9c01631b9a2db4cf825704bb4650fd8c0caa3535 Author: Danilo G. Baio AuthorDate: 2021-06-13 18:00:52 +0000 Commit: Danilo G. Baio CommitDate: 2021-06-13 18:00:52 +0000 pt-br/books/handbook/virtualization: Fix vbox instructions Following English document. Reported by: Gabriel Dutra <0xdutra@gmail.com> --- documentation/content/pt-br/books/handbook/virtualization/_index.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/content/pt-br/books/handbook/virtualization/_index.adoc b/documentation/content/pt-br/books/handbook/virtualization/_index.adoc index 9226b1f85b..be52b00be7 100644 --- a/documentation/content/pt-br/books/handbook/virtualization/_index.adoc +++ b/documentation/content/pt-br/books/handbook/virtualization/_index.adoc @@ -505,7 +505,7 @@ Para que o VirtualBox(TM) esteja ciente dos dispositivos USB conectados à máqu # pw groupmod operator -m yourusername .... -Em seguida, adicione as seguintes linhas ao [.filename]#/etc/rc.conf#: +Em seguida, adicione as seguintes linhas em [.filename]#/etc/devfs.rules# ou crie o arquivo se ele ainda não existir: [.programlisting] .... From owner-dev-commits-doc-all@freebsd.org Sun Jun 13 20:24:24 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A24A06553EA for ; Sun, 13 Jun 2021 20:24:24 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G35f049W2z4hnK; Sun, 13 Jun 2021 20:24:24 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 776CD27722; Sun, 13 Jun 2021 20:24:24 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 15DKOOYt041087; Sun, 13 Jun 2021 20:24:24 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 15DKOOIl041086; Sun, 13 Jun 2021 20:24:24 GMT (envelope-from git) Date: Sun, 13 Jun 2021 20:24:24 GMT Message-Id: <202106132024.15DKOOIl041086@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Dimitry Andric Subject: git: f43eb1cc19 - main - Document __FreeBSD_version values 1400018 through 1400023. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: dim X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: f43eb1cc1991038c25bfbc33ab949bc4788b9f1e Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2021 20:24:24 -0000 The branch main has been updated by dim (src committer): URL: https://cgit.FreeBSD.org/doc/commit/?id=f43eb1cc1991038c25bfbc33ab949bc4788b9f1e commit f43eb1cc1991038c25bfbc33ab949bc4788b9f1e Author: Dimitry Andric AuthorDate: 2021-06-13 20:24:19 +0000 Commit: Dimitry Andric CommitDate: 2021-06-13 20:24:19 +0000 Document __FreeBSD_version values 1400018 through 1400023. --- .../en/books/porters-handbook/versions/_index.adoc | 30 ++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/documentation/content/en/books/porters-handbook/versions/_index.adoc b/documentation/content/en/books/porters-handbook/versions/_index.adoc index bc0cfd79fb..bcb7df581f 100644 --- a/documentation/content/en/books/porters-handbook/versions/_index.adoc +++ b/documentation/content/en/books/porters-handbook/versions/_index.adoc @@ -113,6 +113,36 @@ Here is a convenient list of `__FreeBSD_version` values as defined in https://cg |gitref:beb817edfe22cdea91e19a60c42caabd9404da48[repository="src",length=12] |May 25, 2021 |14.0-CURRENT after adding crypto_cursor_segment(). + +|1400018 +|gitref:a4b07a2701f568c2c0f0c0426091f1489244a92d[repository="src",length=12] +|May 30, 2021 +|14.0-CURRENT after allowing the VFS_QUOTACTL(9) implementation to indicate busy state changes. + +|1400019 +|gitref:37d64dcdfa519157aff9711f1f226ad7bd778f46[repository="src",length=12] +|Jun 7, 2021 +|14.0-CURRENT after including pr_err_once() in the LinuxKPI printk.h. + +|1400020 +|gitref:8a1a42b2a7a428fb97fda9f19fd0d67a4eec7535[repository="src",length=12] +|Jun 9, 2021 +|14.0-CURRENT after adding macros for might_lock_nested() and lockdep_(re/un/)pin_lock() to the LinuxKPI. + +|1400021 +|gitref:b47f461c8e67253fdb394968428b760e880baa08[repository="src",length=12] +|Jun 10, 2021 +|14.0-CURRENT after adding a list_for_each_entry_lockless() macro to the LinuxKPI. + +|1400022 +|gitref:40cc9a3a6b81a65a03712dfd93bbed48552a97ad[repository="src",length=12] +|Jun 11, 2021 +|14.0-CURRENT after commit gitref:e1a907a25cfa[repository="src",length=12 changed the internal KAPI between the krpc and nfsserver. + +|1400023 +|gitref:d409305fa3838fb39b38c26fc085fb729b8766d5[repository="src",length=12] +|Jun 13, 2021 +|14.0-CURRENT after upgrading llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvmorg-12.0.0-0-gd28af7c654d8, a.k.a. 12.0.0 release. |=== [[versions-13]] From owner-dev-commits-doc-all@freebsd.org Sun Jun 13 20:32:07 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3B61F6572B3 for ; Sun, 13 Jun 2021 20:32:07 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G35pv161lz4jJC; Sun, 13 Jun 2021 20:32:07 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 0DD2E279AD; Sun, 13 Jun 2021 20:32:07 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 15DKW6gF050950; Sun, 13 Jun 2021 20:32:06 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 15DKW6P1050949; Sun, 13 Jun 2021 20:32:06 GMT (envelope-from git) Date: Sun, 13 Jun 2021 20:32:06 GMT Message-Id: <202106132032.15DKW6P1050949@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Dimitry Andric Subject: git: 51e8ecfdc5 - main - Replace direct links to cgit.freebsd.org with gitref: tags. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: dim X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 51e8ecfdc5a696396cef4b5da4238c64f9243308 Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2021 20:32:07 -0000 The branch main has been updated by dim (src committer): URL: https://cgit.FreeBSD.org/doc/commit/?id=51e8ecfdc5a696396cef4b5da4238c64f9243308 commit 51e8ecfdc5a696396cef4b5da4238c64f9243308 Author: Dimitry Andric AuthorDate: 2021-06-13 20:32:01 +0000 Commit: Dimitry Andric CommitDate: 2021-06-13 20:32:01 +0000 Replace direct links to cgit.freebsd.org with gitref: tags. --- .../en/books/porters-handbook/versions/_index.adoc | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/documentation/content/en/books/porters-handbook/versions/_index.adoc b/documentation/content/en/books/porters-handbook/versions/_index.adoc index bcb7df581f..c767052c41 100644 --- a/documentation/content/en/books/porters-handbook/versions/_index.adoc +++ b/documentation/content/en/books/porters-handbook/versions/_index.adoc @@ -838,42 +838,42 @@ Here is a convenient list of `__FreeBSD_version` values as defined in https://cg |13.0-CURRENT after improving handling of alternate settings in the USB stack. |1300133 -|link:https://cgit.freebsd.org/src/commit/?id=2ed0c8d801f5f72dbde7a7d30135c1cc361a1e90[2ed0c8d801f5] +|gitref:2ed0c8d801f5f72dbde7a7d30135c1cc361a1e90[repository="src",length=12] |December 23, 2020 |13.0-CURRENT after changing the internal API between the NFS and kernel RPC modules. |1300134 -|link:https://cgit.freebsd.org/src/commit/?id=a84b0e94cdbf1a17a798ab7f77375aacb4d400ff[a84b0e94cdbf] +|gitref:a84b0e94cdbf1a17a798ab7f77375aacb4d400ff[repository="src",length=12] |January 7, 2021 |13.0-CURRENT after factoring out the hardware-independent part of USB HID support to a new module. |1300135 -|link:https://cgit.freebsd.org/src/commit/?id=35a39dc5b34962081eeda8dbcf0b99a31585499b[35a39dc5b349] +|gitref:35a39dc5b34962081eeda8dbcf0b99a31585499b[repository="src",length=12] |January 12, 2021 |13.0-CURRENT after adding `kernel_fpu_begin`/`kernel_fpu_end` to the LinuxKPI. |1300136 -|link:https://cgit.freebsd.org/src/commit/?id=72c551930be195b5ea982c1b16767f54388424f2[72c551930be1] +|gitref:72c551930be195b5ea982c1b16767f54388424f2[repository="src",length=12] |January 17, 2021 |13.0-CURRENT after reimplementing LinuxKPI's `irq_work` queue on top of fast taskqueue. |1300137 -|link:https://cgit.freebsd.org/src/commit/?id=010196adcfaf2bb610725394d40691874b4ff2af[010196adcfaf] +|gitref:010196adcfaf2bb610725394d40691874b4ff2af[repository="src",length=12] |January 30, 2021 |13.0-CURRENT after fixing a clang assertion when building the package:devel/onetbb[] port. |1300138 -|link:https://cgit.freebsd.org/src/commit/?id=dcee9964238b12a8e55917f292139f074b1a80b2[dcee9964238b] +|gitref:dcee9964238b12a8e55917f292139f074b1a80b2[repository="src",length=12] |February 1, 2021 |13.0-ALPHA3 after adding lockless symlink lookup to vfs cache. |1300139 -|link:https://cgit.freebsd.org/src/commit/?id=91a07ed50ffca4dfada3e7f1f050ea746c1bac66[91a07ed50ffc] +|gitref:91a07ed50ffca4dfada3e7f1f050ea746c1bac66[repository="src",length=12] |February 2, 2021 |13.0-ALPHA3 after adding various LinuxKPI bits conflicting with drm-kmod. |1300500 -|link:https://cgit.freebsd.org/src/commit/?id=3c6a89748a01869c18955d5e3bfcdf35f6705d26[3c6a89748a01] +|gitref:3c6a89748a01869c18955d5e3bfcdf35f6705d26[repository="src",length=12] |February 5, 2021 |13.0-STABLE after releng/13.0 was branched. |=== From owner-dev-commits-doc-all@freebsd.org Sun Jun 13 20:46:43 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D208A65A370 for ; Sun, 13 Jun 2021 20:46:43 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G367l59zzz4kcF; Sun, 13 Jun 2021 20:46:43 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 900A32787A; Sun, 13 Jun 2021 20:46:43 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 15DKkh4A068377; Sun, 13 Jun 2021 20:46:43 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 15DKkhxJ068376; Sun, 13 Jun 2021 20:46:43 GMT (envelope-from git) Date: Sun, 13 Jun 2021 20:46:43 GMT Message-Id: <202106132046.15DKkhxJ068376@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Dimitry Andric Subject: git: 4894bfda45 - main - Document __FreeBSD_version values 1300501 through 1300508. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: dim X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 4894bfda45777fa84b4785cbf4a4aefaa2f27632 Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2021 20:46:43 -0000 The branch main has been updated by dim (src committer): URL: https://cgit.FreeBSD.org/doc/commit/?id=4894bfda45777fa84b4785cbf4a4aefaa2f27632 commit 4894bfda45777fa84b4785cbf4a4aefaa2f27632 Author: Dimitry Andric AuthorDate: 2021-06-13 20:46:24 +0000 Commit: Dimitry Andric CommitDate: 2021-06-13 20:46:24 +0000 Document __FreeBSD_version values 1300501 through 1300508. --- .../en/books/porters-handbook/versions/_index.adoc | 45 ++++++++++++++++++++++ 1 file changed, 45 insertions(+) diff --git a/documentation/content/en/books/porters-handbook/versions/_index.adoc b/documentation/content/en/books/porters-handbook/versions/_index.adoc index c767052c41..96e7aa2c28 100644 --- a/documentation/content/en/books/porters-handbook/versions/_index.adoc +++ b/documentation/content/en/books/porters-handbook/versions/_index.adoc @@ -876,6 +876,51 @@ Here is a convenient list of `__FreeBSD_version` values as defined in https://cg |gitref:3c6a89748a01869c18955d5e3bfcdf35f6705d26[repository="src",length=12] |February 5, 2021 |13.0-STABLE after releng/13.0 was branched. + +|1300501 +|gitref:c3f97dd75a1c294c4f60f42b604ee8bcda17be09[repository="src",length=12] +|April 23, 2021 +|13.0-STABLE after fixing rtld's dl_iterate_phdr(). + +|1300501 +|gitref:c3f97dd75a1c294c4f60f42b604ee8bcda17be09[repository="src",length=12] +|April 23, 2021 +|13.0-STABLE after fixing rtld's dl_iterate_phdr(). + +|1300502 +|gitref:da6a8ccfa293c3c831fdde51169754fcb9587657[repository="src",length=12] +|April 23, 2021 +|13.0-STABLE after implementing atomic_dec_and_lock_irqsave() in the LinuxKPI. + +|1300503 +|gitref:d60c6dc8f69b1264c7af5e2479ea94f000fd2c6d[repository="src",length=12] +|April 23, 2021 +|13.0-STABLE after changing the internal KAPI between the krpc and NFS. + +|1300504 +|gitref:fb34817c686cc130449325499870e36979899801[repository="src",length=12] +|April 30, 2021 +|13.0-STABLE after updating the LinuxKPI to accommodate the drm-kmod 5.5 update. + +|1300505 +|gitref:8f81f190a640e211dd814bdde7811982b9491fb0[repository="src",length=12] +|May 10, 2021 +|13.0-STABLE after changing the internal KAPI between the nscl.ko and nfscommon.ko modules. + +|1300506 +|gitref:e31579b8558db508dfc3f8fc276611a7c3c93aa1[repository="src",length=12] +|June 2, 2021 +|13.0-STABLE after adding TCP LRO support for VLAN and VxLAN. + +|1300507 +|gitref:c64d1bd7145b5d30c97d1cd99e584da529d95100[repository="src",length=12] +|June 2, 2021 +|13.0-STABLE after adding a new member to the EPOCH(9) tracker structure. + +|1300508 +|gitref:658f5eed38c35f3f7d6695110b7dae8dc94d12c7[repository="src",length=12] +|June 11, 2021 +|13.0-STABLE after adding macros for might_lock_nested() and lockdep_(re/un/)pin_lock() to the LinuxKPI. |=== [[versions-12]] From owner-dev-commits-doc-all@freebsd.org Sun Jun 13 20:53:43 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 67ED565B8C8 for ; Sun, 13 Jun 2021 20:53:43 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G36Hq2LSLz4lL6; Sun, 13 Jun 2021 20:53:43 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 3901027F40; Sun, 13 Jun 2021 20:53:43 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 15DKrhKl081158; Sun, 13 Jun 2021 20:53:43 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 15DKrhIF081157; Sun, 13 Jun 2021 20:53:43 GMT (envelope-from git) Date: Sun, 13 Jun 2021 20:53:43 GMT Message-Id: <202106132053.15DKrhIF081157@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Dimitry Andric Subject: git: 27005bb368 - main - Document __FreeBSD_version values 1202505 through 1202507. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: dim X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 27005bb368628b2841e831e487606c6ffc88c367 Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2021 20:53:43 -0000 The branch main has been updated by dim (src committer): URL: https://cgit.FreeBSD.org/doc/commit/?id=27005bb368628b2841e831e487606c6ffc88c367 commit 27005bb368628b2841e831e487606c6ffc88c367 Author: Dimitry Andric AuthorDate: 2021-06-13 20:51:37 +0000 Commit: Dimitry Andric CommitDate: 2021-06-13 20:51:37 +0000 Document __FreeBSD_version values 1202505 through 1202507. --- .../en/books/porters-handbook/versions/_index.adoc | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/documentation/content/en/books/porters-handbook/versions/_index.adoc b/documentation/content/en/books/porters-handbook/versions/_index.adoc index 96e7aa2c28..a24da9e33b 100644 --- a/documentation/content/en/books/porters-handbook/versions/_index.adoc +++ b/documentation/content/en/books/porters-handbook/versions/_index.adoc @@ -1643,7 +1643,22 @@ Here is a convenient list of `__FreeBSD_version` values as defined in https://cg |1202504 |link:https://svnweb.freebsd.org/changeset/base/367511[367511] |November 9, 2020 -|12-STABLE after the addition of `ptsname_r`. +|12-STABLE after the addition of man:ptsname_r[3]. + +|1202505 +|gitref:f3d75bed5475b15f21edf4052665b1212b548bd0[repository="src",length=12] +|December 28, 2020 +|12-STABLE after improving handling of alternate settings in the USB stack. + +|1202506 +|gitref:d36cc12ddfe3335ec8306bd4b393f11069551fa0[repository="src",length=12] +|April 30, 2021 +|12-STABLE after changing the internal KAPI between the krpc and NFS. + +|1202507 +|gitref:1e279fe9deaea1c5e3503117dd3077dcffb1276d[repository="src",length=12] +|May 10, 2021 +|12-STABLE after changing the internal KAPI between the nscl.ko and nfscommon.ko modules. |=== [[versions-11]] From owner-dev-commits-doc-all@freebsd.org Sun Jun 13 20:53:44 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A827865BE83 for ; Sun, 13 Jun 2021 20:53:44 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G36Hr3k4wz4lCc; Sun, 13 Jun 2021 20:53:44 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 5C51D27A78; Sun, 13 Jun 2021 20:53:44 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 15DKriLU081184; Sun, 13 Jun 2021 20:53:44 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 15DKric0081183; Sun, 13 Jun 2021 20:53:44 GMT (envelope-from git) Date: Sun, 13 Jun 2021 20:53:44 GMT Message-Id: <202106132053.15DKric0081183@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Dimitry Andric Subject: git: 1eff0e605b - main - Add more man:xxx[y] tags. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: dim X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 1eff0e605b333c13c0eec3b4876fe721c7dc630a Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2021 20:53:44 -0000 The branch main has been updated by dim (src committer): URL: https://cgit.FreeBSD.org/doc/commit/?id=1eff0e605b333c13c0eec3b4876fe721c7dc630a commit 1eff0e605b333c13c0eec3b4876fe721c7dc630a Author: Dimitry Andric AuthorDate: 2021-06-13 20:53:34 +0000 Commit: Dimitry Andric CommitDate: 2021-06-13 20:53:34 +0000 Add more man:xxx[y] tags. --- .../en/books/porters-handbook/versions/_index.adoc | 28 +++++++++++----------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/documentation/content/en/books/porters-handbook/versions/_index.adoc b/documentation/content/en/books/porters-handbook/versions/_index.adoc index a24da9e33b..739d02faee 100644 --- a/documentation/content/en/books/porters-handbook/versions/_index.adoc +++ b/documentation/content/en/books/porters-handbook/versions/_index.adoc @@ -72,12 +72,12 @@ Here is a convenient list of `__FreeBSD_version` values as defined in https://cg |1400005 |gitref:45eabf5754ac1d291bd677fdf29f59ce4bbc2c8f[repository="src",length=12] |February 17, 2021 -|14.0-CURRENT after changing the API of `ptrace(2)` `PT_GETDBREGS`/`PT_SETDBREGS` on arm64. +|14.0-CURRENT after changing the API of man:ptrace[2] `PT_GETDBREGS`/`PT_SETDBREGS` on arm64. |1400006 |gitref:c96151d33509655efb7fb26768cb56a041c176f1[repository="src",length=12] |March 17, 2021 -|14.0-CURRENT after adding sndstat(4) enumeration ioctls. +|14.0-CURRENT after adding man:sndstat[4] enumeration ioctls. |1400007 |gitref:d36d6816151705907393889d661cbfd25c630ca8[repository="src",length=12] @@ -97,7 +97,7 @@ Here is a convenient list of `__FreeBSD_version` values as defined in https://cg |1400010 |gitref:a3a02acde1009f03dc78e979e051acee9f9247c2[repository="src",length=12] |April 21, 2021 -|14.0-CURRENT after changing the sndstat(4) ioctls nvlist schema and definitions. +|14.0-CURRENT after changing the man:sndstat[4] ioctls nvlist schema and definitions. |1400015 |gitref:d72cd275187c6399caf0ca4125292dc7e55fa478[repository="src",length=12] @@ -117,7 +117,7 @@ Here is a convenient list of `__FreeBSD_version` values as defined in https://cg |1400018 |gitref:a4b07a2701f568c2c0f0c0426091f1489244a92d[repository="src",length=12] |May 30, 2021 -|14.0-CURRENT after allowing the VFS_QUOTACTL(9) implementation to indicate busy state changes. +|14.0-CURRENT after allowing the man:VFS_QUOTACTL[9] implementation to indicate busy state changes. |1400019 |gitref:37d64dcdfa519157aff9711f1f226ad7bd778f46[repository="src",length=12] @@ -255,7 +255,7 @@ Here is a convenient list of `__FreeBSD_version` values as defined in https://cg |1300019 |link:https://svnweb.freebsd.org/changeset/base/346282[346282] |April 16, 2019 -|13.0-CURRENT after addition of is_random_seeded(9) to man:random[4]. +|13.0-CURRENT after addition of man:is_random_seeded[9] to man:random[4]. |1300020 |link:https://svnweb.freebsd.org/changeset/base/346358[346358] @@ -345,7 +345,7 @@ Here is a convenient list of `__FreeBSD_version` values as defined in https://cg |1300037 |link:https://svnweb.freebsd.org/changeset/base/350307[350307] |July 24, 2019 -|13.0-CURRENT after removal of libcap_random(3). +|13.0-CURRENT after removal of man:libcap_random[3]. |1300038 |link:https://svnweb.freebsd.org/changeset/base/350437[350437] @@ -420,7 +420,7 @@ Here is a convenient list of `__FreeBSD_version` values as defined in https://cg |1300051 |link:https://svnweb.freebsd.org/changeset/base/353685[353685] |October 17, 2019 -|13.0-CURRENT after splitting out a more generic debugnet(4) from man:netdump[4]. +|13.0-CURRENT after splitting out a more generic man:debugnet[4] from man:netdump[4]. |1300052 |link:https://svnweb.freebsd.org/changeset/base/353698[353698] @@ -450,7 +450,7 @@ Here is a convenient list of `__FreeBSD_version` values as defined in https://cg |1300057 |link:https://svnweb.freebsd.org/changeset/base/354694[354694] |November 13, 2019 -|13.0-CURRENT after adding support for AT_EXECPATH to elf_aux_info(3). +|13.0-CURRENT after adding support for AT_EXECPATH to man:elf_aux_info[3]. |1300058 |link:https://svnweb.freebsd.org/changeset/base/354820[354820] @@ -625,7 +625,7 @@ Here is a convenient list of `__FreeBSD_version` values as defined in https://cg |1300091 |link:https://svnweb.freebsd.org/changeset/base/359839[359839] |April 12, 2020 -|13.0-CURRENT after implementing a close_range(2) syscall. +|13.0-CURRENT after implementing a man:close_range[2] syscall. |1300092 |link:https://svnweb.freebsd.org/changeset/base/359920[359920] @@ -745,7 +745,7 @@ Here is a convenient list of `__FreeBSD_version` values as defined in https://cg |1300114 |link:https://svnweb.freebsd.org/changeset/base/365459[365459] |September 8, 2020 -|13.0-CURRENT after changing arm64 AT_HWCAP definitions for elf_aux_info(3). +|13.0-CURRENT after changing arm64 AT_HWCAP definitions for man:elf_aux_info[3]. |1300115 |link:https://svnweb.freebsd.org/changeset/base/365705[365705] @@ -915,7 +915,7 @@ Here is a convenient list of `__FreeBSD_version` values as defined in https://cg |1300507 |gitref:c64d1bd7145b5d30c97d1cd99e584da529d95100[repository="src",length=12] |June 2, 2021 -|13.0-STABLE after adding a new member to the EPOCH(9) tracker structure. +|13.0-STABLE after adding a new member to the man:EPOCH[9] tracker structure. |1300508 |gitref:658f5eed38c35f3f7d6695110b7dae8dc94d12c7[repository="src",length=12] @@ -1498,7 +1498,7 @@ Here is a convenient list of `__FreeBSD_version` values as defined in https://cg |1201503 |link:https://svnweb.freebsd.org/changeset/base/354928[354928] |November 21, 2019 -|12-STABLE after adding support for AT_EXECPATH to elf_aux_info(3). +|12-STABLE after adding support for AT_EXECPATH to man:elf_aux_info[3]. |1201504 |link:https://svnweb.freebsd.org/changeset/base/355658[355658] @@ -3552,7 +3552,7 @@ Here is a convenient list of `__FreeBSD_version` values as defined in https://cg |900041 |link:https://svnweb.freebsd.org/changeset/base/224834[224834] |August 13, 2011 -|9.0-CURRENT after the implementation of Capsicum capabilities; fget(9) gains a rights argument. +|9.0-CURRENT after the implementation of Capsicum capabilities; man:fget[9] gains a rights argument. |900042 |link:https://svnweb.freebsd.org/changeset/base/225350[225350] @@ -5336,7 +5336,7 @@ Here is a convenient list of `__FreeBSD_version` values as defined in https://cg |602112 |link:https://svnweb.freebsd.org/changeset/base/172284[172284] |September 21, 2007 -|6.2-STABLE after libutil(3) MFC's. +|6.2-STABLE after man:libutil[3] MFC's. |602113 |link:https://svnweb.freebsd.org/changeset/base/172986[172986]