 @@ -211,30 +211,29 @@ builds)
 <dt><span class="sect1"><a href="#build.wrapper">13.10. The <span class="emphasis"><em>wrapper</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.configure">13.11. The <span class="emphasis"><em>configure</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.build">13.12. The <span class="emphasis"><em>build</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.test">13.13. The <span class="emphasis"><em>test</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.install">13.14. The <span class="emphasis"><em>install</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.package">13.15. The <span class="emphasis"><em>package</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.clean">13.16. Cleaning up</a></span></dt>
 <dt><span class="sect1"><a href="#build.helpful-targets">13.17. Other helpful targets</a></span></dt>
 </dl></dd>
 <dt><span class="chapter"><a href="#creating">14. Creating a new pkgsrc package from scratch</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#creating.common">14.1. Common types of packages</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="#creating.perl-module">14.1.1. Perl modules</a></span></dt>
+<dt><span class="sect2"><a href="#creating.python-module">14.1.1. Python modules and programs</a></span></dt>
-<dt><span class="sect2"><a href="#creating.python-module">14.1.2. Python modules and programs</a></span></dt>
+<dt><span class="sect2"><a href="#creating.R-package">14.1.2. R packages</a></span></dt>
-<dt><span class="sect2"><a href="#creating.R-package">14.1.3. R packages</a></span></dt>
+<dt><span class="sect2"><a href="#creating.TeX-package">14.1.3. TeXlive packages</a></span></dt>
 <dt><span class="sect2"><a href="#creating.TeX-package">14.1.4. TeXlive packages</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#creating.examples">14.2. Examples</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#creating.nvu">14.2.1. How the www/nvu package came into pkgsrc</a></span></dt></dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="#makefile">15. Programming in <code class="filename">Makefile</code>s</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#makefile.style">15.1. Caveats</a></span></dt>
 <dt><span class="sect1"><a href="#makefile.variables">15.2. <code class="filename">Makefile</code> variables</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#makefile.variables.names">15.2.1. Naming conventions</a></span></dt></dl></dd>
 <dt><span class="sect1"><a href="#makefile.code">15.3. Code snippets</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#adding-to-list">15.3.1. Adding things to a list</a></span></dt>
 <dt><span class="sect2"><a href="#echo-literal">15.3.2. Echoing a string exactly as-is</a></span></dt>
 @@ -3179,30 +3178,29 @@ anymore, you can remove that file and ru
 <dt><span class="sect1"><a href="#build.wrapper">13.10. The <span class="emphasis"><em>wrapper</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.configure">13.11. The <span class="emphasis"><em>configure</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.build">13.12. The <span class="emphasis"><em>build</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.test">13.13. The <span class="emphasis"><em>test</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.install">13.14. The <span class="emphasis"><em>install</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.package">13.15. The <span class="emphasis"><em>package</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.clean">13.16. Cleaning up</a></span></dt>
 <dt><span class="sect1"><a href="#build.helpful-targets">13.17. Other helpful targets</a></span></dt>
 </dl></dd>
 <dt><span class="chapter"><a href="#creating">14. Creating a new pkgsrc package from scratch</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#creating.common">14.1. Common types of packages</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="#creating.perl-module">14.1.1. Perl modules</a></span></dt>
+<dt><span class="sect2"><a href="#creating.python-module">14.1.1. Python modules and programs</a></span></dt>
-<dt><span class="sect2"><a href="#creating.python-module">14.1.2. Python modules and programs</a></span></dt>
+<dt><span class="sect2"><a href="#creating.R-package">14.1.2. R packages</a></span></dt>
-<dt><span class="sect2"><a href="#creating.R-package">14.1.3. R packages</a></span></dt>
+<dt><span class="sect2"><a href="#creating.TeX-package">14.1.3. TeXlive packages</a></span></dt>
 <dt><span class="sect2"><a href="#creating.TeX-package">14.1.4. TeXlive packages</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#creating.examples">14.2. Examples</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#creating.nvu">14.2.1. How the www/nvu package came into pkgsrc</a></span></dt></dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="#makefile">15. Programming in <code class="filename">Makefile</code>s</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#makefile.style">15.1. Caveats</a></span></dt>
 <dt><span class="sect1"><a href="#makefile.variables">15.2. <code class="filename">Makefile</code> variables</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#makefile.variables.names">15.2.1. Naming conventions</a></span></dt></dl></dd>
 <dt><span class="sect1"><a href="#makefile.code">15.3. Code snippets</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#adding-to-list">15.3.1. Adding things to a list</a></span></dt>
 <dt><span class="sect2"><a href="#echo-literal">15.3.2. Echoing a string exactly as-is</a></span></dt>
 @@ -5056,172 +5054,161 @@ ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site
 	  information on this target.</p>
 </dd>
 </dl></div>
 </div>
 </div>
 <div class="chapter">
 <div class="titlepage"><div><div><h2 class="title">
 <a name="creating"></a>Chapter�14.�Creating a new pkgsrc package from scratch</h2></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <dt><span class="sect1"><a href="#creating.common">14.1. Common types of packages</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="#creating.perl-module">14.1.1. Perl modules</a></span></dt>
