Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified)) by mollari.NetBSD.org (Postfix) with ESMTPS id 9B2D91A9239 for ; Sun, 13 Feb 2022 11:16:58 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 605) id CF70484E91; Sun, 13 Feb 2022 11:16:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 1502E84D82 for ; Sun, 13 Feb 2022 11:16:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id MIilE-Cm0Vpy for ; Sun, 13 Feb 2022 11:16:55 +0000 (UTC) Received: from cvs.NetBSD.org (ivanova.NetBSD.org [IPv6:2001:470:a085:999:28c:faff:fe03:5984]) by mail.netbsd.org (Postfix) with ESMTP id E67E584CBC for ; Sun, 13 Feb 2022 11:16:54 +0000 (UTC) Received: by cvs.NetBSD.org (Postfix, from userid 500) id DDD24FB24; Sun, 13 Feb 2022 11:16:54 +0000 (UTC) Content-Transfer-Encoding: 7bit Content-Type: multipart/mixed; boundary="_----------=_1644751014214290" MIME-Version: 1.0 Date: Sun, 13 Feb 2022 11:16:54 +0000 From: "Nia Alarie" Subject: CVS commit: pkgsrc/doc To: pkgsrc-changes@NetBSD.org Reply-To: nia@netbsd.org X-Mailer: log_accum Message-Id: <20220213111654.DDD24FB24@cvs.NetBSD.org> Sender: pkgsrc-changes-owner@NetBSD.org List-Id: Precedence: bulk List-Unsubscribe: This is a multi-part message in MIME format. --_----------=_1644751014214290 Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII" Module Name: pkgsrc Committed By: nia Date: Sun Feb 13 11:16:54 UTC 2022 Modified Files: pkgsrc/doc: pkgsrc.html pkgsrc.txt Log Message: doc/pkgsrc.*: regen To generate a diff of this commit: cvs rdiff -u -r1.333 -r1.334 pkgsrc/doc/pkgsrc.html cvs rdiff -u -r1.331 -r1.332 pkgsrc/doc/pkgsrc.txt Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. --_----------=_1644751014214290 Content-Disposition: inline Content-Length: 26830 Content-Transfer-Encoding: binary Content-Type: text/x-diff; charset=utf-8 Modified files: Index: pkgsrc/doc/pkgsrc.html diff -u pkgsrc/doc/pkgsrc.html:1.333 pkgsrc/doc/pkgsrc.html:1.334 --- pkgsrc/doc/pkgsrc.html:1.333 Fri Feb 11 08:06:21 2022 +++ pkgsrc/doc/pkgsrc.html Sun Feb 13 11:16:54 2022 @@ -221,10 +221,9 @@ builds)
14.1. Common types of packages
-
14.1.1. Perl modules
-
14.1.2. Python modules and programs
-
14.1.3. R packages
-
14.1.4. TeXlive packages
+
14.1.1. Python modules and programs
+
14.1.2. R packages
+
14.1.3. TeXlive packages
14.2. Examples
14.2.1. How the www/nvu package came into pkgsrc
@@ -3189,10 +3188,9 @@ anymore, you can remove that file and ru
14.1. Common types of packages
-
14.1.1. Perl modules
-
14.1.2. Python modules and programs
-
14.1.3. R packages
-
14.1.4. TeXlive packages
+
14.1.1. Python modules and programs
+
14.1.2. R packages
+
14.1.3. TeXlive packages
14.2. Examples
14.2.1. How the www/nvu package came into pkgsrc
@@ -5066,10 +5064,9 @@ ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site
14.1. Common types of packages
-
14.1.1. Perl modules
-
14.1.2. Python modules and programs
-
14.1.3. R packages
-
14.1.4. TeXlive packages
+
14.1.1. Python modules and programs
+
14.1.2. R packages
+
14.1.3. TeXlive packages
14.2. Examples
14.2.1. How the www/nvu package came into pkgsrc
@@ -5093,20 +5090,16 @@ install the utilities

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 your package and change into -it:

-
$ mkdir category/package
-$ cd category/package
+your own (maybe called local). Change into that +category directory:

