Recent changes to this wiki:

add comments about kernel options for wm
Index: wikisrc/users/msaitoh/Comparison_of_implementations_of_Ethernet_drivers.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/msaitoh/Comparison_of_implementations_of_Ethernet_drivers.mdwn,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- wikisrc/users/msaitoh/Comparison_of_implementations_of_Ethernet_drivers.mdwn	18 Jan 2018 08:58:02 -0000	1.9
+++ wikisrc/users/msaitoh/Comparison_of_implementations_of_Ethernet_drivers.mdwn	18 Jan 2018 23:11:56 -0000	1.10
@@ -22,7 +22,7 @@
   <td>TX_LOCK(spin mutex) + sc_stopping flag</td>
   <td>CORE_LOCK(spin mutex)+sc_stopping flag</td>
   <td>use CORE_LOCK(spin mutex) and TX_LOCK(spin mutex) partially</td>
-  <td>Yes</td>
+  <td>Yes by default. It can be changed by kernel options. See wm.4.</td>
   <td>TX and RX differently</td>
   <td>TX_LOCK(mutex) and check sc_stopping in the beginning</td>
   <td>Yes</td>

wm(4) already use softint-based TX and RX.
Index: wikisrc/users/msaitoh/Comparison_of_implementations_of_Ethernet_drivers.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/msaitoh/Comparison_of_implementations_of_Ethernet_drivers.mdwn,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- wikisrc/users/msaitoh/Comparison_of_implementations_of_Ethernet_drivers.mdwn	20 Jul 2016 04:14:25 -0000	1.8
+++ wikisrc/users/msaitoh/Comparison_of_implementations_of_Ethernet_drivers.mdwn	18 Jan 2018 08:58:02 -0000	1.9
@@ -22,7 +22,7 @@
   <td>TX_LOCK(spin mutex) + sc_stopping flag</td>
   <td>CORE_LOCK(spin mutex)+sc_stopping flag</td>
   <td>use CORE_LOCK(spin mutex) and TX_LOCK(spin mutex) partially</td>
-  <td>No</td>
+  <td>Yes</td>
   <td>TX and RX differently</td>
   <td>TX_LOCK(mutex) and check sc_stopping in the beginning</td>
   <td>Yes</td>

Rephrase so it doesn't sound like the key is stored on the disk.
Index: wikisrc/security/cgdroot.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/security/cgdroot.mdwn,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- wikisrc/security/cgdroot.mdwn	10 Feb 2017 11:10:53 -0000	1.14
+++ wikisrc/security/cgdroot.mdwn	14 Jan 2018 04:12:25 -0000	1.15
@@ -19,7 +19,7 @@
 * a GENERIC kernel
 * the `cgdroot.kmod` kernel module
 * the configuration file for CGD, `cgd.conf`
-* the encryption key for the volume to start from, named after its partition (like `wd0f`)
+* the CGD parameters file for the volume, named after its partition (like `wd0f`), which determines how the encryption key is derived and verified
 
 Once loaded the memory disk mounts the `wd0a` partition onto `/etc/cgd`, and asks for the encryption passphrase as usual (with [[!template id=man name="cgdconfig" section="8"]]). If successful, the `cgd0a` volume configured is mounted on `/altroot`, and [[!template id=man name="init" section="8"]] is told via [[!template id=man name="sysctl" section="7"]] to chroot into this volume before actually booting. The system then starts normally.
 

Add a few words about what has been done already
Index: wikisrc/projects/project/cross-bootstrapping.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/cross-bootstrapping.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/projects/project/cross-bootstrapping.mdwn	6 Nov 2011 14:48:47 -0000	1.3
+++ wikisrc/projects/project/cross-bootstrapping.mdwn	13 Jan 2018 15:29:25 -0000	1.4
@@ -32,5 +32,8 @@
 This project requires good understanding of cross-development,
 some knowledge of NetBSD build process or ability to create cross-development toolchain,
 and familiarity with pkgsrc bootstrapping.
+
+Note: basic infrastructure for this exists as part of various previous
+GSoC projects. General testing is lacking.
 """
 ]]

user-destdir has been the default for a long time and most packages use it
Index: wikisrc/projects/project/pkgsrc-unpriv.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/pkgsrc-unpriv.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/projects/project/pkgsrc-unpriv.mdwn	6 Nov 2011 21:08:23 -0000	1.2
+++ wikisrc/projects/project/pkgsrc-unpriv.mdwn	13 Jan 2018 15:27:00 -0000	1.3
@@ -8,6 +8,7 @@
 
 category="pkgsrc"
 difficulty="medium"
+done_by="joerg"
 
 description="""
 To create packages that are usable by anyone, pkgsrc currently requires that

Index: wikisrc/projects/project/scsipi-locking.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/scsipi-locking.mdwn,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- wikisrc/projects/project/scsipi-locking.mdwn	16 Feb 2015 05:16:15 -0000	1.1
+++ wikisrc/projects/project/scsipi-locking.mdwn	13 Jan 2018 15:07:11 -0000	1.2
@@ -9,6 +9,7 @@
 category="filesystems"
 difficulty="medium"
 duration="1 month"
+done_by="mlelstv"
 
 description="""
 Currently the scsipi subsystem is kernel-locked.

Index: wikisrc/projects/project/pkgsrc-test-depends.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/pkgsrc-test-depends.mdwn,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- wikisrc/projects/project/pkgsrc-test-depends.mdwn	2 Jun 2016 05:26:30 -0000	1.1
+++ wikisrc/projects/project/pkgsrc-test-depends.mdwn	13 Jan 2018 12:50:12 -0000	1.2
@@ -9,6 +9,7 @@
 category="pkgsrc"
 difficulty="medium"
 duration="3-6 weeks"
+done_by="joerg"
 
 description="""
 

add link to head llvm builds
Index: wikisrc/tutorials/clang.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/clang.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/tutorials/clang.mdwn	31 Dec 2017 13:52:57 -0000	1.3
+++ wikisrc/tutorials/clang.mdwn	4 Jan 2018 20:45:01 -0000	1.4
@@ -37,3 +37,10 @@
 you can refrain from building gcc, by additionally adding:
 
     MKGCC=no
+
+# status
+
+On NetBSD-current, clang builds successfully on several architectures.
+These builds are with all three of the above flags enabled.
+
+https://releng.netbsd.org/builds/HEAD-llvm/

Add data. Promote sections
Index: wikisrc/pkgsrc/gcc.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc/gcc.mdwn,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- wikisrc/pkgsrc/gcc.mdwn	1 Jan 2018 23:27:13 -0000	1.11
+++ wikisrc/pkgsrc/gcc.mdwn	4 Jan 2018 20:37:58 -0000	1.12
@@ -10,7 +10,7 @@
 freely takes content from extensive mailinglist discussions, and
 attempts to follow the rough consensus that has emerged.
 
-## Base system gcc vs pkgsrc gcc
+# Base system gcc vs pkgsrc gcc
 
 Systems using gcc (e.g. NetBSD) have a compiler as /usr/bin/gcc, and
 this is usable by pkgsrc without any bootstrapping activity.  One can
@@ -36,7 +36,7 @@
     should be linked with the higher version because the support
     library is backwards compatible but not forward compatible.
 
-## Specific constraints and requirements
+# Specific constraints and requirements
 
 This section attempts to gather all the requirements.
 
@@ -71,7 +71,7 @@
 
   - The compiler selection logic should be understandable and not brittle.
 
-## Design
+# Design
 
 The above requirements could in theory be satisfied in many ways, but
 most of them are too complicated.  We present a design that aims to be
@@ -156,9 +156,9 @@
     linking with a C++ compiler.  This is not a change from the
     current situation.
 
-## Remaining issues
+# Remaining issues
 
-### gcc dependencies introduction
+## gcc dependencies introduction
 
 Because gcc can have dependencies, there could be packages built with
 the system compiler that are then later used with the chosen version.
@@ -179,14 +179,14 @@
 \todo: Consider failing if optins that we want one way are another,
 when bootstrapping.
 
-### managing gcc dependencies
+## managing gcc dependencies
 
 There are multiple paths forward.
 
 \todo Choose one.  Straw proposal is "Don't worry" and recursive
 variable for the initial implementation.
 
-#### Separate prefix
+### Separate prefix
 
 Build compilers in a separate prefix, or a subprefix, so that the
 compiler and the packages needed to build it will not be used by any
@@ -194,7 +194,7 @@
 package one way in bootstrap and another not in bootstrap, at the cost
 of two builds and writing the separate-prefix code.
 
-#### Don't worry
+### Don't worry
 
 Don't worry that packages used to bootstrap the needed compiler are
 compiled with an older compiler.  Don't worry that they might be
@@ -202,7 +202,7 @@
 deal with it.  This requires choosing an approach to omit compiler
 selection logic when building the compiler:
 
-##### Mark bootstrap packages
+#### Mark bootstrap packages
 
 Mark packages used to build gcc as PKGSRC_GCC_BOOTSTRAP=yes.
 Conditionalize this on OPSYS if necessary.  Don't force the compiler
@@ -210,14 +210,14 @@
 
 Alternatively, manage a per-OS list of packages in a central mk file.
 
-##### Pass a recursive variable
+#### Pass a recursive variable
 
 As above, but set PKGSRC_GCC_BOOTSTRAP=yes in the evniroment of the
 call to build the compiler, so that all dependencies inherit
 permission to skip compiler selection logic.  (Alternatively, use some
 other mechanism such as passing a make variable explicitly.)
 
-### Differing GCC and GXX versions
+## Differing GCC and GXX versions
 
 Perhaps it is a mistake to allow the chosen GCC and GXX versions to
 differ.  If we require them to be the same, then essentially all
@@ -225,7 +225,7 @@
 bootstrap the compiler.  For now, we allow them to differ and will
 permit the defaults to differ.
 
-### gcc versions and number of buildable packages
+## gcc versions and number of buildable packages
 
 A gcc version that is too old will not build a number of packages.
 Anything older than 4.8 fails for c++11.  4.8 fails on some c++11
@@ -246,7 +246,7 @@
 Therefore, the current answer to "What is the best version to use" is
 5.
 
-### Default versions for various systems
+## Default versions for various systems
 
 Note that if for any particular system's set of installed packages (or
 bulk build), a newer gcc has to be built, it does not hurt to have
@@ -278,7 +278,7 @@
 that it supports (almost all) C++14 programs.  Our current definiton
 of new enough is gcc 5.
 
-### Limited mixed versions
+## Limited mixed versions
 
 One approach would be to allow limited mixed versions, where
 individual programs could force a specific version to be bootstrapped
@@ -290,7 +290,7 @@
 too much complexity for avoiding building a newer compiler in limited
 situations.
 
-### Fortran
+## Fortran
 
 Fortran support is currently somewhat troubled..  It seems obvious to
 extend to PGKSRC_GFORTRAN_VERSION, and have that match
@@ -302,7 +302,7 @@
 
 \todo Discuss.
 
-### C++ libraries used by C programs
+## C++ libraries used by C programs
 
 The choice of one version for C++ and one for C (e.g. 5, 4.8 on
 netbsd-7) breaks down if a C program links against a library that is
@@ -314,7 +314,7 @@
 PKGSRC_GXX_VERSION to be used.  Or decide that this is a good reason
 to really just have one compiler version.
 
-## Path forward
+# Path forward
 
 (This assumes per-package marking of bootstrap packages, but is
 reasonably obviously extended to the other schemes.)
@@ -336,8 +336,22 @@
    and that PKGSRC_GXX_VERSION is the base system version if >= 5, and
    otherwise 5.  Implement these in platform.mk as they are tested.
 
-### Later steps
+## Later steps
 
  - Address fortran.  Probably add PKGSRC_GFORTRAN_VERSION, after
    determining how Fortran, C and C++ interact with library ABI
    compatibility.
+
+# Data
+
+This section has data points that are relevant to the discussion.
+
+## amd64/i386
+
+It is believed that pkgsrc gcc generally builds on these systems.
+gcc6 builds on netbsd-5/i386.
+
+## macppc
+
+On macppc, [lang/gcc5 fails on netsbd-6 and netbsd-7, but succeeds on
+netbsd-8](https://mail-index.netbsd.org/tech-pkg/2018/01/03/msg019260.html).

adjust nits about acceptbale versions
Index: wikisrc/pkgsrc/gcc.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc/gcc.mdwn,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- wikisrc/pkgsrc/gcc.mdwn	1 Jan 2018 23:18:19 -0000	1.10
+++ wikisrc/pkgsrc/gcc.mdwn	1 Jan 2018 23:27:13 -0000	1.11
@@ -255,12 +255,10 @@
 When the base system is old (e.g., gcc 4.5 in NetBSD 6, or 4.1, in
 NetBSD 5), then it is clear that a newer version must be built.  For
 these, PKGSRC_GXX_VERSION should default to a newish gcc, avoiding
-being so new as to cause building issues.  Currently, gcc5 is probably
-a good choice, with gcc6 compiling significantly but not vastly fewer
-packages.  PKGSRC_GCC_VERSION should probably default to the system
-version if it can build all C99 programs, or match PKGSRC_GXX_VERSION,
-if the system version is too old.  Perhaps gcc 4.5 would be used, but
-4.1 not used.  \todo Discuss.
+being so new as to cause building issues.  PKGSRC_GCC_VERSION should
+probably default to the system version if it can build all C99
+programs, or match PKGSRC_GXX_VERSION, if the system version is too
+old.  Perhaps gcc 4.5 would be used, but 4.1 not used.  \todo Discuss.
 
 When the base system is almost new enough, the decision about the
 default is more complicated.  A key example is gcc 4.8, found in
@@ -269,7 +267,7 @@
 firefox failing, as well as all c++14 programs.  Another is to choose
 4.9, but this makes little sense because c++14 programs will still
 fail, and the general rule of moving to the most recent
-generally-acceptable version applies, which currently leads to gcc6.
+generally-acceptable version applies, which currently leads to gcc5.
 This is in effect a declaration that "almost new enough" does not
 count as new enough.  Thus the plan for NetBSD 7 is to set
 PKGSRC_GCC_VERSION to 4.8 and PKGSRC_GXX_VERSION to 5.

Add Jason's package count data
Index: wikisrc/pkgsrc/gcc.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc/gcc.mdwn,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- wikisrc/pkgsrc/gcc.mdwn	31 Dec 2017 17:15:37 -0000	1.9
+++ wikisrc/pkgsrc/gcc.mdwn	1 Jan 2018 23:18:19 -0000	1.10
@@ -231,10 +231,17 @@
 Anything older than 4.8 fails for c++11.  4.8 fails on some c++11
 packages, such as firefox and glibmm.
 
-A version that is too new also fails to build packages.  Analyses
-posted to tech-pkg indicate that 5 is close to 4.9 in the number of
-packages built, and that moving to 6 causes hundreds of additional
-failures.
+A version that is too new also fails to build packages.  Jason Bacon
+posted counts to tech-pkg indicate that 5 is close to 4.8 in the
+number of packages built, and that moving to 6 causes hundreds of
+additional failures.  (Keep in mind that currently, building with 4.8
+will build 4.9 for firefox, but in the future will not.)
+
+    www/pkgsrc/packages/sharedapps/pkg-2017Q3/RHEL6-gcc48/All	16461
+    www/pkgsrc/packages/sharedapps/pkg-2017Q3/RHEL6-gcc6/All	15849
+
+    www/pkgsrc/packages/sharedapps/pkg-2017Q3/RHEL7-gcc48/All	16414
+    www/pkgsrc/packages/sharedapps/pkg-2017Q3/RHEL7-gcc5/All	16338
 
 Therefore, the current answer to "What is the best version to use" is
 5.

missed 2018 update
Index: wikisrc/templates/page.tmpl
===================================================================
RCS file: /cvsroot/wikisrc/templates/page.tmpl,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- wikisrc/templates/page.tmpl	18 Jun 2017 20:07:00 -0000	1.34
+++ wikisrc/templates/page.tmpl	1 Jan 2018 03:51:04 -0000	1.35
@@ -279,7 +279,7 @@
       <span class="footcopy"><a href="about/disclaimer.html">
         Disclaimer</a> |
         <span class="copyright">
-          Copyright &copy; 1994-2017 The NetBSD Foundation, Inc.
+          Copyright &copy; 1994-2018 The NetBSD Foundation, Inc.
         </span>
         ALL
         RIGHTS RESERVED. <br /> NetBSD<sup>&reg;</sup> is a registered

calendar update
--- /dev/null	2018-01-17 03:40:50.000000000 +0000
+++ wikisrc/archives/2018.mdwn	2018-01-17 03:45:22.000000000 +0000
@@ -0,0 +1 @@
+[[!calendar type=year year=2018 pages="internal(blog/*)"]]
--- /dev/null	2018-01-17 03:40:50.000000000 +0000
+++ wikisrc/archives/2018/01.mdwn	2018-01-17 03:45:22.000000000 +0000
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=01 year=2018 pages="internal(blog/*)"]]
+"""]]
+
+[[!inline pages="creation_month(01) and creation_year(2018) and internal(blog/*)" show=0 feeds=no reverse=yes]]
--- /dev/null	2018-01-17 03:40:50.000000000 +0000
+++ wikisrc/archives/2018/02.mdwn	2018-01-17 03:45:22.000000000 +0000
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=02 year=2018 pages="internal(blog/*)"]]
+"""]]
+
+[[!inline pages="creation_month(02) and creation_year(2018) and internal(blog/*)" show=0 feeds=no reverse=yes]]
--- /dev/null	2018-01-17 03:40:50.000000000 +0000
+++ wikisrc/archives/2018/03.mdwn	2018-01-17 03:45:22.000000000 +0000
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=03 year=2018 pages="internal(blog/*)"]]
+"""]]
+
+[[!inline pages="creation_month(03) and creation_year(2018) and internal(blog/*)" show=0 feeds=no reverse=yes]]
--- /dev/null	2018-01-17 03:40:50.000000000 +0000
+++ wikisrc/archives/2018/04.mdwn	2018-01-17 03:45:22.000000000 +0000
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=04 year=2018 pages="internal(blog/*)"]]
+"""]]
+
+[[!inline pages="creation_month(04) and creation_year(2018) and internal(blog/*)" show=0 feeds=no reverse=yes]]
--- /dev/null	2018-01-17 03:40:50.000000000 +0000
+++ wikisrc/archives/2018/05.mdwn	2018-01-17 03:45:22.000000000 +0000
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=05 year=2018 pages="internal(blog/*)"]]
+"""]]
+
+[[!inline pages="creation_month(05) and creation_year(2018) and internal(blog/*)" show=0 feeds=no reverse=yes]]
--- /dev/null	2018-01-17 03:40:50.000000000 +0000
+++ wikisrc/archives/2018/06.mdwn	2018-01-17 03:45:22.000000000 +0000
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=06 year=2018 pages="internal(blog/*)"]]
+"""]]
+
+[[!inline pages="creation_month(06) and creation_year(2018) and internal(blog/*)" show=0 feeds=no reverse=yes]]
--- /dev/null	2018-01-17 03:40:50.000000000 +0000
+++ wikisrc/archives/2018/07.mdwn	2018-01-17 03:45:22.000000000 +0000
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=07 year=2018 pages="internal(blog/*)"]]
+"""]]
+
+[[!inline pages="creation_month(07) and creation_year(2018) and internal(blog/*)" show=0 feeds=no reverse=yes]]
--- /dev/null	2018-01-17 03:40:50.000000000 +0000
+++ wikisrc/archives/2018/08.mdwn	2018-01-17 03:45:22.000000000 +0000
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=08 year=2018 pages="internal(blog/*)"]]
+"""]]
+
+[[!inline pages="creation_month(08) and creation_year(2018) and internal(blog/*)" show=0 feeds=no reverse=yes]]
--- /dev/null	2018-01-17 03:40:50.000000000 +0000
+++ wikisrc/archives/2018/09.mdwn	2018-01-17 03:45:22.000000000 +0000
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=09 year=2018 pages="internal(blog/*)"]]
+"""]]
+
+[[!inline pages="creation_month(09) and creation_year(2018) and internal(blog/*)" show=0 feeds=no reverse=yes]]
--- /dev/null	2018-01-17 03:40:50.000000000 +0000
+++ wikisrc/archives/2018/10.mdwn	2018-01-17 03:45:22.000000000 +0000
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=10 year=2018 pages="internal(blog/*)"]]
+"""]]
+
+[[!inline pages="creation_month(10) and creation_year(2018) and internal(blog/*)" show=0 feeds=no reverse=yes]]
--- /dev/null	2018-01-17 03:40:50.000000000 +0000
+++ wikisrc/archives/2018/11.mdwn	2018-01-17 03:45:22.000000000 +0000
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=11 year=2018 pages="internal(blog/*)"]]
+"""]]
+
+[[!inline pages="creation_month(11) and creation_year(2018) and internal(blog/*)" show=0 feeds=no reverse=yes]]
--- /dev/null	2018-01-17 03:40:50.000000000 +0000
+++ wikisrc/archives/2018/12.mdwn	2018-01-17 03:45:22.000000000 +0000
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=12 year=2018 pages="internal(blog/*)"]]
+"""]]
+
+[[!inline pages="creation_month(12) and creation_year(2018) and internal(blog/*)" show=0 feeds=no reverse=yes]]

Adjust based on list discussion
Index: wikisrc/pkgsrc/gcc.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc/gcc.mdwn,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- wikisrc/pkgsrc/gcc.mdwn	30 Dec 2017 02:01:59 -0000	1.8
+++ wikisrc/pkgsrc/gcc.mdwn	31 Dec 2017 17:15:37 -0000	1.9
@@ -18,7 +18,7 @@
 in a compiler within ${PREFIX}, e.g. /usr/pkg/gcc6/bin/gcc.  This
 compiler can then be used to compile other packages.
 