+<dt><span class="sect2"><a href="#creating.python-module">14.1.1. Python modules and programs</a></span></dt>
-<dt><span class="sect2"><a href="#creating.python-module">14.1.2. Python modules and programs</a></span></dt>
+<dt><span class="sect2"><a href="#creating.R-package">14.1.2. R packages</a></span></dt>
-<dt><span class="sect2"><a href="#creating.R-package">14.1.3. R packages</a></span></dt>
+<dt><span class="sect2"><a href="#creating.TeX-package">14.1.3. TeXlive packages</a></span></dt>
 <dt><span class="sect2"><a href="#creating.TeX-package">14.1.4. TeXlive packages</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#creating.examples">14.2. Examples</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#creating.nvu">14.2.1. How the www/nvu package came into pkgsrc</a></span></dt></dl></dd>
 </dl>
 </div>
 <p>When you find a package that is not yet in pkgsrc, you
 most likely have a URL from where you can download the source
 code. Starting with this URL, creating a package involves only a
 few steps.</p>
 <div class="procedure"><ol class="procedure" type="1">
 <li class="step"><p>In your <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>, set <code class="code">PKG_DEVELOPER=yes</code> to
 enable the basic quality checks.</p></li>
 <li class="step">
 <p>Install the package <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/meta-pkgs/pkg_developer/index.html" target="_top"><code class="filename">meta-pkgs/pkg_developer</code></a>, which among others will
 install the utilities <span class="command"><strong>url2pkg</strong></span>,
 <span class="command"><strong>pkglint</strong></span>, <span class="command"><strong>pkgvi</strong></span> and
 <span class="command"><strong>mkpatches</strong></span>:</p>
 <pre class="screen"><code class="prompt">$</code> <strong class="userinput"><code>cd /usr/pkgsrc</code></strong>
 <code class="prompt">$</code> <strong class="userinput"><code>(cd meta-pkgs/pkg_developer &amp;&amp; bmake update)</code></strong></pre>
 </li>
 <li class="step">
 <p>Choose one of the top-level directories as the category in
 which you want to place your package. You can also create a directory of
-your own (maybe called <code class="filename">local</code>). In that category
+your own (maybe called <code class="filename">local</code>). Change into that
-directory, create another directory for your package and change into
+category directory:</p>
-it:</p>
+<pre class="screen"><code class="prompt">$</code> <strong class="userinput"><code>cd <em class="replaceable"><code>category</code></em></code></strong></pre>
 <pre class="screen"><code class="prompt">$</code> <strong class="userinput"><code>mkdir <em class="replaceable"><code>category</code></em>/<em class="replaceable"><code>package</code></em></code></strong>
 <code class="prompt">$</code> <strong class="userinput"><code>cd <em class="replaceable"><code>category</code></em>/<em class="replaceable"><code>package</code></em></code></strong></pre>
 </li>
 <li class="step">
-<p>Run the program <span class="command"><strong>url2pkg</strong></span>, which will ask
+<p>Run the program <span class="command"><strong>url2pkg</strong></span>, passing as
-you for a URL. Enter the URL of the distribution file (in most cases a
+argument the URL of the distribution file (in most cases a
-<code class="filename">.tar.gz</code> file) and watch how the basic ingredients
+<code class="filename">.tar.gz</code> file). This will download the distribution
-of your package are created automatically. The distribution file is
+file and create the necessary files of the package, based on what's in
-extracted automatically to fill in some details in the
+the distribution file:</p>
 <code class="filename">Makefile</code> that would otherwise have to be done
 manually:</p>
 <pre class="screen"><code class="prompt">$</code> <strong class="userinput"><code>url2pkg <em class="replaceable"><code>https://www.example.org/packages/package-1.0.tar.gz</code></em></code></strong></pre>
 </li>
 <li class="step">
 <p>Examine the extracted files to determine the dependencies of
 your package. Ideally, this is mentioned in some
 <code class="filename">README</code> file, but things may differ. For each of
 these dependencies, look where it exists in pkgsrc, and if there is a
 file called <code class="filename">buildlink3.mk</code> in that directory, add a
 line to your package <code class="filename">Makefile</code> which includes that
 file just before the last line. If the
 <code class="filename">buildlink3.mk</code> file does not exist, it must be
 created first. The <code class="filename">buildlink3.mk</code> file makes sure
 that the package's include files and libraries are provided.</p>
