git: f80bbbf56d - main - Remove an extra space after '+' characters
Danilo G. Baio
dbaio at FreeBSD.org
Tue Jun 8 10:28:23 UTC 2021
The branch main has been updated by dbaio:
URL: https://cgit.FreeBSD.org/doc/commit/?id=f80bbbf56d7b9f87e93e25545073b98603da9b81
commit f80bbbf56d7b9f87e93e25545073b98603da9b81
Author: Danilo G. Baio <dbaio at FreeBSD.org>
AuthorDate: 2021-06-07 23:04:38 +0000
Commit: Danilo G. Baio <dbaio at FreeBSD.org>
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) <<McKu1999>>.
-+
++
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 at FreeBSD.org[core at 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-<repository>.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 <<kerberos-ldap>> 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 at FreeBSD.org[wiki-admin at 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 <<respect,Respect other committers>> 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 at 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 at Alameda.net[ulf at 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 at HOOVER.STANFORD.EDU[ANDRSN at HOOVER.STANFORD.EDU]
@@ -88,7 +88,7 @@ The following individuals and businesses have generously contributed direct fund
** Chris Silva mailto:ras at interaccess.com[ras at 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 ***
More information about the dev-commits-doc-all
mailing list