-The Issue with using base system gcc is typically that it is too old,
+The issue with using base system gcc is typically that it is too old,
 such as gcc 4.5 with NetBSD 6, which cannot compile c++11.  Another
 example is gcc 4.8 with NetBSD 7.  While this can compile most c++11
 programs, it cannot be used for firefox or glibmm (and therefore any
@@ -26,6 +26,7 @@
 
 Issues when using pkgsrc gcc are that
 
+  - on some platforms, pkgsrc gcc does not build and work
   - it must be bootstrapped, requiring compiling a number of packages
     with the system compiler
   - C++ packages that are linked together should be built with the
@@ -65,6 +66,9 @@
     clang, when set to use GCC, at least as well as the current
     scheme.  It is desirable for this logic to work on NetBSD 5.
 
+  - All systems should work at least as well as they do before
+    implementation of new compiler selection logic.
+
   - The compiler selection logic should be understandable and not brittle.
 
 ## Design
@@ -84,14 +88,20 @@
     4.9.
 
   - A user-settable variable PKGSRC_GCC_VERSION will declare the
-    version of gcc to be used for C programs, with an OS- and
-    version--specific default.
+    version of gcc to be used for C programs, with an OS-,
+    version- and architeture- specific default.
 
   - A user-settable variable PKGSRC_GXX_VERSION will declare the
-    version of gcc to be used for all C++ programs, again with an OS-
-    and version-specific default.  It must be at least
+    version of gcc to be used for all C++ programs, again with an OS-,
+    version- and architeture-specific default.  It must be at least
     PKGSRC_GCC_VERSION.
 
+  - If PKGSRC_GCC_VERSION and PKGSRC_GXX_VERSION are not set, the
+    system will behave much as before.  As a possible exception,
+    builds may still fail if the required version is greater than the
+    base system version.  So far the only known reason to avoid
+    setting these variable is if pkgsrc gcc cannot be built.
+
   - Each of c99, c++, c++11, and c++14 will be associated with a
     minimum gcc version, such that almost all programs declaring that
     language can be built with that version.  (This avoids issues of
@@ -132,6 +142,13 @@
     approach is possible inconsistency with gcc's dependencies being
     built with the base compiler and used later.
 
+    As an alternative, we store lists of bootstrap packages in a
+    variable, because it will vary with OS and version, and with
+    PREFER_PKGSRC settings.
+
+    As a third alternative, we pass a GCC_BOOTSTRAPPING variable
+    recursively.  This is easier but less consistent.
+
   - We hope that the chosen version can be built using the base system
     version, and hope to avoid multi-stage bootstrapping.
 
@@ -149,7 +166,9 @@
 will be less serious than the current situation where all c++11
 programs fail to build on NetBSD 6).
 
-\todo: Change gcc 4.8 and 4.9 to enable gcc-inplace-math by default.
+\todo: Perhaps change gcc 4.8 and 4.9 to enable gcc-inplace-math by
+default.  Perhaps decide that if we want to build gcc, we want to
+build 5 or 6, and 4.9 is no longer of interest as a bootstrap target.
 
 \todo: Analyze what build-time and install-time dependencies actually
 exist.  Include old GNU/Linux in this analysis.
@@ -220,8 +239,6 @@
 Therefore, the current answer to "What is the best version to use" is
 5.
 
-\todo Check this with Jason Bacon.
-
 ### Default versions for various systems
 
 Note that if for any particular system's set of installed packages (or
@@ -280,7 +297,7 @@
 
 \todo Discuss.
 
-### C++ programs used by C programs
+### C++ libraries used by C programs
 
 The choice of one version for C++ and one for C (e.g. 5, 4.8 on
 netbsd-7) breaks down if a C program links against a library that is
@@ -294,6 +311,9 @@
 
 ## Path forward
 
+(This assumes per-package marking of bootstrap packages, but is
+reasonably obviously extended to the other schemes.)
+
  - Modify all gcc packages to have minimal dependencies, and to add
    PKGSRC_GCC_BOOTSTRAP.
 
@@ -303,14 +323,16 @@
  - Modify the compiler selection logic for LANGUAGES= to fail if
    PKGSRC_GCC_VERSION/PKGSRC_GXX_VERSION is not new enough.
 
- - Modify the compiler selection logic for GCC_REQD to fail if the
-   version of GCC/GXX is not new enough.
+ - Modify the compiler selection logic for GCC_REQD to fail if
+   PKGSRC_GCC_VERSION/PKGSRC_GXX_VERSION is not new enough.
 
  - Decide on defaults.  The straw proposal is that PKGSRC_GCC_VERSION
    is the base system version if >= 4.5 (or 4.4?), and otherwise 5,
    and that PKGSRC_GXX_VERSION is the base system version if >= 5, and
-   otherwise 5.
+   otherwise 5.  Implement these in platform.mk as they are tested.
 
 ### Later steps
 
- - Address fortran.
+ - Address fortran.  Probably add PKGSRC_GFORTRAN_VERSION, after
+   determining how Fortran, C and C++ interact with library ABI
+   compatibility.

Fix typo. Remove todo, setting HAVE_LLVM is enough.
Index: wikisrc/tutorials/clang.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/clang.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/tutorials/clang.mdwn	30 Dec 2017 18:40:29 -0000	1.2
+++ wikisrc/tutorials/clang.mdwn	31 Dec 2017 13:52:57 -0000	1.3
@@ -1,4 +1,4 @@
-This page explainsse how to use clang with the NetBSD base system.
+This page explains how to use clang with the NetBSD base system.
 See also [how to use clang to build packages](../pkgsrc/clang/).
 
 \todo: review this entire page.
@@ -31,9 +31,6 @@
 
 to cause clang to be used instead of gcc.
 
-\todo It is not 100% clear if this stage works, vs having to set
-MKGCC=no also.
-
 # Not building gcc
 
 On a system that builds clang and uses it to build the base system,

Fix wiki link
Index: wikisrc/tutorials/clang.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/clang.mdwn,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- wikisrc/tutorials/clang.mdwn	30 Dec 2017 18:34:03 -0000	1.1
+++ wikisrc/tutorials/clang.mdwn	30 Dec 2017 18:40:29 -0000	1.2
@@ -1,5 +1,5 @@
 This page explainsse how to use clang with the NetBSD base system.
-See also [how to use clang to build packages](tutorials/pkgsrc/clang/).
+See also [how to use clang to build packages](../pkgsrc/clang/).
 
 \todo: review this entire page.
 

fix wiki link harder
Index: wikisrc/tutorials/pkgsrc/clang.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/pkgsrc/clang.mdwn,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- wikisrc/tutorials/pkgsrc/clang.mdwn	30 Dec 2017 18:38:31 -0000	1.7
+++ wikisrc/tutorials/pkgsrc/clang.mdwn	30 Dec 2017 18:39:12 -0000	1.8
@@ -1,6 +1,6 @@
 # Using clang from the base system
 
-See [clang and the base system](../clang/).
+See [clang and the base system](../../clang/).
 
 When you have a NetBSD built with at least MKLLVM=yes, you can set
 

fix wiki link
Index: wikisrc/tutorials/pkgsrc/clang.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/pkgsrc/clang.mdwn,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- wikisrc/tutorials/pkgsrc/clang.mdwn	30 Dec 2017 18:37:57 -0000	1.6
+++ wikisrc/tutorials/pkgsrc/clang.mdwn	30 Dec 2017 18:38:31 -0000	1.7
@@ -1,6 +1,6 @@
 # Using clang from the base system
 
-See [clang and the base system](tutorials/clang/).
+See [clang and the base system](../clang/).
 
 When you have a NetBSD built with at least MKLLVM=yes, you can set
 

Clarify base requirements
Index: wikisrc/tutorials/pkgsrc/clang.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/pkgsrc/clang.mdwn,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- wikisrc/tutorials/pkgsrc/clang.mdwn	30 Dec 2017 18:36:47 -0000	1.5
+++ wikisrc/tutorials/pkgsrc/clang.mdwn	30 Dec 2017 18:37:57 -0000	1.6
@@ -17,9 +17,9 @@
 # Using clang from pkgsrc
 
 You can build clang from pkgsrc (lang/clang).  However, it needs
-libstdc++ from the base system, at least from gcc 4.8 or higher.  It
-also depends on cmake, which requires c++11, which needs gcc 4.8 or
-higher.  So this will not work on NetBSD <= 6.
+libstdc++ from the base system, and needs gcc 4.8 or higher.  It also
+depends on cmake, which requires c++11, which needs gcc 4.8 or higher.
+So this will not work on NetBSD <= 6.
 
 Once built, you should (\todo test this) be able to set:
 

Refer to base clang directions
Index: wikisrc/tutorials/pkgsrc/clang.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/pkgsrc/clang.mdwn,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- wikisrc/tutorials/pkgsrc/clang.mdwn	30 Dec 2017 17:58:58 -0000	1.4
+++ wikisrc/tutorials/pkgsrc/clang.mdwn	30 Dec 2017 18:36:47 -0000	1.5
@@ -1,17 +1,8 @@
 # Using clang from the base system
 
-When building NetBSD, you can set
+See [clang and the base system](tutorials/clang/).
 
-    MKLLVM=yes
-
-to also build clang and install it, and additionally
-
-    HAVE_LLVM=yes
-    MKGCC=no
-
-if you want to use it to compile NetBSD itself during build.sh.
-
-When you have a NetBSD compiled this way, you can set
+When you have a NetBSD built with at least MKLLVM=yes, you can set
 
     PKGSRC_COMPILER=       clang
     CLANGBASE=             /usr

move clang page to tutorials
--- wikisrc/clang.mdwn	2018-01-17 03:45:24.000000000 +0000
+++ /dev/null	2018-01-17 03:40:50.000000000 +0000
@@ -1,42 +0,0 @@
-This page explainsse how to use clang with the NetBSD base system.
-See also [how to use clang to build packages](tutorials/pkgsrc/clang/).
-
-\todo: review this entire page.
-
-Since NetBSD 6, the base system has included clang, but it is not
-built or used by default.
-
-\todo Explain if there are or aren't plans to enable it by default, or
-to switch, keeping in mind that compiler support varies by architecture.
-
-There are three steps that can be taken with clang; each depends on the previous.
-
-# Building clang
-
-To build clang as part of the build, set
-
-    MKLLVM=yes
-
-in mk.conf before running "build.sh release".
-
-This will build clang, which will appear in /usr/bin/clang and also
-build libraries that clang needs.  NetBSD itself will not be built
-with clang, but you will be able to use clang to build programs.
-
-# Using clang to build the NetBSD base system
-
-In addition, set
-
-    HAVE_LLVM=yes
-
-to cause clang to be used instead of gcc.
-
-\todo It is not 100% clear if this stage works, vs having to set
-MKGCC=no also.
-
-# Not building gcc
-
-On a system that builds clang and uses it to build the base system,
-you can refrain from building gcc, by additionally adding:
-
-    MKGCC=no
--- /dev/null	2018-01-17 03:40:50.000000000 +0000
+++ wikisrc/tutorials/clang.mdwn	2018-01-17 03:45:24.000000000 +0000
@@ -0,0 +1,42 @@
+This page explainsse how to use clang with the NetBSD base system.
+See also [how to use clang to build packages](tutorials/pkgsrc/clang/).
+
+\todo: review this entire page.
+
+Since NetBSD 6, the base system has included clang, but it is not
+built or used by default.
+
+\todo Explain if there are or aren't plans to enable it by default, or
+to switch, keeping in mind that compiler support varies by architecture.
+
+There are three steps that can be taken with clang; each depends on the previous.
+
+# Building clang
+
+To build clang as part of the build, set
+
+    MKLLVM=yes
+
+in mk.conf before running "build.sh release".
+
+This will build clang, which will appear in /usr/bin/clang and also
+build libraries that clang needs.  NetBSD itself will not be built
+with clang, but you will be able to use clang to build programs.
+
+# Using clang to build the NetBSD base system
+
+In addition, set
+
+    HAVE_LLVM=yes
+
+to cause clang to be used instead of gcc.
+
+\todo It is not 100% clear if this stage works, vs having to set
+MKGCC=no also.
+
+# Not building gcc
+
+On a system that builds clang and uses it to build the base system,
+you can refrain from building gcc, by additionally adding:
+
+    MKGCC=no

Add page about clang and the base system
--- /dev/null	2018-01-17 03:40:50.000000000 +0000
+++ wikisrc/clang.mdwn	2018-01-17 03:45:24.000000000 +0000
@@ -0,0 +1,42 @@
+This page explainsse how to use clang with the NetBSD base system.
+See also [how to use clang to build packages](tutorials/pkgsrc/clang/).
+
+\todo: review this entire page.
+
+Since NetBSD 6, the base system has included clang, but it is not
+built or used by default.
+
+\todo Explain if there are or aren't plans to enable it by default, or
+to switch, keeping in mind that compiler support varies by architecture.
+
+There are three steps that can be taken with clang; each depends on the previous.
+
+# Building clang
+
+To build clang as part of the build, set
+
+    MKLLVM=yes
+
+in mk.conf before running "build.sh release".
+
+This will build clang, which will appear in /usr/bin/clang and also
+build libraries that clang needs.  NetBSD itself will not be built
+with clang, but you will be able to use clang to build programs.
+
+# Using clang to build the NetBSD base system
+
+In addition, set
+
+    HAVE_LLVM=yes
+
+to cause clang to be used instead of gcc.
+
+\todo It is not 100% clear if this stage works, vs having to set
+MKGCC=no also.
+
+# Not building gcc
+
+On a system that builds clang and uses it to build the base system,
+you can refrain from building gcc, by additionally adding:
+
+    MKGCC=no

update notes
Index: wikisrc/tutorials/pkgsrc/clang.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/pkgsrc/clang.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/tutorials/pkgsrc/clang.mdwn	30 Dec 2017 17:51:05 -0000	1.3
+++ wikisrc/tutorials/pkgsrc/clang.mdwn	30 Dec 2017 17:58:58 -0000	1.4
@@ -25,13 +25,18 @@
 
 # Using clang from pkgsrc
 
-You can build clang from pkgsrc (lang/clang).  However, it need
-libstdc++ from the base system, and thus this will only work on
-systems that natively have gcc if the version is 4.8 or higher.
+You can build clang from pkgsrc (lang/clang).  However, it needs
+libstdc++ from the base system, at least from gcc 4.8 or higher.  It
+also depends on cmake, which requires c++11, which needs gcc 4.8 or
+higher.  So this will not work on NetBSD <= 6.
 
 Once built, you should (\todo test this) be able to set:
 
     PKGSRC_COMPILER=       clang
     CLANGBASE=             /usr/pkg
 
+and perhaps
+
+    HAVE_LLVM=             yes
+
 The caveats above about using a consistent compiler apply.

Add notes about pkgsrc clang
Index: wikisrc/tutorials/pkgsrc/clang.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/pkgsrc/clang.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/tutorials/pkgsrc/clang.mdwn	4 Dec 2017 00:43:22 -0000	1.2
+++ wikisrc/tutorials/pkgsrc/clang.mdwn	30 Dec 2017 17:51:05 -0000	1.3
@@ -1,3 +1,5 @@
+# Using clang from the base system
+
 When building NetBSD, you can set
 
     MKLLVM=yes
@@ -18,3 +20,18 @@
 in your /etc/mk.conf to use it. You must do that before building
 packages, especially libtool. It's usually fine to link binaries
 generated from gcc to those generated with clang or vice versa.
+
+\todo: Explain why HAVE_LLVM is set to use clang for pkgsrc.
+
+# Using clang from pkgsrc
+
+You can build clang from pkgsrc (lang/clang).  However, it need
+libstdc++ from the base system, and thus this will only work on
+systems that natively have gcc if the version is 4.8 or higher.
+
+Once built, you should (\todo test this) be able to set:
+
+    PKGSRC_COMPILER=       clang
+    CLANGBASE=             /usr/pkg
+
+The caveats above about using a consistent compiler apply.

Add tutorials links
Index: wikisrc/pkgsrc.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc.mdwn,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- wikisrc/pkgsrc.mdwn	26 Nov 2017 00:05:58 -0000	1.6
+++ wikisrc/pkgsrc.mdwn	30 Dec 2017 17:38:29 -0000	1.7
@@ -17,6 +17,10 @@
 
 pkgsrc supports a [number of exploit mitigation techniques](hardening/)
 
+## Unordered list of pkgsrc tutorials
+
+[[!map pages="tutorials/pkgsrc/* and !*.css"]]
+
 ## Unordered list of all pkgsrc wiki pages
 
 [[!map pages="pkgsrc/* and !*.css"]]

Add central pkg-exclusion suggestion
from abs@
Members: 
	pkgsrc/gcc.mdwn:1.7->1.8 

Index: wikisrc/pkgsrc/gcc.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc/gcc.mdwn,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- wikisrc/pkgsrc/gcc.mdwn	30 Dec 2017 01:29:49 -0000	1.7
+++ wikisrc/pkgsrc/gcc.mdwn	30 Dec 2017 02:01:59 -0000	1.8
@@ -189,6 +189,8 @@
 Conditionalize this on OPSYS if necessary.  Don't force the compiler
 if this is set.
 
+Alternatively, manage a per-OS list of packages in a central mk file.
+
 ##### Pass a recursive variable
 
 As above, but set PKGSRC_GCC_BOOTSTRAP=yes in the evniroment of the

pkgsrc/gcc: Float notion of failing for unexpected options in bootstrap
From Edgar Fuss in private mail.
Members: 
	pkgsrc/gcc.mdwn:1.6->1.7 

Index: wikisrc/pkgsrc/gcc.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc/gcc.mdwn,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- wikisrc/pkgsrc/gcc.mdwn	30 Dec 2017 01:26:56 -0000	1.6
+++ wikisrc/pkgsrc/gcc.mdwn	30 Dec 2017 01:29:49 -0000	1.7
@@ -157,6 +157,9 @@
 \todo: Consider if dropping nls would help.  (On NetBSD, it seems that
 base system libraries are used, so it would not help.)
 
+\todo: Consider failing if optins that we want one way are another,
+when bootstrapping.
+
 ### managing gcc dependencies
 
 There are multiple paths forward.

pkgsrc/gcc: Edit and extend
Some changes were inspired by comments from Edgar Fuss.
Members: 
	pkgsrc/gcc.mdwn:1.5->1.6 

Index: wikisrc/pkgsrc/gcc.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc/gcc.mdwn,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- wikisrc/pkgsrc/gcc.mdwn	26 Nov 2017 15:43:57 -0000	1.5
+++ wikisrc/pkgsrc/gcc.mdwn	30 Dec 2017 01:26:56 -0000	1.6
@@ -19,7 +19,10 @@
 compiler can then be used to compile other packages.
 
 The Issue with using base system gcc is typically that it is too old,
-such as gcc 4.5 with NetBSD 6, which cannot compile c++11.
+such as gcc 4.5 with NetBSD 6, which cannot compile c++11.  Another
+example is gcc 4.8 with NetBSD 7.  While this can compile most c++11
+programs, it cannot be used for firefox or glibmm (and therefore any
+package that links against glibmm).
 
 Issues when using pkgsrc gcc are that
 
@@ -84,9 +87,10 @@
     version of gcc to be used for C programs, with an OS- and
     version--specific default.
 
-  - A user-settable variable PKGSRC_GXX_VERSION will declare the version of gcc to
-    be used for all C++ programs, again with an OS- and
-    version-specific default.  It must be at least PKGSRC_GCC_VERSION.
+  - A user-settable variable PKGSRC_GXX_VERSION will declare the
+    version of gcc to be used for all C++ programs, again with an OS-
+    and version-specific default.  It must be at least
+    PKGSRC_GCC_VERSION.
 
   - Each of c99, c++, c++11, and c++14 will be associated with a
     minimum gcc version, such that almost all programs declaring that
@@ -137,7 +141,7 @@
 
 ## Remaining issues
 
-### gcc dependencies
+### gcc dependencies introduction
 
 Because gcc can have dependencies, there could be packages built with
 the system compiler that are then later used with the chosen version.
@@ -145,11 +149,49 @@
 will be less serious than the current situation where all c++11
 programs fail to build on NetBSD 6).
 
+\todo: Change gcc 4.8 and 4.9 to enable gcc-inplace-math by default.
+
 \todo: Analyze what build-time and install-time dependencies actually
-exist.
+exist.  Include old GNU/Linux in this analysis.
+
+\todo: Consider if dropping nls would help.  (On NetBSD, it seems that
+base system libraries are used, so it would not help.)
+
+### managing gcc dependencies
+
+There are multiple paths forward.
+
+\todo Choose one.  Straw proposal is "Don't worry" and recursive
+variable for the initial implementation.
+
+#### Separate prefix
+
+Build compilers in a separate prefix, or a subprefix, so that the
+compiler and the packages needed to build it will not be used by any
+normal packages.  This completely avoids the issue of building a
+package one way in bootstrap and another not in bootstrap, at the cost
+of two builds and writing the separate-prefix code.
+
+#### Don't worry
+
+Don't worry that packages used to bootstrap the needed compiler are
+compiled with an older compiler.  Don't worry that they might be
+different depending on build order.  If we have an actual problem,
+deal with it.  This requires choosing an approach to omit compiler
+selection logic when building the compiler:
+
+##### Mark bootstrap packages
+
+Mark packages used to build gcc as PKGSRC_GCC_BOOTSTRAP=yes.
+Conditionalize this on OPSYS if necessary.  Don't force the compiler
+if this is set.
 
-\todo: Discuss adjusting options to minimize dependencies, including
-gcc-inplace-math and nls.
+##### Pass a recursive variable
+
+As above, but set PKGSRC_GCC_BOOTSTRAP=yes in the evniroment of the
+call to build the compiler, so that all dependencies inherit
+permission to skip compiler selection logic.  (Alternatively, use some
+other mechanism such as passing a make variable explicitly.)
 
 ### Differing GCC and GXX versions
 
@@ -159,6 +201,22 @@
 bootstrap the compiler.  For now, we allow them to differ and will
 permit the defaults to differ.
 
+### gcc versions and number of buildable packages
+
+A gcc version that is too old will not build a number of packages.
+Anything older than 4.8 fails for c++11.  4.8 fails on some c++11
+packages, such as firefox and glibmm.
+
+A version that is too new also fails to build packages.  Analyses
+posted to tech-pkg indicate that 5 is close to 4.9 in the number of
+packages built, and that moving to 6 causes hundreds of additional
+failures.
+
+Therefore, the current answer to "What is the best version to use" is
+5.
+
+\todo Check this with Jason Bacon.
+
 ### Default versions for various systems
 
 Note that if for any particular system's set of installed packages (or
@@ -189,8 +247,9 @@
 
 When the base system is new enough, e.g. gcc 5, 6 or 7 it should
 simply be used.  By "new enough", we mean that almost no programs in
-pkgsrc fail to build with it, which implies that it supports (almost
-all) C++14 programs.  Our current definiton of new enough is gcc 5.
+pkgsrc fail to build with it (because it is too old), which implies
+that it supports (almost all) C++14 programs.  Our current definiton
+of new enough is gcc 5.
 
 ### Limited mixed versions
 
@@ -209,7 +268,24 @@
 Fortran support is currently somewhat troubled..  It seems obvious to
 extend to PGKSRC_GFORTRAN_VERSION, and have that match
 PKGSRC_GCC_VERSION or PKGSRC_GXX_VERSION, but the Fortran situation is