-<p>If you just need binaries from a package, add a
+<p>If you just need binaries from a dependent package, add a
 <code class="varname">DEPENDS</code> line to the Makefile, which specifies the
 version of the dependency and where it can be found in pkgsrc. This line
 should be placed in the third paragraph. If the dependency is only
 needed for building the package, but not when using it, use
 <code class="varname">TOOL_DEPENDS</code> or <code class="varname">BUILD_DEPENDS</code>
 instead of <code class="varname">DEPENDS</code>.
 The difference between <code class="varname">TOOL_DEPENDS</code> and
 <code class="varname">BUILD_DEPENDS</code> occurs when cross-compiling:
 <code class="varname">TOOL_DEPENDS</code> are <span class="emphasis"><em>native</em></span>
-packages, i.e. packages for the architecture where the package
+packages, i.e. packages for the platform where the package is built;
 is built;
 <code class="varname">BUILD_DEPENDS</code> are <span class="emphasis"><em>target</em></span>
-packages, i.e. packages for the architecture for which the package
+packages, i.e. packages for the platform for which the package
-is built. There is also <code class="varname">TEST_DEPENDS</code>, which is used
+is built. There is also <code class="varname">TEST_DEPENDS</code>, which
-to specify a dependency used only for testing the resulting package
+specifies a dependency used only for testing the resulting package
-built, using the upstream project's included test suite.
+built, using the upstream project's included test suite, on the native
 platform.
 Your package may then look like this:</p>
 <pre class="programlisting">
 [...]
 TOOL_DEPENDS+=  libxslt-[0-9]*:../../textproc/libxslt
 DEPENDS+=       screen-[0-9]*:../../misc/screen
 DEPENDS+=       screen&gt;=4.0:../../misc/screen
 [...]
 .include "../../<em class="replaceable"><code>category</code></em>/<em class="replaceable"><code>package</code></em>/buildlink3.mk"
 .include "../../devel/glib2/buildlink3.mk"
 .include "../../mk/bsd.pkg.mk"
 </pre>
 </li>
 <li class="step"><p>Run <span class="command"><strong>pkglint</strong></span> to see what things still need
 to be done to make your package a <span class="quote">&#8220;<span class="quote">good</span>&#8221;</span> one. If you don't
 know what pkglint's warnings want to tell you, try <span class="command"><strong>pkglint
 --explain</strong></span> or <span class="command"><strong>pkglint -e</strong></span>, which outputs
 additional explanations.</p></li>
 <li class="step"><p>In many cases the package is not yet ready to build. You can
 find instructions for the most common cases in the next section, <a class="xref" href="#creating.common" title="14.1.�Common types of packages">Section�14.1, &#8220;Common types of packages&#8221;</a>. After you have followed the instructions
 over there, you can hopefully continue here.</p></li>
 <li class="step"><p>Run <span class="command"><strong>bmake clean</strong></span> to clean the working
 directory from the extracted files. Besides these files, a lot of cache
-files and other system information has been saved in the working
+files and other system information have been saved in the working
-directory, which may become wrong after you edited the
+directory, which may have become outdated after you edited the
 <code class="filename">Makefile</code>.</p></li>
 <li class="step">
 <p>Now, run <span class="command"><strong>bmake</strong></span> to build the package. For
 the various things that can go wrong in this phase, consult <a class="xref" href="#fixes" title="Chapter�21.�Making your package work">Chapter�21, <i>Making your package work</i></a>.</p>
-<p>If the extracted files from the package need to be fixed, run multiple rounds of these commands:</p>
+<p>If the extracted files from the package need to be fixed, run
-<pre class="screen"><code class="prompt">$</code> <strong class="userinput"><code>make</code></strong>
+multiple rounds of these commands:</p>
 <pre class="screen"><code class="prompt">$</code> <strong class="userinput"><code>bmake</code></strong>
 <code class="prompt">$</code> <strong class="userinput"><code>pkgvi ${WRKSRC}/some/file/that/does/not/compile</code></strong>
 <code class="prompt">$</code> <strong class="userinput"><code>mkpatches</code></strong>