+
$ cd category
  • -

    Run the program url2pkg, which will ask -you for a URL. Enter the URL of the distribution file (in most cases a -.tar.gz file) and watch how the basic ingredients -of your package are created automatically. The distribution file is -extracted automatically to fill in some details in the -Makefile that would otherwise have to be done -manually:

    +

    Run the program url2pkg, passing as +argument the URL of the distribution file (in most cases a +.tar.gz file). This will download the distribution +file and create the necessary files of the package, based on what's in +the distribution file:

    $ url2pkg https://www.example.org/packages/package-1.0.tar.gz
  • @@ -5120,7 +5113,7 @@ 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 +

    If you just need binaries from a dependent package, add a DEPENDS 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 @@ -5130,13 +5123,13 @@ instead of DEPENDS The difference between TOOL_DEPENDS and BUILD_DEPENDS occurs when cross-compiling: TOOL_DEPENDS are native -packages, i.e. packages for the architecture where the package -is built; +packages, i.e. packages for the platform where the package is built; BUILD_DEPENDS are target -packages, i.e. packages for the architecture for which the package -is built. There is also TEST_DEPENDS, which is used -to specify a dependency used only for testing the resulting package -built, using the upstream project's included test suite. +packages, i.e. packages for the platform for which the package +is built. There is also TEST_DEPENDS, which +specifies a dependency used only for testing the resulting package +built, using the upstream project's included test suite, on the native +platform. Your package may then look like this:

     [...]
@@ -5162,18 +5155,19 @@ find instructions for the most common ca
 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 been saved in the working -directory, which may become wrong after you edited the +files and other system information have been saved in the working +directory, which may have become outdated after 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
+
    If the extracted files from the package need to be fixed, run
+multiple rounds of these commands:
    
+
    $ bmake
 $ pkgvi ${WRKSRC}/some/file/that/does/not/compile
 $ mkpatches
-$ make mps
-$ make clean
    