-not worsened by the above design.  \todo Discuss.
+not worsened by the above design.
+
+When building a gcc version, we get gfortran.  Perhaps, because of
+fortran, we should require a single version, vs a C and a C++ version.
+
+\todo Discuss.
+
+### C++ programs used by C programs
+
+The choice of one version for C++ and one for C (e.g. 5, 4.8 on
+netbsd-7) breaks down if a C program links against a library that is
+written in C++ but provides a C API, because we still need the C++
+version's stdlib.
+
+\todo Define a variable for such packages to have in their buildlink3,
+which will not add c++ to USE_LANGUAGES but will force
+PKGSRC_GXX_VERSION to be used.  Or decide that this is a good reason
+to really just have one compiler version.
 
 ## Path forward
 

update for 7.1.1
Index: wikisrc/ports/acorn26.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/acorn26.mdwn,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- wikisrc/ports/acorn26.mdwn	15 Mar 2017 08:29:15 -0000	1.12
+++ wikisrc/ports/acorn26.mdwn	28 Dec 2017 06:15:13 -0000	1.13
@@ -1,6 +1,6 @@
 [[!template id=port
 port="acorn26"
-cur_rel="7.1"
+cur_rel="7.1.1"
 future_rel="8.0"
 pkg_rel="6.1"
 changes_cur="7.0"
Index: wikisrc/ports/acorn32.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/acorn32.mdwn,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- wikisrc/ports/acorn32.mdwn	30 Mar 2017 16:06:58 -0000	1.15
+++ wikisrc/ports/acorn32.mdwn	28 Dec 2017 06:15:13 -0000	1.16
@@ -1,6 +1,6 @@
 [[!template id=port
 port="acorn32"
-cur_rel="7.1"
+cur_rel="7.1.1"
 future_rel="8.0"
 pkg_rel="6.1"
 changes_cur="7.0"
Index: wikisrc/ports/algor.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/algor.mdwn,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- wikisrc/ports/algor.mdwn	30 Mar 2017 16:06:58 -0000	1.14
+++ wikisrc/ports/algor.mdwn	28 Dec 2017 06:15:13 -0000	1.15
@@ -1,6 +1,6 @@
 [[!template id=port
 port="algor"
-cur_rel="7.1"
+cur_rel="7.1.1"
 future_rel="8.0"
 pkg_rel="6.0"
 changes_cur="7.0"
Index: wikisrc/ports/alpha.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/alpha.mdwn,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- wikisrc/ports/alpha.mdwn	15 Mar 2017 08:29:15 -0000	1.12
+++ wikisrc/ports/alpha.mdwn	28 Dec 2017 06:15:13 -0000	1.13
@@ -1,6 +1,6 @@
 [[!template id=port
 port="alpha"
-cur_rel="7.1"
+cur_rel="7.1.1"
 pkg_rel="7.0"
 future_rel="8.0"
 changes_cur="7.0"
Index: wikisrc/ports/amd64.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/amd64.mdwn,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- wikisrc/ports/amd64.mdwn	30 Mar 2017 16:06:58 -0000	1.21
+++ wikisrc/ports/amd64.mdwn	28 Dec 2017 06:15:13 -0000	1.22
@@ -1,6 +1,6 @@
 [[!template id=port
 port="amd64"
-cur_rel="7.1"
+cur_rel="7.1.1"
 future_rel="8.0"
 pkg_rel="7.0"
 changes_cur="7.0"
Index: wikisrc/ports/amiga.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/amiga.mdwn,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- wikisrc/ports/amiga.mdwn	30 Mar 2017 16:06:58 -0000	1.16
+++ wikisrc/ports/amiga.mdwn	28 Dec 2017 06:15:13 -0000	1.17
@@ -1,6 +1,6 @@
 [[!template id=port
 port="amiga"
-cur_rel="7.1"
+cur_rel="7.1.1"
 future_rel="8.0"
 pkg_rel="6.0"
 changes_cur="7.0"
Index: wikisrc/ports/amigappc.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/amigappc.mdwn,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- wikisrc/ports/amigappc.mdwn	15 Mar 2017 08:29:15 -0000	1.12
+++ wikisrc/ports/amigappc.mdwn	28 Dec 2017 06:15:13 -0000	1.13
@@ -1,7 +1,7 @@
 [[!template id=port
 port="amigappc"
 port_alt="powerpc"
-cur_rel="7.1"
+cur_rel="7.1.1"
 pkg_rel="6.0"
 future_rel="8.0"
 changes_cur="7.0"
Index: wikisrc/ports/arc.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/arc.mdwn,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- wikisrc/ports/arc.mdwn	30 Mar 2017 16:06:58 -0000	1.13
+++ wikisrc/ports/arc.mdwn	28 Dec 2017 06:15:13 -0000	1.14
@@ -1,6 +1,6 @@
 [[!template id=port
 port="arc"
-cur_rel="7.1"
+cur_rel="7.1.1"
 future_rel="8.0"
 pkg_rel="6.0"
 changes_cur="7.0"
Index: wikisrc/ports/atari.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/atari.mdwn,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- wikisrc/ports/atari.mdwn	30 Mar 2017 16:06:58 -0000	1.11
+++ wikisrc/ports/atari.mdwn	28 Dec 2017 06:15:13 -0000	1.12
@@ -1,6 +1,6 @@
 [[!template id=port
 port="atari"
-cur_rel="7.1"
+cur_rel="7.1.1"
 future_rel="8.0"
 pkg_rel="6.0"
 changes_cur="7.0"
Index: wikisrc/ports/bebox.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/bebox.mdwn,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- wikisrc/ports/bebox.mdwn	15 Mar 2017 08:29:16 -0000	1.11
+++ wikisrc/ports/bebox.mdwn	28 Dec 2017 06:15:13 -0000	1.12
@@ -1,6 +1,6 @@
 [[!template id=port
 port="bebox"
-cur_rel="7.1"
+cur_rel="7.1.1"
 future_rel="8.0"
 pkg_rel="6.0"
 changes_cur="7.0"
Index: wikisrc/ports/cats.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/cats.mdwn,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- wikisrc/ports/cats.mdwn	30 Mar 2017 16:06:58 -0000	1.12
+++ wikisrc/ports/cats.mdwn	28 Dec 2017 06:15:13 -0000	1.13
@@ -1,6 +1,6 @@
 [[!template id=port
 port="cats"
-cur_rel="7.1"
+cur_rel="7.1.1"
 future_rel="8.0"
 pkg_rel="6.1"
 changes_cur="7.0"
Index: wikisrc/ports/cesfic.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/cesfic.mdwn,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- wikisrc/ports/cesfic.mdwn	15 Mar 2017 08:29:16 -0000	1.11
+++ wikisrc/ports/cesfic.mdwn	28 Dec 2017 06:15:13 -0000	1.12
@@ -1,7 +1,7 @@
 [[!template id=port
 port="cesfic"
 port_alt="m68k"
-cur_rel="7.1"
+cur_rel="7.1.1"
 future_rel="8.0"
 pkg_rel="6.0"
 changes_cur="7.0"
Index: wikisrc/ports/cobalt.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/cobalt.mdwn,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13

(Diff truncated)
update for 7.1.1
Index: wikisrc/ports.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports.mdwn,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- wikisrc/ports.mdwn	15 Mar 2017 08:29:15 -0000	1.12
+++ wikisrc/ports.mdwn	28 Dec 2017 06:13:10 -0000	1.13
@@ -20,14 +20,14 @@
 
 [[!table data="""
 Port		|CPU		|Machines						|Latest Release
-[[amd64]]	|x86_64		|64-bit x86-family machines with AMD and Intel CPUs	|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[evbarm]]	|arm		|ARM evaluation boards					|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[evbmips]]	|mips		|MIPS-based evaluation boards				|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[evbppc]]	|powerpc	|PowerPC-based evaluation boards			|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[hpcarm]]	|arm		|StrongARM based Windows CE PDA machines		|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[i386]]	|i386		|32-bit x86-family generic machines ("PC clones")	|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[sparc64]]	|sparc		|Sun UltraSPARC (64-bit)				|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[xen]]		|i386, x86_64	|Xen Virtual Machine Monitor				|[7.1](http://www.netbsd.org/releases/formal-7/)
+[[amd64]]	|x86_64		|64-bit x86-family machines with AMD and Intel CPUs	|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[evbarm]]	|arm		|ARM evaluation boards					|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[evbmips]]	|mips		|MIPS-based evaluation boards				|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[evbppc]]	|powerpc	|PowerPC-based evaluation boards			|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[hpcarm]]	|arm		|StrongARM based Windows CE PDA machines		|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[i386]]	|i386		|32-bit x86-family generic machines ("PC clones")	|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[sparc64]]	|sparc		|Sun UltraSPARC (64-bit)				|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[xen]]		|i386, x86_64	|Xen Virtual Machine Monitor				|[7.1.1](http://www.netbsd.org/releases/formal-7/)
 """]]
 
 
@@ -44,55 +44,55 @@
 
 [[!table data="""
 Port		|CPU		|Machines								|Latest Release
-[[acorn32]]	|arm		|Acorn RiscPC/A7000/NC and compatibles					|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[algor]]	|mips		|Algorithmics MIPS evaluation boards					|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[alpha]]	|alpha		|Digital Alpha (64-bit)							|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[amiga]]	|m68k		|Commodore Amiga, MacroSystem DraCo					|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[amigappc]]	|powerpc	|PowerPC-based Amiga boards						|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[arc]]		|mips		|Machines following the Advanced RISC Computing spec			|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[atari]]	|m68k		|Atari TT030, Falcon, Hades						|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[bebox]]	|powerpc	|Be Inc's BeBox								|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[cats]]	|arm		|Chalice Technology's Strong Arm evaluation board			|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[cesfic]]	|m68k		|CES's FIC8234 VME processor board					|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[cobalt]]	|mips		|Cobalt Networks' Microservers						|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[dreamcast]]	|[[sh3]]	|Sega Dreamcast game console						|[7.1](http://www.netbsd.org/releases/formal-7/)
+[[acorn32]]	|arm		|Acorn RiscPC/A7000/NC and compatibles					|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[algor]]	|mips		|Algorithmics MIPS evaluation boards					|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[alpha]]	|alpha		|Digital Alpha (64-bit)							|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[amiga]]	|m68k		|Commodore Amiga, MacroSystem DraCo					|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[amigappc]]	|powerpc	|PowerPC-based Amiga boards						|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[arc]]		|mips		|Machines following the Advanced RISC Computing spec			|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[atari]]	|m68k		|Atari TT030, Falcon, Hades						|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[bebox]]	|powerpc	|Be Inc's BeBox								|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[cats]]	|arm		|Chalice Technology's Strong Arm evaluation board			|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[cesfic]]	|m68k		|CES's FIC8234 VME processor board					|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[cobalt]]	|mips		|Cobalt Networks' Microservers						|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[dreamcast]]	|[[sh3]]	|Sega Dreamcast game console						|[7.1.1](http://www.netbsd.org/releases/formal-7/)
 [[epoc32]]	|arm		|32bit PSION EPOC PDA							|none
-[[emips]]	|mips		|Machines based on "Extensible MIPS"					|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[evbsh3]]	|[[sh3]]	|Evaluation boards with Renesas (Hitachi) Super-H SH3 and SH4 CPUs	|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[ews4800mips]]	|mips		|NEC's MIPS based EWS4800 workstations					|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[hp300]]	|m68k		|Hewlett-Packard 9000/300 and 400 series				|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[hppa]]	|hppa		|Hewlett-Packard 9000/700 series					|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[hpcmips]]	|mips		|MIPS based Windows CE PDA machines					|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[hpcsh]]	|[[sh3]]	|Renesas (Hitachi) SH3 and SH4 based Windows CE PDA machines		|[7.1](http://www.netbsd.org/releases/formal-7/)
+[[emips]]	|mips		|Machines based on "Extensible MIPS"					|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[evbsh3]]	|[[sh3]]	|Evaluation boards with Renesas (Hitachi) Super-H SH3 and SH4 CPUs	|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[ews4800mips]]	|mips		|NEC's MIPS based EWS4800 workstations					|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[hp300]]	|m68k		|Hewlett-Packard 9000/300 and 400 series				|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[hppa]]	|hppa		|Hewlett-Packard 9000/700 series					|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[hpcmips]]	|mips		|MIPS based Windows CE PDA machines					|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[hpcsh]]	|[[sh3]]	|Renesas (Hitachi) SH3 and SH4 based Windows CE PDA machines		|[7.1.1](http://www.netbsd.org/releases/formal-7/)
 [[ia64]]	|itanium	|Itanium family of processors						|none
-[[ibmnws]]	|powerpc	|IBM Network Station Series 1000					|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[iyonix]]	|arm		|Iyonix ARM pc								|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[landisk]]	|[[sh3]]	|SH4 based NAS appliances by I-O DATA					|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[luna68k]]	|m68k		|OMRON Tateisi Electronics' LUNA series					|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[mac68k]]	|m68k		|Apple Macintosh							|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[macppc]]	|powerpc	|Apple Power Macintosh and clones					|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[mipsco]]	|mips		|Mips family of workstations and servers				|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[mmeye]]	|[[sh3]]	|Brains' mmEye Multi Media Server					|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[mvme68k]]	|m68k		|Motorola MVME 68k SBCs							|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[mvmeppc]]	|powerpc	|Motorola MVME PowerPC SBCs						|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[netwinder]]	|arm		|StrongARM based NetWinder machines					|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[news68k]]	|arm		|Sony's m68k based "NET WORK STATION" series				|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[newsmips]]	|mips		|Sony's MIPS based "NET WORK STATION" series				|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[next68k]]	|m68k		|NeXT 68k 'black' hardware						|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[ofppc]]	|powerpc	|Generic OpenFirmware compliant PowerPC machines			|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[pmax]]	|mips		|Digital MIPS-based DECstations and DECsystems				|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[prep]]	|powerpc	|PReP (PowerPC Reference Platform) and CHRP machines			|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[rs6000]]	|powerpc	|MCA-based IBM RS/6000 workstations					|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[sandpoint]]	|powerpc	|Motorola Sandpoint reference platform					|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[sbmips]]	|mips		|Broadcom SiByte evaluation boards					|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[sgimips]]	|mips		|Silicon Graphics' MIPS-based workstations				|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[shark]]	|arm		|Digital DNARD ("shark")						|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[sparc]]	|sparc		|Sun SPARC (32-bit)							|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[sun2]]	|m68k		|Sun 2									|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[sun3]]	|m68k		|Sun 3 and 3x								|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[vax]]		|vax		|Digital VAX								|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[x68k]]	|m68k		|Sharp X680x0 series							|[7.1](http://www.netbsd.org/releases/formal-7/)
-[[zaurus]]	|arm		|Sharp C7x0/C860/C1000/C3x00 series PDA					|[7.1](http://www.netbsd.org/releases/formal-7/)
+[[ibmnws]]	|powerpc	|IBM Network Station Series 1000					|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[iyonix]]	|arm		|Iyonix ARM pc								|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[landisk]]	|[[sh3]]	|SH4 based NAS appliances by I-O DATA					|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[luna68k]]	|m68k		|OMRON Tateisi Electronics' LUNA series					|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[mac68k]]	|m68k		|Apple Macintosh							|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[macppc]]	|powerpc	|Apple Power Macintosh and clones					|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[mipsco]]	|mips		|Mips family of workstations and servers				|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[mmeye]]	|[[sh3]]	|Brains' mmEye Multi Media Server					|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[mvme68k]]	|m68k		|Motorola MVME 68k SBCs							|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[mvmeppc]]	|powerpc	|Motorola MVME PowerPC SBCs						|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[netwinder]]	|arm		|StrongARM based NetWinder machines					|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[news68k]]	|arm		|Sony's m68k based "NET WORK STATION" series				|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[newsmips]]	|mips		|Sony's MIPS based "NET WORK STATION" series				|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[next68k]]	|m68k		|NeXT 68k 'black' hardware						|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[ofppc]]	|powerpc	|Generic OpenFirmware compliant PowerPC machines			|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[pmax]]	|mips		|Digital MIPS-based DECstations and DECsystems				|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[prep]]	|powerpc	|PReP (PowerPC Reference Platform) and CHRP machines			|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[rs6000]]	|powerpc	|MCA-based IBM RS/6000 workstations					|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[sandpoint]]	|powerpc	|Motorola Sandpoint reference platform					|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[sbmips]]	|mips		|Broadcom SiByte evaluation boards					|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[sgimips]]	|mips		|Silicon Graphics' MIPS-based workstations				|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[shark]]	|arm		|Digital DNARD ("shark")						|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[sparc]]	|sparc		|Sun SPARC (32-bit)							|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[sun2]]	|m68k		|Sun 2									|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[sun3]]	|m68k		|Sun 3 and 3x								|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[vax]]		|vax		|Digital VAX								|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[x68k]]	|m68k		|Sharp X680x0 series							|[7.1.1](http://www.netbsd.org/releases/formal-7/)
+[[zaurus]]	|arm		|Sharp C7x0/C860/C1000/C3x00 series PDA					|[7.1.1](http://www.netbsd.org/releases/formal-7/)
 """]]
 
 

update
Index: wikisrc/releng.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/releng.mdwn,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- wikisrc/releng.mdwn	26 Oct 2016 20:03:37 -0000	1.18
+++ wikisrc/releng.mdwn	28 Dec 2017 06:08:30 -0000	1.19
@@ -12,9 +12,11 @@
 
 ### NetBSD 7.x
 
-* Next Major Release: NetBSD 7.1 (No release date proposed)
+* Next minor release: NetBSD 7.2 (No release date proposed)
   + CVS branch tag: <code>netbsd-7</code>
 * Actively supported teeny releases:
+  + [NetBSD 7.1.1](http://www.netbsd.org/releases/formal-7/NetBSD-7.1.1.html)
+    - CVS branch tag: <code>netbsd-7-1</code>
   + [NetBSD 7.0.2](http://www.netbsd.org/releases/formal-7/NetBSD-7.0.2.html)
     - CVS branch tag: <code>netbsd-7-0</code>
 * [Current pull-up queue for the netbsd-7 branch](http://releng.netbsd.org/cgi-bin/req-7.cgi)
@@ -22,7 +24,7 @@
 
 ### NetBSD 6.x
 
-* Next Minor Release: NetBSD 6.2 (No release date proposed)
+* Next minor release: NetBSD 6.2 (No release date proposed)
   + CVS branch tag: <code>netbsd-6</code>
 * Actively supported teeny releases:
   + [NetBSD 6.1.5](http://www.netbsd.org/releases/formal-6/NetBSD-6.1.5.html)

Fix a typo
Index: wikisrc/pkgsrc/how_to_install_a_lamp_server.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc/how_to_install_a_lamp_server.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/pkgsrc/how_to_install_a_lamp_server.mdwn	5 Feb 2012 07:14:36 -0000	1.2
+++ wikisrc/pkgsrc/how_to_install_a_lamp_server.mdwn	24 Dec 2017 17:44:32 -0000	1.3
@@ -119,7 +119,7 @@
 
 #  Installing the MySQL module for PHP 
 
-This step is important and enables you to make mysql database connections from your php skript. 
+This step is important and enables you to make mysql database connections from your php script. 
     
     cd /usr/pkgsrc/databases/php-mysql/
     make install clean

Fix filename in example
Index: wikisrc/ports/evbarm/raspberry_pi.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/raspberry_pi.mdwn,v
retrieving revision 1.66
retrieving revision 1.67
diff -u -r1.66 -r1.67
--- wikisrc/ports/evbarm/raspberry_pi.mdwn	31 Oct 2017 11:32:36 -0000	1.66
+++ wikisrc/ports/evbarm/raspberry_pi.mdwn	19 Dec 2017 12:01:42 -0000	1.67
@@ -96,7 +96,7 @@
 Once you have rpi.img.gz (or rpi_inst), put it on a uSD card using gunzip and dd, for example:
 
  - gunzip rpi.img.gz
- - dd if=rpi.i7mg of=/dev/disk1
+ - dd if=rpi.img of=/dev/disk1
 
 ### Serial Console
 

No longer link to PR 47720
This PR (port-xen/47720) has been closed for over two years now.
Members: 
	ports/xen/howto.mdwn:1.140->1.141 

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.140
retrieving revision 1.141
diff -u -r1.140 -r1.141
--- wikisrc/ports/xen/howto.mdwn	15 Dec 2017 16:39:33 -0000	1.140
+++ wikisrc/ports/xen/howto.mdwn	15 Dec 2017 16:40:59 -0000	1.141
@@ -234,7 +234,6 @@
 However, there are some open PRs indicating problems.
 
  - [PR 48125](http://gnats.netbsd.org/48125)
- - [PR 47720](http://gnats.netbsd.org/47720)
 
 Note also that there are issues with sparse vnd(4) instances, but
 these are not about Xen -- they just are noticed with sparse vnd(4)

Use HTTPS where known possible
This notably avoids warnings with the security of the page (eg for the
links to images).
Members: 
	ports/xen/howto.mdwn:1.139->1.140 

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.139
retrieving revision 1.140
diff -u -r1.139 -r1.140
--- wikisrc/ports/xen/howto.mdwn	4 Jan 2017 10:25:16 -0000	1.139
+++ wikisrc/ports/xen/howto.mdwn	15 Dec 2017 16:39:33 -0000	1.140
@@ -2,7 +2,7 @@
 ============
 
 [![[Xen
-screenshot]](http://www.netbsd.org/gallery/in-Action/hubertf-xens.png)](http://www.netbsd.org/gallery/in-Action/hubertf-xen.png)
+screenshot]](https://www.netbsd.org/gallery/in-Action/hubertf-xens.png)](https://www.netbsd.org/gallery/in-Action/hubertf-xen.png)
 
 Xen is a hypervisor (or virtual machine monitor) for x86 hardware
 (i686-class or higher), which supports running multiple guest
@@ -354,7 +354,7 @@
 Note that NetBSD as dom0 does not support multiple CPUs.  This will
 limit the performance of the Xen/dom0 workstation approach.  In theory
 the only issue is that the "backend drivers" are not yet MPSAFE:
-  http://mail-index.netbsd.org/netbsd-users/2014/08/29/msg015195.html
+  https://mail-index.netbsd.org/netbsd-users/2014/08/29/msg015195.html
 
 Installation of NetBSD
 ----------------------
@@ -397,7 +397,7 @@
 
 In the dom0, install sysutils/xenkernel42 and sysutils/xentools42 from
 pkgsrc (or another matching pair).  See [the pkgsrc
-documentation](http://www.NetBSD.org/docs/pkgsrc/) for help with
+documentation](https://www.NetBSD.org/docs/pkgsrc/) for help with
 pkgsrc.  Ensure that your packages are recent; the HOWTO does not
 contemplate old builds.
 
@@ -477,7 +477,7 @@
 [old grub information](/ports/xen/howto-grub).
 
 The [HowTo on Installing into
-RAID-1](http://mail-index.NetBSD.org/port-xen/2006/03/01/0010.html)
+RAID-1](https://mail-index.NetBSD.org/port-xen/2006/03/01/0010.html)
 explains how to set up booting a dom0 with Xen using grub with
 NetBSD's RAIDframe.  (This is obsolete with the use of NetBSD's native
 boot.  Now, just create a system with RAID-1, and alter /boot.cfg as
@@ -677,7 +677,7 @@
         dom0 kernel: NetBSD/amd64 6.1.5
         Xen tools: xentools42-4.2.5 from pkgsrc
 
-See [PR 47720](http://gnats.netbsd.org/47720) for a problem with dom0
+See [PR 47720](https://gnats.netbsd.org/47720) for a problem with dom0
 shutdown.
 
 Unprivileged domains (domU)
@@ -1172,7 +1172,7 @@
 TODO: Explain how to compile npf into a custom kernel, answering (but
 note that the problem was caused by not booting the right kernel)
 [this email to
-netbsd-users](http://mail-index.netbsd.org/netbsd-users/2014/12/26/msg015576.html).
+netbsd-users](https://mail-index.netbsd.org/netbsd-users/2014/12/26/msg015576.html).
 
 TODO items for improving NetBSD/xen
 ===================================
@@ -1187,7 +1187,7 @@
     fragsize/blocksize (UFS2 support may be present; the point is to
     make it so that with any UFS1/UFS2 file system setup that works
     with NetBSD grub will also work).
-    See [pkg/40258](http://gnats.netbsd.org/40258).
+    See [pkg/40258](https://gnats.netbsd.org/40258).
   * Push patches upstream.
   * Get UFS2 patches into pvgrub.
 * Add support for PV ops to a version of /boot, and make it usable as

Add FOSDEM 2018 to `Future Events'.
Index: wikisrc/events.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/events.mdwn,v
retrieving revision 1.53
retrieving revision 1.54
diff -u -r1.53 -r1.54
--- wikisrc/events.mdwn	16 Nov 2017 16:12:11 -0000	1.53
+++ wikisrc/events.mdwn	7 Dec 2017 22:05:50 -0000	1.54
@@ -9,6 +9,16 @@
 Future Events
 -------------
 
+### `Feb 2018` - FOSDEM 2018, Brussels, Belgium
+
+*February 3 - 4, 2018, ULB Solbosch Campus, Brussels, Belgium*
+
+[FOSDEM](https://fosdem.org/2018/) is a free event for software developers to
+meet, share ideas and collaborate. Every year, thousands of developers of
+free and open source software from all over the world gather at the event in
+Brussels.
+
+
 ### `Mar 2018` - AsiaBSDCon 2018, Tokyo, Japan
 
 *March 8 - 11, Tokyo University of Science, Tokyo, Japan*

Suggest MKGCC=no too.
Index: wikisrc/tutorials/pkgsrc/clang.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/pkgsrc/clang.mdwn,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- wikisrc/tutorials/pkgsrc/clang.mdwn	30 Jul 2014 07:37:06 -0000	1.1
+++ wikisrc/tutorials/pkgsrc/clang.mdwn	4 Dec 2017 00:43:22 -0000	1.2
@@ -5,6 +5,7 @@
 to also build clang and install it, and additionally
 
     HAVE_LLVM=yes
+    MKGCC=no
 
 if you want to use it to compile NetBSD itself during build.sh.
 

wiz fixed these
Index: wikisrc/users/spz/projects.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/spz/projects.mdwn,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- wikisrc/users/spz/projects.mdwn	30 Nov 2017 06:59:02 -0000	1.4
+++ wikisrc/users/spz/projects.mdwn	3 Dec 2017 21:00:46 -0000	1.5
@@ -20,6 +20,5 @@
 
 - getting as-safe-as-possible packages on TNF servers. This includes making the odd package eat PIE or to RELRO them.
   currently known issues:  
-  RELRO: textproc/p5-highlight editors/pico 
-
+  RELRO: 
 

Index: wikisrc/users/spz/projects.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/spz/projects.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/users/spz/projects.mdwn	4 Oct 2017 06:50:51 -0000	1.3
+++ wikisrc/users/spz/projects.mdwn	30 Nov 2017 06:59:02 -0000	1.4
@@ -1,6 +1,6 @@
 ## spz's Tax Evasion page
 
-This is not about the tax evasion where you avoid paying taxes, but about what I do instead of doing my tax returns (ick! ick! ick!) in order to get the refund I am due. Don't worry, I do them eventually. :)
+This is not about the tax evasion where you avoid paying taxes, but about the NetBSDish things I do instead of doing my tax returns (ick! ick! ick!) in order to get the refund I am due. 2017 is done, 2018 can be done from about March onwards.
 
 - general maintenance on TNF servers
 
@@ -14,9 +14,12 @@
 
 - [[releng-pkgsrc pullups|https://releng.netbsd.org/cgi-bin/req-pkgsrc.cgi]]
 
-- research [[signing TNF generated packages|pkgsig]]
-
-- research [[the issues about getting trusted rust packages|t-rust]]
+- revisit [[signing TNF generated packages|pkgsig]]
 
 - update the security issues page, move it somewhere useful
 
+- getting as-safe-as-possible packages on TNF servers. This includes making the odd package eat PIE or to RELRO them.
+  currently known issues:  
+  RELRO: textproc/p5-highlight editors/pico 
+
+

I did it.
Index: wikisrc/projects/project/build-kernel-pie.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/build-kernel-pie.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/projects/project/build-kernel-pie.mdwn	1 Jul 2017 15:34:09 -0000	1.3
+++ wikisrc/projects/project/build-kernel-pie.mdwn	27 Nov 2017 09:23:47 -0000	1.4
@@ -8,6 +8,7 @@
 
 category="kernel"
 difficulty="medium"
+done_by="Maxime Villard"
 
 description="""
 Add a toolchain infrastructure that allows the kernel to be compiled as

Adjust straw proposal
Index: wikisrc/pkgsrc/gcc.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc/gcc.mdwn,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- wikisrc/pkgsrc/gcc.mdwn	26 Nov 2017 15:37:02 -0000	1.4
+++ wikisrc/pkgsrc/gcc.mdwn	26 Nov 2017 15:43:57 -0000	1.5
@@ -226,9 +226,9 @@
    version of GCC/GXX is not new enough.
 
  - Decide on defaults.  The straw proposal is that PKGSRC_GCC_VERSION
-   is the base system version if >= 4.5 (or 4.4?), and otherwise 6,
+   is the base system version if >= 4.5 (or 4.4?), and otherwise 5,
    and that PKGSRC_GXX_VERSION is the base system version if >= 5, and
-   otherwise 6.
+   otherwise 5.
 
 ### Later steps
 

Adjust recommendation to gcc 5 vs 6
Jason Bacon reports on tech-pkg that gcc6 builds about 500 fewer
packages than gcc5.
Members: 
	pkgsrc/gcc.mdwn:1.3->1.4 

Index: wikisrc/pkgsrc/gcc.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc/gcc.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/pkgsrc/gcc.mdwn	26 Nov 2017 01:28:44 -0000	1.3
+++ wikisrc/pkgsrc/gcc.mdwn	26 Nov 2017 15:37:02 -0000	1.4
@@ -168,11 +168,12 @@
 When the base system is old (e.g., gcc 4.5 in NetBSD 6, or 4.1, in
 NetBSD 5), then it is clear that a newer version must be built.  For
 these, PKGSRC_GXX_VERSION should default to a newish gcc, avoiding
-being so new as to cause building issues.  Currently, gcc6 is probably
-a good choice.  PKGSRC_GCC_VERSION should probably default to the
-system version if it can build all C99 programs, or match
-PKGSRC_GXX_VERSION, if the system version is too old.  Perhaps gcc 4.5
-would be used, but 4.1 not used.  \todo Discuss.
+being so new as to cause building issues.  Currently, gcc5 is probably
+a good choice, with gcc6 compiling significantly but not vastly fewer
+packages.  PKGSRC_GCC_VERSION should probably default to the system
+version if it can build all C99 programs, or match PKGSRC_GXX_VERSION,
+if the system version is too old.  Perhaps gcc 4.5 would be used, but
+4.1 not used.  \todo Discuss.
 
 When the base system is almost new enough, the decision about the
 default is more complicated.  A key example is gcc 4.8, found in
@@ -184,12 +185,12 @@
 generally-acceptable version applies, which currently leads to gcc6.
 This is in effect a declaration that "almost new enough" does not
 count as new enough.  Thus the plan for NetBSD 7 is to set
-PKGSRC_GCC_VERSION to 4.8 and PKGSRC_GXX_VERSION to 6.
+PKGSRC_GCC_VERSION to 4.8 and PKGSRC_GXX_VERSION to 5.
 
-When the base system is new, e.g. gcc 5 or gcc 6 it should simply be
-used.  By "new enough", we mean that almost no programs in pkgsrc fail
-to build with it, which implies that it supports (almost all) C++14
-programs.   Our current definiton of new enough is gcc 5.
+When the base system is new enough, e.g. gcc 5, 6 or 7 it should
+simply be used.  By "new enough", we mean that almost no programs in
+pkgsrc fail to build with it, which implies that it supports (almost
+all) C++14 programs.  Our current definiton of new enough is gcc 5.
 
 ### Limited mixed versions
 

More edits
Index: wikisrc/pkgsrc/gcc.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc/gcc.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/pkgsrc/gcc.mdwn	26 Nov 2017 01:20:23 -0000	1.2
+++ wikisrc/pkgsrc/gcc.mdwn	26 Nov 2017 01:28:44 -0000	1.3
@@ -18,7 +18,7 @@
 in a compiler within ${PREFIX}, e.g. /usr/pkg/gcc6/bin/gcc.  This
 compiler can then be used to compile other packages.
 
-Issues with using base system gcc are typically that it is too old,
+The Issue with using base system gcc is typically that it is too old,
 such as gcc 4.5 with NetBSD 6, which cannot compile c++11.
 
 Issues when using pkgsrc gcc are that
@@ -47,9 +47,9 @@
     version used in any included library.
 
   - All packages that use C++ should be built with the same compiler
-    version.  Because these typically also include C, the version used
-    for C++ must be at least as new as the version used for any used C
-    package.
+    version.  Because these in the general case may include C, the
+    version used for C++ must be at least as new as the version used
+    for any used C package.
 
   - pkgsrc should avoid building gcc unless it is more or less
     necessary to build packges.  (As an example, if the base system
@@ -102,8 +102,8 @@
     package building will fail.  We call the resulting
     PKGSRC_GCC_VERSION or PKGSRC_GXX_VERSION the chosen version.
 
-  - When building a program using C or C++, the chosen version is not
-    provided by the base system, and the chosen version is not
+  - When building a program using C or C++, if the chosen version is
+    not provided by the base system, and the chosen version is not
     installed via pkgsrc, then it (and its dependencies) will be built
     from pkgsrc in a special bootstrap mode.  When building in
     bootstrap mode, the version selection logic is ignored and the
@@ -151,19 +151,28 @@
 \todo: Discuss adjusting options to minimize dependencies, including
 gcc-inplace-math and nls.
 
+### Differing GCC and GXX versions
+
+Perhaps it is a mistake to allow the chosen GCC and GXX versions to
+differ.  If we require them to be the same, then essentially all
+systems with a base system compiler older than gcc 5 will have to
+bootstrap the compiler.  For now, we allow them to differ and will
+permit the defaults to differ.
+
 ### Default versions for various systems
 
-Note that if any particular system (or bulk build), a newer gcc has to
-be built, it does not hurt incrementally to have built it earlier.
+Note that if for any particular system's set of installed packages (or
+bulk build), a newer gcc has to be built, it does not hurt to have
+built it earlier.
 
 When the base system is old (e.g., gcc 4.5 in NetBSD 6, or 4.1, in
 NetBSD 5), then it is clear that a newer version must be built.  For
 these, PKGSRC_GXX_VERSION should default to a newish gcc, avoiding
 being so new as to cause building issues.  Currently, gcc6 is probably
 a good choice.  PKGSRC_GCC_VERSION should probably default to the
-system version if it can build C99, or match PKGSRC_GXX_VERSION, if
-the system version is too old.  Perhaps gcc 4.5 would be used, but 4.1
-not used.  \todo Discuss.
+system version if it can build all C99 programs, or match
+PKGSRC_GXX_VERSION, if the system version is too old.  Perhaps gcc 4.5
+would be used, but 4.1 not used.  \todo Discuss.
 
 When the base system is almost new enough, the decision about the
 default is more complicated.  A key example is gcc 4.8, found in
@@ -219,3 +228,7 @@
    is the base system version if >= 4.5 (or 4.4?), and otherwise 6,
    and that PKGSRC_GXX_VERSION is the base system version if >= 5, and
    otherwise 6.
+
+### Later steps
+
+ - Address fortran.

General edit/fix pass
Index: wikisrc/pkgsrc/gcc.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc/gcc.mdwn,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- wikisrc/pkgsrc/gcc.mdwn	26 Nov 2017 01:07:36 -0000	1.1
+++ wikisrc/pkgsrc/gcc.mdwn	26 Nov 2017 01:20:23 -0000	1.2
@@ -1,8 +1,6 @@
-Using gcc in pkgsrc
-
 On many systems pkgsrc supports, gcc is the standard compiler.  In
 general, different versions of each OS have different gcc versions,
-and some packages require newer GCC versions, in order to support
+and some packages require newer gcc versions, in order to support
 newer language standards (e.g. c++11, written in the style of
 USE_LANGUAGES), or because older versions don't work (infrequently).
 
@@ -45,33 +43,42 @@
   - The set of packages that are needed when building a bootstrap
     compiler should be minimized.
 
-  - All packages that use C++ should be built with the same compiler version.
-
   - All packages that use C should have final linking with the highest
     version used in any included library.
 
+  - All packages that use C++ should be built with the same compiler
+    version.  Because these typically also include C, the version used
+    for C++ must be at least as new as the version used for any used C
+    package.
+
   - pkgsrc should avoid building gcc unless it is more or less
     necessary to build packges.  (As an example, if the base system
     gcc can build c99 but not c++11, building a c99-only program
     should not trigger building a gcc version adequate for c++11.)
 
-  - The compiler selection logic should work on NetBSD 6, and in-use
-    (including LTS) GNU/Linux systems.  It is desirable for this logic
-    to work on NetBSD 5.
+  - The compiler selection logic should work on NetBSD 6 and newer,
+    and other systems currently supported by pkgsrc, including in-use
+    LTS GNU/Linux systems.  It should work on systems that default to
+    clang, when set to use GCC, at least as well as the current
+    scheme.  It is desirable for this logic to work on NetBSD 5.
 
   - The compiler selection logic should be understandable and not brittle.
 
 ## Design
 
 The above requirements could in theory be satisfied in many ways, but
-most of them are too complicated.
+most of them are too complicated.  We present a design that aims to be
+sound while mimimizing complexity.
 
   - Packages declare what languages they need, with c++, c++11, and
-    c++14 being expressed differently.
+    c++14 being expressed differently.  (This is exactly current
+    practice and just noted for completeness.)
 
   - The package-settable variable GCC_REQD will be used only when a
     compiler that generally can compile the declared language version
-    is insufficient.  These cases are expected to be relatively rare.
+    is insufficient.  These cases are expected to be relatively rare;
+    an example is firefox that is in c++ (but not c+11) and needs gcc
+    4.9.
 
   - A user-settable variable PKGSRC_GCC_VERSION will declare the
     version of gcc to be used for C programs, with an OS- and
@@ -121,6 +128,9 @@
     approach is possible inconsistency with gcc's dependencies being
     built with the base compiler and used later.
 
+  - We hope that the chosen version can be built using the base system
+    version, and hope to avoid multi-stage bootstrapping.
+
   - We expect that any program containing C++ will undergo final
     linking with a C++ compiler.  This is not a change from the
     current situation.
@@ -157,8 +167,7 @@
 
 When the base system is almost new enough, the decision about the
 default is more complicated.  A key example is gcc 4.8, found in
-NetBSD 7.  Firefox requires gcc 4.9 (\todo because the c++11 support
-in 4.8 is not quite good enough), and all programs using c++14 also
+NetBSD 7.  Firefox requires gcc 4.9, and all programs using c++14 also
 need a newer version.  One options is to choose 4.8, resulting in
 firefox failing, as well as all c++14 programs.  Another is to choose
 4.9, but this makes little sense because c++14 programs will still
@@ -173,6 +182,18 @@
 to build with it, which implies that it supports (almost all) C++14
 programs.   Our current definiton of new enough is gcc 5.
 
+### Limited mixed versions
+
+One approach would be to allow limited mixed versions, where
+individual programs could force a specific version to be bootstrapped
+and used, so that e.g. firefox could use 4.9 even though most programs
+use 4.8, which is what happens now on NetBSD 7.  This would rely on
+being able to link c++ with 4.9 including some things built with 4.8
+(which is done presently).  However, this approach would become
+unsound with a library rather than an end program.  We reject this as
+too much complexity for avoiding building a newer compiler in limited
+situations.
+
 ### Fortran
 
 Fortran support is currently somewhat troubled..  It seems obvious to

Add discussion of gcc version selection
--- /dev/null	2018-01-17 03:40:50.000000000 +0000
+++ wikisrc/pkgsrc/gcc.mdwn	2018-01-17 03:45:29.000000000 +0000
@@ -0,0 +1,200 @@
+Using gcc in pkgsrc
+
+On many systems pkgsrc supports, gcc is the standard compiler.  In
+general, different versions of each OS have different gcc versions,
+and some packages require newer GCC versions, in order to support
+newer language standards (e.g. c++11, written in the style of
+USE_LANGUAGES), or because older versions don't work (infrequently).
+
+This page discusses issues related to version selection, and intends
+to be a design document for how pkgsrc should address this problem, to
+be converted into historical design rationale once implemented.  It
+freely takes content from extensive mailinglist discussions, and
+attempts to follow the rough consensus that has emerged.
+
+## Base system gcc vs pkgsrc gcc
+
+Systems using gcc (e.g. NetBSD) have a compiler as /usr/bin/gcc, and
+this is usable by pkgsrc without any bootstrapping activity.  One can
+build gcc versions (typically newer versions) from pkgsrc, resulting
+in a compiler within ${PREFIX}, e.g. /usr/pkg/gcc6/bin/gcc.  This
+compiler can then be used to compile other packages.
+
+Issues with using base system gcc are typically that it is too old,
+such as gcc 4.5 with NetBSD 6, which cannot compile c++11.
+
+Issues when using pkgsrc gcc are that
+
+  - it must be bootstrapped, requiring compiling a number of packages
+    with the system compiler
+  - C++ packages that are linked together should be built with the
+    same compiler, because the standard library ABI is not necessarily
+    the same for each compiler version
+  - While C packages can be built with mixed versions, the binary
+    should be linked with the higher version because the support
+    library is backwards compatible but not forward compatible.
+
+## Specific constraints and requirements
+
+This section attempts to gather all the requirements.
+
+  - By default, pkgsrc should be able to build working packages, even
+    for packages that need a newer compiler than that provided in the
+    base system.
+
+  - The set of packages that are needed when building a bootstrap
+    compiler should be minimized.
+
+  - All packages that use C++ should be built with the same compiler version.
+
+  - All packages that use C should have final linking with the highest
+    version used in any included library.
+
+  - pkgsrc should avoid building gcc unless it is more or less
+    necessary to build packges.  (As an example, if the base system
+    gcc can build c99 but not c++11, building a c99-only program
+    should not trigger building a gcc version adequate for c++11.)
+
+  - The compiler selection logic should work on NetBSD 6, and in-use
+    (including LTS) GNU/Linux systems.  It is desirable for this logic
+    to work on NetBSD 5.
+
+  - The compiler selection logic should be understandable and not brittle.
+
+## Design
+
+The above requirements could in theory be satisfied in many ways, but
+most of them are too complicated.
+
+  - Packages declare what languages they need, with c++, c++11, and
+    c++14 being expressed differently.
+
+  - The package-settable variable GCC_REQD will be used only when a
+    compiler that generally can compile the declared language version
+    is insufficient.  These cases are expected to be relatively rare.
+
+  - A user-settable variable PKGSRC_GCC_VERSION will declare the
+    version of gcc to be used for C programs, with an OS- and
+    version--specific default.
+
+  - A user-settable variable PKGSRC_GXX_VERSION will declare the version of gcc to
+    be used for all C++ programs, again with an OS- and
+    version-specific default.  It must be at least PKGSRC_GCC_VERSION.
+
+  - Each of c99, c++, c++11, and c++14 will be associated with a
+    minimum gcc version, such that almost all programs declaring that
+    language can be built with that version.  (This avoids issues of
+    strict compliance with c++11, which requires a far higher version
+    of gcc than the version required to compile almost all actual
+    programs in c++11.)
+
+  - The minimum version inferred from the language tag will be
+    combined with any GCC_REQD declarations to find a minimum version
+    for a specific package.  If that is greater than
+    PKGSRC_GCC_VERSION (programs using only C) or PKGSRC_GXX_VERSION,
+    package building will fail.  We call the resulting
+    PKGSRC_GCC_VERSION or PKGSRC_GXX_VERSION the chosen version.
+
+  - When building a program using C or C++, the chosen version is not
+    provided by the base system, and the chosen version is not
+    installed via pkgsrc, then it (and its dependencies) will be built
+    from pkgsrc in a special bootstrap mode.  When building in
+    bootstrap mode, the version selection logic is ignored and the
+    base system compiler is used.  Consistency and reproducible builds
+    require that a package built with the normal prefix must be the
+    same whether built because of compiler bootstrapping or normal
+    use.
+
+    There are thus two choices for dealing with bootstrapping.  One is
+    to use a distinct prefix, which will ensure that all packages that
+    are part of the compiler bootstrap will not be linked into normal
+    pkgsrc programs.  This implies that any dependencies of gcc may
+    exist twice, once in bootstrap mode and once if built normally.  A
+    gcc version itself will be built twice, if it is desired for
+    regular use.  This double building and the complexity of a second
+    prefix are the negatives of this approach.
+
+    The other choice is to mark gcc and all depending packages as used
+    for compiler bootstrapping, and to always build those with the
+    base compiler.  We use the package-settable variable
+    PKGSRC_GCC_BOOTSTRAP=yes to denote this.  The negative with this
+    approach is possible inconsistency with gcc's dependencies being
+    built with the base compiler and used later.
+
+  - We expect that any program containing C++ will undergo final
+    linking with a C++ compiler.  This is not a change from the
+    current situation.
+
+## Remaining issues
+
+### gcc dependencies
+
+Because gcc can have dependencies, there could be packages built with
+the system compiler that are then later used with the chosen version.
+For now, we defer worrying about these problems (judging that they
+will be less serious than the current situation where all c++11
+programs fail to build on NetBSD 6).
+
+\todo: Analyze what build-time and install-time dependencies actually
+exist.
+
+\todo: Discuss adjusting options to minimize dependencies, including
+gcc-inplace-math and nls.
+
+### Default versions for various systems
+
+Note that if any particular system (or bulk build), a newer gcc has to
+be built, it does not hurt incrementally to have built it earlier.
+
+When the base system is old (e.g., gcc 4.5 in NetBSD 6, or 4.1, in
+NetBSD 5), then it is clear that a newer version must be built.  For
+these, PKGSRC_GXX_VERSION should default to a newish gcc, avoiding
+being so new as to cause building issues.  Currently, gcc6 is probably
+a good choice.  PKGSRC_GCC_VERSION should probably default to the
+system version if it can build C99, or match PKGSRC_GXX_VERSION, if
+the system version is too old.  Perhaps gcc 4.5 would be used, but 4.1
+not used.  \todo Discuss.
+
+When the base system is almost new enough, the decision about the
+default is more complicated.  A key example is gcc 4.8, found in
+NetBSD 7.  Firefox requires gcc 4.9 (\todo because the c++11 support
+in 4.8 is not quite good enough), and all programs using c++14 also
+need a newer version.  One options is to choose 4.8, resulting in
+firefox failing, as well as all c++14 programs.  Another is to choose
+4.9, but this makes little sense because c++14 programs will still
+fail, and the general rule of moving to the most recent
+generally-acceptable version applies, which currently leads to gcc6.
+This is in effect a declaration that "almost new enough" does not
+count as new enough.  Thus the plan for NetBSD 7 is to set
+PKGSRC_GCC_VERSION to 4.8 and PKGSRC_GXX_VERSION to 6.
+
+When the base system is new, e.g. gcc 5 or gcc 6 it should simply be
+used.  By "new enough", we mean that almost no programs in pkgsrc fail
+to build with it, which implies that it supports (almost all) C++14
+programs.   Our current definiton of new enough is gcc 5.
+
+### Fortran
+
+Fortran support is currently somewhat troubled..  It seems obvious to
+extend to PGKSRC_GFORTRAN_VERSION, and have that match
+PKGSRC_GCC_VERSION or PKGSRC_GXX_VERSION, but the Fortran situation is
+not worsened by the above design.  \todo Discuss.
+
+## Path forward
+
+ - Modify all gcc packages to have minimal dependencies, and to add
+   PKGSRC_GCC_BOOTSTRAP.
+
+ - Modify the compiler selection logic to do nothing if
+   PKGSRC_GCC_BOOTSTRAP is set.
+
+ - Modify the compiler selection logic for LANGUAGES= to fail if
+   PKGSRC_GCC_VERSION/PKGSRC_GXX_VERSION is not new enough.
+
+ - Modify the compiler selection logic for GCC_REQD to fail if the
+   version of GCC/GXX is not new enough.
+
+ - Decide on defaults.  The straw proposal is that PKGSRC_GCC_VERSION

(Diff truncated)
Fix URLs
Index: wikisrc/pkgsrc.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc.mdwn,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- wikisrc/pkgsrc.mdwn	26 Nov 2017 00:04:24 -0000	1.5
+++ wikisrc/pkgsrc.mdwn	26 Nov 2017 00:05:58 -0000	1.6
@@ -13,9 +13,9 @@
 
 pkgsrc supports multiple compilers.
 
- - [GCC](pkgsrc/gcc.mdwn)
+ - [GCC](gcc/)
 
-pkgsrc supports a [number of exploit mitigation techniques](pkgsrc/hardening.mdwn)
+pkgsrc supports a [number of exploit mitigation techniques](hardening/)
 
 ## Unordered list of all pkgsrc wiki pages
 

Improve pkgsrc page with organized content
Index: wikisrc/pkgsrc.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc.mdwn,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- wikisrc/pkgsrc.mdwn	23 Jun 2014 14:34:49 -0000	1.4
+++ wikisrc/pkgsrc.mdwn	26 Nov 2017 00:04:24 -0000	1.5
@@ -1,3 +1,22 @@
+pkgsrc, a portable multi-architecture packaging system
+
+This wiki page attempts to organize information in the NetBSD wiki about pkgsrc.
+
+## Other documentation
+
+The canonical location for pkgsrc documentation is the pkgsrc guide,
+located in pkgsrc/doc/pkgsrc.*.
+
 <http://pkgsrc.org>
 
+## Compilers and compilation options
+
+pkgsrc supports multiple compilers.
+
+ - [GCC](pkgsrc/gcc.mdwn)
+
+pkgsrc supports a [number of exploit mitigation techniques](pkgsrc/hardening.mdwn)
+
+## Unordered list of all pkgsrc wiki pages
+
 [[!map pages="pkgsrc/* and !*.css"]]

Index: wikisrc/ports/evbarm/odroid-c1.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/odroid-c1.mdwn,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- wikisrc/ports/evbarm/odroid-c1.mdwn	12 Apr 2017 23:56:35 -0000	1.28
+++ wikisrc/ports/evbarm/odroid-c1.mdwn	22 Nov 2017 14:35:02 -0000	1.29
@@ -28,7 +28,7 @@
  - I2C
  - Audio
 
-# Installation (NetBSD -current after 20170412)
+# Installation (NetBSD 8.0 and later)
 
 * Start with an ARMv7 image from *evbarm-earmv7hf/binary/gzimg/* such as *armv7.img*
 * Build U-Boot for ODROID-C1 <https://github.com/hardkernel/u-boot/tree/odroidc-v2011.03>

Audio codec is supported on sun7i (same as sun4i)
Index: wikisrc/ports/evbarm/allwinner.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/allwinner.mdwn,v
retrieving revision 1.76
retrieving revision 1.77
diff -u -r1.76 -r1.77
--- wikisrc/ports/evbarm/allwinner.mdwn	13 Nov 2017 14:44:47 -0000	1.76
+++ wikisrc/ports/evbarm/allwinner.mdwn	18 Nov 2017 18:32:37 -0000	1.77
@@ -56,7 +56,7 @@
     </tr>
   </thead>
   <tbody>
-    <tr><td>Audio codec</td><td>Yes</td><td>Supported on sun4i, sun5i, sun6i, sun8i-h2+, sun8i-h3</td></tr>
+    <tr><td>Audio codec</td><td>Yes</td><td>Supported on sun4i, sun5i, sun6i, sun7i, sun8i-h2+, sun8i-h3</td></tr>
     <tr><td>Crypto engine</td><td>-</td><td></td></tr>
     <tr><td>CSI</td><td>-</td><td></td></tr>
     <tr><td>DMA</td><td>Yes</td><td></td></tr>

Move BSDTW 2017 to Past Events.
Index: wikisrc/events.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/events.mdwn,v
retrieving revision 1.52
retrieving revision 1.53
diff -u -r1.52 -r1.53
--- wikisrc/events.mdwn	27 Oct 2017 11:02:30 -0000	1.52
+++ wikisrc/events.mdwn	16 Nov 2017 16:12:11 -0000	1.53
@@ -9,22 +9,6 @@
 Future Events
 -------------
 
-### `Nov 2017` - BSDTW 2017, Taipei, Taiwan
-
-*November 11 - 12, 2017, Taipei, Taiwan*
-
-[BSDTW 2017](https://bsdtw.org/) is planned as a
-single track, 2 days conference with 11 presentations of 50
-minutes each covering the latest BSD technology. The conference
-will attract over 100 highly skilled engineering professionals,
-software developers, computer science professors, users and
-students from all over Asia as well as other parts of the
-world. The goal of BSDTW is to exchange knowledge about the
-BSD operating systems, facilitate coordination and cooperation
-among users and developers and to promote business friendly
-BSD licensed open source software.
-
-
 ### `Mar 2018` - AsiaBSDCon 2018, Tokyo, Japan
 
 *March 8 - 11, Tokyo University of Science, Tokyo, Japan*
@@ -54,6 +38,22 @@
 Past Events
 -----------
 
+### `Nov 2017` - BSDTW 2017, Taipei, Taiwan
+
+*November 11 - 12, 2017, Taipei, Taiwan*
+
+[BSDTW 2017](https://bsdtw.org/) was planned as a
+single track, 2 days conference with 11 presentations of 50
+minutes each covering the latest BSD technology. The conference
+attracted over 100 highly skilled engineering professionals,
+software developers, computer science professors, users and
+students from all over Asia as well as other parts of the
+world. The goal of BSDTW was to exchange knowledge about the
+BSD operating systems, facilitate coordination and cooperation
+among users and developers and to promote business friendly
+BSD licensed open source software.
+
+
 ### `Sep 2017` - EuroBSDCon 2017 Paris, France
 
 *September 21 - 24, 2017, Paris, France*

NAND flash controller is supported now
Index: wikisrc/ports/evbarm/allwinner.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/allwinner.mdwn,v
retrieving revision 1.75
retrieving revision 1.76
diff -u -r1.75 -r1.76
--- wikisrc/ports/evbarm/allwinner.mdwn	6 Nov 2017 21:15:21 -0000	1.75
+++ wikisrc/ports/evbarm/allwinner.mdwn	13 Nov 2017 14:44:47 -0000	1.76
@@ -69,7 +69,7 @@
     <tr><td>I2C</td><td>Yes</td><td></td></tr>
     <tr><td>I2S/PCM</td><td>-</td><td></td></tr>
     <tr><td>IR transceiver</td><td>-</td><td></td></tr>
-    <tr><td>NAND</td><td>-</td><td></td></tr>
+    <tr><td>NAND</td><td>Yes</td><td></td></tr>
     <tr><td>P2WI/RSB</td><td>Yes</td><td></td></tr>
     <tr><td>PWM</td><td>-</td><td></td></tr>
     <tr><td>RTC</td><td>Yes</td><td></td></tr>

Also mention PKGSRC_MKREPRO for building reproducibly
Index: wikisrc/pkgsrc/hardening.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc/hardening.mdwn,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- wikisrc/pkgsrc/hardening.mdwn	12 Nov 2017 15:12:49 -0000	1.37
+++ wikisrc/pkgsrc/hardening.mdwn	12 Nov 2017 15:15:48 -0000	1.38
@@ -79,6 +79,18 @@
 PIE executables will only be built for toolchains that are known to support PIE.
 Currently, this means NetBSD on amd64 and i386.
 
+### 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:
+
+* <https://reproducible-builds.org/>
+
 ### PKGSRC_USE_RELRO
 
 This also makes the exploitation of some security vulnerabilities more

Clarify PIE and ASLR a bit more
Index: wikisrc/pkgsrc/hardening.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc/hardening.mdwn,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -r1.36 -r1.37
--- wikisrc/pkgsrc/hardening.mdwn	12 Nov 2017 15:02:00 -0000	1.36
+++ wikisrc/pkgsrc/hardening.mdwn	12 Nov 2017 15:12:49 -0000	1.37
@@ -67,12 +67,14 @@
 ### PKGSRC_MKPIE
 
 This requests the creation of PIE (Position Independent Executables) for all
-executables. The PIE mechanism is normally used for shared libraries so that
+executables. The PIE mechanism is normally used for shared libraries, so that
 they can be loaded at differing addresses at runtime. PIE itself does not have
-useful security properties.  However, 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.
+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 amd64 and i386.

Remove extra "the"
Index: wikisrc/pkgsrc/hardening.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc/hardening.mdwn,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- wikisrc/pkgsrc/hardening.mdwn	12 Nov 2017 14:59:14 -0000	1.35
+++ wikisrc/pkgsrc/hardening.mdwn	12 Nov 2017 15:02:00 -0000	1.36
@@ -66,14 +66,13 @@
 
 ### PKGSRC_MKPIE
 
-This requests the the creation of PIE (Position Independent
-Executables) for all executables. The PIE mechanism is normally used
-for shared libraries so that they can be loaded at differing addresses
-at runtime. PIE itself does not have useful security properties.
-However, 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.
+This requests the creation of PIE (Position Independent Executables) for all
+executables. The PIE mechanism is normally used for shared libraries so that
+they can be loaded at differing addresses at runtime. PIE itself does not have
+useful security properties.  However, 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.
 
 PIE executables will only be built for toolchains that are known to support PIE.
 Currently, this means NetBSD on amd64 and i386.

Mention the check for SSP
Index: wikisrc/pkgsrc/hardening.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc/hardening.mdwn,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- wikisrc/pkgsrc/hardening.mdwn	7 Nov 2017 02:38:59 -0000	1.34
+++ wikisrc/pkgsrc/hardening.mdwn	12 Nov 2017 14:59:14 -0000	1.35
@@ -289,3 +289,6 @@
     0000000000600ea0 B __stack_chk_guard
 
 This is an indicator that the program was indeed built with support for SSP.
+
+This check is now performed automatically (where supported) if `PKG_DEVELOPER`
+is set and `SSP` is enabled.

Fix the markup
Index: wikisrc/pkgsrc/hardening.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc/hardening.mdwn,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -r1.33 -r1.34
--- wikisrc/pkgsrc/hardening.mdwn	7 Nov 2017 02:37:43 -0000	1.33
+++ wikisrc/pkgsrc/hardening.mdwn	7 Nov 2017 02:38:59 -0000	1.34
@@ -44,6 +44,7 @@
 and therefore exposing these bugs.
 
 Different mitigation levels are available:
+
 * the default ("yes"), which will only protect functions considered vulnerable
   by the compiler;
 * "all", which will protect every function;
@@ -56,6 +57,7 @@
 It is enabled by default where known supported since pkgsrc-2017Q3.
 
 More details can be found here:
+
 * <https://en.wikipedia.org/wiki/Buffer_overflow_protection>
 
 ## Enabled by default in pkgsrc HEAD
@@ -82,6 +84,7 @@
 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;
 * full: in addition to partial RELRO, every relocation is performed immediately
@@ -92,6 +95,7 @@
 feature by default, at the "partial" level.
 
 More details can be found here:
+
 * <http://tk-blog.blogspot.co.at/2009/02/relro-not-so-well-known-memory.html>
 
 ### PKGSRC_USE_STACK_CHECK

Clarify RELRO
Index: wikisrc/pkgsrc/hardening.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc/hardening.mdwn,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -r1.32 -r1.33
--- wikisrc/pkgsrc/hardening.mdwn	7 Nov 2017 02:26:54 -0000	1.32
+++ wikisrc/pkgsrc/hardening.mdwn	7 Nov 2017 02:37:43 -0000	1.33
@@ -55,6 +55,7 @@
 
 It is enabled by default where known supported since pkgsrc-2017Q3.
 
+More details can be found here:
 * <https://en.wikipedia.org/wiki/Buffer_overflow_protection>
 
 ## Enabled by default in pkgsrc HEAD
@@ -80,12 +81,18 @@
 This also makes the exploitation of some security vulnerabilities more
 difficult in some cases.
 
-TODO: Explain gcc vs clang, and whether this has broad support or just
-a few platforms.
+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;
+* full: in addition to partial RELRO, every relocation is performed immediately
+  when starting the program (with a slight performance impact), allowing the
+  entire GOT to be read-only.
 
-TODO: Address "partial" vs "full"; which is this?
+This is currently supported by GCC. Many software distributions now enable this
+feature by default, at the "partial" level.
 
-TODO: Give a link to a comprehensive explanation.
+More details can be found here:
+* <http://tk-blog.blogspot.co.at/2009/02/relro-not-so-well-known-memory.html>
 
 ### PKGSRC_USE_STACK_CHECK
 
@@ -278,8 +285,3 @@
     0000000000600ea0 B __stack_chk_guard
 
 This is an indicator that the program was indeed built with support for SSP.
-
-# References
-
-* <http://tk-blog.blogspot.co.at/2009/02/relro-not-so-well-known-memory.html>
-

Add some flesh to PKGSRC_USE_STACK_CHECK
Index: wikisrc/pkgsrc/hardening.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc/hardening.mdwn,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- wikisrc/pkgsrc/hardening.mdwn	7 Nov 2017 02:22:50 -0000	1.31
+++ wikisrc/pkgsrc/hardening.mdwn	7 Nov 2017 02:26:54 -0000	1.32
@@ -89,8 +89,11 @@
 
 ### PKGSRC_USE_STACK_CHECK
 
-This uses `-fstack-check` with GCC for another stack protection
-mitigation.
+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.
 
 # Caveats
 

Clarify support for PIE
Index: wikisrc/pkgsrc/hardening.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc/hardening.mdwn,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -r1.30 -r1.31
--- wikisrc/pkgsrc/hardening.mdwn	7 Nov 2017 02:18:46 -0000	1.30
+++ wikisrc/pkgsrc/hardening.mdwn	7 Nov 2017 02:22:50 -0000	1.31
@@ -72,9 +72,8 @@
 time a program is run. This makes it more difficult for an attacker
 to guess addresses and thus makes exploits harder to construct.
 
-TODO/check: PIE executables will only be built for toolchains that
-support PIE and operating systems known to support ASLR. Currently,
-this means NetBSD 8 and later, i386 and amd64.
+PIE executables will only be built for toolchains that are known to support PIE.
+Currently, this means NetBSD on amd64 and i386.
 
 ### PKGSRC_USE_RELRO
 

List the mitigation levels for PKGSRC_USE_SSP
Index: wikisrc/pkgsrc/hardening.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc/hardening.mdwn,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- wikisrc/pkgsrc/hardening.mdwn	7 Nov 2017 02:14:50 -0000	1.29
+++ wikisrc/pkgsrc/hardening.mdwn	7 Nov 2017 02:18:46 -0000	1.30
@@ -43,6 +43,12 @@
 the meantime. This can happen in case of buffer overflows or memory corruption,
 and therefore exposing these bugs.
 
+Different mitigation levels are available:
+* the default ("yes"), which will only protect functions considered vulnerable
+  by the compiler;
+* "all", which will protect every function;
+* "strong", which will apply a better balance between the two settings above.
+
 This mitigation is supported by both GCC and clang. It may be supported in
 additional compilers, possibly under a different name. It is particularly useful
 for unsafe programming languages, such as C/C++.

Add more details for PKGSRC_USE_SSP
Index: wikisrc/pkgsrc/hardening.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc/hardening.mdwn,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- wikisrc/pkgsrc/hardening.mdwn	7 Nov 2017 02:00:44 -0000	1.28
+++ wikisrc/pkgsrc/hardening.mdwn	7 Nov 2017 02:14:50 -0000	1.29
@@ -36,13 +36,21 @@
 
 ### PKGSRC_USE_SSP
 
-This enables a stack-smashing protection mitigation.
-
-TODO: Give a link to a good explanation. Explain if this is gcc
-specific or also works with other compilers. Explain if it is C/C++ only.
+This enables a stack-smashing protection mitigation. It is done by adding a
+guard variable to functions with vulnerable objects. The guards are initialized
+when a function is entered and then checked when the function exits. The guard
+check will fail and the program forcibly exited if the variable was modified in
+the meantime. This can happen in case of buffer overflows or memory corruption,
+and therefore exposing these bugs.
+
+This mitigation is supported by both GCC and clang. It may be supported in
+additional compilers, possibly under a different name. It is particularly useful
+for unsafe programming languages, such as C/C++.
 
 It is enabled by default where known supported since pkgsrc-2017Q3.
 
+* <https://en.wikipedia.org/wiki/Buffer_overflow_protection>
+
 ## Enabled by default in pkgsrc HEAD
 
 ## Not enabled by default

Add a caveat for FORTIFY
Index: wikisrc/pkgsrc/hardening.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc/hardening.mdwn,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- wikisrc/pkgsrc/hardening.mdwn	7 Nov 2017 01:52:37 -0000	1.27
+++ wikisrc/pkgsrc/hardening.mdwn	7 Nov 2017 02:00:44 -0000	1.28
@@ -136,6 +136,13 @@
 crash, usually indicating an actual bug in the program. The fix will typically
 involve patching the original program.
 
+### Optimization is required
+
+At least in the case of GCC, FORTIFY will only be applied if optimization is
+applied while compiling. This means that the CFLAGS should also contain -O, -O2
+or another optimization level. This cannot easily be applied globally, as some
+packages may require specific optimization levels.
+
 ## Problems with `PKGSRC_USE_RELRO`
 
 ### Performance impact

Typo
Index: wikisrc/pkgsrc/hardening.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc/hardening.mdwn,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- wikisrc/pkgsrc/hardening.mdwn	7 Nov 2017 01:51:03 -0000	1.26
+++ wikisrc/pkgsrc/hardening.mdwn	7 Nov 2017 01:52:37 -0000	1.27
@@ -8,7 +8,7 @@
 # Mechanisms
 
 Mechanisms can be enabled individually in `mk.conf`, and are
-individually described below. They are sorted by whether thery are
+individually described below. They are sorted by whether they are
 enabled by default, and then by their ordering in `mk/defaults/mk.conf`.
 
 Typically, a feature will cause some programs to fail to build or work

Add markup to a filename
Index: wikisrc/pkgsrc/hardening.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc/hardening.mdwn,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- wikisrc/pkgsrc/hardening.mdwn	7 Nov 2017 01:49:31 -0000	1.25
+++ wikisrc/pkgsrc/hardening.mdwn	7 Nov 2017 01:51:03 -0000	1.26
@@ -9,7 +9,7 @@
 
 Mechanisms can be enabled individually in `mk.conf`, and are
 individually described below. They are sorted by whether thery are
-enabled by default, and then by their ordering in mk/defaults/mk.conf.
+enabled by default, and then by their ordering in `mk/defaults/mk.conf`.
 
 Typically, a feature will cause some programs to fail to build or work
 when first enabled. This can be due to latent problems in the

Remove doubled spaces
Index: wikisrc/pkgsrc/hardening.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc/hardening.mdwn,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- wikisrc/pkgsrc/hardening.mdwn	6 Nov 2017 00:04:07 -0000	1.24
+++ wikisrc/pkgsrc/hardening.mdwn	7 Nov 2017 01:49:31 -0000	1.25
@@ -8,12 +8,12 @@
 # Mechanisms
 
 Mechanisms can be enabled individually in `mk.conf`, and are
-individually described below.  They are sorted by whether thery are
+individually described below. They are sorted by whether thery are
 enabled by default, and then by their ordering in mk/defaults/mk.conf.
 
 Typically, a feature will cause some programs to fail to build or work
-when first enabled.  This can be due to latent problems in the
-program, and can be due to other reasons.  After enough testing to
+when first enabled. This can be due to latent problems in the
+program, and can be due to other reasons. After enough testing to
 have confidence that user problems will be quite rare, individual
 mechanisms will be enabled by default.
 
@@ -29,8 +29,8 @@
 library functions that do not have built-in bounds checking - but
 could in some cases.
 
-TODO: Explain FORTIFY_SOURCE 1 vs 2, and which is used.  Give a link
-to a good explanation of the technique.  Explain if this is gcc specific.
+TODO: Explain FORTIFY_SOURCE 1 vs 2, and which is used. Give a link
+to a good explanation of the technique. Explain if this is gcc specific.
 
 It has been enabled by default since pkgsrc-2017Q3.
 
@@ -38,8 +38,8 @@
 
 This enables a stack-smashing protection mitigation.
 
-TODO: Give a link to a good explanation.  Explain if this is gcc
-specific or also works with other compilers.  Explain if it is C/C++ only.
+TODO: Give a link to a good explanation. Explain if this is gcc
+specific or also works with other compilers. Explain if it is C/C++ only.
 
 It is enabled by default where known supported since pkgsrc-2017Q3.
 
@@ -50,16 +50,16 @@
 ### PKGSRC_MKPIE
 
 This requests the the creation of PIE (Position Independent
-Executables) for all executables.  The PIE mechanism is normally used
+Executables) for all executables. The PIE mechanism is normally used
 for shared libraries so that they can be loaded at differing addresses
-at runtime.  PIE itself does not have useful security properties.
+at runtime. PIE itself does not have useful security properties.
 However, 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
+time a program is run. This makes it more difficult for an attacker
 to guess addresses and thus makes exploits harder to construct.
 
 TODO/check: PIE executables will only be built for toolchains that
-support PIE and operating systems known to support ASLR.  Currently,
+support PIE and operating systems known to support ASLR. Currently,
 this means NetBSD 8 and later, i386 and amd64.
 
 ### PKGSRC_USE_RELRO

GR8 support landed in 8.99.5
Index: wikisrc/ports/evbarm/allwinner.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/allwinner.mdwn,v
retrieving revision 1.74
retrieving revision 1.75
diff -u -r1.74 -r1.75
--- wikisrc/ports/evbarm/allwinner.mdwn	6 Nov 2017 17:01:23 -0000	1.74
+++ wikisrc/ports/evbarm/allwinner.mdwn	6 Nov 2017 21:15:21 -0000	1.75
@@ -23,7 +23,7 @@
     <tr><td>sun4i</td><td>A10</td><td>8.99.3 and later</td><td><a href="https://www.olimex.com/Products/OLinuXino/A10/A10-OLinuXino-LIME/open-source-hardware">Olimex A10-OLinuXino-LIME</a><td></td></tr>
     <tr><td>sun5i</td><td>A10s</td><td>-</td><td></td></tr>
     <tr><td>sun5i</td><td>A13</td><td>8.99.2 and later</td><td><a href="https://www.olimex.com/Products/OLinuXino/A13/A13-OLinuXino/open-source-hardware">Olimex A13-OLinuXino</a>, <a href="https://www.olimex.com/Products/OLinuXino/A13/A13-OLinuXino-MICRO/open-source-hardware">Olimex A13-OLinuXino-MICRO</a></td></tr>
-    <tr><td>sun5i</td><td>GR8</td><td>-</td><td><a href="https://getchip.com/pages/chippro">C.H.I.P. Pro</a></td><td></td></tr>
+    <tr><td>sun5i</td><td>GR8</td><td>8.99.5</td><td><a href="https://getchip.com/pages/chippro">C.H.I.P. Pro</a></td><td></td></tr>
     <tr><td>sun5i</td><td>R8</td><td>8.99.2 and later</td><td><a href="https://getchip.com/pages/chip">C.H.I.P.</a>, <a href="https://getchip.com/pages/pocketchip">Pocket C.H.I.P.</a></td><td></td></tr>
     <tr><td>sun6i</td><td>A31</td><td>7.0 and later</td><td><a href="http://linux-sunxi.org/Merrii_Hummingbird_A31">Merrii Hummingbird A31</a></td><td></td></tr>
     <tr><td>sun6i</td><td>A31s</td><td>-</td><td></td><td></td></tr>

GR8 is not supported yet
Index: wikisrc/ports/evbarm/allwinner.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/allwinner.mdwn,v
retrieving revision 1.73
retrieving revision 1.74
diff -u -r1.73 -r1.74
--- wikisrc/ports/evbarm/allwinner.mdwn	6 Nov 2017 11:33:30 -0000	1.73
+++ wikisrc/ports/evbarm/allwinner.mdwn	6 Nov 2017 17:01:23 -0000	1.74
@@ -23,7 +23,7 @@
     <tr><td>sun4i</td><td>A10</td><td>8.99.3 and later</td><td><a href="https://www.olimex.com/Products/OLinuXino/A10/A10-OLinuXino-LIME/open-source-hardware">Olimex A10-OLinuXino-LIME</a><td></td></tr>
     <tr><td>sun5i</td><td>A10s</td><td>-</td><td></td></tr>
     <tr><td>sun5i</td><td>A13</td><td>8.99.2 and later</td><td><a href="https://www.olimex.com/Products/OLinuXino/A13/A13-OLinuXino/open-source-hardware">Olimex A13-OLinuXino</a>, <a href="https://www.olimex.com/Products/OLinuXino/A13/A13-OLinuXino-MICRO/open-source-hardware">Olimex A13-OLinuXino-MICRO</a></td></tr>
-    <tr><td>sun5i</td><td>GR8</td><td>8.99.2 and later</td><td><a href="https://getchip.com/pages/chippro">C.H.I.P. Pro</a></td><td></td></tr>
+    <tr><td>sun5i</td><td>GR8</td><td>-</td><td><a href="https://getchip.com/pages/chippro">C.H.I.P. Pro</a></td><td></td></tr>
     <tr><td>sun5i</td><td>R8</td><td>8.99.2 and later</td><td><a href="https://getchip.com/pages/chip">C.H.I.P.</a>, <a href="https://getchip.com/pages/pocketchip">Pocket C.H.I.P.</a></td><td></td></tr>
     <tr><td>sun6i</td><td>A31</td><td>7.0 and later</td><td><a href="http://linux-sunxi.org/Merrii_Hummingbird_A31">Merrii Hummingbird A31</a></td><td></td></tr>
     <tr><td>sun6i</td><td>A31s</td><td>-</td><td></td><td></td></tr>

add V3s to status table
Index: wikisrc/ports/evbarm/allwinner.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/allwinner.mdwn,v
retrieving revision 1.72
retrieving revision 1.73
diff -u -r1.72 -r1.73
--- wikisrc/ports/evbarm/allwinner.mdwn	6 Nov 2017 11:25:43 -0000	1.72
+++ wikisrc/ports/evbarm/allwinner.mdwn	6 Nov 2017 11:33:30 -0000	1.73
@@ -34,6 +34,7 @@
     <tr><td>sun8i</td><td>A83T</td><td>8.0 and later</td><td><a href="http://www.banana-pi.org/m3.html">Sinovoip Banana Pi BPI-M3</a></td><td></td></tr>
     <tr><td>sun8i</td><td>H2+</td><td>8.0 and later</td><td><a href="http://www.orangepi.org/orangepizero/">Xunlong Orange Pi Zero</a></td><td></td></tr>
     <tr><td>sun8i</td><td>H3</td><td>8.0 and later</td><td><a href="http://nanopi.io/nanopi-neo.html">FriendlyARM NanoPi NEO</a>, <a href="http://www.orangepi.org/orangepiplus2e/">Xunlong Orange Pi Plus 2E</a></td><td></td></tr>
+    <tr><td>sun8i</td><td>V3s</td><td>-</td><td><a href="https://www.indiegogo.com/projects/licheepi-zero-6-extensible-linux-module-on-finger-wifi-diy#/">Lichee Pi Zero</a></td><td></td></tr>
     <tr><td>sun9i</td><td>A80</td><td>8.0 and later</td><td><a href="http://linux-sunxi.org/Cubietech_Cubieboard4">Cubietech Cubieboard 4</a></td><td></td></tr>
     <tr><td>sun50i</td><td>A64</td><td>8.99.2 and later</td><td><a href="https://www.pine64.org/?page_id=1194">Pine64</a>, <a href="https://www.pine64.org/?page_id=3707">Pinebook</a></td><td>aarch32 mode</td></tr>
     <tr><td>sun50i</td><td>H5</td><td>8.99.4 and later</td><td><a href="http://www.friendlyarm.com/index.php?route=product/product&path=69&product_id=180">FriendlyARM NanoPi NEO2</td><td>aarch32 mode</td></tr>

add A13 and A33 example boards
Index: wikisrc/ports/evbarm/allwinner.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/allwinner.mdwn,v
retrieving revision 1.71
retrieving revision 1.72
diff -u -r1.71 -r1.72
--- wikisrc/ports/evbarm/allwinner.mdwn	24 Oct 2017 23:48:03 -0000	1.71
+++ wikisrc/ports/evbarm/allwinner.mdwn	6 Nov 2017 11:25:43 -0000	1.72
@@ -22,14 +22,14 @@
   <tbody>
     <tr><td>sun4i</td><td>A10</td><td>8.99.3 and later</td><td><a href="https://www.olimex.com/Products/OLinuXino/A10/A10-OLinuXino-LIME/open-source-hardware">Olimex A10-OLinuXino-LIME</a><td></td></tr>
     <tr><td>sun5i</td><td>A10s</td><td>-</td><td></td></tr>
-    <tr><td>sun5i</td><td>A13</td><td>8.99.2 and later</td><td></td></tr>
+    <tr><td>sun5i</td><td>A13</td><td>8.99.2 and later</td><td><a href="https://www.olimex.com/Products/OLinuXino/A13/A13-OLinuXino/open-source-hardware">Olimex A13-OLinuXino</a>, <a href="https://www.olimex.com/Products/OLinuXino/A13/A13-OLinuXino-MICRO/open-source-hardware">Olimex A13-OLinuXino-MICRO</a></td></tr>
     <tr><td>sun5i</td><td>GR8</td><td>8.99.2 and later</td><td><a href="https://getchip.com/pages/chippro">C.H.I.P. Pro</a></td><td></td></tr>
     <tr><td>sun5i</td><td>R8</td><td>8.99.2 and later</td><td><a href="https://getchip.com/pages/chip">C.H.I.P.</a>, <a href="https://getchip.com/pages/pocketchip">Pocket C.H.I.P.</a></td><td></td></tr>
     <tr><td>sun6i</td><td>A31</td><td>7.0 and later</td><td><a href="http://linux-sunxi.org/Merrii_Hummingbird_A31">Merrii Hummingbird A31</a></td><td></td></tr>
     <tr><td>sun6i</td><td>A31s</td><td>-</td><td></td><td></td></tr>
     <tr><td>sun7i</td><td>A20</td><td>7.0 and later</td><td><a href="https://linux-sunxi.org/Cubietech_Cubieboard2">Cubietech Cubieboard 2</a>, <a href="https://linux-sunxi.org/Cubietruck">Cubietech Cubietruck</a>, <a href="http://linux-sunxi.org/LeMaker_Banana_Pi">LeMaker Banana Pi</a></td><td></td></tr>
     <tr><td>sun8i</td><td>A23</td><td>-</td><td></td></tr>
-    <tr><td>sun8i</td><td>A33</td><td>-</td><td></td></tr>
+    <tr><td>sun8i</td><td>A33</td><td>-</td><td><a href="https://www.olimex.com/Products/OLinuXino/A33/A33-OLinuXino/open-source-hardware">Olimex A33-OLinuXino</a></td></tr>
     <tr><td>sun8i</td><td>R40</td><td>-</td><td><a href="http://www.banana-pi.org/m2u.html">Sinovoip Banana Pi BPI-M2U</a></td></tr>
     <tr><td>sun8i</td><td>A83T</td><td>8.0 and later</td><td><a href="http://www.banana-pi.org/m3.html">Sinovoip Banana Pi BPI-M3</a></td><td></td></tr>
     <tr><td>sun8i</td><td>H2+</td><td>8.0 and later</td><td><a href="http://www.orangepi.org/orangepizero/">Xunlong Orange Pi Zero</a></td><td></td></tr>

Add more text
Index: wikisrc/pkgsrc/hardening.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc/hardening.mdwn,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- wikisrc/pkgsrc/hardening.mdwn	5 Nov 2017 23:54:11 -0000	1.23
+++ wikisrc/pkgsrc/hardening.mdwn	6 Nov 2017 00:04:07 -0000	1.24
@@ -11,9 +11,15 @@
 individually described below.  They are sorted by whether thery are
 enabled by default, and then by their ordering in mk/defaults/mk.conf.
 
-For each, see the Caveats section below for an explanation of what
-might go wrong at compile time and at run time, and how to notice and
-address these problems.
+Typically, a feature will cause some programs to fail to build or work
+when first enabled.  This can be due to latent problems in the
+program, and can be due to other reasons.  After enough testing to
+have confidence that user problems will be quite rare, individual
+mechanisms will be enabled by default.
+
+For each mechanism, see the Caveats section below for an explanation
+of what might go wrong at compile time and at run time, and how to
+notice and address these problems.
 
 ## Enabled by default in the stable branch
 
@@ -61,6 +67,13 @@
 This also makes the exploitation of some security vulnerabilities more
 difficult in some cases.
 
+TODO: Explain gcc vs clang, and whether this has broad support or just
+a few platforms.
+
+TODO: Address "partial" vs "full"; which is this?
+
+TODO: Give a link to a comprehensive explanation.
+
 ### PKGSRC_USE_STACK_CHECK
 
 This uses `-fstack-check` with GCC for another stack protection

Explain more
Index: wikisrc/pkgsrc/hardening.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc/hardening.mdwn,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- wikisrc/pkgsrc/hardening.mdwn	5 Nov 2017 23:07:27 -0000	1.22
+++ wikisrc/pkgsrc/hardening.mdwn	5 Nov 2017 23:54:11 -0000	1.23
@@ -11,29 +11,60 @@
 individually described below.  They are sorted by whether thery are
 enabled by default, and then by their ordering in mk/defaults/mk.conf.
 
+For each, see the Caveats section below for an explanation of what
+might go wrong at compile time and at run time, and how to notice and
+address these problems.
+
 ## Enabled by default in the stable branch
 
-* `PKGSRC_USE_FORTIFY`: allows substitute wrappers to be used for commonly used
-  functions that do not bounds checking regularly - but could in some cases
-  (enabled by default since pkgsrc-2017Q3)
+### PKGSRC_USE_FORTIFY
+
+This allows substitute wrappers to be used for some commonly used
+library functions that do not have built-in bounds checking - but
+could in some cases.
+
+TODO: Explain FORTIFY_SOURCE 1 vs 2, and which is used.  Give a link
+to a good explanation of the technique.  Explain if this is gcc specific.
+
+It has been enabled by default since pkgsrc-2017Q3.
+
+### PKGSRC_USE_SSP
 
-* 'PKGSRC_USE_SSP`: enables a stack-smashing protection mitigation (enabled
-  by default where known supported since pkgsrc-2017Q3)
+This enables a stack-smashing protection mitigation.
+
+TODO: Give a link to a good explanation.  Explain if this is gcc
+specific or also works with other compilers.  Explain if it is C/C++ only.
+
+It is enabled by default where known supported since pkgsrc-2017Q3.
 
 ## Enabled by default in pkgsrc HEAD
 
 ## Not enabled by default
 
-* `PKGSRC_MKPIE`: forces the creation of PIE (Position Independent
-  Executables) when supported on the current platform.  With PIE
-  executables, a platform that supports ASLR will be able to randomize
-  the process layout.
+### PKGSRC_MKPIE
+
+This requests the the creation of PIE (Position Independent
+Executables) for all executables.  The PIE mechanism is normally used
+for shared libraries so that they can be loaded at differing addresses
+at runtime.  PIE itself does not have useful security properties.
+However, 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.
+
+TODO/check: PIE executables will only be built for toolchains that
+support PIE and operating systems known to support ASLR.  Currently,
+this means NetBSD 8 and later, i386 and amd64.
+
+### PKGSRC_USE_RELRO
+
+This also makes the exploitation of some security vulnerabilities more
+difficult in some cases.
 
-* `PKGSRC_USE_RELRO`: this also makes the exploitation of some security
-  vulnerabilities more difficult in some cases.
+### PKGSRC_USE_STACK_CHECK
 
-* `PKGSRC_USE_STACK_CHECK`: uses `-fstack-check` with GCC for another stack
-  protection mitigation.
+This uses `-fstack-check` with GCC for another stack protection
+mitigation.
 
 # Caveats
 

Explain a bit more
Index: wikisrc/pkgsrc/hardening.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc/hardening.mdwn,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- wikisrc/pkgsrc/hardening.mdwn	7 Sep 2017 11:32:21 -0000	1.21
+++ wikisrc/pkgsrc/hardening.mdwn	5 Nov 2017 23:07:27 -0000	1.22
@@ -1,19 +1,37 @@
 [[!meta title="Hardening pkgsrc"]]
 
-A number of mechanisms are available in [pkgsrc](https://www.pkgsrc.org/) to
-improve the security of the resulting system. They can be enabled individually
-in `mk.conf`, and consist of:
+A number of mechanisms are available in
+[pkgsrc](https://www.pkgsrc.org/) to improve the security of the
+resulting system. This page describes the mechanisms, and gives hints
+about detecting and fixing problems.
+
+# Mechanisms
+
+Mechanisms can be enabled individually in `mk.conf`, and are
+individually described below.  They are sorted by whether thery are
+enabled by default, and then by their ordering in mk/defaults/mk.conf.
+
+## Enabled by default in the stable branch
 
-* `PKGSRC_MKPIE`: forces the creation of PIE (Position Independent
-  Executables) when supported on the current platform. This option is necessary
-  to fully leverage ASLR as a mitigation for security vulnerabilities.
 * `PKGSRC_USE_FORTIFY`: allows substitute wrappers to be used for commonly used
   functions that do not bounds checking regularly - but could in some cases
   (enabled by default since pkgsrc-2017Q3)
+
+* 'PKGSRC_USE_SSP`: enables a stack-smashing protection mitigation (enabled
+  by default where known supported since pkgsrc-2017Q3)
+
+## Enabled by default in pkgsrc HEAD
+
+## Not enabled by default
+
+* `PKGSRC_MKPIE`: forces the creation of PIE (Position Independent
+  Executables) when supported on the current platform.  With PIE
+  executables, a platform that supports ASLR will be able to randomize
+  the process layout.
+
 * `PKGSRC_USE_RELRO`: this also makes the exploitation of some security
   vulnerabilities more difficult in some cases.
-* `PKGSRC_USE_SSP`: enables a stack-smashing protection mitigation (enabled
-  by default where known supported since pkgsrc-2017Q3)
+
 * `PKGSRC_USE_STACK_CHECK`: uses `-fstack-check` with GCC for another stack
   protection mitigation.
 

Add blank line before bulleted list
Index: wikisrc/ports/evbarm/raspberry_pi.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/raspberry_pi.mdwn,v
retrieving revision 1.65
retrieving revision 1.66
diff -u -r1.65 -r1.66
--- wikisrc/ports/evbarm/raspberry_pi.mdwn	28 Oct 2017 00:43:01 -0000	1.65
+++ wikisrc/ports/evbarm/raspberry_pi.mdwn	31 Oct 2017 11:32:36 -0000	1.66
@@ -76,6 +76,7 @@
 ### Building yourself
 
 Getting sources and building a release with build.sh is not special for evbarm.  Pick a CPU type alias and pass it to build.sh with -m.  Examples (the first two are equivalent):
+
  - ./build.sh -m earmv6hf -u release
  - ./build.sh -m evbarm -a earmv6hf -u release
  - ./build.sh -m evbarm -a earmv7hf -u release

Explain installation more
Index: wikisrc/ports/evbarm/raspberry_pi.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/raspberry_pi.mdwn,v
retrieving revision 1.64
retrieving revision 1.65
diff -u -r1.64 -r1.65
--- wikisrc/ports/evbarm/raspberry_pi.mdwn	22 Oct 2017 16:25:18 -0000	1.64
+++ wikisrc/ports/evbarm/raspberry_pi.mdwn	28 Oct 2017 00:43:01 -0000	1.65
@@ -55,32 +55,27 @@
 
 ## SD card structure
 
-The Raspberry Pi looks for firmware and a kernel on the first FAT32
-partition of the uSD card.  The NetBSD kernel will then use the FFS
-partition as the root filesystem.
+The Raspberry Pi looks for firmware and kernel.img on the first FAT32 partition of the uSD card.  A separate kernel (kernel7.img) is used on RPI2 and RPI3.
 
-A 2 GB card is the smallest workable size.  The NetBSD filesystem will
-be expanded to fit on larger cards.
+The NetBSD kernel will then use the FFS partition as the root filesystem.
+
+A 2 GB card is the smallest workable size.  The NetBSD filesystem will be expanded to fit.
 
 ## Choosing a version
 
-First, decide if you want to install a formal release (7.1), a stable
-branch build (netbsd-7, netbsd-8), or current.  Note that 7.1 predates
-Raspberry Pi 3 support.  For people who don't know how to choose among
-those, netbsd-8 is probably best.
+First, decide if you want to install a formal release (7.1), a stable branch build (netbsd-7, netbsd-8), or NetBSD-current.  Note that 7.1 predates Raspberry Pi 3 support.  For people who don't know how to choose among those, netbsd-8 is probably best.
+
+See also "ebijun's image", below, which is NetBSD-current and includes packages.
 
 ## Getting bits to install
 
 You can either build a release yourself with build.sh, or get one from the NetBSD FTP servers.
 
-Both will provide rpi.img.gz and rpi_inst.img.gz.  Each is an image to
-be written to a uSD card, and has a FAT32 partition for booting.  In
-rpi.img.gz, there is also an FFS partition for NetBSD.
+Both will provide rpi.img.gz and rpi_inst.img.gz.  Each is an image to be written to a uSD card, and has a FAT32 partition for booting.  In rpi.img.gz, there is also an FFS partition for NetBSD.
 
 ### Building yourself
 
-Getting sources and building a release with build.sh is not special for evbarm.
-Pick a CPU type alias and pass it to build.sh with -m.  Examples:
+Getting sources and building a release with build.sh is not special for evbarm.  Pick a CPU type alias and pass it to build.sh with -m.  Examples (the first two are equivalent):
  - ./build.sh -m earmv6hf -u release
  - ./build.sh -m evbarm -a earmv6hf -u release
  - ./build.sh -m evbarm -a earmv7hf -u release
@@ -95,9 +90,9 @@
  - The not-yet-released stable build directory will be under netbsd-8/YYYYMMDDHHMMZ/ (for example, http://nyftp.netbsd.org/pub/NetBSD-daily/netbsd-8/201710211010Z/evbarm-earmv6hf/binary/gzimg/)
  - The HEAD/current directory build will be under HEAD/YYYYMMDDHHMMZ/ (for example, http://nyftp.netbsd.org/pub/NetBSD-daily/HEAD/201710202210Z/evbarm-earmv7hf/binary/gzimg/)
 
-## Installing to uSD
+## Preparing a uSD card
 
-Once you have rpi.img.gz, put it on a uSD card using gunzip and dd, for example:
+Once you have rpi.img.gz (or rpi_inst), put it on a uSD card using gunzip and dd, for example:
 
  - gunzip rpi.img.gz
  - dd if=rpi.i7mg of=/dev/disk1
@@ -113,9 +108,13 @@
 
    In minicom, run "minicom -s" and set hardware flow control to "no"
 
+### Enabling ssh
+
+If you want to enable ssh with the standard image, so that you can log in over the net without either a serial or HDMI console, mount the ffs partition, place /root/.ssh/authorized_keys, uncomment PermitRootLogin in /etc/ssh/sshd_config, and comment out the rc_configure=NO in /etc/rc.conf.  Besides having to find the IP address, you will have to wait for the partition resizing and reboot.
+
 ### Installation with sshramdisk image
 
-build.sh (and hence the FTP site) also creates an image 'rpi_inst.img.gz' specifically for installation without HDMI or a serial console.  To use this method, write that image to a uSD card as above, and then:
+build.sh (and hence the FTP site) also creates an image 'rpi_inst.img.gz' specifically for installation without HDMI or a serial console.  Note that this image is much smaller and that you will need to fetch the sets over the network.  To use this method, write that image to a uSD card as above, and then:
 
  - Ensure that you have a lan with a DHCP server.
  - Connect an Ethernet cable from the RPI to the LAN.

Add BSDCan 2018 to `Future Events'.
Index: wikisrc/events.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/events.mdwn,v
retrieving revision 1.51
retrieving revision 1.52
diff -u -r1.51 -r1.52
--- wikisrc/events.mdwn	27 Sep 2017 20:32:55 -0000	1.51
+++ wikisrc/events.mdwn	27 Oct 2017 11:02:30 -0000	1.52
@@ -39,6 +39,18 @@
 possible audience.
 
 
+### `Jun 2018` - BSDCan 2018, Ottawa, Canada
+
+*June 6 - 9, 2018, University of Ottawa, Ottawa, Canada*
+
+[BSDCan](https://www.bsdcan.org/2018/), a BSD conference held in
+Ottawa, Canada, quickly established itself as the technical conference
+for people working on and with 4.4BSD based operating systems and
+related projects. The organizers have found a fantastic formula
+that appeals to a wide range of people from extreme novices to
+advanced developers.
+
+
 Past Events
 -----------
 

Add R40 to device table (not currently supported)
Index: wikisrc/ports/evbarm/allwinner.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/allwinner.mdwn,v
retrieving revision 1.70
retrieving revision 1.71
diff -u -r1.70 -r1.71
--- wikisrc/ports/evbarm/allwinner.mdwn	20 Oct 2017 22:32:20 -0000	1.70
+++ wikisrc/ports/evbarm/allwinner.mdwn	24 Oct 2017 23:48:03 -0000	1.71
@@ -30,6 +30,7 @@
     <tr><td>sun7i</td><td>A20</td><td>7.0 and later</td><td><a href="https://linux-sunxi.org/Cubietech_Cubieboard2">Cubietech Cubieboard 2</a>, <a href="https://linux-sunxi.org/Cubietruck">Cubietech Cubietruck</a>, <a href="http://linux-sunxi.org/LeMaker_Banana_Pi">LeMaker Banana Pi</a></td><td></td></tr>
     <tr><td>sun8i</td><td>A23</td><td>-</td><td></td></tr>
     <tr><td>sun8i</td><td>A33</td><td>-</td><td></td></tr>
+    <tr><td>sun8i</td><td>R40</td><td>-</td><td><a href="http://www.banana-pi.org/m2u.html">Sinovoip Banana Pi BPI-M2U</a></td></tr>
     <tr><td>sun8i</td><td>A83T</td><td>8.0 and later</td><td><a href="http://www.banana-pi.org/m3.html">Sinovoip Banana Pi BPI-M3</a></td><td></td></tr>
     <tr><td>sun8i</td><td>H2+</td><td>8.0 and later</td><td><a href="http://www.orangepi.org/orangepizero/">Xunlong Orange Pi Zero</a></td><td></td></tr>
     <tr><td>sun8i</td><td>H3</td><td>8.0 and later</td><td><a href="http://nanopi.io/nanopi-neo.html">FriendlyARM NanoPi NEO</a>, <a href="http://www.orangepi.org/orangepiplus2e/">Xunlong Orange Pi Plus 2E</a></td><td></td></tr>

Explain 64-bit RPI3 support future location
Index: wikisrc/ports/evbarm/raspberry_pi.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/raspberry_pi.mdwn,v
retrieving revision 1.63
retrieving revision 1.64
diff -u -r1.63 -r1.64
--- wikisrc/ports/evbarm/raspberry_pi.mdwn	22 Oct 2017 00:39:08 -0000	1.63
+++ wikisrc/ports/evbarm/raspberry_pi.mdwn	22 Oct 2017 16:25:18 -0000	1.64
@@ -41,6 +41,7 @@
 
  - USB (host); isochronous transfers.
  - WiFi
+ - Raspberry Pi 3 in 64-bit mode.  (Note that this will be provided by the evbarm64 port, rather than evbarm.)
 
 # CPU types
 
@@ -48,7 +49,7 @@
 
  - Raspberry Pi 1 uses "earmv6hf".
  - Raspberry Pi 2 uses "earmv7hf".
- - Raspberry Pi 3 uses "earmv7hf".  (NetBSD does not yet have 64-bit support.)
+ - Raspberry Pi 3 uses "earmv7hf".
 
 # Installation
 

Fix explanation of FAT32/FFS.
(The _inst image has no FFS.)
Members: 
	ports/evbarm/raspberry_pi.mdwn:1.62->1.63 

Index: wikisrc/ports/evbarm/raspberry_pi.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/raspberry_pi.mdwn,v
retrieving revision 1.62
retrieving revision 1.63
diff -u -r1.62 -r1.63
--- wikisrc/ports/evbarm/raspberry_pi.mdwn	22 Oct 2017 00:06:31 -0000	1.62
+++ wikisrc/ports/evbarm/raspberry_pi.mdwn	22 Oct 2017 00:39:08 -0000	1.63
@@ -58,6 +58,9 @@
 partition of the uSD card.  The NetBSD kernel will then use the FFS
 partition as the root filesystem.
 
+A 2 GB card is the smallest workable size.  The NetBSD filesystem will
+be expanded to fit on larger cards.
+
 ## Choosing a version
 
 First, decide if you want to install a formal release (7.1), a stable
@@ -70,8 +73,8 @@
 You can either build a release yourself with build.sh, or get one from the NetBSD FTP servers.
 
 Both will provide rpi.img.gz and rpi_inst.img.gz.  Each is an image to
-be written to a uSD card, and it has a FAT32 partition for booting and
-an FFS partition for NetBSD.
+be written to a uSD card, and has a FAT32 partition for booting.  In
+rpi.img.gz, there is also an FFS partition for NetBSD.
 
 ### Building yourself
 

describe boot partition
Index: wikisrc/ports/evbarm/raspberry_pi.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/raspberry_pi.mdwn,v
retrieving revision 1.61
retrieving revision 1.62
diff -u -r1.61 -r1.62
--- wikisrc/ports/evbarm/raspberry_pi.mdwn	21 Oct 2017 23:58:28 -0000	1.61
+++ wikisrc/ports/evbarm/raspberry_pi.mdwn	22 Oct 2017 00:06:31 -0000	1.62
@@ -52,6 +52,14 @@
 
 # Installation
 
+## SD card structure
+
+The Raspberry Pi looks for firmware and a kernel on the first FAT32
+partition of the uSD card.  The NetBSD kernel will then use the FFS
+partition as the root filesystem.
+
+## Choosing a version
+
 First, decide if you want to install a formal release (7.1), a stable
 branch build (netbsd-7, netbsd-8), or current.  Note that 7.1 predates
 Raspberry Pi 3 support.  For people who don't know how to choose among

Minor fixes
Index: wikisrc/ports/evbarm/raspberry_pi.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/raspberry_pi.mdwn,v
retrieving revision 1.60
retrieving revision 1.61
diff -u -r1.60 -r1.61
--- wikisrc/ports/evbarm/raspberry_pi.mdwn	21 Oct 2017 23:54:22 -0000	1.60
+++ wikisrc/ports/evbarm/raspberry_pi.mdwn	21 Oct 2017 23:58:28 -0000	1.61
@@ -85,7 +85,7 @@
 
 ## Installing to uSD
 
-Once you have rpi.img.gz, put it on a uSD card using gunzip and dd, for examples
+Once you have rpi.img.gz, put it on a uSD card using gunzip and dd, for example:
 
  - gunzip rpi.img.gz
  - dd if=rpi.i7mg of=/dev/disk1
@@ -105,7 +105,8 @@
 
 build.sh (and hence the FTP site) also creates an image 'rpi_inst.img.gz' specifically for installation without HDMI or a serial console.  To use this method, write that image to a uSD card as above, and then:
 
- - Connect Ethernet Cable to RPI.
+ - Ensure that you have a lan with a DHCP server.
+ - Connect an Ethernet cable from the RPI to the LAN.
  - After starting DHCP client, SSH login to with user "sysinst", and password "netbsd".
    - Be careful to note the ip address given during DHCP so you don't lose your connection
    - Also for after the sysinst is done and the system reboots

Add gunzip. Minor formatting fixes
Index: wikisrc/ports/evbarm/raspberry_pi.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/raspberry_pi.mdwn,v
retrieving revision 1.59
retrieving revision 1.60
diff -u -r1.59 -r1.60
--- wikisrc/ports/evbarm/raspberry_pi.mdwn	21 Oct 2017 23:52:26 -0000	1.59
+++ wikisrc/ports/evbarm/raspberry_pi.mdwn	21 Oct 2017 23:54:22 -0000	1.60
@@ -87,18 +87,19 @@
 
 Once you have rpi.img.gz, put it on a uSD card using gunzip and dd, for examples
 
- - dd if=rpi.img of=/dev/disk1
+ - gunzip rpi.img.gz
+ - dd if=rpi.i7mg of=/dev/disk1
 
 ### Serial Console
 
 By default the rpi.img is set to use the HDMI output.  If you wish to use a serial console, first mount the FAT32 partition and then
 edit cmdline.txt and remove '"console=fb"'.
 
-    - Most (all?) USB-to-TTL serial adapters only connect Tx, Rx and ground, and do not connect any flow control lines. An effect of missing flow control is that you see console output, but cannot type anything. If so, adjust your serial console application's flow control settings to "none".
+ - Most (all?) USB-to-TTL serial adapters only connect Tx, Rx and ground, and do not connect any flow control lines. An effect of missing flow control is that you see console output, but cannot type anything. If so, adjust your serial console application's flow control settings to "none".
 
-      In Kermit, the command is "set flow none".
+   In Kermit, the command is "set flow none".
 
-      In minicom, run "minicom -s" and set hardware flow control to "no"
+   In minicom, run "minicom -s" and set hardware flow control to "no"
 
 ### Installation with sshramdisk image
 

adjust lists
Index: wikisrc/ports/evbarm/raspberry_pi.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/raspberry_pi.mdwn,v
retrieving revision 1.58
retrieving revision 1.59
diff -u -r1.58 -r1.59
--- wikisrc/ports/evbarm/raspberry_pi.mdwn	21 Oct 2017 23:50:25 -0000	1.58
+++ wikisrc/ports/evbarm/raspberry_pi.mdwn	21 Oct 2017 23:52:26 -0000	1.59
@@ -46,9 +46,9 @@
 
 Note that one can also use code for earlier models on later models.
 
-  - Raspberry Pi 1 uses "earmv6hf".
-  - Raspberry Pi 2 uses "earmv7hf".
-  - Raspberry Pi 3 uses "earmv7hf".  (NetBSD does not yet have 64-bit support.)
+ - Raspberry Pi 1 uses "earmv6hf".
+ - Raspberry Pi 2 uses "earmv7hf".
+ - Raspberry Pi 3 uses "earmv7hf".  (NetBSD does not yet have 64-bit support.)
 
 # Installation
 
@@ -69,32 +69,32 @@
 
 Getting sources and building a release with build.sh is not special for evbarm.
 Pick a CPU type alias and pass it to build.sh with -m.  Examples:
-    - ./build.sh -m earmv6hf -u release
-    - ./build.sh -m evbarm -a earmv6hf -u release
-    - ./build.sh -m evbarm -a earmv7hf -u release
+ - ./build.sh -m earmv6hf -u release
+ - ./build.sh -m evbarm -a earmv6hf -u release
+ - ./build.sh -m evbarm -a earmv7hf -u release
 
 ### NetBSD FTP servers
 
 NetBSD provides nightly builds on [nyftp.netbsd.org](http://nyftp.netbsd.org/pub/NetBSD-daily/).  These are equivalent to building yourself.
 
-    - The 'evbarm-earmv6hf/binary/gzimg/' directory contains an rpi.img file that can be used as a single image for both boards.
-    - The 'evbarm-earmv7hf/binary/gzimg/' directory contains an armv7.img file that is optimized for Raspberry Pi 2.
-    - The stable build directory will be under netbsd-7/YYYYMMDDHHMMZ/ (for example, http://nyftp.netbsd.org/pub/NetBSD-daily/netbsd-7/201710201440Z/evbarm-earmv6hf/binary/gzimg)    
-    - The not-yet-released stable build directory will be under netbsd-8/YYYYMMDDHHMMZ/ (for example, http://nyftp.netbsd.org/pub/NetBSD-daily/netbsd-8/201710211010Z/evbarm-earmv6hf/binary/gzimg/)
-    - The HEAD/current directory build will be under HEAD/YYYYMMDDHHMMZ/ (for example, http://nyftp.netbsd.org/pub/NetBSD-daily/HEAD/201710202210Z/evbarm-earmv7hf/binary/gzimg/)
+ - The 'evbarm-earmv6hf/binary/gzimg/' directory contains an rpi.img file that can be used as a single image for both boards.
+ - The 'evbarm-earmv7hf/binary/gzimg/' directory contains an armv7.img file that is optimized for Raspberry Pi 2.
+ - The stable build directory will be under netbsd-7/YYYYMMDDHHMMZ/ (for example, http://nyftp.netbsd.org/pub/NetBSD-daily/netbsd-7/201710201440Z/evbarm-earmv6hf/binary/gzimg)    
+ - The not-yet-released stable build directory will be under netbsd-8/YYYYMMDDHHMMZ/ (for example, http://nyftp.netbsd.org/pub/NetBSD-daily/netbsd-8/201710211010Z/evbarm-earmv6hf/binary/gzimg/)
+ - The HEAD/current directory build will be under HEAD/YYYYMMDDHHMMZ/ (for example, http://nyftp.netbsd.org/pub/NetBSD-daily/HEAD/201710202210Z/evbarm-earmv7hf/binary/gzimg/)
 
 ## Installing to uSD
 
 Once you have rpi.img.gz, put it on a uSD card using gunzip and dd, for examples
 
-   - dd if=rpi.img of=/dev/disk1
+ - dd if=rpi.img of=/dev/disk1
 
 ### Serial Console
 
 By default the rpi.img is set to use the HDMI output.  If you wish to use a serial console, first mount the FAT32 partition and then
 edit cmdline.txt and remove '"console=fb"'.
 
-   - Most (all?) USB-to-TTL serial adapters only connect Tx, Rx and ground, and do not connect any flow control lines. An effect of missing flow control is that you see console output, but cannot type anything. If so, adjust your serial console application's flow control settings to "none".
+    - Most (all?) USB-to-TTL serial adapters only connect Tx, Rx and ground, and do not connect any flow control lines. An effect of missing flow control is that you see console output, but cannot type anything. If so, adjust your serial console application's flow control settings to "none".
 
       In Kermit, the command is "set flow none".
 

Update installation instructions and discuss 7/8/current.
Index: wikisrc/ports/evbarm/raspberry_pi.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/raspberry_pi.mdwn,v
retrieving revision 1.57
retrieving revision 1.58
diff -u -r1.57 -r1.58
--- wikisrc/ports/evbarm/raspberry_pi.mdwn	21 Oct 2017 22:51:21 -0000	1.57
+++ wikisrc/ports/evbarm/raspberry_pi.mdwn	21 Oct 2017 23:50:25 -0000	1.58
@@ -52,20 +52,47 @@
 
 # Installation
 
- - The automatic nightly builds  on [nyftp.netbsd.org](http://nyftp.netbsd.org/pub/NetBSD-daily/) provide image files that can be used for installation. The Raspberry Pi and Pi 2 ports are part of the NetBSD 7 release.
+First, decide if you want to install a formal release (7.1), a stable
+branch build (netbsd-7, netbsd-8), or current.  Note that 7.1 predates
+Raspberry Pi 3 support.  For people who don't know how to choose among
+those, netbsd-8 is probably best.
+
+## Getting bits to install
+
+You can either build a release yourself with build.sh, or get one from the NetBSD FTP servers.
+
+Both will provide rpi.img.gz and rpi_inst.img.gz.  Each is an image to
+be written to a uSD card, and it has a FAT32 partition for booting and
+an FFS partition for NetBSD.
+
+### Building yourself
+
+Getting sources and building a release with build.sh is not special for evbarm.
+Pick a CPU type alias and pass it to build.sh with -m.  Examples:
+    - ./build.sh -m earmv6hf -u release
+    - ./build.sh -m evbarm -a earmv6hf -u release
+    - ./build.sh -m evbarm -a earmv7hf -u release
+
+### NetBSD FTP servers
+
+NetBSD provides nightly builds on [nyftp.netbsd.org](http://nyftp.netbsd.org/pub/NetBSD-daily/).  These are equivalent to building yourself.
+
     - The 'evbarm-earmv6hf/binary/gzimg/' directory contains an rpi.img file that can be used as a single image for both boards.
-    - The 'evbarm-earmv7hf/binary/gzimg/' directory, as of August 6th 2015, contains an armv7.img file that is optimized for Raspberry Pi 2.
-    - The stable build directory will be under netbsd-7/YYYYMMDDHHMMZ/ (for example, http://nyftp.netbsd.org/pub/NetBSD-daily/netbsd-7/201412161700Z/evbarm-earmv6hf/binary/gzimg/)
-    - The HEAD/current directory build will be under HEAD/YYYYMMDDHHMMZ/ (for example, http://nyftp.netbsd.org/pub/NetBSD-daily/netbsd-7/201508062150Z/evbarm-earminstv7hf/binary/gzimg/)
-  - You can build your own version of these images using (for example) './build.sh -m evbarm -a earmv6hf -u release', or './build.sh -m evbarm -a earmv7hf -u release'
-   - <i>gunzip and dd</i> this img to your sd card. For example,
+    - The 'evbarm-earmv7hf/binary/gzimg/' directory contains an armv7.img file that is optimized for Raspberry Pi 2.
+    - The stable build directory will be under netbsd-7/YYYYMMDDHHMMZ/ (for example, http://nyftp.netbsd.org/pub/NetBSD-daily/netbsd-7/201710201440Z/evbarm-earmv6hf/binary/gzimg)    
+    - The not-yet-released stable build directory will be under netbsd-8/YYYYMMDDHHMMZ/ (for example, http://nyftp.netbsd.org/pub/NetBSD-daily/netbsd-8/201710211010Z/evbarm-earmv6hf/binary/gzimg/)
+    - The HEAD/current directory build will be under HEAD/YYYYMMDDHHMMZ/ (for example, http://nyftp.netbsd.org/pub/NetBSD-daily/HEAD/201710202210Z/evbarm-earmv7hf/binary/gzimg/)
+
+## Installing to uSD
 
-	   dd if=rpi.img of=/dev/disk1
+Once you have rpi.img.gz, put it on a uSD card using gunzip and dd, for examples
 
- - Using a serial console
-   - By default the rpi.img is set to use the HDMI output; to change to using a serial console first mount rpi.img (it's a FAT filesystem)
+   - dd if=rpi.img of=/dev/disk1
 
-	   edit cmdline.txt and remove '"console=fb"'
+### Serial Console
+
+By default the rpi.img is set to use the HDMI output.  If you wish to use a serial console, first mount the FAT32 partition and then
+edit cmdline.txt and remove '"console=fb"'.
 
    - Most (all?) USB-to-TTL serial adapters only connect Tx, Rx and ground, and do not connect any flow control lines. An effect of missing flow control is that you see console output, but cannot type anything. If so, adjust your serial console application's flow control settings to "none".
 
@@ -73,9 +100,10 @@
 
       In minicom, run "minicom -s" and set hardware flow control to "no"
 
-## Installation with sshramdisk image
+### Installation with sshramdisk image
+
+build.sh (and hence the FTP site) also creates an image 'rpi_inst.img.gz' specifically for installation without HDMI or a serial console.  To use this method, write that image to a uSD card as above, and then:
 
- - You may use the  rpi_inst.img.gz file created by an evbarm build.
  - Connect Ethernet Cable to RPI.
  - After starting DHCP client, SSH login to with user "sysinst", and password "netbsd".
    - Be careful to note the ip address given during DHCP so you don't lose your connection
@@ -84,9 +112,11 @@
 
 ## Installation via ebijun's image
 
-Jun Ebihara provides an install image for Raspberry Pi that includes
-packages.  It is based on NetBSD-current.  This image is typically
-updated every few weeks.
+As an alternative to the standard installation images, Jun Ebihara
+provides an install image for Raspberry Pi that includes packages.  It
+is based on NetBSD-current and is built for earmv6hf, and thus will
+work on Raspberry Pi 1, 2 and 3.  This image is typically updated
+every few weeks.
 
  - [https://github.com/ebijun/NetBSD/blob/master/RPI/RPIimage/Image/README](https://github.com/ebijun/NetBSD/blob/master/RPI/RPIimage/Image/README)
 

Add cputype information
Index: wikisrc/ports/evbarm/raspberry_pi.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/raspberry_pi.mdwn,v
retrieving revision 1.56
retrieving revision 1.57
diff -u -r1.56 -r1.57
--- wikisrc/ports/evbarm/raspberry_pi.mdwn	14 Oct 2017 15:08:18 -0000	1.56
+++ wikisrc/ports/evbarm/raspberry_pi.mdwn	21 Oct 2017 22:51:21 -0000	1.57
@@ -42,6 +42,14 @@
  - USB (host); isochronous transfers.
  - WiFi
 
+# CPU types
+
+Note that one can also use code for earlier models on later models.
+
+  - Raspberry Pi 1 uses "earmv6hf".
+  - Raspberry Pi 2 uses "earmv7hf".
+  - Raspberry Pi 3 uses "earmv7hf".  (NetBSD does not yet have 64-bit support.)
+
 # Installation
 
  - The automatic nightly builds  on [nyftp.netbsd.org](http://nyftp.netbsd.org/pub/NetBSD-daily/) provide image files that can be used for installation. The Raspberry Pi and Pi 2 ports are part of the NetBSD 7 release.

fix wording
Index: wikisrc/ports/evbarm.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm.mdwn,v
retrieving revision 1.43
retrieving revision 1.44
diff -u -r1.43 -r1.44
--- wikisrc/ports/evbarm.mdwn	21 Oct 2017 22:43:03 -0000	1.43
+++ wikisrc/ports/evbarm.mdwn	21 Oct 2017 22:45:12 -0000	1.44
@@ -29,7 +29,7 @@
 there is hardware floating point.  By default the CPU type is "earm",
 and this implies little endian (el when explicitly stated), and soft
 (emulated) floating point.  Another example, suitable for Raspberry PI
-2, is earmv7hf, which is the v7 instruction support, little endian,
+2, is earmv7hf, which is the v7 instruction set, little endian,
 and hardware floating point.
 
 Typically, various boards are best compiled with a CPU type that

Extend cpu discussion
Index: wikisrc/ports/evbarm.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm.mdwn,v
retrieving revision 1.42
retrieving revision 1.43
diff -u -r1.42 -r1.43
--- wikisrc/ports/evbarm.mdwn	21 Oct 2017 22:39:47 -0000	1.42
+++ wikisrc/ports/evbarm.mdwn	21 Oct 2017 22:43:03 -0000	1.43
@@ -26,13 +26,23 @@
 
 The evbarm port can be built with a variety of CPU options.  There are
 three main variables: the instruction set, the endianness, and whether
-there is hardware flaoting point.  By default the CPU type is "earm".
+there is hardware floating point.  By default the CPU type is "earm",
+and this implies little endian (el when explicitly stated), and soft
+(emulated) floating point.  Another example, suitable for Raspberry PI
+2, is earmv7hf, which is the v7 instruction support, little endian,
+and hardware floating point.
 
 Typically, various boards are best compiled with a CPU type that
 matches the board's CPU and floating point support, but generally a
 lower CPU instruction set version is workable on a newer board.  See
 build.sh and look for aliases for the evbarm port.
 
+### Kernels and userland
+
+The evbarm userland can be used on any system that can run code of the
+CPU type used for the build.  Typically, a particular board requires a
+kernel for that board.
+
 ### Board specific information
  - [[Allwinner sunxi family SoCs|Allwinner]]
  - [[BeagleBone and BeagleBone Black|BeagleBone]]

Describe CPU type notion
Index: wikisrc/ports/evbarm.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm.mdwn,v
retrieving revision 1.41
retrieving revision 1.42
diff -u -r1.41 -r1.42
--- wikisrc/ports/evbarm.mdwn	10 Oct 2017 10:43:51 -0000	1.41
+++ wikisrc/ports/evbarm.mdwn	21 Oct 2017 22:39:47 -0000	1.42
@@ -22,6 +22,17 @@
 
 Matt Thomas is the maintainer of NetBSD/evbarm.
 
+### CPU types
+
+The evbarm port can be built with a variety of CPU options.  There are
+three main variables: the instruction set, the endianness, and whether
+there is hardware flaoting point.  By default the CPU type is "earm".
+
+Typically, various boards are best compiled with a CPU type that
+matches the board's CPU and floating point support, but generally a
+lower CPU instruction set version is workable on a newer board.  See
+build.sh and look for aliases for the evbarm port.
+
 ### Board specific information
  - [[Allwinner sunxi family SoCs|Allwinner]]
  - [[BeagleBone and BeagleBone Black|BeagleBone]]

Added a comment: doesn't work
--- /dev/null	2018-01-17 03:40:50.000000000 +0000
+++ wikisrc/tutorials/how_to_install_netbsd_on_hpcarm/comment_1_4ccf2cd6224e5e97c2fca71a02944ae7._comment	2018-01-17 03:45:38.000000000 +0000
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/ceCmhGBukoQo3T2YQY9d06pQzt76i4Jp#a1439"
+ nickname="Nigel"
+ subject="doesn't work"
+ date="2017-10-21T14:02:25Z"
+ content="""
+# disklabel -i -I sd0
+disklabel: /dev/rsd0: Device not configured
+
+"""]]

Fast Ethernet (sun4i/sun7i) is supported now
Index: wikisrc/ports/evbarm/allwinner.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/allwinner.mdwn,v
retrieving revision 1.69
retrieving revision 1.70
diff -u -r1.69 -r1.70
--- wikisrc/ports/evbarm/allwinner.mdwn	11 Oct 2017 10:55:19 -0000	1.69
+++ wikisrc/ports/evbarm/allwinner.mdwn	20 Oct 2017 22:32:20 -0000	1.70
@@ -58,7 +58,7 @@
     <tr><td>Crypto engine</td><td>-</td><td></td></tr>
     <tr><td>CSI</td><td>-</td><td></td></tr>
     <tr><td>DMA</td><td>Yes</td><td></td></tr>
-    <tr><td>Fast Ethernet (sun4i/sun7i)</td><td>-</td><td></td></tr>
+    <tr><td>Fast Ethernet (sun4i/sun7i)</td><td>Yes</td><td></td></tr>
     <tr><td>Framebuffer</td><td>Yes</td><td>Uses simplefb configured by bootloader</td></tr>
     <tr><td>Gigabit Ethernet (sun6i/sun7i/sun9i)</td><td>Yes</td><td></td></tr>
     <tr><td>Gigabit Ethernet (sun8i/sun50i)</td><td>Yes</td><td></td></tr>

Typo
Index: wikisrc/tutorials/pkgsrc/cross_compile_distcc.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/pkgsrc/cross_compile_distcc.mdwn,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- wikisrc/tutorials/pkgsrc/cross_compile_distcc.mdwn	22 Feb 2012 21:36:40 -0000	1.4
+++ wikisrc/tutorials/pkgsrc/cross_compile_distcc.mdwn	19 Oct 2017 23:31:44 -0000	1.5
@@ -3,7 +3,7 @@
 You may want to use several machines to speed up your *pkgsrc* builds, but
 as those computers are not running NetBSD, you may think they are useless as
 build-helpers. This is where enters NetBSD's *cross-compiling* system in
-conjuction with [distcc](http://code.google.com/p/distcc/).
+conjunction with [distcc](http://code.google.com/p/distcc/).
 
 ### A classic scenario
 

Remove SCTP from list.
Index: wikisrc/projects/ideas.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/ideas.mdwn,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- wikisrc/projects/ideas.mdwn	17 Feb 2016 06:32:39 -0000	1.5
+++ wikisrc/projects/ideas.mdwn	17 Oct 2017 19:36:48 -0000	1.6
@@ -43,8 +43,6 @@
 
 1. *difficult* Write new DTrace provider for watching locks(lockdebug), userspace or any other from available ones <http://wikis.sun.com/display/DTrace/Providers>
 
-1. SCTP support
-
 1. Change keyboard drivers to emit USB scancodes in event mode so for example ADB or Sun keyboards can coexist with things like USB keypads on the same mux and we don't need a separate InputDevice section in xorg.conf for each. This should be relatively easy.
 
 1. Port FreeBSD's DAHDI implementation to NetBSD, so that Asterisk on NetBSD will have hardware support.  FreeBSD's DAHDI implementation is SMP, so this isn't a simple port.  Also, just about every FreeBSD kernel API related to device drivers and modules are different from the NetBSD equivalent meaning that one needs to basically know both kernels.

fix link
Index: wikisrc/ports/evbarm/raspberry_pi.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/raspberry_pi.mdwn,v
retrieving revision 1.55
retrieving revision 1.56
diff -u -r1.55 -r1.56
--- wikisrc/ports/evbarm/raspberry_pi.mdwn	14 Oct 2017 15:06:30 -0000	1.55
+++ wikisrc/ports/evbarm/raspberry_pi.mdwn	14 Oct 2017 15:08:18 -0000	1.56
@@ -80,7 +80,7 @@
 packages.  It is based on NetBSD-current.  This image is typically
 updated every few weeks.
 
- - https://github.com/ebijun/NetBSD/blob/master/RPI/RPIimage/Image/README
+ - [https://github.com/ebijun/NetBSD/blob/master/RPI/RPIimage/Image/README](https://github.com/ebijun/NetBSD/blob/master/RPI/RPIimage/Image/README)
 
 ## Updating the kernel
 

Remove incorporated comment
--- wikisrc/ports/evbarm/raspberry_pi/comment_19_82864947fcb8737650f36e90ed1ed9b8._comment	2018-01-17 03:45:39.000000000 +0000
+++ /dev/null	2018-01-17 03:40:50.000000000 +0000
@@ -1,9 +0,0 @@
-[[!comment format=mdwn
- username="https://me.yahoo.com/a/UM0fy451yPQ9iZSVKjtjNcPifA--#1f032"
- nickname="Fredrik Pettai"
- subject="Lots of useful info regarding NetBSD on RPI collected by Jun Ebihara"
- date="2017-02-04T20:35:28Z"
- content="""
-See Jun Ebihara's GitHub page where lots of stuff regarding NetBSD on RPI is collected:
-<https://github.com/ebijun/NetBSD/blob/master/RPI/RPIimage/Image/README>
-"""]]

Add link to ebijun's image.
Index: wikisrc/ports/evbarm/raspberry_pi.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/raspberry_pi.mdwn,v
retrieving revision 1.54
retrieving revision 1.55
diff -u -r1.54 -r1.55
--- wikisrc/ports/evbarm/raspberry_pi.mdwn	14 Oct 2017 14:54:58 -0000	1.54
+++ wikisrc/ports/evbarm/raspberry_pi.mdwn	14 Oct 2017 15:06:30 -0000	1.55
@@ -48,7 +48,7 @@
     - The 'evbarm-earmv6hf/binary/gzimg/' directory contains an rpi.img file that can be used as a single image for both boards.
     - The 'evbarm-earmv7hf/binary/gzimg/' directory, as of August 6th 2015, contains an armv7.img file that is optimized for Raspberry Pi 2.
     - The stable build directory will be under netbsd-7/YYYYMMDDHHMMZ/ (for example, http://nyftp.netbsd.org/pub/NetBSD-daily/netbsd-7/201412161700Z/evbarm-earmv6hf/binary/gzimg/)
-    - The HEAD/current directory build will be under HEAD/YYYYMMDDHHMMZ/ (for example, http://nyftp.netbsd.org/pub/NetBSD-daily/netbsd-7/201508062150Z/evbarm-earmv7hf/binary/gzimg/)
+    - The HEAD/current directory build will be under HEAD/YYYYMMDDHHMMZ/ (for example, http://nyftp.netbsd.org/pub/NetBSD-daily/netbsd-7/201508062150Z/evbarm-earminstv7hf/binary/gzimg/)
   - You can build your own version of these images using (for example) './build.sh -m evbarm -a earmv6hf -u release', or './build.sh -m evbarm -a earmv7hf -u release'
    - <i>gunzip and dd</i> this img to your sd card. For example,
 
@@ -74,6 +74,14 @@
    - Also for after the sysinst is done and the system reboots
  - sysinst started!
 
+## Installation via ebijun's image
+
+Jun Ebihara provides an install image for Raspberry Pi that includes
+packages.  It is based on NetBSD-current.  This image is typically
+updated every few weeks.
+
+ - https://github.com/ebijun/NetBSD/blob/master/RPI/RPIimage/Image/README
+
 ## Updating the kernel
 
  - Build a new kernel, e.g. using build.sh. It will tell you where the ELF version of the kernel is, e.g.

demote "what doesn't work" to level 2
Index: wikisrc/ports/evbarm/raspberry_pi.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/raspberry_pi.mdwn,v
retrieving revision 1.53
retrieving revision 1.54
diff -u -r1.53 -r1.54
--- wikisrc/ports/evbarm/raspberry_pi.mdwn	14 Oct 2017 14:53:46 -0000	1.53
+++ wikisrc/ports/evbarm/raspberry_pi.mdwn	14 Oct 2017 14:54:58 -0000	1.54
@@ -10,7 +10,7 @@
 
 <small>([Raspberry Pi image](http://www.flickr.com/photos/42325803@N07/8118758647/) by Christopher Lee used under CC-By-2.0 license)</small>
 
-# What works
+# What works (and what doesn't yet)
 
 ## NetBSD 7 before July, 2017
 
@@ -37,7 +37,7 @@
  - Raspberry Pi 3 bluetooth
  - Raspberry Pi 3 new SD host controller driver
 
-# What needs work
+## What needs work
 
  - USB (host); isochronous transfers.
  - WiFi

reorganize to focus more on users
Index: wikisrc/ports/evbarm/raspberry_pi.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/raspberry_pi.mdwn,v
retrieving revision 1.52
retrieving revision 1.53
diff -u -r1.52 -r1.53
--- wikisrc/ports/evbarm/raspberry_pi.mdwn	8 Oct 2017 23:26:29 -0000	1.52
+++ wikisrc/ports/evbarm/raspberry_pi.mdwn	14 Oct 2017 14:53:46 -0000	1.53
@@ -10,7 +10,40 @@
 
 <small>([Raspberry Pi image](http://www.flickr.com/photos/42325803@N07/8118758647/) by Christopher Lee used under CC-By-2.0 license)</small>
 
+# What works
+
+## NetBSD 7 before July, 2017
+
+ - RaspberryPi 1, and 2 (including SMP)
+ - multi-user boot with root on SD card
+ - serial or graphics console (with EDID query / parsing)
+ - DMA controller driver and sdhc(4) support
+ - Audio: works. man page missing.
+ - I²C: works, could use enhancements, man page
+ - GPIO
+ - RNG
+ - SPI: could use enhancements, man page
+ - GPU (VCHIQ) - 3D and video decode. man page missing.
+ - USB (host) - dwctwo(4)
+ - USB Ethernet - usmsc(4)
+ - X windows.
+
+## NetBSD 7 after July, 2017 and NetBSD 8
+
+ - Raspberry Pi 3 (excluding WiFi and bluetooth)
+
+## NetBSD current
+
+ - Raspberry Pi 3 bluetooth
+ - Raspberry Pi 3 new SD host controller driver
+
+# What needs work
+
+ - USB (host); isochronous transfers.
+ - WiFi
+
 # Installation
+
  - The automatic nightly builds  on [nyftp.netbsd.org](http://nyftp.netbsd.org/pub/NetBSD-daily/) provide image files that can be used for installation. The Raspberry Pi and Pi 2 ports are part of the NetBSD 7 release.
     - The 'evbarm-earmv6hf/binary/gzimg/' directory contains an rpi.img file that can be used as a single image for both boards.
     - The 'evbarm-earmv7hf/binary/gzimg/' directory, as of August 6th 2015, contains an armv7.img file that is optimized for Raspberry Pi 2.
@@ -32,7 +65,8 @@
 
       In minicom, run "minicom -s" and set hardware flow control to "no"
 
-# Installation with sshramdisk image
+## Installation with sshramdisk image
+
  - You may use the  rpi_inst.img.gz file created by an evbarm build.
  - Connect Ethernet Cable to RPI.
  - After starting DHCP client, SSH login to with user "sysinst", and password "netbsd".
@@ -40,27 +74,8 @@
    - Also for after the sysinst is done and the system reboots
  - sysinst started!
 
-# Updating the firmware
-
-You probably don't want to do this. Firmware updates can break things,
-and the latest firmware that's been tested is already included in the
-NetBSD build you installed.
-
-If you're feeling adventurous (or are the port maintainer), here's what
-to test whenever you try new firmware:
-
-- Audio
-- OMXPlayer (and [[!template id=man name="vchiq"]])
-- Serial/framebuffer console
-- CPU frequency scaling
-
-That goes for all of `rpi[0123]`.
+## Updating the kernel
 
-Upstream firmware releases are
-[on GitHub](https://github.com/raspberrypi/firmware/releases).
-Copy all files except `kernel*.img` into `/boot` and reboot.
-
-# Updating the kernel
  - Build a new kernel, e.g. using build.sh. It will tell you where the ELF version of the kernel is, e.g.
 
          ...
@@ -73,6 +88,9 @@
  - reboot
 
 # Wireless Networking
+
+  Note that the built-in WiFi in the RPI3 is not yet supported.
+
  - A Realtek 802.11n USB adaptor configures as urtwn(4).
    - Configure with wpa_supplicant in /etc/rc.conf -
 
@@ -115,32 +133,26 @@
 $ retroarch --appendconfig gamepad.cfg -L /usr/pkg/lib/libretro/gambatte_libretro.so game.gbc
 """]]
 
-# What works
+# Developer notes
 
-## NetBSD 7 before July, 2017
+These notes are for people working on improvements to RPI support in NetBSD.
 
- - RaspberryPi 1, and 2 (including SMP)
- - multi-user boot with root on SD card
- - serial or graphics console (with EDID query / parsing)
- - DMA controller driver and sdhc(4) support
- - Audio: works. man page missing.
- - I²C: works, could use enhancements, man page
- - GPIO
- - RNG
- - SPI: could use enhancements, man page
- - GPU (VCHIQ) - 3D and video decode. man page missing.
- - USB (host) - dwctwo(4)
- - USB Ethernet - usmsc(4)
- - X windows.
+## Updating the firmware
 
-## NetBSD 7 after July, 2017 and NetBSD 8
+You probably don't want to do this. Firmware updates can break things,
+and the latest firmware that's been tested is already included in the
+NetBSD build you installed.
 
- - Raspberry Pi 3 (excluding wifi and bluetooth)
+If you're feeling adventurous (or are the port maintainer), here's what
+to test whenever you try new firmware:
 
-## NetBSD current
+- Audio
+- OMXPlayer (and [[!template id=man name="vchiq"]])
+- Serial/framebuffer console
+- CPU frequency scaling
 
- - Raspberry Pi 3 bluetooth
- - Raspberry Pi 3 new SD host controller driver
+That goes for all of `rpi[0123]`.
 
-# What needs work
- - USB (host); isochronous transfers.
+Upstream firmware releases are
+[on GitHub](https://github.com/raspberrypi/firmware/releases).
+Copy all files except `kernel*.img` into `/boot` and reboot.

Use markdown lists to ease a bit the readability, NFCI.
Index: wikisrc/tutorials/how_to_enable_and_run_dtrace.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_enable_and_run_dtrace.mdwn,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- wikisrc/tutorials/how_to_enable_and_run_dtrace.mdwn	13 Oct 2017 04:38:31 -0000	1.21
+++ wikisrc/tutorials/how_to_enable_and_run_dtrace.mdwn	13 Oct 2017 08:24:18 -0000	1.22
@@ -51,13 +51,13 @@
 
 For example, add the following to `/etc/modules.conf` (the file may not exist already on a system):
     
-    solaris
-    dtrace
-    dtrace_sdt
-    dtrace_fbt
-    dtrace_lockstat
-    dtrace_profile
-    dtrace_syscall
+- `solaris`
+- `dtrace`
+- `dtrace_sdt`
+- `dtrace_fbt`
+- `dtrace_lockstat`
+- `dtrace_profile`
+- `dtrace_syscall`
     
 A `dtrace` device node is created automatically in `/dev/dtrace` when the modules are loaded into place.
     
@@ -136,8 +136,8 @@
 
 At present, the following scripts are installed in `/usr/sbin`: 
 
-    dtruss - An implementation of the truss utility in DTrace which traces the system calls
-    made by a process
-    execsnoop - snoop on execution of processes as they occur
-    opensnoop - snoop on openning of files as they occur
-    procsystime -  print process system call time details.
+- `dtruss` - An implementation of the truss utility in DTrace which traces the system calls
+made by a process
+- `execsnoop` - snoop on execution of processes as they occur
+- `opensnoop` - snoop on openning of files as they occur
+- `procsystime` -  print process system call time details.

Remove duplication mistake.
State the path the scripts are installed in.
Index: wikisrc/tutorials/how_to_enable_and_run_dtrace.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_enable_and_run_dtrace.mdwn,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- wikisrc/tutorials/how_to_enable_and_run_dtrace.mdwn	13 Oct 2017 04:27:54 -0000	1.20
+++ wikisrc/tutorials/how_to_enable_and_run_dtrace.mdwn	13 Oct 2017 04:38:31 -0000	1.21
@@ -134,7 +134,7 @@
 Starting with NetBSD-8, on builds where `MKDTRACE=yes` is set, scripts from
 [Brendan Gregg's DTrace toolkit](https://github.com/opendtrace/toolkit/) are installed in base as standard.
 
-At present the following scripts are installed are installed:
+At present, the following scripts are installed in `/usr/sbin`: 
 
     dtruss - An implementation of the truss utility in DTrace which traces the system calls
     made by a process

Break up listing to separate lines?
Index: wikisrc/tutorials/how_to_enable_and_run_dtrace.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_enable_and_run_dtrace.mdwn,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- wikisrc/tutorials/how_to_enable_and_run_dtrace.mdwn	13 Oct 2017 04:25:27 -0000	1.19
+++ wikisrc/tutorials/how_to_enable_and_run_dtrace.mdwn	13 Oct 2017 04:27:54 -0000	1.20
@@ -136,8 +136,8 @@
 
 At present the following scripts are installed are installed:
 
-dtruss - An implementation of the truss utility in DTrace which traces the system calls
-made by a process
-execsnoop - snoop on execution of processes as they occur
-opensnoop - snoop on openning of files as they occur
-procsystime -  print process system call time details.
+    dtruss - An implementation of the truss utility in DTrace which traces the system calls
+    made by a process
+    execsnoop - snoop on execution of processes as they occur
+    opensnoop - snoop on openning of files as they occur
+    procsystime -  print process system call time details.

Mention scripts installed from DTrace Toolkit.
Index: wikisrc/tutorials/how_to_enable_and_run_dtrace.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_enable_and_run_dtrace.mdwn,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- wikisrc/tutorials/how_to_enable_and_run_dtrace.mdwn	8 Apr 2017 21:38:18 -0000	1.18
+++ wikisrc/tutorials/how_to_enable_and_run_dtrace.mdwn	13 Oct 2017 04:25:27 -0000	1.19
@@ -128,3 +128,16 @@
     
 
 Start the script running (dtrace -s sleep.d) and then execute a "sleep 2" in another shell. 
+
+## Tools included base
+
+Starting with NetBSD-8, on builds where `MKDTRACE=yes` is set, scripts from
+[Brendan Gregg's DTrace toolkit](https://github.com/opendtrace/toolkit/) are installed in base as standard.
+
+At present the following scripts are installed are installed:
+
+dtruss - An implementation of the truss utility in DTrace which traces the system calls
+made by a process
+execsnoop - snoop on execution of processes as they occur
+opensnoop - snoop on openning of files as they occur
+procsystime -  print process system call time details.

Add a comment
Contact | Disclaimer | Copyright © 1994-2018 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
NetBSD® is a registered trademark of The NetBSD Foundation, Inc.