-<code class="prompt">$</code> <strong class="userinput"><code>make mps</code></strong>
+<code class="prompt">$</code> <strong class="userinput"><code>bmake mps</code></strong>
-<code class="prompt">$</code> <strong class="userinput"><code>make clean</code></strong></pre>
+<code class="prompt">$</code> <strong class="userinput"><code>bmake clean</code></strong></pre>
 </li>
 <li class="step"><p>When the package builds fine, the next step is to install
 the package. Run <span class="command"><strong>bmake install</strong></span> and hope that
 everything works.</p></li>
 <li class="step"><p>Up to now, the file <code class="filename">PLIST</code>, which
 contains a list of the files that are installed by the package, is
 nearly empty. Run <span class="command"><strong>bmake print-PLIST
 &gt;PLIST</strong></span> to generate a probably correct list. Check
 the file using your preferred text editor to see if the list of
 files looks plausible.</p></li>
 <li class="step"><p>Run <span class="command"><strong>pkglint</strong></span> again to see if the generated
 <code class="filename">PLIST</code> contains garbage or not.</p></li>
 <li class="step"><p>When you ran <span class="command"><strong>bmake install</strong></span>, the package
 had been registered in the database of installed files, but with an
 empty list of files. To fix this, run <span class="command"><strong>bmake deinstall</strong></span>
 and <span class="command"><strong>bmake install</strong></span> again. Now the package is
 registered with the list of files from
 <code class="filename">PLIST</code>.</p></li>
 <li class="step"><p>Run <span class="command"><strong>bmake package</strong></span> to create a binary
 package from the set of installed files.</p></li>
 <li class="step"><p>Run <span class="command"><strong>bmake clean update</strong></span> to run everything
 from above again in a single step, making sure that the PLIST is correct
 and the whole package is created as intended.</p></li>
-<li class="step"><p>Run <span class="command"><strong>pkglint</strong></span> to see if there's anything left to do.</p></li>
+<li class="step"><p>Run <span class="command"><strong>pkglint</strong></span> to see if there's anything
 left to do.</p></li>
 <li class="step"><p>Commit the package to pkgsrc-wip or main pkgsrc; see <a class="xref" href="#submit" title="Chapter�23.�Submitting and Committing">Chapter�23, <i>Submitting and Committing</i></a>.</p></li>
 </ol></div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="creating.common"></a>14.1.�Common types of packages</h2></div></div></div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="creating.perl-module"></a>14.1.1.�Perl modules</h3></div></div></div>
+<a name="creating.python-module"></a>14.1.1.�Python modules and programs</h3></div></div></div>
 <p>Simple Perl modules are handled automatically by
 <span class="command"><strong>url2pkg</strong></span>, including dependencies.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="creating.python-module"></a>14.1.2.�Python modules and programs</h3></div></div></div>
 <p>Python modules and programs packages are easily created using a
 set of predefined variables.</p>
 <p>
 If some Python versions are not supported by the software, set the
 <code class="varname">PYTHON_VERSIONS_INCOMPATIBLE</code> variable to the Python versions
 that are not supported, e.g.
 </p>
 <pre class="programlisting">
 PYTHON_VERSIONS_INCOMPATIBLE=       27
 </pre>
 <p>
 If the packaged software is a Python module, include one of
 <code class="filename">../../lang/python/egg.mk</code> or
 @@ -5256,42 +5243,42 @@ packages that should be depended upon an
 <span class="quote">&#8220;<span class="quote"><code class="filename">../../lang/python/versioned_dependencies.mk</code></span>&#8221;</span>,
 then the pkgsrc infrastructure will depend on the appropriate package
 version. For example:
 </p>
 <pre class="programlisting">
 PYTHON_VERSIONED_DEPENDENCIES=dialog
 </pre>
 <p>
 Look inside <code class="filename">versioned_dependencies.mk</code> for a list
 of supported packages.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="creating.R-package"></a>14.1.3.�R packages</h3></div></div></div>
+<a name="creating.R-package"></a>14.1.2.�R packages</h3></div></div></div>
 <p>Simple R packages from <a class="ulink" href="https://cran.r-project.org/web/packages/available_packages_by_name.html" target="_top">CRAN</a>
 are handled automatically by <span class="command"><strong>R2pkg</strong></span>, which is
 available in <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/R2pkg/index.html" target="_top"><code class="filename">pkgtools/R2pkg</code></a>.
 Individual packages (and optionally their dependencies) may be created
 and updated.  R packages generally follow the same form, and most of
 the relevant information needed is contained in a
 <code class="filename">DESCRIPTION</code> file as part of each R package on
 <a class="ulink" href="https://cran.r-project.org/web/packages/available_packages_by_name.html" target="_top">CRAN</a>.
 Consequently, <span class="command"><strong>R2pkg</strong></span> downloads that information and
 creates or updates a package in the canonical form.  The resulting
 package should be reviewed for correctness.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="creating.TeX-package"></a>14.1.4.�TeXlive packages</h3></div></div></div>