+$ bmake mps
+$ bmake clean

  • When the package builds fine, the next step is to install the package. Run bmake install and hope that @@ -5192,12 +5186,11 @@ empty list of files. To fix this, run 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 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.

    • +

  • 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.

    • @@ -5205,13 +5198,7 @@ and the whole package is created as inte 14.1. Common types of packages

    -14.1.1. Perl modules

    -

    Simple Perl modules are handled automatically by -url2pkg, including dependencies.

    -
    -
    -

    -14.1.2. Python modules and programs

    +14.1.1. Python modules and programs

    Python modules and programs packages are easily created using a set of predefined variables.

    @@ -5266,7 +5253,7 @@ of supported packages.

    -14.1.3. R packages

    +14.1.2. R packages

    Simple R packages from CRAN are handled automatically by R2pkg, which is available in pkgtools/R2pkg. @@ -5281,7 +5268,7 @@ package should be reviewed for correctne

    -14.1.4. TeXlive packages

    +14.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 @@ -11035,33 +11022,9 @@ Currently, this means NetBSD on x86, ARM PKGSRC_MKPIE was enabled by default after the pkgsrc-2021Q3 branch.

    - -
    -

    -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: -

    -
    -

    -More work likely needs to be done before pkgsrc is fully reproducible. -

    -
    -
    -

    -B.1.2.2. PKGSRC_USE_RELRO

    +B.1.1.4. PKGSRC_USE_RELRO

    This also makes the exploitation of some security vulnerabilities more difficult in some cases. @@ -11069,7 +11032,7 @@ 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 sections precede the program's own data sections, and non-PLT GOT is read-only;

    • @@ -11090,9 +11053,33 @@ More details can be found here: Hardening ELF binaries using Relocation Read-Only (RELRO)

    + +
    +

    +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: +

    +
    +

    +More work likely needs to be done before pkgsrc is fully reproducible. +

    +

    -B.1.2.3. PKGSRC_USE_STACK_CHECK

    +B.1.2.2. PKGSRC_USE_STACK_CHECK

    This uses -fstack-check with GCC for another stack protection mitigation. Index: pkgsrc/doc/pkgsrc.txt diff -u pkgsrc/doc/pkgsrc.txt:1.331 pkgsrc/doc/pkgsrc.txt:1.332 --- pkgsrc/doc/pkgsrc.txt:1.331 Fri Feb 11 08:06:21 2022 +++ pkgsrc/doc/pkgsrc.txt Sun Feb 13 11:16:54 2022 @@ -205,10 +205,9 @@ II. The pkgsrc developer's guide 14.1. Common types of packages - 14.1.1. Perl modules - 14.1.2. Python modules and programs - 14.1.3. R packages - 14.1.4. TeXlive packages + 14.1.1. Python modules and programs + 14.1.2. R packages + 14.1.3. TeXlive packages 14.2. Examples @@ -2731,10 +2730,9 @@ Table of Contents 14.1. Common types of packages - 14.1.1. Perl modules - 14.1.2. Python modules and programs - 14.1.3. R packages - 14.1.4. TeXlive packages + 14.1.1. Python modules and programs + 14.1.2. R packages + 14.1.3. TeXlive packages 14.2. Examples @@ -4215,10 +4213,9 @@ Table of Contents 14.1. Common types of packages - 14.1.1. Perl modules - 14.1.2. Python modules and programs - 14.1.3. R packages - 14.1.4. TeXlive packages + 14.1.1. Python modules and programs + 14.1.2. R packages + 14.1.3. TeXlive packages 14.2. Examples @@ -4238,17 +4235,14 @@ package involves only a few steps. 3. 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 - your package and change into it: + called local). Change into that category directory: - $ mkdir category/package - $ cd category/package + $ cd category - 4. Run the program url2pkg, which will ask you for a URL. Enter the URL of the - distribution file (in most cases a .tar.gz file) and watch how the basic - ingredients of your package are created automatically. The distribution - file is extracted automatically to fill in some details in the Makefile - that would otherwise have to be done manually: + 4. Run the program url2pkg, passing as argument the URL of the distribution + file (in most cases a .tar.gz file). This will download the distribution + file and create the necessary files of the package, based on what's in the + distribution file: $ url2pkg https://www.example.org/packages/package-1.0.tar.gz @@ -4261,18 +4255,18 @@ package involves only a few steps. 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 - 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 TOOL_DEPENDS or BUILD_DEPENDS instead of DEPENDS. The difference - between TOOL_DEPENDS and BUILD_DEPENDS occurs when cross-compiling: - TOOL_DEPENDS are native packages, i.e. packages for the architecture where - the package is built; BUILD_DEPENDS are target packages, i.e. packages for - the architecture for which the package is built. There is also - TEST_DEPENDS, which is used to specify a dependency used only for testing - the resulting package built, using the upstream project's included test - suite. Your package may then look like this: + If you just need binaries from a dependent package, add a DEPENDS 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 TOOL_DEPENDS or BUILD_DEPENDS instead of DEPENDS. The + difference between TOOL_DEPENDS and BUILD_DEPENDS occurs when + cross-compiling: TOOL_DEPENDS are native packages, i.e. packages for the + platform where the package is built; BUILD_DEPENDS are target packages, + i.e. packages for the platform for which the package is built. There is + also TEST_DEPENDS, which specifies a dependency used only for testing the + resulting package built, using the upstream project's included test suite, + on the native platform. Your package may then look like this: [...] @@ -4296,9 +4290,9 @@ package involves only a few steps. there, you can hopefully continue here. 8. 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 - been saved in the working directory, which may become wrong after you - edited the Makefile. + Besides these files, a lot of cache files and other system information have + been saved in the working directory, which may have become outdated after + you edited the Makefile. 9. 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. @@ -4306,11 +4300,11 @@ package involves only a few steps. 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 - $ make clean + $ bmake mps + $ bmake clean 10. When the package builds fine, the next step is to install the package. Run bmake install and hope that everything works. @@ -4327,26 +4321,18 @@ package involves only a few steps. deinstall and bmake install again. Now the package is registered with the list of files from PLIST. -14. Run bmake package to create a binary package from the set of installed - files. - -15. Run bmake clean update to run everything from above again in a single step, +14. 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. -16. Run pkglint to see if there's anything left to do. +15. Run pkglint to see if there's anything left to do. -17. Commit the package to pkgsrc-wip or main pkgsrc; see Chapter 23, Submitting +16. Commit the package to pkgsrc-wip or main pkgsrc; see Chapter 23, Submitting and Committing. 14.1. Common types of packages -14.1.1. Perl modules - -Simple Perl modules are handled automatically by url2pkg, including -dependencies. - -14.1.2. Python modules and programs +14.1.1. Python modules and programs Python modules and programs packages are easily created using a set of predefined variables. @@ -4386,7 +4372,7 @@ PYTHON_VERSIONED_DEPENDENCIES=dialog Look inside versioned_dependencies.mk for a list of supported packages. -14.1.3. R packages +14.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 @@ -4396,7 +4382,7 @@ file as part of each R package on CRAN. information and creates or updates a package in the canonical form. The resulting package should be reviewed for correctness. -14.1.4. TeXlive packages +14.1.3. TeXlive packages TeXlive packages from CTAN are handled automatically by texlive2pkg, which is available in pkgtools/texlive2pkg. @@ -9034,32 +9020,16 @@ PIE. Currently, this means NetBSD on x86 PKGSRC_MKPIE was enabled by default after the pkgsrc-2021Q3 branch. -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_RELRO +B.1.1.4. 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 - precede the program's own data sections, and non-PLT GOT is read-only; + * 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; * full: in addition to partial RELRO, every relocation is performed immediately when starting the program, allowing the entire GOT to be @@ -9073,7 +9043,24 @@ 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. --_----------=_1644751014214290--