+<a name="creating.TeX-package"></a>14.1.3.�TeXlive packages</h3></div></div></div>
 <p>TeXlive packages from <a class="ulink" href="https://www.ctan.org/" target="_top">CTAN</a> are handled automatically by
 <span class="command"><strong>texlive2pkg</strong></span>, which is available in <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/texlive2pkg/index.html" target="_top"><code class="filename">pkgtools/texlive2pkg</code></a>.</p>
 <p>If the TeXlive package name is not known, it may be useful to
 search <a class="ulink" href="https://www.ctan.org/" target="_top">CTAN</a>.  A
 <span class="quote">&#8220;<span class="quote">Contained in</span>&#8221;</span> field on the package page typically
 identifies the basename of the package file in the <a class="ulink" href="https://www.ctan.org/tex-archive/systems/texlive/tlnet/archive" target="_top">TeXlive
 archive</a>.</p>
 <p>If the TeXlive package name is known, download the files from
 the <a class="ulink" href="https://www.ctan.org/tex-archive/systems/texlive/tlnet/archive" target="_top">TeXlive
 archive</a>.  For package <code class="filename">foo</code>, you will need
 to download <code class="filename">foo.tar.xz</code>.  Most TeXlive packages
 also have associated documentation packages, so download
 <code class="filename">foo.doc.tar.xz</code> at the same time.  These files
 @@ -11025,84 +11012,84 @@ such as ASLR.  Some operating systems su
 (ASLR), which causes different addresses to be used each time a program is run.
 This makes it more difficult for an attacker to guess addresses and thus makes
 exploits harder to construct. With PIE, ASLR can really be applied to the entire
 program, instead of the stack and heap only.
 </p>
 <p>
 PIE executables will only be built for toolchains that are known to support PIE.
 Currently, this means NetBSD on x86, ARM, SPARC64, m68k, and MIPS.
 </p>
 <p>
 <code class="varname">PKGSRC_MKPIE</code> was enabled by default after the pkgsrc-2021Q3 branch.
 </p>
 </div>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="hardening.mechanisms.disabled"></a>B.1.2.�Not enabled by default</h3></div></div></div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="hardening.mechanisms.disabled.repro"></a>B.1.2.1.�PKGSRC_MKREPRO</h4></div></div></div>
+<a name="hardening.mechanisms.enabled.relro"></a>B.1.1.4.�PKGSRC_USE_RELRO</h4></div></div></div>
 <p>
 With this option, pkgsrc will try to build packages reproducibly. This allows
 packages built from the same tree and with the same options, to produce
 identical results bit by bit. This option should be combined with ASLR and
 <code class="varname">PKGSRC_MKPIE</code> to avoid predictable address offsets for
 attackers attempting to exploit security vulnerabilities.
 </p>
 <p>
 More details can be found here:
 </p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
 <a class="ulink" href="https://reproducible-builds.org/" target="_top">Reproducible Builds - a set of software development practices that create an independently-verifiable path from source to binary code</a>
 </p></li></ul></div>
 <p>
 More work likely needs to be done before pkgsrc is fully reproducible.
 </p>
 </div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="hardening.mechanisms.enabled.relro"></a>B.1.2.2.�PKGSRC_USE_RELRO</h4></div></div></div>
 <p>
 This also makes the exploitation of some security vulnerabilities more
 difficult in some cases.
 </p>
 <p>Two different mitigation levels are available:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p>
-partial: the ELF sections are reordered so that internal data sections
+partial (the default): the ELF sections are reordered so that internal data sections
 precede the program's own data sections, and non-PLT GOT is read-only;
 </p></li>
 <li class="listitem"><p>
 full: in addition to partial RELRO, every relocation is performed immediately
 when starting the program, allowing the entire GOT to be read-only.  This
 can greatly slow down startup of large programs.
 </p></li>
 </ul></div>
 <p>
 This is currently supported by GCC. Many software distributions now enable this
 feature by default, at the "partial" level. However, it cannot yet be enforced
 globally in pkgsrc through cwrappers.
 </p>
 <p>
 More details can be found here:
 </p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
 <a class="ulink" href="https://www.redhat.com/en/blog/hardening-elf-binaries-using-relocation-read-only-relro" target="_top">Hardening ELF binaries using Relocation Read-Only (RELRO)</a>
 </p></li></ul></div>
 </div>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="hardening.mechanisms.disabled"></a>B.1.2.�Not enabled by default</h3></div></div></div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="hardening.mechanisms.disabled.repro"></a>B.1.2.1.�PKGSRC_MKREPRO</h4></div></div></div>
 <p>
 With this option, pkgsrc will try to build packages reproducibly. This allows
 packages built from the same tree and with the same options, to produce
 identical results bit by bit. This option should be combined with ASLR and
 <code class="varname">PKGSRC_MKPIE</code> to avoid predictable address offsets for
 attackers attempting to exploit security vulnerabilities.
 </p>
 <p>
 More details can be found here:
 </p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
 <a class="ulink" href="https://reproducible-builds.org/" target="_top">Reproducible Builds - a set of software development practices that create an independently-verifiable path from source to binary code</a>
 </p></li></ul></div>
 <p>
 More work likely needs to be done before pkgsrc is fully reproducible.
 </p>
 </div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="hardening.mechanisms.disabled.stackcheck"></a>B.1.2.3.�PKGSRC_USE_STACK_CHECK</h4></div></div></div>
+<a name="hardening.mechanisms.disabled.stackcheck"></a>B.1.2.2.�PKGSRC_USE_STACK_CHECK</h4></div></div></div>
 <p>
 This uses <code class="literal">-fstack-check</code> with GCC for
 another stack protection mitigation.
 </p>
 <p>
 It asks the compiler to generate code verifying that it does not corrupt the
 stack. According to GCC's manual page, this is really only useful for
 multi-threaded programs.
 </p>
 </div>
 </div>
 </div>
 <div class="sect1">

 @@ -195,30 +195,29 @@ II. The pkgsrc developer's guide
 .10. The wrapper phase
 .11. The configure phase
 .12. The build phase
 .13. The test phase
 .14. The install phase
 .15. The package phase
 .16. Cleaning up
 .17. Other helpful targets
 . Creating a new pkgsrc package from scratch
 .1. Common types of packages
-.1.1. Perl modules
+.1.1. Python modules and programs
-.1.2. Python modules and programs
+.1.2. R packages
-.1.3. R packages
+.1.3. TeXlive packages
 .1.4. TeXlive packages
 .2. Examples
 .2.1. How the www/nvu package came into pkgsrc
 . Programming in Makefiles
 .1. Caveats
 .2. Makefile variables
 .2.1. Naming conventions
 .3. Code snippets
 @@ -2721,30 +2720,29 @@ Table of Contents
 .10. The wrapper phase
 .11. The configure phase
 .12. The build phase
 .13. The test phase
 .14. The install phase
 .15. The package phase
 .16. Cleaning up
 .17. Other helpful targets
 . Creating a new pkgsrc package from scratch
 .1. Common types of packages
-.1.1. Perl modules
+.1.1. Python modules and programs
-.1.2. Python modules and programs
+.1.2. R packages
-.1.3. R packages
+.1.3. TeXlive packages
 .1.4. TeXlive packages
 .2. Examples
 .2.1. How the www/nvu package came into pkgsrc
 . Programming in Makefiles
 .1. Caveats
 .2. Makefile variables
 .2.1. Naming conventions
 .3. Code snippets
 @@ -4205,158 +4203,146 @@ print-PLIST
     If the package installs files via tar(1) or other methods that don't update
     file access times, be sure to add these files manually to your PLIST, as
     the "find -newer" command used by this target won't catch them!
     See Section 19.3, "Tweaking output of make print-PLIST" for more
     information on this target.
 Chapter 14. Creating a new pkgsrc package from scratch
 Table of Contents
 .1. Common types of packages
-.1.1. Perl modules
+.1.1. Python modules and programs
-.1.2. Python modules and programs
+.1.2. R packages
-.1.3. R packages
+.1.3. TeXlive packages
 .1.4. TeXlive packages
 .2. Examples
 .2.1. How the www/nvu package came into pkgsrc
 When you find a package that is not yet in pkgsrc, you most likely have a URL
 from where you can download the source code. Starting with this URL, creating a
 package involves only a few steps.
 . In your mk.conf, set PKG_DEVELOPER=yes to enable the basic quality checks.
 . Install the package meta-pkgs/pkg_developer, which among others will
     install the utilities url2pkg, pkglint, pkgvi and mkpatches:
     $ cd /usr/pkgsrc
     $ (cd meta-pkgs/pkg_developer && bmake update)
 . Choose one of the top-level directories as the category in which you want
     to place your package. You can also create a directory of your own (maybe
-    called local). In that category directory, create another directory for
+    called local). Change into that category directory:
     your package and change into it:
-    $ mkdir category/package
+    $ cd category
     $ cd category/package
-. Run the program url2pkg, which will ask you for a URL. Enter the URL of the
+. Run the program url2pkg, passing as argument the URL of the distribution
-    distribution file (in most cases a .tar.gz file) and watch how the basic
+    file (in most cases a .tar.gz file). This will download the distribution
-    ingredients of your package are created automatically. The distribution
+    file and create the necessary files of the package, based on what's in the
-    file is extracted automatically to fill in some details in the Makefile
+    distribution file:
     that would otherwise have to be done manually:
     $ url2pkg https://www.example.org/packages/package-1.0.tar.gz
 . Examine the extracted files to determine the dependencies of your package.
     Ideally, this is mentioned in some README file, but things may differ. For
     each of these dependencies, look where it exists in pkgsrc, and if there is
     a file called buildlink3.mk in that directory, add a line to your package
     Makefile which includes that file just before the last line. If the
     buildlink3.mk file does not exist, it must be created first. The
     buildlink3.mk file makes sure that the package's include files and
     libraries are provided.
-    If you just need binaries from a package, add a DEPENDS line to the
+    If you just need binaries from a dependent package, add a DEPENDS line to
-    Makefile, which specifies the version of the dependency and where it can be
+    the Makefile, which specifies the version of the dependency and where it
-    found in pkgsrc. This line should be placed in the third paragraph. If the
+    can be found in pkgsrc. This line should be placed in the third paragraph.
-    dependency is only needed for building the package, but not when using it,
+    If the dependency is only needed for building the package, but not when
-    use TOOL_DEPENDS or BUILD_DEPENDS instead of DEPENDS. The difference
+    using it, use TOOL_DEPENDS or BUILD_DEPENDS instead of DEPENDS. The
-    between TOOL_DEPENDS and BUILD_DEPENDS occurs when cross-compiling:
+    difference between TOOL_DEPENDS and BUILD_DEPENDS occurs when
-    TOOL_DEPENDS are native packages, i.e. packages for the architecture where
+    cross-compiling: TOOL_DEPENDS are native packages, i.e. packages for the
-    the package is built; BUILD_DEPENDS are target packages, i.e. packages for
+    platform where the package is built; BUILD_DEPENDS are target packages,
-    the architecture for which the package is built. There is also
+    i.e. packages for the platform for which the package is built. There is
-    TEST_DEPENDS, which is used to specify a dependency used only for testing
+    also TEST_DEPENDS, which specifies a dependency used only for testing the
-    the resulting package built, using the upstream project's included test
+    resulting package built, using the upstream project's included test suite,
-    suite. Your package may then look like this:
+    on the native platform. Your package may then look like this:
     [...]
     TOOL_DEPENDS+=  libxslt-[0-9]*:../../textproc/libxslt
     DEPENDS+=       screen-[0-9]*:../../misc/screen
     DEPENDS+=       screen>=4.0:../../misc/screen
     [...]
     .include "../../category/package/buildlink3.mk"
     .include "../../devel/glib2/buildlink3.mk"
     .include "../../mk/bsd.pkg.mk"
 . Run pkglint to see what things still need to be done to make your package a
     "good" one. If you don't know what pkglint's warnings want to tell you, try
     pkglint --explain or pkglint -e, which outputs additional explanations.
 . In many cases the package is not yet ready to build. You can find
     instructions for the most common cases in the next section, Section 14.1,
     "Common types of packages". After you have followed the instructions over
     there, you can hopefully continue here.
 . Run bmake clean to clean the working directory from the extracted files.
-    Besides these files, a lot of cache files and other system information has
+    Besides these files, a lot of cache files and other system information have
-    been saved in the working directory, which may become wrong after you
+    been saved in the working directory, which may have become outdated after
-    edited the Makefile.
+    you edited the Makefile.
 . Now, run bmake to build the package. For the various things that can go
     wrong in this phase, consult Chapter 21, Making your package work.
     If the extracted files from the package need to be fixed, run multiple
     rounds of these commands:
-    $ make
+    $ bmake
     $ pkgvi ${WRKSRC}/some/file/that/does/not/compile
     $ mkpatches
-    $ make mps
+    $ bmake mps
-    $ make clean
+    $ bmake clean
 . When the package builds fine, the next step is to install the package. Run
     bmake install and hope that everything works.
 . Up to now, the file PLIST, which contains a list of the files that are
     installed by the package, is nearly empty. Run bmake print-PLIST >PLIST to
     generate a probably correct list. Check the file using your preferred text
     editor to see if the list of files looks plausible.
 . Run pkglint again to see if the generated PLIST contains garbage or not.
 . When you ran bmake install, the package had been registered in the database
     of installed files, but with an empty list of files. To fix this, run bmake
     deinstall and bmake install again. Now the package is registered with the
     list of files from PLIST.
-. Run bmake package to create a binary package from the set of installed
+. Run bmake clean update to run everything from above again in a single step,
     files.
 . Run bmake clean update to run everything from above again in a single step,
     making sure that the PLIST is correct and the whole package is created as
     intended.
 . Run pkglint to see if there's anything left to do.
 . Commit the package to pkgsrc-wip or main pkgsrc; see Chapter 23, Submitting
     and Committing.
 .1. Common types of packages
-.1.1. Perl modules
+.1.1. Python modules and programs
 Simple Perl modules are handled automatically by url2pkg, including
 dependencies.
 .1.2. Python modules and programs
 Python modules and programs packages are easily created using a set of
 predefined variables.
 If some Python versions are not supported by the software, set the
 PYTHON_VERSIONS_INCOMPATIBLE variable to the Python versions that are not
 supported, e.g.
 PYTHON_VERSIONS_INCOMPATIBLE=       27
 If the packaged software is a Python module, include one of ../../lang/python/
 egg.mk or ../../lang/python/extension.mk.
 @@ -4376,37 +4362,37 @@ be corrected. For example:
 REPLACE_PYTHON=   *.py
 Some Python modules have separate distributions for Python-2.x and Python-3.x
 support. In pkgsrc this is handled by the versioned_dependencies.mk file. Set
 PYTHON_VERSIONED_DEPENDENCIES to the list of packages that should be depended
 upon and include "../../lang/python/versioned_dependencies.mk", then the pkgsrc
 infrastructure will depend on the appropriate package version. For example:
 PYTHON_VERSIONED_DEPENDENCIES=dialog
 Look inside versioned_dependencies.mk for a list of supported packages.
-.1.3. R packages
+.1.2. R packages
 Simple R packages from CRAN are handled automatically by R2pkg, which is
 available in pkgtools/R2pkg. Individual packages (and optionally their
 dependencies) may be created and updated. R packages generally follow the same
 form, and most of the relevant information needed is contained in a DESCRIPTION
 file as part of each R package on CRAN. Consequently, R2pkg downloads that
 information and creates or updates a package in the canonical form. The
 resulting package should be reviewed for correctness.
-.1.4. TeXlive packages
+.1.3. TeXlive packages
 TeXlive packages from CTAN are handled automatically by texlive2pkg, which is
 available in pkgtools/texlive2pkg.
 If the TeXlive package name is not known, it may be useful to search CTAN. A "
 Contained in" field on the package page typically identifies the basename of
 the package file in the TeXlive archive.
 If the TeXlive package name is known, download the files from the TeXlive
 archive. For package foo, you will need to download foo.tar.xz. Most TeXlive
 packages also have associated documentation packages, so download
 foo.doc.tar.xz at the same time. These files should be placed in the
 appropriate category directory, which is often but not always print. Then run
 @@ -9024,66 +9010,67 @@ executables. The PIE mechanism is normal
 they can be loaded at differing addresses at runtime. PIE itself does not have
 useful security properties; however, it is necessary to fully leverage some,
 such as ASLR. Some operating systems support Address Space Layout Randomization
 (ASLR), which causes different addresses to be used each time a program is run.
 This makes it more difficult for an attacker to guess addresses and thus makes
 exploits harder to construct. With PIE, ASLR can really be applied to the
 entire program, instead of the stack and heap only.
 PIE executables will only be built for toolchains that are known to support
 PIE. Currently, this means NetBSD on x86, ARM, SPARC64, m68k, and MIPS.
 PKGSRC_MKPIE was enabled by default after the pkgsrc-2021Q3 branch.
-B.1.2. Not enabled by default
+B.1.1.4. PKGSRC_USE_RELRO
 B.1.2.1. PKGSRC_MKREPRO
 With this option, pkgsrc will try to build packages reproducibly. This allows
 packages built from the same tree and with the same options, to produce
 identical results bit by bit. This option should be combined with ASLR and
 PKGSRC_MKPIE to avoid predictable address offsets for attackers attempting to
 exploit security vulnerabilities.
 More details can be found here:
   * Reproducible Builds - a set of software development practices that create
     an independently-verifiable path from source to binary code
 More work likely needs to be done before pkgsrc is fully reproducible.
 B.1.2.2. PKGSRC_USE_RELRO
 This also makes the exploitation of some security vulnerabilities more
 difficult in some cases.
 Two different mitigation levels are available:
-  * partial: the ELF sections are reordered so that internal data sections
+  * partial (the default): the ELF sections are reordered so that internal data
-    precede the program's own data sections, and non-PLT GOT is read-only;
+    sections precede the program's own data sections, and non-PLT GOT is
     read-only;
   * full: in addition to partial RELRO, every relocation is performed
     immediately when starting the program, allowing the entire GOT to be
     read-only. This can greatly slow down startup of large programs.
 This is currently supported by GCC. Many software distributions now enable this
 feature by default, at the "partial" level. However, it cannot yet be enforced
 globally in pkgsrc through cwrappers.
 More details can be found here:
   * Hardening ELF binaries using Relocation Read-Only (RELRO)
-B.1.2.3. PKGSRC_USE_STACK_CHECK
+B.1.2. Not enabled by default
 B.1.2.1. PKGSRC_MKREPRO
 With this option, pkgsrc will try to build packages reproducibly. This allows
 packages built from the same tree and with the same options, to produce
 identical results bit by bit. This option should be combined with ASLR and
 PKGSRC_MKPIE to avoid predictable address offsets for attackers attempting to
 exploit security vulnerabilities.
 More details can be found here:
   * Reproducible Builds - a set of software development practices that create
     an independently-verifiable path from source to binary code
 More work likely needs to be done before pkgsrc is fully reproducible.
 B.1.2.2. PKGSRC_USE_STACK_CHECK
 This uses -fstack-check with GCC for another stack protection mitigation.
 It asks the compiler to generate code verifying that it does not corrupt the
 stack. According to GCC's manual page, this is really only useful for
 multi-threaded programs.
 B.2. Caveats
 B.2.1. Problems with PKGSRC_MKPIE
 B.2.1.1. Packages failing to build