Index: wikisrc/ports/evbarm/raspberry_pi.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/raspberry_pi.mdwn,v
retrieving revision 1.155
retrieving revision 1.156
diff -u -r1.155 -r1.156
--- wikisrc/ports/evbarm/raspberry_pi.mdwn	18 Feb 2024 18:32:33 -0000	1.155
+++ wikisrc/ports/evbarm/raspberry_pi.mdwn	10 Oct 2024 11:06:18 -0000	1.156
@@ -25,7 +25,7 @@
 While NetBSD 8 is of historic interest only, we document what was working in 8.
 
  - RPI1, RPI2, RPI2-1.2, RPI3, RPI3+ (except RPI3 builtin WiFi and bluetooth)
- - RPI0 and RPI0W are expected to work (without WiFi, and one needs fdt files \todo where from?)
+ - RPI0 and RPI0W are expected to work
  - multiple processors on RPI2/RPI3
  - boots normally to multiuser, with FAT32 boot partition on uSD
  - root filesystem can be uSD or USB-attached mass storage
@@ -50,7 +50,7 @@
 
 ## NetBSD 10
 
- - RPI4 general support (but there are issues)
+ - RPI4 general support (UEFI firmware required)
  - RPI4 ethernet (Broadcom GENETv5) (but the man page for genet(4) is missing)
  - RPI3/RPI4 audio with aarch64 kernels (Previously the driver was only included with 32-bit (ARMv7/ARMv6) kernels, and now works [due to dma-ranges](//mail-index.NetBSD.org/source-changes-d/2021/01/22/msg013133.html).
  - builtin bluetooth on RPI3 (RPI0W? RPI4?) 
@@ -59,7 +59,7 @@
 
 ## NetBSD current
 
- - \todo Is anything supported in current that doesn't work in 10?
+- RPI5 general support (UEFI firmware required)
 
 ## What needs documenting if it works
 

Index: wikisrc/tutorials.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials.mdwn,v
retrieving revision 1.50
retrieving revision 1.51
diff -u -r1.50 -r1.51
--- wikisrc/tutorials.mdwn	23 Mar 2024 18:09:10 -0000	1.50
+++ wikisrc/tutorials.mdwn	8 Oct 2024 11:43:26 -0000	1.51
@@ -44,7 +44,7 @@
 * [[Testing new wifi]]
 * [[Converting drivers to the new wifi stack]]
 * [[Converting USB drivers to usbwifi(9)]]
-* (Current state of wifi drivers)[../wifi driver state matrix]
+* [Current state of wifi drivers](../wifi_driver_state_matrix)
 
 ### Testing
 * [[atf]]

Index: wikisrc/ports/riscv.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/riscv.mdwn,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- wikisrc/ports/riscv.mdwn	29 Sep 2024 07:26:52 -0000	1.8
+++ wikisrc/ports/riscv.mdwn	29 Sep 2024 13:18:16 -0000	1.9
@@ -6,7 +6,8 @@
 NetBSD/riscv is a nascent port of NetBSD to RISC-V. Interested individuals can
 subscribe to the port-riscv mailing list.
 
-NetBSD/riscv64 now works under qemu.
+RISC-V support is only available as part of NetBSD-CURRENT and has not
+yet been published in a stable release.
 
 [[!toc levels=3]]
 """
@@ -32,6 +33,9 @@
 * StarFive VisionFive 2
 
 ### QEMU
+
+NetBSD/riscv64 now works under qemu.  
+
 See the [[NetBSD/riscv under QEMU|qemu_riscv]] page for instructions on how to get started with QEMU.
 """
 

Index: wikisrc/ports/riscv.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/riscv.mdwn,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- wikisrc/ports/riscv.mdwn	30 Mar 2024 19:27:00 -0000	1.7
+++ wikisrc/ports/riscv.mdwn	29 Sep 2024 07:26:52 -0000	1.8
@@ -22,6 +22,15 @@
 
 Most RISC-V boards require a board-specific U-Boot image. A list of supported boards will appear here.
 
+#### Allwinner D1-based devices
+
+* MangoPi MQ Pro
+
+#### StarFive JH71XX-based devices
+
+* BeagleBoard BeagleV
+* StarFive VisionFive 2
+
 ### QEMU
 See the [[NetBSD/riscv under QEMU|qemu_riscv]] page for instructions on how to get started with QEMU.
 """

Index: wikisrc/projects/project/xen-drmkms.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/xen-drmkms.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/projects/project/xen-drmkms.mdwn	11 Aug 2019 13:35:19 -0000	1.2
+++ wikisrc/projects/project/xen-drmkms.mdwn	20 Sep 2024 17:35:43 -0000	1.3
@@ -16,12 +16,16 @@
 description="""
 Abstract:
 
-Make the dom0 kernel use and provide drm(4) support. This enable
-gui use of dom0.
+Make the dom0 kernel use and provide drm(4) support.
+This will enable 3d acceleration within of dom0, making it more
+reasonable to run a dom0 instead of GENERIC for a workstation that
+also supports domUs.
+
 
 Deliverables:
 
-Functioning X server using native kernel style drmkms support.
+Functioning X server using native kernel-style drmkms support.
+This must function at least in a PVH style dom0 kernel.
 
 Implementation:
 

Index: wikisrc/projects/project/xen-domU-pv-on-hvm.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/xen-domU-pv-on-hvm.mdwn,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- wikisrc/projects/project/xen-domU-pv-on-hvm.mdwn	19 Aug 2015 00:12:08 -0000	1.1
+++ wikisrc/projects/project/xen-domU-pv-on-hvm.mdwn	20 Sep 2024 17:24:06 -0000	1.2
@@ -9,6 +9,8 @@
 mentors="""
 """
 
+done_by=""
+
 category="kernel"
 difficulty="hard"
 duration="48 hours"

Index: wikisrc/projects/project/xen-dom0-smp.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/xen-dom0-smp.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/projects/project/xen-dom0-smp.mdwn	15 Feb 2018 00:40:11 -0000	1.2
+++ wikisrc/projects/project/xen-dom0-smp.mdwn	20 Sep 2024 17:21:38 -0000	1.3
@@ -9,6 +9,8 @@
 mentors="""
 """
 
+done_by=""
+
 category="kernel"
 difficulty="medium"
 duration="64 hours"

Members: 
	ports/xen/howto.mdwn:1.267->1.268 

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.267
retrieving revision 1.268
diff -u -r1.267 -r1.268
--- wikisrc/ports/xen/howto.mdwn	19 Sep 2024 23:32:28 -0000	1.267
+++ wikisrc/ports/xen/howto.mdwn	20 Sep 2024 17:07:43 -0000	1.268
@@ -71,9 +71,9 @@
 [[!table data="""
 Style of guest	|dom0 can be?	|dom0 can support?	|domU can be?	|needs Hardware Virtualization Support
 PV		|yes		|yes			|yes		|no
-PVH		|not yet	|10/current		|10/current	|yes
+PVH		|10+(exp)	|10+			|10+		|yes
 HVM		|N/A		|yes			|yes		|yes
-PVHVM		|N/A		|yes			|10/current	|yes
+PVHVM		|N/A		|yes			|10+		|yes
 """]]
 
 In PV (paravirtualized) mode, the guest OS does not attempt to access
@@ -176,9 +176,8 @@
 
 NetBSD 8 and later as a dom0 supports running HVM domUs.
 
-NetBSD 10 and later as a domU can be run in PVH and PVHVM modes.
-
-NetBSD up to and including NetBSD 9 as a dom0 cannot safely run SMP
+NetBSD 10 and later as a domU can be run in PVH and PVHVM modes, and
+s a dom0 can (experimentally) be run in PVH mode.etBSD up to and including NetBSD 9 as a dom0 cannot safely run SMP
 (due to inadequate locking).  NetBSD 10 supports SMP in dom0, and
 XEN3_DOM0 includes "options MULTIPROCESSOR".
 
@@ -286,23 +285,45 @@
 
 First, get a PV dom0 working following the instructions above.
 
-Then, create a copy of the boot line, adding `dom0=pvh` near
-`dom0_mem`, and instead of loading a `XEN3_DOM0` kernel, load a
-generic kernel with modifications:
-  - disable i915drmkms, radeon and nouveau (probably, not necessarily?)
-  - probably include [[!template id=programlisting text="""
+While GENERIC works as a PV guest, it does not have DOM0 support
+(which is present in XEN3_DOM0, but that's reduced to be PV only).
+Prepare a GENERIC kernel with the additions necessary to be a DOM0,
+which consists of code to deal with DOM0 requests, and PV drivers for
+the dom0 part of events, network interfaces, and disks.
+[[!template id=programlisting text="""
 options		DOM0OPS
 pseudo-device	xenevt
 pseudo-device	xvif
 pseudo-device	xbdback
 
+# Likely only necessary if you have these devices and booting with them crashes.
+no i915drmkms*     at pci?
+no radeon*         at pci?
+no nouveau*        at pci?
+no options      DRM_LEGACY
+
 no options DDB_COMMANDONENTER
 #options DDB_COMMANDONENTER="trace"
 """]]
 
-\todo Explain whether the DOM0OPS and xen pseudodevices are necessary,
-and if so why they aren't in GENERIC (or why there isn't a
-XEN3_DOM0PVH).
+As an alternative to disabling graphic devices in the kernel, add to /boot.cfg:
+[[!template id=programlisting text="""
+userconf=disable i915drmkms*
+userconf=disable nouveau*
+userconf=disable radeon*
+"""]]
+
+Then, create a copy of the boot line, adding `dom0=pvh` near
+`dom0_mem`, and instead of loading a `XEN3_DOM0` kernel, load the
+modified GENERIC.
+
+GENERIC with DOM0OPS and the extra dom0-side PV drivers should work
+fine on bare metal and if not it's a bug -- but so far we have no
+reports either way.  In the glorious future, it will be normal to run
+a dom0 as PVH (because it's faster), and to run a domU as PVH or PVHVM
+(because it's faster), and thus: - DOM00PS and xenevt, xvif, and
+xbdback will be in GENERIC - XEN3_DOM* kernels will be non-preferred
+and perhaps not used much
 
 \todo Validate that these instructions are correct, and that they work.
 

Members: 
	ports/xen/howto.mdwn:1.266->1.267 

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.266
retrieving revision 1.267
diff -u -r1.266 -r1.267
--- wikisrc/ports/xen/howto.mdwn	14 Sep 2024 23:08:44 -0000	1.266
+++ wikisrc/ports/xen/howto.mdwn	19 Sep 2024 23:32:28 -0000	1.267
@@ -819,7 +819,14 @@
 is to keep "type" lines near "kernel" lines, as they tend to require
 being changed aat the same time.
 
+## Varying drivers in the domU
 
+For a NetBSD domU using PV drivers (PV, PVH, PVHVM), the disks will
+appear as xbdN.  For one using emulated drivers (HVM), the disks will
+appear as wdN.  See fstab(5) which explains how to use "ROOT." instead
+of xbd0/wd0. enabling switching modes without changing /etc/fstab.
+
+\todo Explain if there is a similar approach for network interfaces.
 
 ## Creating a NetBSD PV domU
 
@@ -922,8 +929,10 @@
 
 ## Creating a NetBSD PVH dom0
 
-\todo This might or might not work in current.
-\todo The following instructions are likely wrong.
+\todo Expand to say NetBSD 10 and later.
+
+\todo Include needing to add DOM0 OPS and the dom0-flavored
+psuedodevices to GENERIC.
 
 In boot.cfg, add dom0=pvh (dom0=pv is the default).  Configure GENERIC
 instead of XEN3_DOM0.

Members: 
	projects/project/xen-dom0-pvh.mdwn:1.1->1.2(DEAD) 
	projects/project/xen-domU-pvops-pvh.mdwn:1.1->1.2(DEAD) 

--- wikisrc/projects/project/xen-dom0-pvh.mdwn	2024-09-14 23:13:26.108199717 +0000
+++ /dev/null	2024-09-14 23:13:03.356880356 +0000
@@ -1,48 +0,0 @@
-[[!template id=project
-
-title="Dom0 hvm container support (PVH)"
-
-contact="""
-[port-xen](mailto:[email protected])
-"""
-
-mentors="""
-"""
-
-category="kernel"
-difficulty="hard"
-duration="32 hours"
-
-description="""
-Abstract:
-
-NetBSD Dom0 kernels currently operate in fully PV mode.
-On amd64, this has the same performance drawbacks as for PV
-mode in domU.
-Instead, PVH mode provides a HVM container over pagetable
-management, while virtualising everything else. This mode is
-available on dom0, we attempt to support it.
-
-Note: Xen/Linux is moving to this dom0 pvh support model.
-
-Deliverables: PVH mode dom0 operation.
-
-Implementation:
-
-This project depends on the domU pvops/pvh
-project. The main work is in configuration and
-testing related (bringing in native device drivers as
-well as backend ones).
-
-The bootstrap path may need to be tweaked for dom0
-specific things.
-
-Dependencies:    This project depends on completion of the domU
-pvops/pvh project. 
-This project can enable the NetBSD/Xen/ARM dom0 port.
-
-See <http://wiki.xenproject.org/wiki/Xen_Project_Hypervisor_Roadmap/4.6>
-"""
-
-]]
-
--- wikisrc/projects/project/xen-domU-pvops-pvh.mdwn	2024-09-14 23:13:26.148771010 +0000
+++ /dev/null	2024-09-14 23:13:03.356880356 +0000
@@ -1,46 +0,0 @@
-[[!template id=project
-
-title="pvops/pvh - Runtime Paravirtualised/Native Boot with PV drivers in an HVM container in PVH mode"
-
-contact="""
-[port-xen](mailto:[email protected])
-"""
-
-mentors="""
-"""
-
-category="kernel"
-difficulty="hard"
-duration="48 hours"
-
-description="""
-Abstract: This is the final step towards PVH mode. This is relevant
-only for DomU.
-Xen is moving to this eventual dom0 pvh support model.
-This project depends on completion of pv-on-hvm.
-
-Deliverables: 
-
-* operational interrupt (event) handling
-* PV only drivers.
-
-Implementation: 
-
-Following on from the pv-on-hvm project, this project removes all
-remaining dependencies on native drivers. All drivers are PV
-only. Interrupt setup and handling is via the "event" mechanism.
-
-Scope (Timelines):
-
-This project has some uncertainty based on the change in the interrupt
-mechanism. Since the interrupt mechanism moves from apic + IDT based,
-to event based, there's room for debug/testing spillover.
-
-Further, private APIs may need to be developed to parition the pv and
-native setup and management code for both mechanisms.
-
-See: <http://wiki.xenproject.org/wiki/Virtualization_Spectrum#Almost_fully_PV:_PVH_mode>
-"""
-
-]]
-

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.265
retrieving revision 1.266
diff -u -r1.265 -r1.266
--- wikisrc/ports/xen/howto.mdwn	14 Sep 2024 23:01:55 -0000	1.265
+++ wikisrc/ports/xen/howto.mdwn	14 Sep 2024 23:08:44 -0000	1.266
@@ -280,6 +280,9 @@
 [caveats](https://xenbits.xen.org/docs/4.19-testing/SUPPORT.html#x86pvh),
 notably that SR-IOV is missing and PCI passthrough does not work.
 
+Note that while Xen upstream calls it experimental, the NetBSD/xen
+community seems to have one person who has gotten it to work and one
+who is trying but so far not succeeded.  This is a clue!
 
 First, get a PV dom0 working following the instructions above.
 

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.264
retrieving revision 1.265
diff -u -r1.264 -r1.265
--- wikisrc/ports/xen/howto.mdwn	14 Sep 2024 17:51:35 -0000	1.264
+++ wikisrc/ports/xen/howto.mdwn	14 Sep 2024 23:01:55 -0000	1.265
@@ -271,14 +271,35 @@
 trouble at some point, and keeping an up-to-date GENERIC for use in
 fixing problems is the standard prudent approach.
 
-### Setting up PVH
+### Setting up the dom0 as PVH
 
-A PVH dom0 is currently experimental.  First, get a PV dom0 working
-following the instructions above.
+A PVH dom0 is currently experimental, as of Xen 4.18.  For 4.19 and
+later, not yet in pkgsrc, it is
+[supported](https://xenbits.xen.org/docs/unstable/support-matrix.html
+) with
+[caveats](https://xenbits.xen.org/docs/4.19-testing/SUPPORT.html#x86pvh),
+notably that SR-IOV is missing and PCI passthrough does not work.
+
+
+First, get a PV dom0 working following the instructions above.
 
 Then, create a copy of the boot line, adding `dom0=pvh` near
 `dom0_mem`, and instead of loading a `XEN3_DOM0` kernel, load a
-generic kernel.
+generic kernel with modifications:
+  - disable i915drmkms, radeon and nouveau (probably, not necessarily?)
+  - probably include [[!template id=programlisting text="""
+options		DOM0OPS
+pseudo-device	xenevt
+pseudo-device	xvif
+pseudo-device	xbdback
+
+no options DDB_COMMANDONENTER
+#options DDB_COMMANDONENTER="trace"
+"""]]
+
+\todo Explain whether the DOM0OPS and xen pseudodevices are necessary,
+and if so why they aren't in GENERIC (or why there isn't a
+XEN3_DOM0PVH).
 
 \todo Validate that these instructions are correct, and that they work.
 

Index: wikisrc/ports/amd64.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/amd64.mdwn,v
retrieving revision 1.39
retrieving revision 1.40
diff -u -r1.39 -r1.40
--- wikisrc/ports/amd64.mdwn	14 Sep 2024 22:35:21 -0000	1.39
+++ wikisrc/ports/amd64.mdwn	14 Sep 2024 22:48:08 -0000	1.40
@@ -31,9 +31,11 @@
 multiprocessor (SMP) Opteron configurations. Since the <a class="ulink" href="http://www.NetBSD.org/releases/formal-2.0/NetBSD-2.0.html" target="_top">release of NetBSD 2.0</a>,
 it is a completely supported platform.
 
+### Running NetBSD/amd64 on Cloud Services
+
 Links to pages about running NetBSD on cloud services:
-  - https://www.netmeister.org/blog/netbsd-on-linode.html
-  - https://cloudbsd.xyz/main/
+  * https://www.netmeister.org/blog/netbsd-on-linode.html
+  * https://cloudbsd.xyz/main/
 
 See also the [xen HOWTO](../xen/howto.mdwn) which discusses several
 xen-based VPS providers.

Index: wikisrc/ports/amd64.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/amd64.mdwn,v
retrieving revision 1.38
retrieving revision 1.39
diff -u -r1.38 -r1.39
--- wikisrc/ports/amd64.mdwn	14 Sep 2024 22:31:54 -0000	1.38
+++ wikisrc/ports/amd64.mdwn	14 Sep 2024 22:35:21 -0000	1.39
@@ -30,7 +30,6 @@
 The port is fully functional. It has been tested on single-CPU and
 multiprocessor (SMP) Opteron configurations. Since the <a class="ulink" href="http://www.NetBSD.org/releases/formal-2.0/NetBSD-2.0.html" target="_top">release of NetBSD 2.0</a>,
 it is a completely supported platform.
-"""
 
 Links to pages about running NetBSD on cloud services:
   - https://www.netmeister.org/blog/netbsd-on-linode.html
@@ -38,5 +37,6 @@
 
 See also the [xen HOWTO](../xen/howto.mdwn) which discusses several
 xen-based VPS providers.
+"""
 ]]
 [[!tag tier1port]]

Index: wikisrc/ports/amd64.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/amd64.mdwn,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- wikisrc/ports/amd64.mdwn	30 Mar 2024 19:27:00 -0000	1.37
+++ wikisrc/ports/amd64.mdwn	14 Sep 2024 22:31:54 -0000	1.38
@@ -32,5 +32,11 @@
 it is a completely supported platform.
 """
 
+Links to pages about running NetBSD on cloud services:
+  - https://www.netmeister.org/blog/netbsd-on-linode.html
+  - https://cloudbsd.xyz/main/
+
+See also the [xen HOWTO](../xen/howto.mdwn) which discusses several
+xen-based VPS providers.
 ]]
 [[!tag tier1port]]

Members: 
	ports/xen/howto.mdwn:1.263->1.264 

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.263
retrieving revision 1.264
diff -u -r1.263 -r1.264
--- wikisrc/ports/xen/howto.mdwn	9 Sep 2024 14:47:25 -0000	1.263
+++ wikisrc/ports/xen/howto.mdwn	14 Sep 2024 17:51:35 -0000	1.264
@@ -216,14 +216,14 @@
 ### Building Xen
 
 Use the most recent version of Xen in pkgsrc, unless the DESCR says
-that it is not suitable.  Therefore, choose 4.15.  In the dom0,
-install xenkernel415 and xentools415 from pkgsrc.
+that it is not suitable.  Therefore, choose 4.18.  In the dom0,
+install xenkernel418 and xentools418 from pkgsrc.
 
 Once this is done, copy the Xen kernel from where pkgsrc puts it to
 where the boot process will be able to find it:
 
 [[!template id=programlisting text="""
-# cp -p /usr/pkg/xen413-kernel/xen.gz /
+# cp -p /usr/pkg/xen418-kernel/xen.gz /
 """]]
 
 Then, place a NetBSD XEN3_DOM0 kernel in the `/` directory. Such
@@ -231,7 +231,7 @@
 manually, or downloaded from the NetBSD FTP, for example at:
 
 [[!template id=programlisting text="""
-ftp.netbsd.org/pub/NetBSD/NetBSD-9.1/amd64/binary/kernel/netbsd-XEN3_DOM0.gz
+ftp.netbsd.org/pub/NetBSD/NetBSD-10.0/amd64/binary/kernel/netbsd-XEN3_DOM0.gz
 """]]
 
 ### Configuring booting
@@ -271,6 +271,17 @@
 trouble at some point, and keeping an up-to-date GENERIC for use in
 fixing problems is the standard prudent approach.
 
+### Setting up PVH
+
+A PVH dom0 is currently experimental.  First, get a PV dom0 working
+following the instructions above.
+
+Then, create a copy of the boot line, adding `dom0=pvh` near
+`dom0_mem`, and instead of loading a `XEN3_DOM0` kernel, load a
+generic kernel.
+
+\todo Validate that these instructions are correct, and that they work.
+
 ### Selecting the console for the boot blocks
 
 See boot_console(8).  Understand that you should start from a place of

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.262
retrieving revision 1.263
diff -u -r1.262 -r1.263
--- wikisrc/ports/xen/howto.mdwn	8 Sep 2024 16:32:52 -0000	1.262
+++ wikisrc/ports/xen/howto.mdwn	9 Sep 2024 14:47:25 -0000	1.263
@@ -398,6 +398,16 @@
 indirect branch tracking was disabled, via the "cet=no-ibt" xen boot
 argument.
 
+In 2024-09, on an Intel i7-12700K under Xen 4.18.0, AVX2 instructions
+resulted in a privileged opcode fault.  ccache in particular tries to
+use AVX2 if the flag is set in cpufeatures.  See
+[XSA-435](https://xenbits.xen.org/xsa/advisory-435.html).  Adding
+`spec-ctrl=gds-mit=no` or `spec-ctrl=no-gds-mit` did not help; ccache
+still crashed.  Adding (an unreasonably large hammer) `spec-ctrl=no`
+did not help either.  This seems like a bug as Xen loads microcode
+which should have the mitigation.  However, our Xen 4.18 is at .0, vs
+.3.
+
 ### rc.conf
 
 Ensure that the boot scripts installed in

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.261
retrieving revision 1.262
diff -u -r1.261 -r1.262
--- wikisrc/ports/xen/howto.mdwn	8 Sep 2024 13:11:30 -0000	1.261
+++ wikisrc/ports/xen/howto.mdwn	8 Sep 2024 16:32:52 -0000	1.262
@@ -202,10 +202,6 @@
 NetBSD system, and then pivots the install to a dom0 install by
 changing the kernel and boot configuration.
 
-In 2018-05, trouble booting a dom0 was reported with 256M of RAM: with
-512M it worked reliably.  This does not make sense, but if you see
-"not ELF" after Xen boots, try increasing dom0 RAM.
-
 ## Installation of NetBSD
 
 [Install NetBSD/amd64](/guide/inst/) just as you would if you were not
@@ -252,13 +248,14 @@
 menu=Xen single user:load /netbsd-XEN3_DOM0.gz rndseed=/var/db/entropy-file bootdev=wd0a console=pc -s;multiboot /xen.gz dom0_mem=1024M
 """]]
 
-"dom0_mem" is mandatory.  This example specifies that the dom0 should
-have 1024MB of ram, leaving the rest to be allocated for domUs.  Do
-not start out with a very low value, because diagnosing too-low dom0
-RAM is difficult, and it may be that a dom0 will fail with an amount
-of RAM that would hav been ok on a physical machine.  512 MB is
-probably ok; 256M is probably not.  (Data points and wisdom should be
-sent to port-xen@.)
+The dom0_mem parameter specifies how much RAM should be seen by the
+dom0 kernel, with the rest (less Xen overhead) available for domU use.
+If not given, almost all or all memory will be assigned to the dom0.
+Do not start out with a very low value, because diagnosing too-low
+dom0 RAM is difficult.  In 2018-05, trouble booting a dom0 was
+reported with 256M of RAM: with 512M it worked reliably.  This does
+not make sense, but if you see "not ELF" after Xen boots, try
+increasing dom0 RAM.
 
 "bootdev" (or the earlier form "root") is also in general required,
 because the boot device from /boot is not passed via Xen to the dom0
@@ -316,7 +313,7 @@
 
 Xen can be configured to explicitly use only a serial port console, e.g.
 [[!template id=filecontent name="/boot.cfg" text="""
-menu=Xen:load /netbsd-XEN3_DOM0.gz rndseed=/var/db/entropy-file bootdev=sd0; multiboot /xen.gz dom0_mem=512M console=com1
+menu=Xen:load /netbsd-XEN3_DOM0.gz rndseed=/var/db/entropy-file bootdev=sd0; multiboot /xen.gz dom0_mem=1024M console=com1
 """]]
 
 On Xen's console, one can type the escape character (default ^A) three
@@ -341,7 +338,7 @@
 default xencons(4) for NetBSD and force Xen to serial only:
 
 [[!template id=filecontent name="/boot.cfg" text="""
-menu=Xen:load /netbsd-XEN3_DOM0.gz rndseed=/var/db/entropy-file bootdev=sd0; multiboot /xen.gz dom0_mem=512M console=com1
+menu=Xen:load /netbsd-XEN3_DOM0.gz rndseed=/var/db/entropy-file bootdev=sd0; multiboot /xen.gz dom0_mem=1024M console=com1
 """]]
 
 To have NetBSD use VGA for a console, add "console=pc" to the NetBSD
@@ -349,7 +346,7 @@
 VGA only.
 
 [[!template id=filecontent name="/boot.cfg" text="""
-menu=Xen:load /netbsd-XEN3_DOM0.gz rndseed=/var/db/entropy-file bootdev=sd0 console=pc; multiboot /xen.gz dom0_mem=512M console=vga
+menu=Xen:load /netbsd-XEN3_DOM0.gz rndseed=/var/db/entropy-file bootdev=sd0 console=pc; multiboot /xen.gz dom0_mem=1024M console=vga
 """]]
 
 If using serial console with Xen, the default of xencons will be
@@ -358,7 +355,7 @@
 input from the serial port to NetBSD, except for commands for the
 hypervisor.  Thus configure
 
-  menu=Xen:load /netbsd-XEN3_DOM0.gz bootdev=sd0; multiboot /xen.gz console=com1 dom0_mem=512M
+  menu=Xen:load /netbsd-XEN3_DOM0.gz bootdev=sd0; multiboot /xen.gz console=com1 dom0_mem=1024M
 
 to force Xen to use serial only, and for NetBSD implicitly to use
 xencons(4).
@@ -397,11 +394,9 @@
 until it boots and then removing disable statements to find the
 minimal set.
 
-On an Intel i7-12700K, Xen crashed until CET was disabled.  On the
-same CPU, x2apic was perhaps troublesome, but the crash could have
-been due to CET.
-
-\todo Give boot line with max disabled, and the minimal one.
+In 2024-09, on an Intel i7-12700K, Xen 4.18 crashed on boot, until CET
+indirect branch tracking was disabled, via the "cet=no-ibt" xen boot
+argument.
 
 ### rc.conf
 

Add mention of CET and how to debug crashes.

Members: 
	ports/xen/howto.mdwn:1.260->1.261 

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.260
retrieving revision 1.261
diff -u -r1.260 -r1.261
--- wikisrc/ports/xen/howto.mdwn	5 Sep 2024 22:53:31 -0000	1.260
+++ wikisrc/ports/xen/howto.mdwn	8 Sep 2024 13:11:30 -0000	1.261
@@ -248,12 +248,17 @@
 adjusting for your root filesystem:
 
 [[!template id=filecontent name="/boot.cfg" text="""
-menu=Xen:load /netbsd-XEN3_DOM0.gz bootdev=wd0a rndseed=/var/db/entropy-file console=pc;multiboot /xen.gz dom0_mem=512M
-menu=Xen single user:load /netbsd-XEN3_DOM0.gz rndseed=/var/db/entropy-file bootdev=wd0a console=pc -s;multiboot /xen.gz dom0_mem=512M
+menu=Xen:load /netbsd-XEN3_DOM0.gz bootdev=wd0a rndseed=/var/db/entropy-file console=pc;multiboot /xen.gz dom0_mem=1024M
+menu=Xen single user:load /netbsd-XEN3_DOM0.gz rndseed=/var/db/entropy-file bootdev=wd0a console=pc -s;multiboot /xen.gz dom0_mem=1024M
 """]]
 
-"dom0_mem" is mandatory. This example specifies that the dom0 should
-have 512MB of ram, leaving the rest to be allocated for domUs.
+"dom0_mem" is mandatory.  This example specifies that the dom0 should
+have 1024MB of ram, leaving the rest to be allocated for domUs.  Do
+not start out with a very low value, because diagnosing too-low dom0
+RAM is difficult, and it may be that a dom0 will fail with an amount
+of RAM that would hav been ok on a physical machine.  512 MB is
+probably ok; 256M is probably not.  (Data points and wisdom should be
+sent to port-xen@.)
 
 "bootdev" (or the earlier form "root") is also in general required,
 because the boot device from /boot is not passed via Xen to the dom0
@@ -358,17 +363,16 @@
 to force Xen to use serial only, and for NetBSD implicitly to use
 xencons(4).
 
-### Early NetBSD 9
-
-When the dom0 kernel is NetBSD 9 before 2021-04-17 (9.3 is ok), Xen
-4.15 and later require "dom0=msr-relaxed=1" on the boof.cfg line.
-(See /src/sys/arch/x86/x86/pmap.c revision 1.410.)
-
-### Tuning
+### Xen Options Related to NetBSD Versions
 
 See xen-command-line.html(7), but other than dom0 memory and
 max_vcpus, tuning options are not generally necessary.
 
+When the dom0 kernel is NetBSD 9 before 2021-04-17 (9.3 is ok), Xen
+4.15 and later require "dom0=msr-relaxed=1" on the boof.cfg line.
+(See /src/sys/arch/x86/x86/pmap.c revision 1.410.)  However, no one
+should be running early NetBSD 9 in 2024 or later, so fix that instead.
+
 With NetBSD 9 and below, one could add `dom0_max_vcpus=1
 dom0_vcpus_pin`, to force only one vcpu to be provided and to pin that
 vcpu to a physical CPU.  \todo Explain if anyone has ever actually
@@ -377,6 +381,28 @@
 With NetBSD 10 and up, there does not seem to be an argument that
 pinning or limiting CPUs is a good idea.
 
+From discussion on port-xen@, some machines have problems with
+timekeeping, and sometimes having one CPU, and further pinned, seems
+to help.
+
+### Xen Options Related to CPU Features
+
+In general, Xen detects CPU features and uses them, as upstream judges
+prudent.  Occasionally this goes not go well.  Mostly it works, and in
+general one should enable "virtualization support" (often VMX) in the
+BIOS, as well as VT-d.  The general strategy if Xen crashes on boot is
+to use a serial console, and if not possible/practical, record
+high-speed video of the vga console.  Even with that, the reason for a
+crash may not be apparent, leading to disabling everything one can,
+until it boots and then removing disable statements to find the
+minimal set.
+
+On an Intel i7-12700K, Xen crashed until CET was disabled.  On the
+same CPU, x2apic was perhaps troublesome, but the crash could have
+been due to CET.
+
+\todo Give boot line with max disabled, and the minimal one.
+
 ### rc.conf
 
 Ensure that the boot scripts installed in

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.259
retrieving revision 1.260
diff -u -r1.259 -r1.260
--- wikisrc/ports/xen/howto.mdwn	25 Aug 2024 13:47:06 -0000	1.259
+++ wikisrc/ports/xen/howto.mdwn	5 Sep 2024 22:53:31 -0000	1.260
@@ -46,6 +46,17 @@
 There are many choices one can make; the HOWTO recommends the standard
 approach and limits discussion of alternatives in many cases.
 
+## CPU Architecture
+
+Xen runs on x86_64 hardware (the NetBSD amd64 port).
+
+There is a concept of Xen running on arm32 and aarch64, but there are
+thus far no reports of this working with NetBSD.
+
+The dom0 system must be amd64.
+
+The domU can be i386 PAE or amd64.  It can be various operating systems.
+
 ## Guest Styles
 
 Xen supports different styles of guests.  See
@@ -75,7 +86,6 @@
 AMD's support is called AMD-V and denoted by the cpuflag SVM.  While
 these features are not identical, Xen can use either.
 
-
 There have been two PVH modes: original PVH and PVHv2.  Original PVH
 was based on PV mode and is no longer relevant at all.  Therefore
 PVHv2 is written as PVH, here and elsewhere.  PVH is basically
@@ -88,7 +98,13 @@
 With a CPU having the EPT feature, PVH is substantially more efficient
 than PV because it uses hardware-assisted virtualization.  Without
 EPT, benchmarking results posted in 2024-08 indicate that it is slower
-for x86_64 guests.  (The EPT feature might be VT-d in cpufeatures.)
+for x86_64 guests.
+
+Some CPUs have a feature Hardware-Assisted Paging (HAP).  \todo
+Explain how to tell and what it is used for.
+
+Some Intel CPUs support VT-d, also referred to as IOMMU.  This can
+allow the hardware to mediate PCI passthrough efficiently and safely.
 
 In HVM (Hardware Virtual Machine) mode, guest operating systems with
 no knowledge of or accomodation for Xen can be run.  The dom0 runs
@@ -112,17 +128,6 @@
 summarize benchmark results more acccurately, once there are a few
 more.
 
-## CPU Architecture
-
-Xen runs on x86_64 hardware (the NetBSD amd64 port).
-
-There is a concept of Xen running on arm32 and aarch64, but there are
-thus far no reports of this working with NetBSD.
-
-The dom0 system must be amd64.
-
-The domU can be i386 PAE or amd64.  It can be various operating systems.
-
 ## Xen Versions
 
 In NetBSD, Xen is provided in pkgsrc, via matching pairs of packages

Members: 
	ports/xen/howto.mdwn:1.258->1.259 

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.258
retrieving revision 1.259
diff -u -r1.258 -r1.259
--- wikisrc/ports/xen/howto.mdwn	26 Jul 2024 00:08:18 -0000	1.258
+++ wikisrc/ports/xen/howto.mdwn	25 Aug 2024 13:47:06 -0000	1.259
@@ -52,10 +52,6 @@
 https://wiki.xenproject.org/wiki/Virtualization_Spectrum for a
 discussion.
 
-Some kinds of guests need hardware support for virtualization.  This
-support is called "VT-X" by Intel, and is denoted by the cpuflag VMX.
-AMD's support is called AMD-V and denoted by the cpuflag SVM.  While
-these features are not identical, Xen can use either.
 
 This table shows the styles, if a NetBSD dom0 can run in that
 style, if a NetBSD dom0 can support that style of guest in a domU, and
@@ -74,12 +70,12 @@
 guests must be specifically coded for Xen.  See
 [PV](https://wiki.xen.org/wiki/Paravirtualization_(PV\)).
 
-For various PVH/HVM modes, hardware support is required, such as VT-x
-on Intel CPUs and SVM on AMD CPUs to assist with the processor
-emulation.
+Various PVH/HVM modes need hardware support for virtualization.  This
+support is called "VT-X" by Intel, and is denoted by the cpuflag VMX.
+AMD's support is called AMD-V and denoted by the cpuflag SVM.  While
+these features are not identical, Xen can use either.
+
 
-PVH is substantially more efficient than PV because it uses
-hardware-assisted virtualization.
 There have been two PVH modes: original PVH and PVHv2.  Original PVH
 was based on PV mode and is no longer relevant at all.  Therefore
 PVHv2 is written as PVH, here and elsewhere.  PVH is basically
@@ -89,6 +85,11 @@
 config files use pvh -- these refer to PVHv2.  See
 [PVH(v2)](https://wiki.xenproject.org/wiki/PVH_(v2\)_Domu).
 
+With a CPU having the EPT feature, PVH is substantially more efficient
+than PV because it uses hardware-assisted virtualization.  Without
+EPT, benchmarking results posted in 2024-08 indicate that it is slower
+for x86_64 guests.  (The EPT feature might be VT-d in cpufeatures.)
+
 In HVM (Hardware Virtual Machine) mode, guest operating systems with
 no knowledge of or accomodation for Xen can be run.  The dom0 runs
 qemu to emulate hardware other than the processor.  It is therefore
@@ -103,6 +104,14 @@
 kernel stored in the domU's filesystem.  This can be useful in VPS
 situations where the owner of the domU has no access to the dom0.
 
+With a CPU having the EPT feature, and perhaps HAP and IOMMU, (PV)HVM
+appears more efficient than PV.  With an older CPU lacking these
+features, it can be very slow.
+
+\todo Explain more about features and how to tell (xl dmesg), and
+summarize benchmark results more acccurately, once there are a few
+more.
+
 ## CPU Architecture
 
 Xen runs on x86_64 hardware (the NetBSD amd64 port).

Members: 
	pkgsrc/how_to_upgrade_packages.mdwn:1.11->1.12 

Index: wikisrc/pkgsrc/how_to_upgrade_packages.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc/how_to_upgrade_packages.mdwn,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- wikisrc/pkgsrc/how_to_upgrade_packages.mdwn	23 Aug 2024 13:17:35 -0000	1.11
+++ wikisrc/pkgsrc/how_to_upgrade_packages.mdwn	23 Aug 2024 13:46:17 -0000	1.12
@@ -50,10 +50,21 @@
 
 # Methods that build packages from source
 
-**Note: Be sure you have an updated "pkgsrc" directory. It is recommended that you don't update just parts of the pkgsrc directory.**
+pkgsrc is developed and tested with a consistent source tree.  While
+you can do partial updates, doing so crosses into undefined behavior.
+Thus, you should be up to date with respect to the repository, either
+on HEAD, a quarterly branch, or much less  likely, a specific date on HEAD.
+
+That said, it is often necessary to update a particular package to an
+older date to work around broken updates.  This risks difficulty but
+can be reasonable for those who can cope.
+
+Among the options below, the mainstream/popular options are pkg_rolling-replace, and sandbox/separate-computer, and pbulk, which have been listed in (roughly) order of both increasing setup difficulty and increasing reliability.
 
 ## make update
 
+Note that there has been little recent discussion of experiences with make update; this is a clue that few are using it, because it is extremely unlikely that people are using it without problems.
+
 'make update', invoked in a pkgsrc package directory, will remove the package and all packages that depend on it, keeping a list of such packages. It will then attempt to rebuild and install the package and all the packages that were removed.
 
 It is possible, and in the case of updating a package with hundreds of dependencies, arguably even likely that the process will fail at some point. One can fix problems and resume the update by typing make update in the original directory, but the system can have unusuable packages for a prolonged period of time. Thus, many people find 'make update' too dangerous, particularly for something like glib on a system using gnome.
@@ -62,16 +73,17 @@
 
 To enable manual rollback one can keep binary packages. One method is to always use 'make package', and to have "DEPENDS_TARGET=package" in /etc/mk.conf. Another is to use pkg_tarup to save packages before starting.
 
-
 ## make replace
 
-The make replace target should only be used by those who understand that there may be ABI issues and can deal with fixing the resulting problems. It is possible that a replaced package will have a different binary interface and thus packages that depend on the replaced packages may not work correctly. This can be because of a shlib (shared library) version bump, where depending package binaries will no longer run, or something more subtle. In these cases, the correct fix is to 'make replace' the problematic depending package. The careful reader will note that this process can in theory require all packages that depend (recursively) on a replaced package to be replaced. See the pkg_rolling-replace section for a way to automate this process.
+'make replace' builds a new package and substitutes it, without changing the packages that depend on it.  This is good, because large numbers of packages are not removed in the hope they can be rebuilt.   It is bad, because depending packages may find ABI breaks, because a shlib major version changed, or something else more subtle, such as changed behavior of a program invoked by another program.   If there is an ABI change, the correct approach is to 'make replace' the depending package. The careful reader will note that this process can in theory require all packages that depend (recursively) on a replaced package to be replaced. See the pkg_rolling-replace section for a way to automate this process.
 
-The "make replace" target preserves the existing +REQUIRED_BY file, uninstalls the currently installed package, installs the newly built package, reinstalls the +REQUIRED_BY file, and changes depending packages to reference the new package instead. It also marks such depending packages with the "unsafe_depends" build variable, set to YES.
+The "make replace" target preserves the existing +REQUIRED_BY file, uninstalls the currently installed package, installs the newly built package, reinstalls the +REQUIRED_BY file, and changes depending packages to reference the new package instead. It also marks such depending packages with the "unsafe_depends" build variable, set to YES, if the package version changes, and "unsafe_depends_strict" is set in all cases.
 
-It also uses the pkg_tarup tool to create a tarball package for the the currently installed package first, just in case there is a problem.
+It can use the pkg_tarup tool to create a tarball package for the the currently installed package first, just in case there is a problem (\todo Check this; it doesn't seem to happen in 2024.)
 
-make replace should preserve the "automatic" build variable, but does not.
+### advice to be reconsidered
+
+\todo Explain this better and perhaps prune; gdt hasn't found any reason to set this, and not any related to make replace.
 
 If you are an expert (and don't plan to share your packages publically), you can also use in your mk.conf:
 
@@ -79,11 +91,11 @@
 
 This is for ignoring the ABI dependency recommendations and just use the required DEPENDS.
 
+### Problems occuring during make replace
 
-### Problems with make replace
-
-Besides ABI changes (for which pkg_rolling-replace is a good solution), make replace can fail if packages are named or split. A particularly tricky case is when package foo is installed, but in pkgsrc has been split into foo and foo-libs. In this case, make replace will try to build the new foo (while the old monolithic foo is installed). The foo package depends on foo-libs, and so pkgsrc will go to build and install foo-libs. This will fail because foo-libs will conflict with the old foo. There are three approaches:
+Besides ABI changes (for which pkg_rolling-replace is a good solution), make replace can fail if packages are named or split. A particularly tricky case is when package foo is installed, but in pkgsrc has been split into foo and foo-libs. In this case, make replace will try to build the new foo (while the old monolithic foo is installed). The foo package depends on foo-libs, and so pkgsrc will go to build and install foo-libs. This will fail because foo-libs will conflict with the old foo. There are multiple approaches:
 
+  * Use pkg_delete -f, and then make install.  This loses dependency information.  Run "pkg_admin rebuild-tree".   Perhaps do make replace on depending packages.
   * manually save the foo +REQUIRED_BY file, pkg_delete foo, and then make package of the new foo. Put back the +REQUIRED_BY, and pkg_admin set unsafe_depends=YES all packages in the +REQUIRED_BY.
   * pkg_delete -r foo, and make package on everything you still want. Or do make update. Note that this could delete a lot.
   * Automating the first option would be a useful contribution to pkgsrc.
@@ -103,7 +115,7 @@
 
 You can set UPDATE_TARGET=package in /etc/mk.conf and specify the -b flag, so that the results of compilation work are saved for later use, and binary packages are used if they are not outdated or dependent on outdated packages.
 
-The main problem with pkg_chk, is that it deinstalls all to-be-upgraded candidates before reinstalling then. However a failure is not fatal, because the current state of packages is saved in a pkg_chk* file at the root of the pkgsrc directory.
+The main problem with pkg_chk, is that it deinstalls all to-be-upgraded candidates before reinstalling then. However a failure is not entirely fatal, because the current state of packages is saved in a pkg_chk* file at the root of the pkgsrc directory.  But, if new ones can't be built, it is still quite problematic.
 
 
 ## pkg_rolling-replace
@@ -112,12 +124,14 @@
 
 Because pkg_rolling-replace just invokes make replace, the problems of ABI changes with make replace apply to pkg_rolling-replace, and the system will be in a state which might be inconsistent while pkg_rolling-replace is executing. But, by the time pkg_rolling-replace has successfully finished, the system will be consistent because every package that has a depending package 'make replaced' out from under it will be marked unsafe_depends, and then replaced itself. This replace "rolls" up the dependency tree because pkg_rolling-replace sorts the packages by dependency and replaces the earliest needing-rebuild package first.
 
-See the pkg_rolling-replace man page (installed by the pkg) for further details.
+Also, some "make replace" operations might fail due to new packages having conflicts with old packages (newly split packages, moving files between packages, etc.).  These need the same manual intervention.
+
+See the pkg_rolling-replace man page (installed by the pkg) for further details.  Note that it asks that problems with pkg_rolling-replace itself be separated from problems with make replace operations that pkg_rolling-replace chose to do (when the choice was reasonable), and specifically that underlying package build failures not be reported as pkg_rolling-replace problems.
 
 
 ### Example
 
-Find essentials package, that we would rather update manually:
+As an example of running pkg_rolling-replace and excluding packages marked not for deletion, perhaps for separate manual updating:
 
     cd /var/db/pkg
     find . -name "+PRESERVE" | awk -F/ '{print $2}'
@@ -127,6 +141,8 @@
     pkg_rolling-replace -rsuvX bmake,bootstrap-mk-files,pax,pkg_install
 
 
+(Experience does not suggest that this is necessary; pkg_rolling-replace without these exclusions has not been reported to be problematic.  And if so, the problem is almost certainly an underlying issue with the specific package.)
+
 ### Real-world experience with pkg_rolling-replace
 
 Even if a lot of packages need to be updated, make replace usually works very well if the interval from the last 'pkg_rolling-replace -u' run is not that long (a month or so). With a longer interval, like a year or two, the odds of package renaming/splitting are higher. Still, for those who can resolve the issues, this is a fairly low-pain and reliable way to update.
@@ -165,9 +181,13 @@
 An alternative way to choose the packages you want installed is to create your own custom meta-package. A meta-package doesn't install any files itself, but just depends on other packages (usually within a similar topic or need). Have a look at pkgsrc/meta-pkgs category for various examples. If your new meta-package is generic enough and useful for others, please be sure to share it.
 
 
+## different computer
+
+One can use another computer (or a VM) and build packages on it, and then e.g. use pkgin.  That computer can use any of the methods, with the benefit that until you have a complete set of packages (relative to what you need), you can refrain from changing the operational systems.
+
 ## chroot environment
 
-Nothing special here. This is really basically the same as just having a another physical system to build packages.
+This is basically the same as using another computer, except that a chroot is lighter weight than a VM.
 
 Manually setup a directory containing your base operating system (including compilers, libraries, shells, etc). Put a copy of your pkgsrc tree and distfiles into there or use mount to mount shared directories containing these. Then use the "chroot" command to chroot into that new directory. You can even switch users from root to a regular user in the new environment.
 
@@ -175,9 +195,13 @@
 
 Then use other technique from this list to install from these packages (built in chroot).
 
-Or instead of using this manual method, use pkg_comp's chroot.
+Or instead of using this manual method, use pkgtools/mksandbox, or (older) pkg_comp's chroot.
 
-## pkg_comp's chroot
+## pbulk
+
+See pkgtools/pbulk.  This is the standard approach for building packages in bulk.  It can be configured to build only packages you want, rather than all of them; building all of them can take between most of 24h, if you have an enormously powerful machine, to 6 months, if you are retrocomputing.
+
+## pkg_comp
 
 Apart from the examples in the man page, it's necessary supply a list of packages you want to build. The command 'pkg_info -u -Q PKGPATH' will produce a list of packages you explicitly requested be installed; in some strong sense, it's what you want to rebuild.
 
@@ -194,6 +218,8 @@
 
 ## bulk build framework
 
+NB: This section is historical and probably should be deleted; see pbulk above.
+
 Use the scripts in pkgsrc/mk/bulk/, e.g. as pointed out in <http://www.netbsd.org/Documentation/pkgsrc/binary.html#bulkbuild>.
 
 To go easy on the existing pkgsrc installation, creating a sandbox (automated chroot environment) is highly recommended here: <http://www.netbsd.org/Documentation/pkgsrc/binary.html#setting-up-a-sandbox>.
@@ -204,9 +230,9 @@
 
 Or upload them on a www-site and pkg_add <http://www.site/packages/All/><pkg>
 
-## wip/distbb - distributed bulk builds
+## wip/distbb-git - distributed bulk builds
 
-Using wip/distbb you may build packages in parallel using several machines and/or chroots. Read PREFIX/share/doc/distbb/README file for the instructions.
+Using wip/distbb-git you may build packages in parallel using several machines and/or chroots. Read PREFIX/share/doc/distbb/README file for the instructions.
 
 ## pkgdepgraph
 

Index: wikisrc/pkgsrc/how_to_upgrade_packages.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc/how_to_upgrade_packages.mdwn,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- wikisrc/pkgsrc/how_to_upgrade_packages.mdwn	12 Mar 2022 18:27:22 -0000	1.10
+++ wikisrc/pkgsrc/how_to_upgrade_packages.mdwn	23 Aug 2024 13:17:35 -0000	1.11
@@ -1,9 +1,225 @@
-NetBSD consists of a core base system and any third-party software you install
-on top. The NetBSD base system can be upgraded in numerous ways, including
-booting a new installer image, using the sysupgrade tool, or building from
-source. For more information, see
-[the NetBSD guide](//www.netbsd.org/docs/guide/en/chap-upgrading.html#using-sysupgrade).
-
-NetBSD uses [pkgsrc](//www.pkgsrc.org) for managing third-party software. The instructions
-for [upgrading pkgsrc packages](//www.NetBSD.org/docs/pkgsrc/using.html#using-pkg)
-have moved to the pkgsrc guide.
+There are various techniques for upgrading packages either by using pre-built binary package tarballs or by building new packages via pkgsrc build system. This wiki page hopefully will summarize all of the different ways this can be done, with examples and pointing you to further information.
+
+**Contents**
+
+[[!toc levels=2]]
+
+# Methods using only binary packages
+
+
+## pkgin
+
+The recommended way to manage your system with binary packages is by using [pkgtools/pkgin](http://pkgsrc.se/pkgtools/pkgin).
+
+    pkg_add pkgin
+
+Then configure your binary repository from which you want to install packages in /usr/pkg/etc/pkgin/repositories.conf.
+Run 'pkgin update' to get the list of available packages. You can then install packages using 'pkgin install firefox'.
+
+To update all installed packages, just run
+
+	pkgin update
+	pkgin upgrade
+
+
+## pkg_add -uu
+
+pkg_add's -u option is used to update a package. Basically: it saves the package's current list of packages that depend on it (+REQUIRED_BY), installs the new package, and replaces that list of dependencies.
+
+By using the -uu (option used twice), it will attempt to update prerequisite packages also.
+
+See the manual page, [[!template id=man name="pkg_add" section="1"]], for details.
+
+
+## pkg_chk -b
+
+Use "-b -P URL" where URL is where the binary packages are (e.g. <ftp://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/i386/5.1/All/>).
+
+For example, to update any missing packages by using binary packages:
+
+    pkg_chk -b -P URL -u
+
+Or to automatically add any missing packages using just binary packages:
+
+    pkg_chk -b -P URL -a -C pkg_chk.conf
+
+If both -b and -P are given, no pkgsrc tree is used. If packages are on the local machine, they are scanned directly, otherwise the pkg_summary database is fetched. (Using pkg_summary for local packages is on the TODO list.)
+
+(pkg_chk is also covered below.)
+
+
+# Methods that build packages from source
+
+**Note: Be sure you have an updated "pkgsrc" directory. It is recommended that you don't update just parts of the pkgsrc directory.**
+
+## make update
+
+'make update', invoked in a pkgsrc package directory, will remove the package and all packages that depend on it, keeping a list of such packages. It will then attempt to rebuild and install the package and all the packages that were removed.
+
+It is possible, and in the case of updating a package with hundreds of dependencies, arguably even likely that the process will fail at some point. One can fix problems and resume the update by typing make update in the original directory, but the system can have unusuable packages for a prolonged period of time. Thus, many people find 'make update' too dangerous, particularly for something like glib on a system using gnome.
+
+To use binary packages if available with "make update", use "UPDATE_TARGET=bin-install". If package tarball is not available in ${PACKAGES} locally or at URLs (defined with BINPKG_SITES), it will build a package from source.
+
+To enable manual rollback one can keep binary packages. One method is to always use 'make package', and to have "DEPENDS_TARGET=package" in /etc/mk.conf. Another is to use pkg_tarup to save packages before starting.
+
+
+## make replace
+
+The make replace target should only be used by those who understand that there may be ABI issues and can deal with fixing the resulting problems. It is possible that a replaced package will have a different binary interface and thus packages that depend on the replaced packages may not work correctly. This can be because of a shlib (shared library) version bump, where depending package binaries will no longer run, or something more subtle. In these cases, the correct fix is to 'make replace' the problematic depending package. The careful reader will note that this process can in theory require all packages that depend (recursively) on a replaced package to be replaced. See the pkg_rolling-replace section for a way to automate this process.
+
+The "make replace" target preserves the existing +REQUIRED_BY file, uninstalls the currently installed package, installs the newly built package, reinstalls the +REQUIRED_BY file, and changes depending packages to reference the new package instead. It also marks such depending packages with the "unsafe_depends" build variable, set to YES.
+
+It also uses the pkg_tarup tool to create a tarball package for the the currently installed package first, just in case there is a problem.
+
+make replace should preserve the "automatic" build variable, but does not.
+
+If you are an expert (and don't plan to share your packages publically), you can also use in your mk.conf:
+
+    USE_ABI_DEPENDS?=no
+
+This is for ignoring the ABI dependency recommendations and just use the required DEPENDS.
+
+
+### Problems with make replace
+
+Besides ABI changes (for which pkg_rolling-replace is a good solution), make replace can fail if packages are named or split. A particularly tricky case is when package foo is installed, but in pkgsrc has been split into foo and foo-libs. In this case, make replace will try to build the new foo (while the old monolithic foo is installed). The foo package depends on foo-libs, and so pkgsrc will go to build and install foo-libs. This will fail because foo-libs will conflict with the old foo. There are three approaches:
+
+  * manually save the foo +REQUIRED_BY file, pkg_delete foo, and then make package of the new foo. Put back the +REQUIRED_BY, and pkg_admin set unsafe_depends=YES all packages in the +REQUIRED_BY.
+  * pkg_delete -r foo, and make package on everything you still want. Or do make update. Note that this could delete a lot.
+  * Automating the first option would be a useful contribution to pkgsrc.
+
+In addition, any problem that can occur with building a package can occur with make replace. Usually, the solution is not make replace specific
+
+
+## pkg_chk
+
+See all packages which need upgrading:
+
+    pkg_chk -u -q
+
+Update packages from sources:
+
+    pkg_chk -u -s
+
+You can set UPDATE_TARGET=package in /etc/mk.conf and specify the -b flag, so that the results of compilation work are saved for later use, and binary packages are used if they are not outdated or dependent on outdated packages.
+
+The main problem with pkg_chk, is that it deinstalls all to-be-upgraded candidates before reinstalling then. However a failure is not fatal, because the current state of packages is saved in a pkg_chk* file at the root of the pkgsrc directory.
+
+
+## pkg_rolling-replace
+
+[pkgtools/pkg_rolling-replace](http://pkgsrc.se/pkgtools/pkg_rolling-replace) is a shell script available via pkgsrc. It makes a list of all packages that need updating, and sorts them in dependency order. Then, it invokes "make replace" on the first one, and repeats. A package needs updating if it is marked unsafe_depends or if it is marked rebuild (=YES). If pkg_rolling-replace is invoked with -u, a package needs updating if [pkgtools/pkg_chk](http://pkgsrc.se/pkgtools/pkg_chk) reports that the installed version differs from the source version. On error, pkg_rolling-replace exits. The user should remove all working directories and fix the reported problem. This can be tricky, but the same process that is appropriate for a make replace should be followed.
+
+Because pkg_rolling-replace just invokes make replace, the problems of ABI changes with make replace apply to pkg_rolling-replace, and the system will be in a state which might be inconsistent while pkg_rolling-replace is executing. But, by the time pkg_rolling-replace has successfully finished, the system will be consistent because every package that has a depending package 'make replaced' out from under it will be marked unsafe_depends, and then replaced itself. This replace "rolls" up the dependency tree because pkg_rolling-replace sorts the packages by dependency and replaces the earliest needing-rebuild package first.
+
+See the pkg_rolling-replace man page (installed by the pkg) for further details.
+
+
+### Example
+
+Find essentials package, that we would rather update manually:
+
+    cd /var/db/pkg
+    find . -name "+PRESERVE" | awk -F/ '{print $2}'
+
+Update everything except the packages above:
+
+    pkg_rolling-replace -rsuvX bmake,bootstrap-mk-files,pax,pkg_install
+
+
+### Real-world experience with pkg_rolling-replace
+
+Even if a lot of packages need to be updated, make replace usually works very well if the interval from the last 'pkg_rolling-replace -u' run is not that long (a month or so). With a longer interval, like a year or two, the odds of package renaming/splitting are higher. Still, for those who can resolve the issues, this is a fairly low-pain and reliable way to update.
+
+
+## Delete everything
+
+If you don't have a production environment or don't care if your packages will be missing for a while, you can just delete everything and reinstall.
+
+This method is the easiest:
+
+    # pkg_delete -Rr '*-*'
+
+-or-
+
+    # pkg_delete -ff '*-*'
+
+This expands to all packages, and deletes all packages without caring about dependencies. The second version of the command should be faster, as it does not perform any dependency recursion. (The quotes around the wildcards are so it doesn't get expanded by the shell first.)
+
+Here is one idea (from posting on pkgsrc-users):
+
+Get a list of packages installed:
+
+    # pkg_info -Q PKGPATH -a > pkgs_i_want_to_have
+
+Remove all the packages:
+
+    # pkg_info -a | sed 's/ .*//' | tail -r | while read p ; do pkg_delete $p ; done
+
+(There are many ways to do this.)
+
+Then edit your "pkgs_i_want_to_have" (created above) as needed. And reinstall just those from it:
+
+    # cat pkgs_i_want_to_have | (while read pp ; do cd /usr/pkgsrc/$pp ; make && make install ; done)
+
+An alternative way to choose the packages you want installed is to create your own custom meta-package. A meta-package doesn't install any files itself, but just depends on other packages (usually within a similar topic or need). Have a look at pkgsrc/meta-pkgs category for various examples. If your new meta-package is generic enough and useful for others, please be sure to share it.
+
+
+## chroot environment
+
+Nothing special here. This is really basically the same as just having a another physical system to build packages.
+
+Manually setup a directory containing your base operating system (including compilers, libraries, shells, etc). Put a copy of your pkgsrc tree and distfiles into there or use mount to mount shared directories containing these. Then use the "chroot" command to chroot into that new directory. You can even switch users from root to a regular user in the new environment.
+
+Then build and remove packages as you wish with out affecting your real production system. Be sure to create packages for everything.
+
+Then use other technique from this list to install from these packages (built in chroot).
+
+Or instead of using this manual method, use pkg_comp's chroot.
+
+## pkg_comp's chroot
+
+Apart from the examples in the man page, it's necessary supply a list of packages you want to build. The command 'pkg_info -u -Q PKGPATH' will produce a list of packages you explicitly requested be installed; in some strong sense, it's what you want to rebuild.

(Diff truncated)

Index: wikisrc/amazon_ec2/bsdec2_image_upload.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/amazon_ec2/bsdec2_image_upload.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/amazon_ec2/bsdec2_image_upload.mdwn	16 Jul 2021 09:36:07 -0000	1.2
+++ wikisrc/amazon_ec2/bsdec2_image_upload.mdwn	18 Aug 2024 19:55:41 -0000	1.3
@@ -16,7 +16,9 @@
 ### Arm
 
 * NetBSD -current: <http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/latest/evbarm-aarch64/binary/gzimg/arm64.img.gz>
-* NetBSD 9.x: <http://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-9/latest/evbarm-aarch64/binary/gzimg/arm64.img.gz>
+* NetBSD 10.0 (official release): <https://ftp.netbsd.org/pub/NetBSD/NetBSD-10.0/evbarm-aarch64/binary/gzimg/arm64.img.gz>
+* NetBSD 10.x (latest): <http://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-10/latest/evbarm-aarch64/binary/gzimg/arm64.img.gz>
+* NetBSD 9.x (latest): <http://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-9/latest/evbarm-aarch64/binary/gzimg/arm64.img.gz>
 
 ## Prerequisites
 

Index: wikisrc/laptops.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/laptops.mdwn,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- wikisrc/laptops.mdwn	26 Jul 2024 09:13:06 -0000	1.37
+++ wikisrc/laptops.mdwn	6 Aug 2024 18:35:28 -0000	1.38
@@ -158,14 +158,8 @@
 * Ethernet is supported through the [[!template id=man name="wm" section="4"]] driver.
 * WiFi is supported through the [[!template id=man name="iwm" section="4"]] driver.
 * Extra trackpoint buttons: run at least 9.0_STABLE for fixes to the Synaptics driver.
-* Brightness buttons do not work in 9.0 by default. You can bind them to
-  xrandr in your window manager.
-* Webcam will depend on upcoming xhci isochronous pipe support.
+* Webcam works.
 * To record from the internal mic, set `mixerctl -w record.source=ADC02`
-* Some spam from [[!template id=man name="hdaudio" section="4"]] on some 
-  reboots, the chip doesn't seem to reset properly. Disappears and boots
-  normally after a few seconds.
-  [[!template id=pr number=51734]]
 * Suspend and resume work.
 
 ## ThinkPad X260
@@ -175,10 +169,21 @@
 * Ethernet is supported through the [[!template id=man name="wm" section="4"]] driver.
 * WiFi is supported through the [[!template id=man name="iwm" section="4"]] driver.
 * Extra trackpoint buttons: run at least 9.0_STABLE for fixes to the Synaptics driver.
-* Webcam will depend on upcoming xhci isochronous pipe support.
+* Webcam works.
 * Suspend and resume work.
 * Bluetooth works.
 
+## ThinkPad X270
+
+Hardware is very similar to the X260.
+
+## ThinkPad A475
+
+* GPU acceleration works with the amdgpu driver in NetBSD 10 (not built into the default kernel, though)
+* WiFi may not be supported, consider a [[!template id=man name="urtwn" section="4"]] dongle.
+* Ethernet is supported through the [[!template id=man name="re" section="4"]] driver.
+* Suspend/resume almost fully works - the USB3 ports stop working after resume.
+
 ---
 
 # Asus

Index: wikisrc/laptops.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/laptops.mdwn,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -r1.36 -r1.37
--- wikisrc/laptops.mdwn	3 May 2024 12:45:37 -0000	1.36
+++ wikisrc/laptops.mdwn	26 Jul 2024 09:13:06 -0000	1.37
@@ -85,6 +85,11 @@
 [[!template id=man name="mixerctl" section="1"]] variable can be
 modified.
 
+Since NetBSD 10, it's possible that the kernel may prefer
+to use HDMI audio over the internal chip -
+use [[!template id=man name="audiocfg" section="1"]] to change
+its preference.
+
 ## Sensors
 
 Regardless of whether the system is ACPI, NetBSD will

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.257
retrieving revision 1.258
diff -u -r1.257 -r1.258
--- wikisrc/ports/xen/howto.mdwn	25 Jul 2024 23:00:31 -0000	1.257
+++ wikisrc/ports/xen/howto.mdwn	26 Jul 2024 00:08:18 -0000	1.258
@@ -21,6 +21,10 @@
 not, it is best to ask on port-xen and if you are correct to file a
 PR.
 
+See also an [earlier Xen tutorial]
+(http://wiki.netbsd.org/tutorials/how_to_set_up_a_guest_os_using_xen3/)
+which should perhaps be folded into this HOWTO.
+
 [[!toc]]
 
 # Overview
@@ -555,6 +559,10 @@
 power-press event and do a clean shutdown.  Shutting down the dom0
 will trigger controlled shutdowns of all configured domUs.
 
+## Logs
+
+Look in /var/log/xen/* for logs written at creation time.
+
 ## CPU and memory
 
 A domain is provided with some number of vcpus; any domain can have up
@@ -580,6 +588,24 @@
 [upstream documentation]
 (https://xenbits.xenproject.org/docs/4.18-testing/man/xl-disk-configuration.5.html).
 
+Read the man page carefully.  Note that NetBSD has a culture of using
+deprecated positional syntax.  This HOWTO is converting to keyword
+syntax.
+
+One big hint is that vdev= must precede target, despite the order in
+which keywords are documented, and despite the fact that obviously
+keywords may be in any order.  \todo Check and maybe file a bug.
+
+A second hint is that for a target in PV mode, one must give a block
+device.  But for a target in HVM mode, one must give the raw device.
+If passing a block device, xen tries to transform it and adds a
+suprious r.  \todo Check and maybe file a bug.
+
+A third is that vdev can be 0x0 in PV mode but must be something like
+hda in HVM mode.
+
+\todo Fold in or gc the following.
+
 For key-value pairs: \todo
 
 For 3-tuples:
@@ -627,6 +653,9 @@
 configurations.  We focus on two common and useful cases for which
 there are existing scripts: bridging and NAT.
 
+See the [upstream documentation]
+(https://xenbits.xen.org/docs/unstable/man/xl-network-configuration.5.html).
+
 With bridging (in the example above), the domU perceives itself to be
 on the same network as the dom0.  For server virtualization, this is
 usually best.  Bridging is accomplished by creating a bridge(4) device

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.256
retrieving revision 1.257
diff -u -r1.256 -r1.257
--- wikisrc/ports/xen/howto.mdwn	25 Jul 2024 19:56:23 -0000	1.256
+++ wikisrc/ports/xen/howto.mdwn	25 Jul 2024 23:00:31 -0000	1.257
@@ -576,8 +576,9 @@
 ## Virtual disks
 
 In domU config files, disks can be defined by key-value pairs or as a
-sequence of 3-tuples.  See the [upstream
-documentation](https://xenbits.xenproject.org/docs/4.18-testing/man/xl-disk-configuration.5.html).q
+sequence of 3-tuples.  See the
+[upstream documentation]
+(https://xenbits.xenproject.org/docs/4.18-testing/man/xl-disk-configuration.5.html).
 
 For key-value pairs: \todo
 
@@ -880,7 +881,7 @@
     disk = [ 'phy:/dev/wd0e,0x1,w' ]
 
 does matter to Linux. It wants a Linux device number here (e.g. 0x300
-for hda).  Linux builds device numbers as: (major \<\< 8 + minor).
+for hda).  Linux builds device numbers as: (major << 8 + minor).
 So, hda1 which has major 3 and minor 1 on a Linux system will have
 device number 0x301.  Alternatively, devices names can be used (hda,
 hdb, ...)  as xentools has a table to map these names to devices

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.255
retrieving revision 1.256
diff -u -r1.255 -r1.256
--- wikisrc/ports/xen/howto.mdwn	14 Jul 2024 17:18:50 -0000	1.255
+++ wikisrc/ports/xen/howto.mdwn	25 Jul 2024 19:56:23 -0000	1.256
@@ -311,7 +311,7 @@
 XEN3_DOM0 uses xencons(4) as its console.  It will use vga if
 console=pc has been passed.
 
-Using xencons(4) is only sensible if Xen is using appp serial console,
+Using xencons(4) is only sensible if Xen is using a serial console,
 because Xen will have relinquished the vga console.  NetBSD will
 connect its console(4) device to xencons(4) and console I/O will
 happen there, and thus on the console Xen is using.  To use the
@@ -802,12 +802,13 @@
 from Xen 4.15 to 4.18, the only change needed for an i386 domU is the
 two lines above.
 
-It seems that this use of pvh (for i386 guests) works ok even on
-systems that lack VT-X/SVM.
+This use of pvh (for i386 guests) worked ok even on a system that
+lacked VMX (Intel E5700).
 
-There is 1 data point that it seems to work for amd64 PV guests on a
-system without VT-X/SVM, but with abysmal performance (at least 100x
-slowdown).  \todo Confirm speed issue, file a PR, and explain.
+There is 1 data point that it seems to work for amd64 PV guests (on a
+system with VMX, and one without), but with abysmal performance (on
+the order of 100x slowdown).  \todo Get confirmation from someone
+else, and decide what to do.
 
 ## Creating a NetBSD PVH dom0
 
@@ -851,9 +852,9 @@
 
 ## Creating a NetBSD PVHVM domU
 
-Exactly as HVM, except don't disable the PV drivers.
+Exactly as HVM, except allow the PV drivers that are in GENERIC to remain.
 
-When a PVHVM guest attaches hypervisor0, which happens, before regular
+When a PVHVM guest attaches hypervisor0, which happens before regular
 devices, code in sys/arch/xen/xen/hypervisor.c:hypervisor_attach()
 asks the hypervisor to disable emulated disks and network.  Thus,
 despite the guest's kernel supporting emulated disks, and the

--- /dev/null	2024-07-25 14:32:03.549279250 +0000
+++ wikisrc/abi.mdwn	2024-07-25 14:32:34.917187900 +0000
@@ -0,0 +1,25 @@
+# NetBSD ABI: Application Binary Interface
+
+Documentation and references for the NetBSD ABI.
+
+## ELF
+
+XXX
+
+## Thread-local storage
+
+XXX
+
+## Exception handling and unwinding
+
+XXX
+
+## Processor supplements
+
+XXX
+
+## Library versioning and compatibility
+
+XXX
+
+[XXX symbol versioning|symbol_versions]

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.254
retrieving revision 1.255
diff -u -r1.254 -r1.255
--- wikisrc/ports/xen/howto.mdwn	14 Jul 2024 15:54:07 -0000	1.254
+++ wikisrc/ports/xen/howto.mdwn	14 Jul 2024 17:18:50 -0000	1.255
@@ -829,8 +829,8 @@
 
 Use type='hvm'.  Use a GENERIC kernel within the disk image, or an
 INSTALL cd image.  The disk image should have bootblocks, as if it
-were a real machine.  Note that because GENERIC has PV drivers, this
-will be PVHVM if you dno't remove them.
+were a real machine.  (Note that because GENERIC has PV drivers, this
+will be PVHVM, unless you remove or disable them.)
 
 Perhaps configure serial="pty" to gain access to the domUs first
 serial port (and hence console?).
@@ -853,8 +853,12 @@
 
 Exactly as HVM, except don't disable the PV drivers.
 
-\todo Explain if declaring pvhvm vs hvm causes disk/networking to
-appear as PV instead of emulated, or ?
+When a PVHVM guest attaches hypervisor0, which happens, before regular
+devices, code in sys/arch/xen/xen/hypervisor.c:hypervisor_attach()
+asks the hypervisor to disable emulated disks and network.  Thus,
+despite the guest's kernel supporting emulated disks, and the
+hypervisor supporting them, such a guest will only see PV disks --
+which is the point of PVHVM vs HVM.
 
 ## Creating a FreeBSD domU
 

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.253
retrieving revision 1.254
diff -u -r1.253 -r1.254
--- wikisrc/ports/xen/howto.mdwn	13 Jul 2024 14:27:46 -0000	1.253
+++ wikisrc/ports/xen/howto.mdwn	14 Jul 2024 15:54:07 -0000	1.254
@@ -173,7 +173,10 @@
 significantly and because renaming it would not be useful.
 
 See also
-[NetBSD Xen daily test results](https://largo.lip6.fr/~bouyer/NetBSD-tests/xen/).
+[NetBSD Xen daily test results](https://largo.lip6.fr/~bouyer/NetBSD-tests/xen/)
+for automated tests of various domU styles and the
+[scripts to run the tests](https://ftp.netbsd.org/pub/NetBSD/misc/bouyer/nbsd-tests/)
+as a source of configuration hints.
 
 # Creating a NetBSD dom0
 
@@ -706,6 +709,8 @@
 is to keep "type" lines near "kernel" lines, as they tend to require
 being changed aat the same time.
 
+
+
 ## Creating a NetBSD PV domU
 
 See the earlier config file, and adjust memory.  Decide on how much

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.252
retrieving revision 1.253
diff -u -r1.252 -r1.253
--- wikisrc/ports/xen/howto.mdwn	13 Jul 2024 14:15:58 -0000	1.252
+++ wikisrc/ports/xen/howto.mdwn	13 Jul 2024 14:27:46 -0000	1.253
@@ -53,8 +53,8 @@
 AMD's support is called AMD-V and denoted by the cpuflag SVM.  While
 these features are not identical, Xen can use either.
 
-This table shows the styles, and if a NetBSD dom0 can run in that
-style, if a NetBSD dom0 can sypport that style of guest in a domU, and
+This table shows the styles, if a NetBSD dom0 can run in that
+style, if a NetBSD dom0 can support that style of guest in a domU, and
 if NetBSD as a domU can support that style.
 
 [[!table data="""

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.251
retrieving revision 1.252
diff -u -r1.251 -r1.252
--- wikisrc/ports/xen/howto.mdwn	13 Jul 2024 13:13:20 -0000	1.251
+++ wikisrc/ports/xen/howto.mdwn	13 Jul 2024 14:15:58 -0000	1.252
@@ -654,19 +654,9 @@
 xendomains="domU-netbsd domU-linux"
 """]]
 
-# domU setup for specific systems
-
-Creating domUs is almost entirely independent of operating system.  We
-have already presented the basics of config files in the previous system.
+# domU general setup
 
-Of course, this section presumes that you have a working dom0.
-
-Many of the following examples advise adding lines to config files.
-While it (mostly?) doesn't matter how lines are ordered, best practice
-is to keep "type" lines near "kernel" lines, as they tend to require
-being changed aat the same time.
-
-## PV/PVh kernels
+## PV/PVH kernels
 
 For PV/PVH, one specifies the domU's kernel as a file in the dom0
 filesystem.  The kernel must support PV, and can be either
@@ -696,11 +686,25 @@
 
 There have been multiple flavors of grub that can be used this way
 over the years, and the situation is a little confusing.
-\todo It remains to describe it properly.
 
-See the sections below about Panix and Tornado VPS.
+See [Xen's Booting Overview](https://wiki.xenproject.org/wiki/Booting_Overview).
+and the more detailed [pvgrub2 page](https://wiki.xenproject.org/wiki/PvGrub2).
+
+See [Debian's pvgrub page](https://wiki.debian.org/PvGrub). 
 
-See the [Xen Project's pvgrub2 page](https://wiki.xenproject.org/wiki/PvGrub2).
+For information about how specific provider's address booting,  
+see the sections below about Panix and Tornado VPS.
+See also [Bitfolk's Booting page](https://tools.bitfolk.com/wiki/Booting).
+
+The pkgsrc xentools418 package has pygrub, which is very old.  There
+are no recent reports of anyone using it.
+
+# domU setup for specific systems
+
+Many of the following examples advise adding lines to config files.
+While it (mostly?) doesn't matter how lines are ordered, best practice
+is to keep "type" lines near "kernel" lines, as they tend to require
+being changed aat the same time.
 
 ## Creating a NetBSD PV domU
 

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.250
retrieving revision 1.251
diff -u -r1.250 -r1.251
--- wikisrc/ports/xen/howto.mdwn	12 Jul 2024 14:34:30 -0000	1.250
+++ wikisrc/ports/xen/howto.mdwn	13 Jul 2024 13:13:20 -0000	1.251
@@ -48,12 +48,17 @@
 https://wiki.xenproject.org/wiki/Virtualization_Spectrum for a
 discussion.
 
+Some kinds of guests need hardware support for virtualization.  This
+support is called "VT-X" by Intel, and is denoted by the cpuflag VMX.
+AMD's support is called AMD-V and denoted by the cpuflag SVM.  While
+these features are not identical, Xen can use either.
+
 This table shows the styles, and if a NetBSD dom0 can run in that
 style, if a NetBSD dom0 can sypport that style of guest in a domU, and
 if NetBSD as a domU can support that style.
 
 [[!table data="""
-Style of guest	|dom0 can be?	|dom0 can support?	|domU can be?	|needs VT-X/SVM
+Style of guest	|dom0 can be?	|dom0 can support?	|domU can be?	|needs Hardware Virtualization Support
 PV		|yes		|yes			|yes		|no
 PVH		|not yet	|10/current		|10/current	|yes
 HVM		|N/A		|yes			|yes		|yes
@@ -69,8 +74,8 @@
 on Intel CPUs and SVM on AMD CPUs to assist with the processor
 emulation.
 
-PVH is substantially more efficient than PV because it uses hardware
-assisted virtualization.
+PVH is substantially more efficient than PV because it uses
+hardware-assisted virtualization.
 There have been two PVH modes: original PVH and PVHv2.  Original PVH
 was based on PV mode and is no longer relevant at all.  Therefore
 PVHv2 is written as PVH, here and elsewhere.  PVH is basically
@@ -661,20 +666,50 @@
 is to keep "type" lines near "kernel" lines, as they tend to require
 being changed aat the same time.
 
+## PV/PVh kernels
+
+For PV/PVH, one specifies the domU's kernel as a file in the dom0
+filesystem.  The kernel must support PV, and can be either
+uncompressed or compressed (ending in .gz).
+
 ## Stub domains
 
 Xen has a concept of stub domains, where the qemu part of HVM is in a
 domU.  \todo Explain better, and once understood, migrate this section
 to where it belongs.
 
+## Boot mechanisms
+
+For PV and PVH domUs, the kernel is specified in the config file and
+taken from the dom0 filesystem.
+
+For HVM (and PVHVM) domUs, the boot code on the domUs disk is
+executed.
+
+Sometimes, one wants to run a PV or PVH system but have the kernel
+obtained from within the domU.  This is particularly important when
+the domU administrator lacks privileges on the dom0, such as VPS
+setups.  In these cases, the domU can be configured to load a
+bootloader, typically grub, instead of the real kernel.  Xen then runs
+the bootloader, which can read the disk, find the real kernel, and
+then load and run it.
+
+There have been multiple flavors of grub that can be used this way
+over the years, and the situation is a little confusing.
+\todo It remains to describe it properly.
+
+See the sections below about Panix and Tornado VPS.
+
+See the [Xen Project's pvgrub2 page](https://wiki.xenproject.org/wiki/PvGrub2).
+
 ## Creating a NetBSD PV domU
 
 See the earlier config file, and adjust memory.  Decide on how much
 storage you will provide, and prepare it (file or LVM).
 
-While the kernel will be obtained from the dom0 file system, the same
-file should be present in the domU as /netbsd so that tools like
-savecore(8) can work.   (This is helpful but not necessary.)
+While the kernel will be obtained from the dom0 file system, it is
+helpful but not necessary for the same kernel to be present in the
+domU as /netbsd so that tools like savecore(8) can work.
 
 The kernel must be specifically built for Xen, to use PV interfaces as
 a domU.  NetBSD release builds provide the following kernels:
@@ -691,12 +726,12 @@
 and can load sets from the network.  To do this, copy the INSTALL
 kernel to / and change the kernel line in the config file to:
 
-        kernel = "/home/bouyer/netbsd-INSTALL_XEN3_DOMU"
+        kernel = "/netbsd-INSTALL_XEN3_DOMU"
 
 Then, start the domain as "xl create -c configfile".
 
-Alternatively, if you want to install NetBSD/Xen with a CDROM image, the following
-line should be used in the config file.
+Alternatively, if you want to install NetBSD/Xen with a physical
+CDROM, the following line should be used in the config file.
 
     disk = [ 'phy:/dev/wd0e,0x1,w', 'phy:/dev/cd0a,0x2,r' ]
 

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.249
retrieving revision 1.250
diff -u -r1.249 -r1.250
--- wikisrc/ports/xen/howto.mdwn	12 Jul 2024 14:12:22 -0000	1.249
+++ wikisrc/ports/xen/howto.mdwn	12 Jul 2024 14:34:30 -0000	1.250
@@ -785,7 +785,8 @@
 
 Use type='hvm'.  Use a GENERIC kernel within the disk image, or an
 INSTALL cd image.  The disk image should have bootblocks, as if it
-were a real machine.
+were a real machine.  Note that because GENERIC has PV drivers, this
+will be PVHVM if you dno't remove them.
 
 Perhaps configure serial="pty" to gain access to the domUs first
 serial port (and hence console?).
@@ -806,10 +807,10 @@
 
 ## Creating a NetBSD PVHVM domU
 
-Probably just like HVM, except ensure that GENERIC has PV drivers also.
+Exactly as HVM, except don't disable the PV drivers.
 
 \todo Explain if declaring pvhvm vs hvm causes disk/networking to
-appear as PV instead of emulated.
+appear as PV instead of emulated, or ?
 
 ## Creating a FreeBSD domU
 

Members: 
	ports/xen/howto.mdwn:1.248->1.249 

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.248
retrieving revision 1.249
diff -u -r1.248 -r1.249
--- wikisrc/ports/xen/howto.mdwn	12 Jul 2024 13:36:19 -0000	1.248
+++ wikisrc/ports/xen/howto.mdwn	12 Jul 2024 14:12:22 -0000	1.249
@@ -148,29 +148,27 @@
 versions has been pruned.
 
 Xen has been supported in NetBSD for a long time, at least since 2005.
-Initially Xen was PV only.
+NetBSD Xen has always supported PV (originally, Xen simply was PV), in
+both dom0 and domU.
 
-NetBSD Xen has always supported PV, in both dom0 and domU.
-NetBSD 8 and later as a dom0 supports HVM mode in domUs.
+NetBSD 8 and later as a dom0 supports running HVM domUs.
 
-Support for PVH and PVHVM is available in NetBSD 10; this is currently
-somewhat experimental, although PVHVM appears reasonably solid.
+NetBSD 10 and later as a domU can be run in PVH and PVHVM modes.
 
-NetBSD up to and including NetBSD 9 as a dom0 cannot safely run SMP.
-Even if one added "options MULTIPROCESSOR" and configured multiple
-vcpus, the kernel is likely to crash because of drivers without
-adequate locking.  NetBSD 10 supports SMP in dom0, and XEN3_DOM0
-includes "options MULTIPROCESSOR".
-
-NetBSD (since NetBSD 6), when run as a domU, can run SMP, using
-multiple CPUs if provided.  The XEN3_DOMU kernel is built
-with "options MULITPROCESSOR".
+NetBSD up to and including NetBSD 9 as a dom0 cannot safely run SMP
+(due to inadequate locking).  NetBSD 10 supports SMP in dom0, and
+XEN3_DOM0 includes "options MULTIPROCESSOR".
+
+NetBSD 6 and later, when run as a domU, can run SMP, using multiple
+CPUs if provided.  The XEN3_DOMU kernel is built with "options
+MULITPROCESSOR".
 
 Note that while the current version of Xen is 4.X, the kernel support
 is still called XEN3, because the hypercall interface has not changed
 significantly and because renaming it would not be useful.
 
-See also [NetBSD Xen daily test results](https://largo.lip6.fr/~bouyer/NetBSD-tests/xen/).
+See also
+[NetBSD Xen daily test results](https://largo.lip6.fr/~bouyer/NetBSD-tests/xen/).
 
 # Creating a NetBSD dom0
 
@@ -777,20 +775,21 @@
 
 ## Creating a NetBSD PVH domU
 
-\todo Check/fix these instructions.
-
-This is only supported for NetBSD 10 and up as the guest.
-
 Use type='pvh'.  Configure a GENERIC kernel instead of XEN3_DOMU.
 
 There is a PR about i386 PVH guests, but they work fine during daily tests.
 See [PR 57199](https://gnats.netbsd.org/57199).
+See [NetBSD daily tests](https://largo.lip6.fr/~bouyer/NetBSD-tests/xen/).
 
 ## Creating a NetBSD HVM domU
 
-Use a GENERIC kernel within the disk image.  Use bootblocks, as if it
+Use type='hvm'.  Use a GENERIC kernel within the disk image, or an
+INSTALL cd image.  The disk image should have bootblocks, as if it
 were a real machine.
 
+Perhaps configure serial="pty" to gain access to the domUs first
+serial port (and hence console?).
+
 This config snippet was stolen from a port-xen post.  It might not
 quite work, as it was in the context of debugging issues apparently
 from zvol usage.
@@ -865,7 +864,7 @@
 
 ## Creating a Solaris domU
 
-See possibly outdated
+See the very outdated
 [Solaris domU instructions](/ports/xen/howto-solaris/).
 
 ## PCI passthrough: Using PCI devices in guest domains
@@ -1093,18 +1092,15 @@
 The intent is to list providers only if they document support for
 running NetBSD, and to point to their resources briefly.
 
-
 ### panix.com
 
 [Panix](http://www.panix.com/) provides NetBSD as an OS option.  See
 their [Colocated Virtual Servers](https://www.panix.com/v-colo/) page
-for more information.  NetBSD 9 is available in PV mode,
-straightforwardly for amd64 and using the pvh/pvshim=1 technique
-described above for i386.  NetBSD 10 amd64 is available to customers
-in PVHVM mode, enabling booting a kernel from the VPS's filesystem.
-(NetBSD 10 also runs in PV and PVH mode on Panix's infrastructure, but
-PVHVM mode is preferred because it allows easy user control over the
-kernel.)
+for more information.  NetBSD 9 is available in PV mode, (pvh/pvshim=1
+for i386).  NetBSD 10 amd64 is available to customers in PVHVM mode,
+enabling booting a kernel from the VPS's filesystem.  (NetBSD 10 also
+runs in PV and PVH mode on Panix's infrastructure, but PVHVM mode is
+preferred because it allows easy user control over the kernel.)
 
 ### tornadovps.com
 
@@ -1114,9 +1110,9 @@
 /boot).  See the [tornadovps.com NetBSD
 instructions](https://tornadovps.com/documentation/netbsd).
 
-The main path for NetBSD is PV mode, but HVM modes might also work.
+The main path for NetBSD is PV mode; HVM modes are experimental.
 
-As of 2023-12, NetBSD 10 kernels booting in PV mode crash during booting.
+See the "Grant Table Hypervisor Bug" above.
 
 ### precedence.co.uk
 

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.247
retrieving revision 1.248
diff -u -r1.247 -r1.248
--- wikisrc/ports/xen/howto.mdwn	12 Jul 2024 11:35:09 -0000	1.247
+++ wikisrc/ports/xen/howto.mdwn	12 Jul 2024 13:36:19 -0000	1.248
@@ -55,9 +55,9 @@
 [[!table data="""
 Style of guest	|dom0 can be?	|dom0 can support?	|domU can be?	|needs VT-X/SVM
 PV		|yes		|yes			|yes		|no
-PVH		|not yet	|10/current		|10/current	|no
+PVH		|not yet	|10/current		|10/current	|yes
 HVM		|N/A		|yes			|yes		|yes
-PVHVM		|N/A		|yes			|10/current	|\todo probably
+PVHVM		|N/A		|yes			|10/current	|yes
 """]]
 
 In PV (paravirtualized) mode, the guest OS does not attempt to access
@@ -94,12 +94,12 @@
 kernel stored in the domU's filesystem.  This can be useful in VPS
 situations where the owner of the domU has no access to the dom0.
 
-
 ## CPU Architecture
 
 Xen runs on x86_64 hardware (the NetBSD amd64 port).
 
-There is a concept of Xen running on ARM, but there are no reports of this working with NetBSD.
+There is a concept of Xen running on arm32 and aarch64, but there are
+thus far no reports of this working with NetBSD.
 
 The dom0 system must be amd64.
 
@@ -122,20 +122,25 @@
 4.18		|xenkernel418	|x86_64			|2026-11-16   |2025-05-16  |
 """]]
 
-As of December 2023, 4.15 has been working well on NetBSD 9 through
-current with both i386 and amd64 guests.
-
-4.18 works well, when the dom0 is NetBSD 10 and has had some testing
-on NetBSD-current.  It is not clear if 4.18 will run well or not on
-NetBSD 9 as a dom0.  Note that i386 PV guests are no longer directly
-supported; see the "PVH shim" section below for the required
-adjustment.
-
-The standard approach is thus blurred between 4.15 and 4.18.
-
-\todo Describe i386 and amd64 PVH and HVM guest status.
-
-See also the [Xen Security Advisory page](http://xenbits.xen.org/xsa/).
+See also the
+[Xen Support Matrix page](https://xenbits.xen.org/docs/unstable/support-matrix.html)
+and the
+[Xen Security Advisory page](http://xenbits.xen.org/xsa/).
+
+As of July 2024, both 4.15 and 4.18 generally work well on NetBSD 9
+through current with i386 and amd64 guests.  The standard approach is
+4.18.
+However, there is a timekeeping issue on some systems with 4.18; see
+"Timekeeping Woes" below.
+
+Note that with 4.18, i386 PV guests are no longer directly supported;
+see the "Creating a NetBSD PV Shim domU" section below for the
+required minor adjustment.
+
+As of July 2024, there are no efforts to package 4.19 (not yet
+released), and there are hints that 4.20 (not even listed on the
+support matrix page yet) might be packaged.  Note that 4.18 is the
+current stable release of Xen; pkgsrc is not behind.
 
 ## NetBSD versions
 
@@ -148,16 +153,14 @@
 NetBSD Xen has always supported PV, in both dom0 and domU.
 NetBSD 8 and later as a dom0 supports HVM mode in domUs.
 
-Support for PVHVM and PVH is available in NetBSD 10; this is currently
+Support for PVH and PVHVM is available in NetBSD 10; this is currently
 somewhat experimental, although PVHVM appears reasonably solid.
 
 NetBSD up to and including NetBSD 9 as a dom0 cannot safely run SMP.
 Even if one added "options MULTIPROCESSOR" and configured multiple
 vcpus, the kernel is likely to crash because of drivers without
-adequate locking.
-
-NetBSD 10 supports SMP in dom0, and XEN3_DOM0 includes "options
-MULTIPROCESSOR".
+adequate locking.  NetBSD 10 supports SMP in dom0, and XEN3_DOM0
+includes "options MULTIPROCESSOR".
 
 NetBSD (since NetBSD 6), when run as a domU, can run SMP, using
 multiple CPUs if provided.  The XEN3_DOMU kernel is built
@@ -167,15 +170,14 @@
 is still called XEN3, because the hypercall interface has not changed
 significantly and because renaming it would not be useful.
 
+See also [NetBSD Xen daily test results](https://largo.lip6.fr/~bouyer/NetBSD-tests/xen/).
+
 # Creating a NetBSD dom0
 
 In order to install a NetBSD as a dom0, one first installs a normal
 NetBSD system, and then pivots the install to a dom0 install by
 changing the kernel and boot configuration.
 
-NB: As of 2021-04, you must arrange to have the system use BIOS boot,
-not EFI boot.
-
 In 2018-05, trouble booting a dom0 was reported with 256M of RAM: with
 512M it worked reliably.  This does not make sense, but if you see
 "not ELF" after Xen boots, try increasing dom0 RAM.
@@ -748,10 +750,6 @@
 Xen 4.18.  For them, performance seems similar to regular PV with
 older Xen.
 
-There is 1 data point that it seems to work for amd64 PV guests, but
-with abysmal performance (at least 100x slowdown).  \todo Confirm
-speed issue, file a PR, and explain.
-
 Configure as for pv, but add
 
     type="pvh"
@@ -762,6 +760,13 @@
 from Xen 4.15 to 4.18, the only change needed for an i386 domU is the
 two lines above.
 
+It seems that this use of pvh (for i386 guests) works ok even on
+systems that lack VT-X/SVM.
+
+There is 1 data point that it seems to work for amd64 PV guests on a
+system without VT-X/SVM, but with abysmal performance (at least 100x
+slowdown).  \todo Confirm speed issue, file a PR, and explain.
+
 ## Creating a NetBSD PVH dom0
 
 \todo This might or might not work in current.
@@ -778,7 +783,7 @@
 
 Use type='pvh'.  Configure a GENERIC kernel instead of XEN3_DOMU.
 
-Operation of i386 PVH guests is not reliable.
+There is a PR about i386 PVH guests, but they work fine during daily tests.
 See [PR 57199](https://gnats.netbsd.org/57199).
 
 ## Creating a NetBSD HVM domU
@@ -956,6 +961,8 @@
 
 http://gnats.netbsd.org/58395
 
+This has so far only been reported at tornadovps, believed to be running 4.14.0.88.g1d1d1f53.
+
 ## Timekeeping Woes
 
 As of 2024-07, there has been extensive recent discussion about

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.246
retrieving revision 1.247
diff -u -r1.246 -r1.247
--- wikisrc/ports/xen/howto.mdwn	12 Jul 2024 00:10:24 -0000	1.246
+++ wikisrc/ports/xen/howto.mdwn	12 Jul 2024 11:35:09 -0000	1.247
@@ -786,19 +786,9 @@
 Use a GENERIC kernel within the disk image.  Use bootblocks, as if it
 were a real machine.
 
-This config snippet was stolen from a port-xen post.  It uses older
-directives and is likely not appropriate for modern xen.  Complaints
-should be accompanied by a better example!
-
-[[!template id=programlisting text="""
-kernel = "/usr/pkg/lib/xen/boot/hvmloader"
-builder='hvm'
-device_model_version="qemu-xen-traditional"
-boot='c'
-"""]]
-
-This config snippet was also stolen from a port-xen post.  This uses
-current config, but may not work.
+This config snippet was stolen from a port-xen post.  It might not
+quite work, as it was in the context of debugging issues apparently
+from zvol usage.
 
 [[!template id=programlisting text="""
 type = "hvm"
@@ -807,10 +797,9 @@
 vcpus = 2
 vif = [ 'mac=00:01:02:ab:cd:ef, bridge=bridge0' ]
 disk =  [ 'format=raw, vdev=hda, access=rw,
-target=phy:/dev/zvol/dsk/tank/foo' ]
+           target=phy:/dev/zvol/dsk/tank/foo' ]
 """]]
 
-
 ## Creating a NetBSD PVHVM domU
 
 Probably just like HVM, except ensure that GENERIC has PV drivers also.

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.245
retrieving revision 1.246
diff -u -r1.245 -r1.246
--- wikisrc/ports/xen/howto.mdwn	12 Jul 2024 00:05:37 -0000	1.245
+++ wikisrc/ports/xen/howto.mdwn	12 Jul 2024 00:10:24 -0000	1.246
@@ -797,6 +797,20 @@
 boot='c'
 """]]
 
+This config snippet was also stolen from a port-xen post.  This uses
+current config, but may not work.
+
+[[!template id=programlisting text="""
+type = "hvm"
+name = "foo"
+memory = 2048
+vcpus = 2
+vif = [ 'mac=00:01:02:ab:cd:ef, bridge=bridge0' ]
+disk =  [ 'format=raw, vdev=hda, access=rw,
+target=phy:/dev/zvol/dsk/tank/foo' ]
+"""]]
+
+
 ## Creating a NetBSD PVHVM domU
 
 Probably just like HVM, except ensure that GENERIC has PV drivers also.

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.244
retrieving revision 1.245
diff -u -r1.244 -r1.245
--- wikisrc/ports/xen/howto.mdwn	11 Jul 2024 23:29:30 -0000	1.244
+++ wikisrc/ports/xen/howto.mdwn	12 Jul 2024 00:05:37 -0000	1.245
@@ -786,11 +786,9 @@
 Use a GENERIC kernel within the disk image.  Use bootblocks, as if it
 were a real machine.
 
-This config snippet was stolen from a port-xen post.
-
-\todo Explain about builder vs type.
-
-\todo Confirm and fix text.
+This config snippet was stolen from a port-xen post.  It uses older
+directives and is likely not appropriate for modern xen.  Complaints
+should be accompanied by a better example!
 
 [[!template id=programlisting text="""
 kernel = "/usr/pkg/lib/xen/boot/hvmloader"
@@ -803,7 +801,7 @@
 
 Probably just like HVM, except ensure that GENERIC has PV drivers also.
 
-\todo Explain if the type/builder= define causes disk/networking to
+\todo Explain if declaring pvhvm vs hvm causes disk/networking to
 appear as PV instead of emulated.
 
 ## Creating a FreeBSD domU

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.243
retrieving revision 1.244
diff -u -r1.243 -r1.244
--- wikisrc/ports/xen/howto.mdwn	11 Jul 2024 23:01:59 -0000	1.243
+++ wikisrc/ports/xen/howto.mdwn	11 Jul 2024 23:29:30 -0000	1.244
@@ -726,9 +726,9 @@
 One should also run `powerd` in a domU, but this should not need
 configuring.  With powerd, the domain will run a controlled shutdown
 if `xl shutdown -R` or `xl shutdown -H` is used on the dom0, via
-receiving a synthetic `power button pressed` signal.  In 9 and
-current, `powerd` is run by default under Xen kernels (or if ACPI is
-present), and it can be added to rc.conf if not.
+receiving a synthetic `power button pressed` signal.  In NetBSD 9 and
+later, `powerd` is enabled by default under Xen (or if ACPI is
+present).
 
 It is not strictly necessary to have a kernel (as /netbsd) in the domU
 file system.  However, various programs (e.g. netstat) will use that
@@ -745,37 +745,66 @@
 
 This is like a PV domU, but has a second copy of xen (shim) between
 dom0 and domU.  Note that this is necessary for i386 PV guests with
-Xen 4.18.  It also works for amd64 PV guests, but there are no known
-reasons to favor PV shim over normal PV.
+Xen 4.18.  For them, performance seems similar to regular PV with
+older Xen.
+
+There is 1 data point that it seems to work for amd64 PV guests, but
+with abysmal performance (at least 100x slowdown).  \todo Confirm
+speed issue, file a PR, and explain.
 
 Configure as for pv, but add
 
     type="pvh"
     pvshim=1
 
-The domU system itself is unchanged; it still uses a PV (XEN3_DOMU or XEN3PAE_DOMU) kernel,
-and still sees the same devices.
+The domU system itself is unchanged; it still uses a PV (XEN3_DOMU or
+XEN3PAE_DOMU) kernel, and still sees the same devices.  When upgrading
+from Xen 4.15 to 4.18, the only change needed for an i386 domU is the
+two lines above.
+
+## Creating a NetBSD PVH dom0
+
+\todo This might or might not work in current.
+\todo The following instructions are likely wrong.
+
+In boot.cfg, add dom0=pvh (dom0=pv is the default).  Configure GENERIC
+instead of XEN3_DOM0.
 
 ## Creating a NetBSD PVH domU
 
+\todo Check/fix these instructions.
+
 This is only supported for NetBSD 10 and up as the guest.
 
-Use type='pvh'.  Configure GENERIC instead of XEN3_DOMU.  In boot.cfg,
-add dom0=pvh.  (dom0=pv is the default, which is why this expression
-has not been previously discussed.)
+Use type='pvh'.  Configure a GENERIC kernel instead of XEN3_DOMU.
 
 Operation of i386 PVH guests is not reliable.
 See [PR 57199](https://gnats.netbsd.org/57199).
 
 ## Creating a NetBSD HVM domU
 
-Use type='hvm', probably.  Use a GENERIC kernel within the disk image.
+Use a GENERIC kernel within the disk image.  Use bootblocks, as if it
+were a real machine.
+
+This config snippet was stolen from a port-xen post.
+
+\todo Explain about builder vs type.
+
 \todo Confirm and fix text.
 
+[[!template id=programlisting text="""
+kernel = "/usr/pkg/lib/xen/boot/hvmloader"
+builder='hvm'
+device_model_version="qemu-xen-traditional"
+boot='c'
+"""]]
+
 ## Creating a NetBSD PVHVM domU
 
-Use type='pvhvm', guessing wildly.  Use a GENERIC kernel within the disk image.
-\todo Confirm and fix text.
+Probably just like HVM, except ensure that GENERIC has PV drivers also.
+
+\todo Explain if the type/builder= define causes disk/networking to
+appear as PV instead of emulated.
 
 ## Creating a FreeBSD domU
 
@@ -788,8 +817,7 @@
 Creating unprivileged Linux domains isn't much different from
 unprivileged NetBSD domains, but there are some details to know.
 
-NOTE: This is old text, and aparently Linux no longer supports PV.
-Instead, use pvh.
+\todo Confirm/rototill.
 
 First, the second parameter passed to the disk declaration (the '0x1' in
 the example below)

Members: 
	ports/xen/howto.mdwn:1.242->1.243 

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.242
retrieving revision 1.243
diff -u -r1.242 -r1.243
--- wikisrc/ports/xen/howto.mdwn	11 Jul 2024 22:57:54 -0000	1.242
+++ wikisrc/ports/xen/howto.mdwn	11 Jul 2024 23:01:59 -0000	1.243
@@ -745,7 +745,8 @@
 
 This is like a PV domU, but has a second copy of xen (shim) between
 dom0 and domU.  Note that this is necessary for i386 PV guests with
-Xen 4.18.
+Xen 4.18.  It also works for amd64 PV guests, but there are no known
+reasons to favor PV shim over normal PV.
 
 Configure as for pv, but add
 

Members: 
	ports/xen/howto.mdwn:1.241->1.242 

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.241
retrieving revision 1.242
diff -u -r1.241 -r1.242
--- wikisrc/ports/xen/howto.mdwn	11 Jul 2024 19:37:36 -0000	1.241
+++ wikisrc/ports/xen/howto.mdwn	11 Jul 2024 22:57:54 -0000	1.242
@@ -55,9 +55,9 @@
 [[!table data="""
 Style of guest	|dom0 can be?	|dom0 can support?	|domU can be?	|needs VT-X/SVM
 PV		|yes		|yes			|yes		|no
+PVH		|not yet	|10/current		|10/current	|no
 HVM		|N/A		|yes			|yes		|yes
 PVHVM		|N/A		|yes			|10/current	|\todo probably
-PVH		|not yet	|10/current		|10/current	|\todo probably
 """]]
 
 In PV (paravirtualized) mode, the guest OS does not attempt to access
@@ -69,6 +69,17 @@
 on Intel CPUs and SVM on AMD CPUs to assist with the processor
 emulation.
 
+PVH is substantially more efficient than PV because it uses hardware
+assisted virtualization.
+There have been two PVH modes: original PVH and PVHv2.  Original PVH
+was based on PV mode and is no longer relevant at all.  Therefore
+PVHv2 is written as PVH, here and elsewhere.  PVH is basically
+lightweight HVM with PV drivers.  A critical feature of it is that
+qemu is not needed; the hypervisor can do the emulation that is
+required.  Thus, a dom0 can be PVH.  The source code uses PVH and
+config files use pvh -- these refer to PVHv2.  See
+[PVH(v2)](https://wiki.xenproject.org/wiki/PVH_(v2\)_Domu).
+
 In HVM (Hardware Virtual Machine) mode, guest operating systems with
 no knowledge of or accomodation for Xen can be run.  The dom0 runs
 qemu to emulate hardware other than the processor.  It is therefore
@@ -83,16 +94,6 @@
 kernel stored in the domU's filesystem.  This can be useful in VPS
 situations where the owner of the domU has no access to the dom0.
 
-PVH is substantially more efficient than PV because it uses hardware
-assisted virtualization.
-There have been two PVH modes: original PVH and PVHv2.  Original PVH
-was based on PV mode and is no longer relevant at all.  Therefore
-PVHv2 is written as PVH, here and elsewhere.  PVH is basically
-lightweight HVM with PV drivers.  A critical feature of it is that
-qemu is not needed; the hypervisor can do the emulation that is
-required.  Thus, a dom0 can be PVH.  The source code uses PVH and
-config files use pvh -- these refer to PVHv2.  See
-[PVH(v2)](https://wiki.xenproject.org/wiki/PVH_(v2\)_Domu).
 
 ## CPU Architecture
 

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.240
retrieving revision 1.241
diff -u -r1.240 -r1.241
--- wikisrc/ports/xen/howto.mdwn	11 Jul 2024 19:35:16 -0000	1.240
+++ wikisrc/ports/xen/howto.mdwn	11 Jul 2024 19:37:36 -0000	1.241
@@ -331,7 +331,7 @@
 to force Xen to use serial only, and for NetBSD implicitly to use
 xencons(4).
 
-### Early NetBSD 90
+### Early NetBSD 9
 
 When the dom0 kernel is NetBSD 9 before 2021-04-17 (9.3 is ok), Xen
 4.15 and later require "dom0=msr-relaxed=1" on the boof.cfg line.
@@ -925,6 +925,14 @@
 
 http://gnats.netbsd.org/58395
 
+## Timekeeping Woes
+
+As of 2024-07, there has been extensive recent discussion about
+timekeeping problems on dom0 and domU NetBSD systems, perhaps worse
+with 4.18.
+
+\todo Add link to crisp PR summarizing what we know, after someone(tm) files one.
+
 ## Configuration of non-NetBSD dom0s to run NetBSD domUs
 
 Apparently one must have "pv-linear-pt=true" in the dom0 circumstances

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.239
retrieving revision 1.240
diff -u -r1.239 -r1.240
--- wikisrc/ports/xen/howto.mdwn	11 Jul 2024 19:09:28 -0000	1.239
+++ wikisrc/ports/xen/howto.mdwn	11 Jul 2024 19:35:16 -0000	1.240
@@ -118,7 +118,7 @@
 [[!table data="""
 Xen Version	|Package Name	|Xen CPU Support	|Security EOL |Feature EOL | 
 4.15		|xenkernel415	|x86_64			|2024-04-08   |2022-10-08  |
-4.18		|xenkernel415	|x86_64			|2026-11-16   |2025-05-16  |
+4.18		|xenkernel418	|x86_64			|2026-11-16   |2025-05-16  |
 """]]
 
 As of December 2023, 4.15 has been working well on NetBSD 9 through
@@ -331,14 +331,11 @@
 to force Xen to use serial only, and for NetBSD implicitly to use
 xencons(4).
 
-### Older NetBSD kernels
+### Early NetBSD 90
 
-When the dom0 kernel is NetBSD 8 and earlier, or NetBSD 9 before
-2021-04-17 (9.3 is ok), Xen 4.15 and later require
-"dom0=msr-relaxed=1" on the boof.cfg line.  (See
-/src/sys/arch/x86/x86/pmap.c revision 1.410.)
-
-(NetBSD 5 domUs appear to be troubled with recent Xen and NetBSD dom0.)
+When the dom0 kernel is NetBSD 9 before 2021-04-17 (9.3 is ok), Xen
+4.15 and later require "dom0=msr-relaxed=1" on the boof.cfg line.
+(See /src/sys/arch/x86/x86/pmap.c revision 1.410.)
 
 ### Tuning
 
@@ -420,8 +417,8 @@
 One is that through NetBSD 9 the module ABI is different because some
 of the #defines change, so there are separate sets of modules in
 /stand.  (Further, zfs in Xen is troubled because of differing
-MAXPHYS; see the zfs howto for more.)  In NetBSD-current, there is
-only one set of modules.
+MAXPHYS; see the zfs howto for more.)  In NetBSD 10 and later, there
+is only one set of modules.
 
 The other difference is that XEN3_DOM0 does not have exactly the same
 options as GENERIC.  While this is roughly agreed to be in large part
@@ -437,7 +434,7 @@
 Note the previous advice to maintain a working and tested boot config
 into GENERIC without Xen.
 
-Updating Xen in a dom0 consists of updating the xnekernel and xentools
+Updating Xen in a dom0 consists of updating the xenkernel and xentools
 packages, along with copying the xen.gz into place, and of course
 rebooting.
 
@@ -456,7 +453,7 @@
 likelihood of trouble is increased.  Therefore, 'make replace' of
 xentools on a dom0 with running domUs is not recommended.  A shutdown
 on all domUs before replacing xentools is likely sufficient.  A safer
-appraoch is to boot into GENERIC to replace the packages, as then no
+approach is to boot into GENERIC to replace the packages, as then no
 Xen code will be running.  Single user is another option.
 
 ## Updating NetBSD in a dom0
@@ -746,7 +743,8 @@
 ## Creating a NetBSD PV Shim domU
 
 This is like a PV domU, but has a second copy of xen (shim) between
-dom0 and domU.
+dom0 and domU.  Note that this is necessary for i386 PV guests with
+Xen 4.18.
 
 Configure as for pv, but add
 
@@ -767,9 +765,6 @@
 Operation of i386 PVH guests is not reliable.
 See [PR 57199](https://gnats.netbsd.org/57199).
 
-\todo Verify if one can have netbsd-10 PVH domU on a 9 dom0, and
-adjust the dom0 pvh text.
-
 ## Creating a NetBSD HVM domU
 
 Use type='hvm', probably.  Use a GENERIC kernel within the disk image.
@@ -921,6 +916,15 @@
 
 https://wiki.xenproject.org/wiki/Grant_Table
 
+## Grant Table Hypervisor Bug
+
+Some Xen versions return bad values for the 33rd grant table entry.
+This affects NetBSD 10 always, because it pre-acquires grant table
+entries.  It affects earlier NetBSD and Linux if the 33rd is
+requested.
+
+http://gnats.netbsd.org/58395
+
 ## Configuration of non-NetBSD dom0s to run NetBSD domUs
 
 Apparently one must have "pv-linear-pt=true" in the dom0 circumstances

Members: 
	ports/xen/howto.mdwn:1.238->1.239 

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.238
retrieving revision 1.239
diff -u -r1.238 -r1.239
--- wikisrc/ports/xen/howto.mdwn	13 Jan 2024 20:13:55 -0000	1.238
+++ wikisrc/ports/xen/howto.mdwn	11 Jul 2024 19:09:28 -0000	1.239
@@ -35,6 +35,10 @@
 and how to deal with having a domU in a Xen environment run by someone
 else and/or not running NetBSD.
 
+At system boot, the dom0 kernel is loaded as a module with Xen as the
+kernel.  The dom0 can start one or more domUs.  (Booting is explained
+in detail in the dom0 section.)
+
 There are many choices one can make; the HOWTO recommends the standard
 approach and limits discussion of alternatives in many cases.
 
@@ -49,11 +53,11 @@
 if NetBSD as a domU can support that style.
 
 [[!table data="""
-Style of guest	|dom0 can be?	|dom0 can support?	|domU can be?
-PV		|yes		|yes			|yes
-HVM		|N/A		|yes			|yes
-PVHVM		|N/A		|yes			|10/current
-PVH		|not yet	|10/current		|10/current
+Style of guest	|dom0 can be?	|dom0 can support?	|domU can be?	|needs VT-X/SVM
+PV		|yes		|yes			|yes		|no
+HVM		|N/A		|yes			|yes		|yes
+PVHVM		|N/A		|yes			|10/current	|\todo probably
+PVH		|not yet	|10/current		|10/current	|\todo probably
 """]]
 
 In PV (paravirtualized) mode, the guest OS does not attempt to access
@@ -61,25 +65,16 @@
 guests must be specifically coded for Xen.  See
 [PV](https://wiki.xen.org/wiki/Paravirtualization_(PV\)).
 
-PVH is substantially more efficient than PV because it uses hardware
-assisted virtualization.
-There have been two PVH modes: original PVH and PVHv2.  Original PVH
-was based on PV mode and is no longer relevant at all.  Therefore
-PVHv2 is written as PVH, here and elsewhere.  PVH is basically
-lightweight HVM with PV drivers.  A critical feature of it is that
-qemu is not needed; the hypervisor can do the emulation that is
-required.  Thus, a dom0 can be PVH.  The source code uses PVH and
-config files use pvh -- these refer to PVHv2.  See
-[PVH(v2)](https://wiki.xenproject.org/wiki/PVH_(v2\)_Domu).
+For various PVH/HVM modes, hardware support is required, such as VT-x
+on Intel CPUs and SVM on AMD CPUs to assist with the processor
+emulation.
 
 In HVM (Hardware Virtual Machine) mode, guest operating systems with
-no knowledge of or accomodation for Xen can be run.  However, hardware
-support is required, such as VT-x on Intel CPUs and SVM on AMD CPUs to
-assist with the processor emulation.  The dom0 runs qemu to emulate
-hardware other than the processor.  It is therefore non-sensical to
-have an HVM dom0, because there is no underlying system to provide
-emulation.  HVM can be useful to work around bugs even if some other
-mode could be used.
+no knowledge of or accomodation for Xen can be run.  The dom0 runs
+qemu to emulate hardware other than the processor.  It is therefore
+non-sensical to have an HVM dom0, because there is no underlying
+system to provide emulation.  HVM can be useful to work around bugs
+even if some other mode could be used.
 
 In PVHVM mode, the guest runs as HVM, but additionally uses PV drivers
 for efficiency.  Therefore it is non-sensical for to have a PVHVM
@@ -88,9 +83,16 @@
 kernel stored in the domU's filesystem.  This can be useful in VPS
 situations where the owner of the domU has no access to the dom0.
 
-At system boot, the dom0 kernel is loaded as a module with Xen as the
-kernel.  The dom0 can start one or more domUs.  (Booting is explained
-in detail in the dom0 section.)
+PVH is substantially more efficient than PV because it uses hardware
+assisted virtualization.
+There have been two PVH modes: original PVH and PVHv2.  Original PVH
+was based on PV mode and is no longer relevant at all.  Therefore
+PVHv2 is written as PVH, here and elsewhere.  PVH is basically
+lightweight HVM with PV drivers.  A critical feature of it is that
+qemu is not needed; the hypervisor can do the emulation that is
+required.  Thus, a dom0 can be PVH.  The source code uses PVH and
+config files use pvh -- these refer to PVHv2.  See
+[PVH(v2)](https://wiki.xenproject.org/wiki/PVH_(v2\)_Domu).
 
 ## CPU Architecture
 
@@ -119,39 +121,34 @@
 4.18		|xenkernel415	|x86_64			|2026-11-16   |2025-05-16  |
 """]]
 
-As of December 2023, 4.15 has been working well on NetBSD 8 through
-current with both i386 and amd64 guests and is the standard approach.
+As of December 2023, 4.15 has been working well on NetBSD 9 through
+current with both i386 and amd64 guests.
 
 4.18 works well, when the dom0 is NetBSD 10 and has had some testing
-on NetBSD-current.  It runs a NetBSD 9 PV domU well.  Note that i386
-PV guests are no longer supported; see the "PVH shim" section below
-for the required adjustment.
+on NetBSD-current.  It is not clear if 4.18 will run well or not on
+NetBSD 9 as a dom0.  Note that i386 PV guests are no longer directly
+supported; see the "PVH shim" section below for the required
+adjustment.
 
-\todo Describe i386 and amd64 PVH and HVM guest status.
+The standard approach is thus blurred between 4.15 and 4.18.
 
-It is not clear if 4.18 will run well or not on NetBSD 9 as a dom0.
-It is likely to be troubled on NetBSD 8 as a dom0 (which is expected
-to be no longer relevant very soon).
+\todo Describe i386 and amd64 PVH and HVM guest status.
 
 See also the [Xen Security Advisory page](http://xenbits.xen.org/xsa/).
 
-Extremely old Xen had a python-based management tool called xm; this
-has long since been replaced by xl and is not discussed further.
-
 ## NetBSD versions
 
+This HOWTO addresses NetBSD 9 and later; information about EOL NetBSD
+versions has been pruned.
+
 Xen has been supported in NetBSD for a long time, at least since 2005.
 Initially Xen was PV only.
 
-NetBSD Xen has always supported PV, in both dom0 and domU -- this used
-to be the only way.  NetBSD 8 and later as a dom0 supports HVM mode in domUs.
+NetBSD Xen has always supported PV, in both dom0 and domU.
+NetBSD 8 and later as a dom0 supports HVM mode in domUs.
 
 Support for PVHVM and PVH is available in NetBSD 10; this is currently
-somewhat experimental, although PVHVM appears reasonably solid.  Note
-that these require newer CPU features than just PV, but as of 2023
-most hardware that one intends to actually use with Xen is likely to
-have support.  \todo Describe the CPU flags or provide a link to
-upstream.
+somewhat experimental, although PVHVM appears reasonably solid.
 
 NetBSD up to and including NetBSD 9 as a dom0 cannot safely run SMP.
 Even if one added "options MULTIPROCESSOR" and configured multiple

Members: 
	amazon_ec2/first_steps.mdwn:1.4->1.5 

Index: wikisrc/amazon_ec2/first_steps.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/amazon_ec2/first_steps.mdwn,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- wikisrc/amazon_ec2/first_steps.mdwn	8 Oct 2019 11:03:51 -0000	1.4
+++ wikisrc/amazon_ec2/first_steps.mdwn	11 Jul 2024 10:29:44 -0000	1.5
@@ -14,18 +14,18 @@
 These can be created through the [Security Credentials](https://aws-portal.amazon.com/gp/aws/developer/account/index.html?ie=UTF8&action=access-key) page (also accessible from the [Account](http://aws.amazon.com/account/) page):
 
 1. create the access key. Keep a secured copy of the ID and its associated secret value. These will be used by various scripts later on to perform certain EC2 actions.
-1. note down your account number (different from your access key ID!). This identifier can usually be obtained in the right top part of the page; it is a serie of numbers, separated with dashes: XXXX-XXXX-XXXX.
+1. note down your account number (different from your access key ID!). This identifier can usually be obtained in the right top part of the page; it is a series of numbers, separated with dashes: XXXX-XXXX-XXXX.
 1. create, or upload, a X.509 certificate, in PEM format. Keep the private key in a safe place.
 1. lastly, generate Amazon EC2 key pairs that will be used for SSH access. This step will be performed through the [Amazon Management Console](https://console.aws.amazon.com/ec2/home). Note down the SSH Key Pair Name you chose.
 
 ### Keep your credentials!
 
-The different credentials created above will be used in various places of EC2, and by a myriad of commands. You are advised to keep them easily accessible, while still reasonably secure regarding their access. Most EC2 tools expect them to be find through a set of environment variables.
+The different credentials created above will be used in various places of EC2, and by a myriad of commands. You are advised to keep them easily accessible, while still reasonably secure regarding their access. Most EC2 tools expect them to be found through a set of environment variables.
 
 For convenience, you could store them under a *.ec2* directory inside your *$HOME*:
 
 [[!template id=programlisting text="""
-$ ls .ec2/                                                                
+$ ls .ec2/
 cert-SOMERANDOMKEY.pem # the X.509 certificate
 id_rsa.ec2             # private RSA SSH key
 id_rsa.ec2.pub         # public RSA SSH key

Index: wikisrc/ports/evbarm/qemu_arm.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/qemu_arm.mdwn,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- wikisrc/ports/evbarm/qemu_arm.mdwn	14 Mar 2022 07:22:29 -0000	1.11
+++ wikisrc/ports/evbarm/qemu_arm.mdwn	25 Jun 2024 11:58:47 -0000	1.12
@@ -34,6 +34,17 @@
           -netdev type=user,id=net0 -device virtio-net-device,netdev=net0,mac=00:11:22:33:44:55 \
           -bios QEMU_EFI.fd -nographic
 
+# Booting the system (arm64) directly into the kernel with hardware accelerated virtualization on a Linux host
+
+    $ qemu-system-aarch64 -M virt,accel=kvm -cpu host -m 256 \
+          -drive if=none,file=arm64.img,id=hd0 -device virtio-blk-device,drive=hd0 \
+          -device virtio-rng-pci -kernel netbsd-GENERIC64.img -append "root=NAME=netbsd-root" \
+          -netdev type=user,id=net0 -device virtio-net-device,netdev=net0,mac=00:11:22:33:44:55 \
+          -display none -serial stdio
+
+* As of today, a regular ELF kernel won't boot, use `netbsd-GENERIC64.img` (`.img` suffix)
+* `-device virtio-rng-pci` is needed for the boot not to hang on `Waiting for entropy...`
+
 # Booting the system (armv7)
 
     $ qemu-system-arm -M virt -cpu cortex-a15 -smp 4 -m 2g \

Index: wikisrc/ports.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports.mdwn,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- wikisrc/ports.mdwn	2 Jun 2024 23:26:56 -0000	1.31
+++ wikisrc/ports.mdwn	23 Jun 2024 22:41:14 -0000	1.32
@@ -45,7 +45,7 @@
 
 [[!table data="""
 Port		|CPU		|Machines								|Latest Release
-[[acorn32]]	|arm		|Acorn RiscPC/A7000/NC and compatibles					|[8.1](http://www.NetBSD.org/releases/formal-8/)
+[[acorn32]]	|arm		|Acorn RiscPC/A7000/NC and compatibles					|[10.0](http://www.NetBSD.org/releases/formal-10/)
 [[algor]]	|mips		|Algorithmics MIPS evaluation boards					|[10.0](http://www.NetBSD.org/releases/formal-10/)
 [[alpha]]	|alpha		|Digital Alpha (64-bit)							|[10.0](http://www.NetBSD.org/releases/formal-10/)
 [[amiga]]	|m68k		|Commodore Amiga, MacroSystem DraCo					|[10.0](http://www.NetBSD.org/releases/formal-10/)

But it has been _practically_ mandatory since support for the
original i386 was removed some years prior -- not sure exactly when.

Members: 
	ports/i386.mdwn:1.27->1.28 

Index: wikisrc/ports/i386.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/i386.mdwn,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- wikisrc/ports/i386.mdwn	30 Mar 2024 19:27:00 -0000	1.27
+++ wikisrc/ports/i386.mdwn	19 Jun 2024 19:06:36 -0000	1.28
@@ -9,7 +9,7 @@
 changes_future="11.0"
 thumbnail="//www.netbsd.org/images/ports/i386/header.gif"
 about="""
-NetBSD/i386 is the port of NetBSD to generic machines ("PC clones") with 32-bit x86-family processors. It runs on PCI-Express, PCI, and CardBus systems, as well as older hardware with PCMCIA, VL-bus, EISA, MCA, and ISA (AT-bus) interfaces, with or without math coprocessors.
+NetBSD/i386 is the port of NetBSD to generic machines ("PC clones") with 32-bit x86-family processors. It runs on PCI-Express, PCI, and CardBus systems, as well as older hardware with PCMCIA, VL-bus, EISA, MCA, and ISA (AT-bus) interfaces, with x87 math coprocessors.
 
 Any i486 or better CPU should work - genuine Intel or a compatible such as Cyrix, AMD, or NexGen.
 

Index: wikisrc/gitsofar.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/gitsofar.mdwn,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- wikisrc/gitsofar.mdwn	4 Jun 2024 11:57:06 -0000	1.14
+++ wikisrc/gitsofar.mdwn	4 Jun 2024 12:03:59 -0000	1.15
@@ -70,6 +70,9 @@
 
 [In 2019, FreeBSD core team has appointed a WG to explore transition from Subversion to Git.](https://www.freebsd.org/news/status/report-2019-04-2019-06.html#FreeBSD-Core-Team)
 
+[FreeBSD has moved to git](http://bsdimp.blogspot.com/2020/09/freebsd-subversion-to-git-migration.html)
+[More FreeBSD git docs](https://docs.freebsd.org/en/articles/committers-guide/#git-primer)
+
 ### how to install
 
 git should fit into NetBSD src/tools easily.  I have not personally tested
@@ -107,7 +110,7 @@
 
 ### how to convert
 
-https://github.com/netbsd/
+[NetBSD on github](https://github.com/netbsd/)
 
 This has been working for years.
 
@@ -146,7 +149,7 @@
 
 ikiwiki's main backend is git so wikisrc and pkgsrc.org websites are better as git repos.
 
-[[RCS $Id: gitsofar.mdwn,v 1.14 2024/06/04 11:57:06 wiki Exp $ and more|https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes#Keyword-Expansion]] addresses RDS Id expansion specifically but consider not doing this in a 1:1 way in the future. These problems are likely solved by DragonflyBSD or FreeBSD already.
+[RCS Id and more)[https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes#Keyword-Expansion] addresses RDS Id expansion specifically but consider not doing this in a 1:1 way in the future. These problems are likely solved by DragonflyBSD or FreeBSD already.
 
 Very few systems should be relying on CVS _internals_ and should, generally, be able to replace a `cvs checkout` with `git clone` and that will be the extent of it. It's not a major concern but can't be done until decisions are made.
 

Index: wikisrc/gitsofar.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/gitsofar.mdwn,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- wikisrc/gitsofar.mdwn	4 Jun 2024 11:37:55 -0000	1.13
+++ wikisrc/gitsofar.mdwn	4 Jun 2024 11:57:06 -0000	1.14
@@ -142,9 +142,13 @@
 3. cvs is turned off
 4. git is made available over ssh
 
-### future considerations & misc
+### future considerations, internal tooling, & misc
 
-ikiwiki's main backend is git so wikisrc and pkgsrc.org websites are better as git repos
+ikiwiki's main backend is git so wikisrc and pkgsrc.org websites are better as git repos.
+
+[[RCS $Id: gitsofar.mdwn,v 1.14 2024/06/04 11:57:06 wiki Exp $ and more|https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes#Keyword-Expansion]] addresses RDS Id expansion specifically but consider not doing this in a 1:1 way in the future. These problems are likely solved by DragonflyBSD or FreeBSD already.
+
+Very few systems should be relying on CVS _internals_ and should, generally, be able to replace a `cvs checkout` with `git clone` and that will be the extent of it. It's not a major concern but can't be done until decisions are made.
 
 ### Addressing specific workflow concerns
 

Index: wikisrc/gitsofar.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/gitsofar.mdwn,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- wikisrc/gitsofar.mdwn	4 Jun 2024 11:36:04 -0000	1.12
+++ wikisrc/gitsofar.mdwn	4 Jun 2024 11:37:55 -0000	1.13
@@ -148,7 +148,7 @@
 
 ### Addressing specific workflow concerns
 
-The ability for CVS to checkout subdirectories appears to be a frequently requested feature. Git provides a way to do this using [sparse checkouts|https://git-scm.com/docs/git-sparse-checkout]. Let's demonstrate another neat feature [worktrees|https://git-scm.com/docs/git-worktree] so we can have multiple parallel branches checked out of `/bin/sh`
+The ability for CVS to checkout subdirectories appears to be a frequently requested feature. Git provides a way to do this using [[sparse checkouts|https://git-scm.com/docs/git-sparse-checkout]]. Let's demonstrate another neat feature [[worktrees|https://git-scm.com/docs/git-worktree]] so we can have multiple parallel branches checked out of `/bin/sh`
 
 doing parallel development of a specific tool efficiently. Repeat this into as many worktrees as you want.
 

Index: wikisrc/gitsofar.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/gitsofar.mdwn,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- wikisrc/gitsofar.mdwn	4 Jun 2024 01:06:44 -0000	1.11
+++ wikisrc/gitsofar.mdwn	4 Jun 2024 11:36:04 -0000	1.12
@@ -101,6 +101,10 @@
 Try to references named branches/tags instead of sha-1's
 Also using the dates for commits instead of commit id's
 
+The only rules I know about git commit messages are that the first line is treated specially insomuch that it is shown in `git log --oneline` output.
+
+Special commit messages you might have seen around "Closes CORE-1234" etc are commands being sent to commit hooks to interact with other systems (like bug trackers).
+
 ### how to convert
 
 https://github.com/netbsd/
@@ -138,8 +142,47 @@
 3. cvs is turned off
 4. git is made available over ssh
 
-### future considerations
+### future considerations & misc
 
 ikiwiki's main backend is git so wikisrc and pkgsrc.org websites are better as git repos
 
+### Addressing specific workflow concerns
+
+The ability for CVS to checkout subdirectories appears to be a frequently requested feature. Git provides a way to do this using [sparse checkouts|https://git-scm.com/docs/git-sparse-checkout]. Let's demonstrate another neat feature [worktrees|https://git-scm.com/docs/git-worktree] so we can have multiple parallel branches checked out of `/bin/sh`
+
+doing parallel development of a specific tool efficiently. Repeat this into as many worktrees as you want.
+
+
+```
+cd netbsd.git #my clone
+
+#make a new worktree and branch named new2
+git worktree add -b new2 --no-checkout ../new2
+cd ../new2 #only contains a .git/ dir
+
+#--no-cone avoids grabbing top-level files
+git sparse-checkout set --no-cone bin/sh
+
+#check on things
+git sparse-checkout list
+#output
+# bin/sh
+
+#get the files
+git checkout new2
+
+#did it work?
+find ./ -type d
+./
+./bin
+./bin/sh
+./bin/sh/funcs
+./bin/sh/USD.doc
+./bin/sh/bltin
+
+git status
+On branch new3
+You are in a sparse checkout with 1% of tracked files present.
 
+nothing to commit, working tree clean
+```

Index: wikisrc/gitsofar.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/gitsofar.mdwn,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- wikisrc/gitsofar.mdwn	3 Sep 2019 01:16:05 -0000	1.10
+++ wikisrc/gitsofar.mdwn	4 Jun 2024 01:06:44 -0000	1.11
@@ -48,13 +48,15 @@
 
 See above for CVS server provided if ongoing conversion is really desired.
 
-### existing cvs dependencies
+### existing cvs dependencies & server setup
 
 is there a list of these?  build systems?
-The entire build infrastructure of NetBSD should (even without giti) change into a "jobs"-oriented workflow instead of a "server"-oriented workflow.
+The entire build infrastructure of NetBSD should (even without git) change into a "jobs"-oriented workflow instead of a "server"-oriented workflow.
 
 Very recent (summer 2017) events have shown that the ability to move things around is very important.
 
+ivanova (cvs.netbsd.org) will become git.netbsd.org already for pkgsrc. Our restricted shell has a hook for git* commands to be passed to git-shell.
+
 
 ### How should NetBSD be setup
 
@@ -88,6 +90,9 @@
 A non-developer could also post a pull request to github or host his git repo
 for a friendly developer to add as an origin and pull his branch.
 
+Pull Requests using mailing lists https://patchwork.readthedocs.io/en/latest/
+
+
 (git origin add future-developer http://example.com/~greatguy/src.git)
 
 
@@ -100,6 +105,8 @@
 
 https://github.com/netbsd/
 
+This has been working for years.
+
 ### No lock-in
 
 I am unable to anticipate the next generation of SCM.
@@ -131,3 +138,8 @@
 3. cvs is turned off
 4. git is made available over ssh
 
+### future considerations
+
+ikiwiki's main backend is git so wikisrc and pkgsrc.org websites are better as git repos
+
+

Index: wikisrc/ports.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports.mdwn,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -r1.30 -r1.31
--- wikisrc/ports.mdwn	30 Mar 2024 19:26:59 -0000	1.30
+++ wikisrc/ports.mdwn	2 Jun 2024 23:26:56 -0000	1.31
@@ -1,5 +1,5 @@
 [[!meta title="Platforms supported by NetBSD"]]
-NetBSD calls a supported architecture a 'port'. Most ports run on generic hardware and emulators, although some [commercial hardware](http://www.netbsd.org/gallery/hardware.html) also exists. The NetBSD Ports History page details the inclusion date for each port.
+NetBSD calls a supported architecture a 'port'. Most ports run on generic hardware and emulators, although some [commercial hardware](http://www.NetBSD.org/gallery/hardware.html) also exists. The NetBSD Ports History page details the inclusion date for each port.
 
 Ports are classified into three 'tiers' based on the current importance of the architecture and the level of community activity. Summarizing, the tiers can be viewed to represent ports that NetBSD will support, ports that NetBSD does its best to support, and ports which may be desupported soon. The tier for each port may change over time and is decided by <[email protected]> based on input from users and developers.
 
@@ -20,15 +20,15 @@
 
 [[!table data="""
 Port		|CPU		|Machines						|Latest Release
-[[aarch64]]	|aarch64	|64-bit ARM CPUs					|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[amd64]]	|x86_64		|64-bit x86-family machines with AMD and Intel CPUs	|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[evbarm]]	|arm		|ARM evaluation boards					|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[evbmips]]	|mips		|MIPS-based evaluation boards				|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[evbppc]]	|powerpc	|PowerPC-based evaluation boards			|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[hpcarm]]	|arm		|StrongARM based Windows CE PDA machines		|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[i386]]	|i386		|32-bit x86-family generic machines ("PC clones")	|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[sparc64]]	|sparc		|Sun UltraSPARC (64-bit)				|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[xen]]		|i386, x86_64	|Xen Virtual Machine Monitor				|[10.0](http://www.netbsd.org/releases/formal-9/)
+[[aarch64]]	|aarch64	|64-bit ARM CPUs					|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[amd64]]	|x86_64		|64-bit x86-family machines with AMD and Intel CPUs	|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[evbarm]]	|arm		|ARM evaluation boards					|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[evbmips]]	|mips		|MIPS-based evaluation boards				|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[evbppc]]	|powerpc	|PowerPC-based evaluation boards			|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[hpcarm]]	|arm		|StrongARM based Windows CE PDA machines		|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[i386]]	|i386		|32-bit x86-family generic machines ("PC clones")	|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[sparc64]]	|sparc		|Sun UltraSPARC (64-bit)				|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[xen]]		|i386, x86_64	|Xen Virtual Machine Monitor				|[10.0](http://www.NetBSD.org/releases/formal-10/)
 """]]
 
 
@@ -45,56 +45,56 @@
 
 [[!table data="""
 Port		|CPU		|Machines								|Latest Release
-[[acorn32]]	|arm		|Acorn RiscPC/A7000/NC and compatibles					|[8.1](http://www.netbsd.org/releases/formal-8/)
-[[algor]]	|mips		|Algorithmics MIPS evaluation boards					|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[alpha]]	|alpha		|Digital Alpha (64-bit)							|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[amiga]]	|m68k		|Commodore Amiga, MacroSystem DraCo					|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[amigappc]]	|powerpc	|PowerPC-based Amiga boards						|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[arc]]		|mips		|Machines following the Advanced RISC Computing spec			|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[atari]]	|m68k		|Atari TT030, Falcon, Hades						|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[bebox]]	|powerpc	|Be Inc's BeBox								|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[cats]]	|arm		|Chalice Technology's Strong Arm evaluation board			|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[cesfic]]	|m68k		|CES's FIC8234 VME processor board					|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[cobalt]]	|mips		|Cobalt Networks' Microservers						|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[dreamcast]]	|[[sh3]]	|Sega Dreamcast game console						|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[epoc32]]	|arm		|32bit PSION EPOC PDA							|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[emips]]	|mips		|Machines based on "Extensible MIPS"					|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[evbsh3]]	|[[sh3]]	|Evaluation boards with Renesas (Hitachi) Super-H SH3 and SH4 CPUs	|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[ews4800mips]]	|mips		|NEC's MIPS based EWS4800 workstations					|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[hp300]]	|m68k		|Hewlett-Packard 9000/300 and 400 series				|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[hppa]]	|hppa		|Hewlett-Packard 9000/700 series					|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[hpcmips]]	|mips		|MIPS based Windows CE PDA machines					|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[hpcsh]]	|[[sh3]]	|Renesas (Hitachi) SH3 and SH4 based Windows CE PDA machines		|[10.0](http://www.netbsd.org/releases/formal-9/)
+[[acorn32]]	|arm		|Acorn RiscPC/A7000/NC and compatibles					|[8.1](http://www.NetBSD.org/releases/formal-8/)
+[[algor]]	|mips		|Algorithmics MIPS evaluation boards					|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[alpha]]	|alpha		|Digital Alpha (64-bit)							|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[amiga]]	|m68k		|Commodore Amiga, MacroSystem DraCo					|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[amigappc]]	|powerpc	|PowerPC-based Amiga boards						|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[arc]]		|mips		|Machines following the Advanced RISC Computing spec			|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[atari]]	|m68k		|Atari TT030, Falcon, Hades						|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[bebox]]	|powerpc	|Be Inc's BeBox								|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[cats]]	|arm		|Chalice Technology's Strong Arm evaluation board			|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[cesfic]]	|m68k		|CES's FIC8234 VME processor board					|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[cobalt]]	|mips		|Cobalt Networks' Microservers						|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[dreamcast]]	|[[sh3]]	|Sega Dreamcast game console						|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[epoc32]]	|arm		|32bit PSION EPOC PDA							|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[emips]]	|mips		|Machines based on "Extensible MIPS"					|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[evbsh3]]	|[[sh3]]	|Evaluation boards with Renesas (Hitachi) Super-H SH3 and SH4 CPUs	|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[ews4800mips]]	|mips		|NEC's MIPS based EWS4800 workstations					|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[hp300]]	|m68k		|Hewlett-Packard 9000/300 and 400 series				|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[hppa]]	|hppa		|Hewlett-Packard 9000/700 series					|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[hpcmips]]	|mips		|MIPS based Windows CE PDA machines					|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[hpcsh]]	|[[sh3]]	|Renesas (Hitachi) SH3 and SH4 based Windows CE PDA machines		|[10.0](http://www.NetBSD.org/releases/formal-10/)
 [[ia64]]	|itanium	|Itanium family of processors						|none
-[[ibmnws]]	|powerpc	|IBM Network Station Series 1000					|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[iyonix]]	|arm		|Iyonix ARM pc								|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[landisk]]	|[[sh3]]	|SH4 based NAS appliances by I-O DATA					|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[luna68k]]	|m68k		|OMRON Tateisi Electronics' LUNA series					|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[mac68k]]	|m68k		|Apple Macintosh							|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[macppc]]	|powerpc	|Apple Power Macintosh and clones					|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[mipsco]]	|mips		|Mips family of workstations and servers				|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[mmeye]]	|[[sh3]]	|Brains' mmEye Multi Media Server					|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[mvme68k]]	|m68k		|Motorola MVME 68k SBCs							|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[mvmeppc]]	|powerpc	|Motorola MVME PowerPC SBCs						|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[netwinder]]	|arm		|StrongARM based NetWinder machines					|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[news68k]]	|m68k		|Sony's m68k based "NET WORK STATION" series				|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[newsmips]]	|mips		|Sony's MIPS based "NET WORK STATION" series				|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[next68k]]	|m68k		|NeXT 68k 'black' hardware						|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[ofppc]]	|powerpc	|Generic OpenFirmware compliant PowerPC machines			|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[pmax]]	|mips		|Digital MIPS-based DECstations and DECsystems				|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[prep]]	|powerpc	|PReP (PowerPC Reference Platform) and CHRP machines			|[10.0](http://www.netbsd.org/releases/formal-9/)
+[[ibmnws]]	|powerpc	|IBM Network Station Series 1000					|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[iyonix]]	|arm		|Iyonix ARM pc								|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[landisk]]	|[[sh3]]	|SH4 based NAS appliances by I-O DATA					|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[luna68k]]	|m68k		|OMRON Tateisi Electronics' LUNA series					|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[mac68k]]	|m68k		|Apple Macintosh							|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[macppc]]	|powerpc	|Apple Power Macintosh and clones					|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[mipsco]]	|mips		|Mips family of workstations and servers				|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[mmeye]]	|[[sh3]]	|Brains' mmEye Multi Media Server					|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[mvme68k]]	|m68k		|Motorola MVME 68k SBCs							|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[mvmeppc]]	|powerpc	|Motorola MVME PowerPC SBCs						|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[netwinder]]	|arm		|StrongARM based NetWinder machines					|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[news68k]]	|m68k		|Sony's m68k based "NET WORK STATION" series				|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[newsmips]]	|mips		|Sony's MIPS based "NET WORK STATION" series				|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[next68k]]	|m68k		|NeXT 68k 'black' hardware						|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[ofppc]]	|powerpc	|Generic OpenFirmware compliant PowerPC machines			|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[pmax]]	|mips		|Digital MIPS-based DECstations and DECsystems				|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[prep]]	|powerpc	|PReP (PowerPC Reference Platform) and CHRP machines			|[10.0](http://www.NetBSD.org/releases/formal-10/)
 [[riscv]]	|riscv		|RISC-V									|none
-[[rs6000]]	|powerpc	|MCA-based IBM RS/6000 workstations					|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[sandpoint]]	|powerpc	|Motorola Sandpoint reference platform					|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[sbmips]]	|mips		|Broadcom SiByte evaluation boards					|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[sgimips]]	|mips		|Silicon Graphics' MIPS-based workstations				|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[shark]]	|arm		|Digital DNARD ("shark")						|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[sparc]]	|sparc		|Sun SPARC (32-bit)							|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[sun2]]	|m68k		|Sun 2									|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[sun3]]	|m68k		|Sun 3 and 3x								|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[vax]]		|vax		|Digital VAX								|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[x68k]]	|m68k		|Sharp X680x0 series							|[10.0](http://www.netbsd.org/releases/formal-9/)
-[[zaurus]]	|arm		|Sharp C7x0/C860/C1000/C3x00 series PDA					|[10.0](http://www.netbsd.org/releases/formal-9/)
+[[rs6000]]	|powerpc	|MCA-based IBM RS/6000 workstations					|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[sandpoint]]	|powerpc	|Motorola Sandpoint reference platform					|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[sbmips]]	|mips		|Broadcom SiByte evaluation boards					|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[sgimips]]	|mips		|Silicon Graphics' MIPS-based workstations				|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[shark]]	|arm		|Digital DNARD ("shark")						|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[sparc]]	|sparc		|Sun SPARC (32-bit)							|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[sun2]]	|m68k		|Sun 2									|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[sun3]]	|m68k		|Sun 3 and 3x								|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[vax]]		|vax		|Digital VAX								|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[x68k]]	|m68k		|Sharp X680x0 series							|[10.0](http://www.NetBSD.org/releases/formal-10/)
+[[zaurus]]	|arm		|Sharp C7x0/C860/C1000/C3x00 series PDA					|[10.0](http://www.NetBSD.org/releases/formal-10/)
 """]]
 
 

Index: wikisrc/users/wiz/pkgsrc-migration.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/wiz/pkgsrc-migration.mdwn,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- wikisrc/users/wiz/pkgsrc-migration.mdwn	31 May 2024 09:23:37 -0000	1.19
+++ wikisrc/users/wiz/pkgsrc-migration.mdwn	1 Jun 2024 18:02:13 -0000	1.20
@@ -92,7 +92,7 @@
     where they do the `-` version looks better. So clean up the other ones:
 
     `git branch -al | grep _ | grep -v pkg_install-renovation | while read a; do echo git branch -d "$a"; done`
-    - `pkgsrc` is a misbranch of `pkgsrc-2017Q3`, delete it:
+    - `pkgsrc-` is a misbranch of `pkgsrc-2017Q3`, delete it:
 
       `git branch -d pkgsrc`
     - `pkgsrc-pkgsrc-2019Q4` is a misbranch of `pkgsrc-2019Q4`, delete it:

Index: wikisrc/users/wiz/pkgsrc-migration.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/wiz/pkgsrc-migration.mdwn,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- wikisrc/users/wiz/pkgsrc-migration.mdwn	9 May 2024 10:42:55 -0000	1.18
+++ wikisrc/users/wiz/pkgsrc-migration.mdwn	31 May 2024 09:23:37 -0000	1.19
@@ -92,7 +92,7 @@
     where they do the `-` version looks better. So clean up the other ones:
 
     `git branch -al | grep _ | grep -v pkg_install-renovation | while read a; do echo git branch -d "$a"; done`
-    - `pkgsrc-` is a misbranch of `pkgsrc-2017Q3`, delete it:
+    - `pkgsrc` is a misbranch of `pkgsrc-2017Q3`, delete it:
 
       `git branch -d pkgsrc`
     - `pkgsrc-pkgsrc-2019Q4` is a misbranch of `pkgsrc-2019Q4`, delete it:

Index: wikisrc/users/cjep/git4pkgsrc.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/cjep/git4pkgsrc.mdwn,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- wikisrc/users/cjep/git4pkgsrc.mdwn	27 May 2024 08:28:19 -0000	1.12
+++ wikisrc/users/cjep/git4pkgsrc.mdwn	30 May 2024 22:00:25 -0000	1.13
@@ -223,7 +223,7 @@
 The commit hash can be found in the output of ```git commit```:
 
 ```
-$ git commit -m "ix off-by-one security problem in lang/nawk." -a
+$ git commit -m "fix off-by-one security problem in lang/nawk." -a
 [main ba3116fda897] spurious change
 1 file changed, 1 insertion(+)
 ```

Index: wikisrc/users/cjep/git4pkgsrc.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/cjep/git4pkgsrc.mdwn,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- wikisrc/users/cjep/git4pkgsrc.mdwn	26 May 2024 18:06:37 -0000	1.11
+++ wikisrc/users/cjep/git4pkgsrc.mdwn	27 May 2024 08:28:19 -0000	1.12
@@ -42,9 +42,10 @@
 Use ```git clone``` to obtain the source tree via ```git``` as follows:
 
 ```
-git clone nyftp.netbsd.org:/home/git/pkgsrc.git 
+git clone xxxhosttbaxxx.netbsd.org:/home/git/pkgsrc.git 
 ```
 
+
 Set up your user and e-mail address. Please use your pkgsrc.org e-mail address and not your netbsd.org one.
 
 ```

Index: wikisrc/users/cjep/git4pkgsrc.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/cjep/git4pkgsrc.mdwn,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- wikisrc/users/cjep/git4pkgsrc.mdwn	25 May 2024 19:51:21 -0000	1.10
+++ wikisrc/users/cjep/git4pkgsrc.mdwn	26 May 2024 18:06:37 -0000	1.11
@@ -142,7 +142,7 @@
 git config pull.rebase true
 ```
 
-If the local repository and branch contain conflicting changes, you will need to fix the conflicts by hand, re-add the files and commit them to the local repository. For example, here we make a local change that conflicts when we attempt to push our repository. We fetch the changes, resolve the conflicts and push our changes again. The ```rebase``` method requires us to readd the conflicting files and use ```git rebase --continue```. Please see the git-rebase(1) manual page for the detail.
+If the local repository and branch contain conflicting changes, you will need to fix the conflicts by hand, re-add the files and commit them to the local repository. For example, here we make a local change that conflicts when we attempt to push our repository. We fetch the changes, resolve the conflicts and push our changes again. The ```rebase``` method requires us to re-add the conflicting files and use ```git rebase --continue```. Please see the git-rebase(1) manual page for the detail.
 
 ```
 $ git commit -m "mychange" test
@@ -188,8 +188,9 @@
 $ git add patches/p*
 $ cd ..
 # add "SUBDIR+=pkgname" line to the parent Makefile
-$ vi Makefile 
+$ vi Makefile
 $ git commit -m "category/pkgname: add new package" Makefile pkgname
+$ cd pkgname
 $ make CTYPE=Added PKG_DEVELOPER=yes commit-changes-entry
 $ git push
 ```

Index: wikisrc/users/cjep.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/cjep.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/users/cjep.mdwn	25 May 2024 15:32:11 -0000	1.2
+++ wikisrc/users/cjep.mdwn	26 May 2024 09:27:42 -0000	1.3
@@ -3,6 +3,7 @@
 ## Things of potential interest
 
 * Draft [Using Git with the NetBSD Packages Collection](http://wiki.netbsd.org/users/cjep/git4pkgsrc/)
+* [Getting Tezos to work on NetBSD](http://wiki.netbsd.org/users/cjep/tezos-on-netbsd/) (WIP)
 
 * [Transitioning from a.out to ELF on NetBSD](https://chrispinnock.com/2022/08/20/netbsdaout/)
 * [NetBSD/i386 from 1.0 to present](https://chrispinnock.com/2022/09/30/netbsdhist/)
--- /dev/null	2024-05-29 13:24:18.037339641 +0000
+++ wikisrc/users/cjep/hacl-star-raw-patch.txt	2024-05-29 13:35:04.039101151 +0000
@@ -0,0 +1,38 @@
+diff -ur hacl-star-raw-0.7.1/hacl-star-raw/Makefile hacl-star-raw-new/hacl-star-raw/Makefile
+--- hacl-star-raw-0.7.1/hacl-star-raw/Makefile	2023-06-01 13:29:49.000000000 +0000
++++ hacl-star-raw-new/hacl-star-raw/Makefile	2024-01-27 13:32:29.252198742 +0000
+@@ -33,6 +33,10 @@
+   SO 		= so
+   OCAML_SO	= so
+   CFLAGS	+= -fPIC
++else ifeq ($(UNAME),NetBSD)
++  SO 		= so
++  OCAML_SO	= so
++  CFLAGS	+= -fPIC
+ endif
+ 
+ STATIC_C_LIB_NAME=hacl_static
+diff -ur hacl-star-raw-0.7.1/hacl-star-raw.opam hacl-star-raw-new/hacl-star-raw.opam
+--- hacl-star-raw-0.7.1/hacl-star-raw.opam	2023-06-01 13:29:49.000000000 +0000
++++ hacl-star-raw-new/hacl-star-raw.opam	2024-01-27 19:48:16.065305017 +0000
+@@ -26,7 +26,7 @@
+ ]
+ available: [
+   arch != "ppc64" & arch != "ppc32" & arch != "arm32" &
+-  (os = "freebsd" | os-family != "bsd")
++  ( os = "freebsd" | os = "netbsd" | os-family != "bsd")
+ ]
+ build: [
+   [make "-C" "hacl-star-raw" "build-c"]
+diff -ur hacl-star-raw-0.7.1/hacl-star.opam hacl-star-raw-new/hacl-star.opam
+--- hacl-star-raw-0.7.1/hacl-star.opam	2023-06-01 13:29:49.000000000 +0000
++++ hacl-star-raw-new/hacl-star.opam	2024-01-27 19:48:31.031026498 +0000
+@@ -25,7 +25,7 @@
+   "odoc" {with-doc}
+ ]
+ available: [
+-  os = "freebsd" | os-family != "bsd"
++ os = "freebsd" |  os = "netbsd" | os-family != "bsd"
+ ]
+ build: [
+   ["dune" "subst"] {dev}
--- /dev/null	2024-05-29 13:24:18.037339641 +0000
+++ wikisrc/users/cjep/tezos-on-netbsd.mdwn	2024-05-29 13:35:04.070143015 +0000
@@ -0,0 +1,135 @@
+# Tezos on NetBSD
+
+Some notes on getting Octez to compile on NetBSD. Work in progress.
+
+## Problems with possible solutions
+
+1. Opam package doesn't include solver properly.
+
+Three ways:
+
+- Add lib-ext to targets and run before all (which isn't working for me)
+- Is there another way to include the solver at runtime?
+- Builds natively - accept that we have to do this outside of pkgsrc
+
+2. Once Opam is installed, it cannot compile OCaml on arm64 platforms (and
+probably others). Amd64 is fine.
+
+OCaml builds in pkgsrc. Submit our pkgsrc patches back to OCaml team?
+
+```
+# [...]
+# In file included from /usr/include/ctype.h:100,
+#                  from sak.c:29:
+# sak.c: In function 'add_stdlib_prefix':
+# sak.c:126:26: warning: array subscript has type 'char' [-Wchar-subscripts]
+#   126 |       *name = toupper_os(*name);
+#       |                          ^
+# sak.c:126:15: note: in expansion of macro 'toupper_os'
+#   126 |       *name = toupper_os(*name);
+#       |               ^~~~~~~~~~
+# gcc -O2 -fno-strict-aliasing -fwrapv -pthread -Wall -Wdeclaration-after-statement -fno-common -fexcess-precision=standard -g  -Wl,-E  -o sak sak.o
+# gmake[1]: Leaving directory '/disc/tezos/_opam/.opam-switch/build/ocaml-base-compiler.4.14.1/runtime'
+# Makefile:988: *** The native-code compiler is not supported on this platform.  Stop.
+```
+
+3. HACL Star library explicitly excludes NetBSD
+Patch done. FreeBSD settings work. Sent to vdum.
+
+4. GMP fix
+
+Cannot find GMP where it expects.
+
+```
+zen: {343} setenv CFLAGS -I/usr/pkg/include
+zen: {344} opam install conf-gmp --verbose
+zen: {345} eval `opam env`
+```
+
+5. Zarith 1.12
+
+Zarith hackery 1.13 works out of the box. We seem to require 1.12?
+
+```
+cd ../
+mkdir zarith-1.12
+ftp -a https://github.com/ocaml/Zarith/archive/release-1.13.tar.gz
+cd zarith-1.12/
+tar zxvf ../release-1.13.tar.gz
+zen: {363} cd ../../tezos/
+zen: {364} pwd
+/home/cjep/src/tezos
+zen: {365} opam install ../zarith-1.12/Zarith-release-1.13
+```
+
+mirage-crypto-rng
+	__FreeBSD__ definition line in sources - needs __NetBSD__ too!
+	Add -D__FreeBSD__ as a workaround
+
+pringo.1.3
+	popcount function conflicts with native one
+	I worked around by renaming it - what is the best way normally?
+
+pyml
+	pyml_arch.ml.c checks for unix. We have __unix__
+	Pull request submitted to pyml
+	https://github.com/thierry-martinez/pyml/pull/99
+
+parsexp
+	SEG FAULT
+
+tezos-rust-libs.1.6
+
+1.	disc space error in /tmp.
+	/tmp needs at least 906M free
+	drwxrwxrwt   6 root  wheel        384 Jan 27 15:32 tmp
+
+2. error[E0412]: cannot find type `QueryIter` in module `os`
+ --> /home/cjep/src/tezos/_opam/.opam-switch/build/tezos-rust-libs.1.6/vendor/region/src/qu
+ery.rs:7:24
+  |
+7 |   iterator: Option<os::QueryIter>,
+  |                        ^^^^^^^^^ not found in `os`
+  |
+help: consider importing this struct
+
+Repeatedly wanting to install autoconf. Has to be a path issue
+
+## Process
+
+I will update this as I go.
+
+0. Make sure /tmp has at least 1G available otherwise tezos-rust-libs
+cannot start to compile. On older machines /tmp is often in RAM to speed up.
+
+1. Install prerequisites
+pkgin install gmake ocaml-opam jq git libev libhidapi autoconf
+
+2. Get Rust
+
+3. Get the Tezos sources
+
+setenv C_INCLUDE_PATH /usr/pkg/include:/usr/pkg/include/ev
+setenv LIBRARY_PATH /usr/pkg/lib:/usr/pkg/lib/ev
+#setenv CFLAGS "-I/usr/pkg/include -D__FreeBSD__ -fPIC"
+setenv CFLAGS -I/usr/pkg/include 
+
+4. init --bare
+gmake build-deps
+
+Fix ups:
+opam install ../fixed up
+- hacl-star-raw needs the patch
+- pringo function fix
+- pyml
+- mirage-crypto-rng -D__FreeBSD__
+- zarith (install 13 instead of 12)
+
+gmake build-deps
+
+- class_group_vdf ** Cannot find gmpxx.h library **
+- p
+- tezos-rust-lib
+
+
+

Index: wikisrc/users/cjep/git4pkgsrc.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/cjep/git4pkgsrc.mdwn,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- wikisrc/users/cjep/git4pkgsrc.mdwn	25 May 2024 16:54:49 -0000	1.9
+++ wikisrc/users/cjep/git4pkgsrc.mdwn	25 May 2024 19:51:21 -0000	1.10
@@ -16,7 +16,7 @@
 
 # Initial Setup
 
-Install ```pkgsrc/devel/git-base``` for a minimal installation of ```git```. To do this from source, you will need to [download pkgsrc first](http://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc.tar.xz). For non-NetBSD platforms you will beed to bootstrap - please see [the documentation](http://www.pkgsrc.org/#index1h1) for more details
+Install ```pkgsrc/devel/git-base``` for a minimal installation of ```git```. To do this from source, you will need to [download pkgsrc first](http://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc.tar.xz). For non-NetBSD platforms you will need to bootstrap - please see [the documentation](http://www.pkgsrc.org/#index1h1) for more details
 
 ```
 # From pkgsrc

Index: wikisrc/donations.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/donations.mdwn,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- wikisrc/donations.mdwn	18 Jan 2023 21:02:24 -0000	1.5
+++ wikisrc/donations.mdwn	25 May 2024 17:06:19 -0000	1.6
@@ -20,5 +20,4 @@
 
 Equipment | Location | Shipping | Contact
 ----------|----------|----------|--------
-Mac PowerPC G5 | London, UK | Can be delivered within the UK; possibly to continental Europe | Chris Pinnock (<[email protected]>)
-
+| | |

Index: wikisrc/users/cjep/git4pkgsrc.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/cjep/git4pkgsrc.mdwn,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- wikisrc/users/cjep/git4pkgsrc.mdwn	25 May 2024 14:33:58 -0000	1.8
+++ wikisrc/users/cjep/git4pkgsrc.mdwn	25 May 2024 16:54:49 -0000	1.9
@@ -142,7 +142,7 @@
 git config pull.rebase true
 ```
 
-If the local repository and branch contain conflicting changes, you will need to fix the conflicts by hand, readd the files and commit them to the local repository. For example, here we make a local change that conflicts when we attempt to push our repository. We fetch the changes, resolve the conflicts and push our changes again. The ```rebase``` method requires us to readd the conflicting files and use ```git rebase --continue```. Please see the git-rebase(1) manual page for the detail.
+If the local repository and branch contain conflicting changes, you will need to fix the conflicts by hand, re-add the files and commit them to the local repository. For example, here we make a local change that conflicts when we attempt to push our repository. We fetch the changes, resolve the conflicts and push our changes again. The ```rebase``` method requires us to readd the conflicting files and use ```git rebase --continue```. Please see the git-rebase(1) manual page for the detail.
 
 ```
 $ git commit -m "mychange" test

Index: wikisrc/users/cjep.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/cjep.mdwn,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- wikisrc/users/cjep.mdwn	25 May 2024 11:53:39 -0000	1.1
+++ wikisrc/users/cjep.mdwn	25 May 2024 15:32:11 -0000	1.2
@@ -2,6 +2,8 @@
 
 ## Things of potential interest
 
+* Draft [Using Git with the NetBSD Packages Collection](http://wiki.netbsd.org/users/cjep/git4pkgsrc/)
+
 * [Transitioning from a.out to ELF on NetBSD](https://chrispinnock.com/2022/08/20/netbsdaout/)
 * [NetBSD/i386 from 1.0 to present](https://chrispinnock.com/2022/09/30/netbsdhist/)
 * [Forking NetBSD](https://chrispinnock.com/2022/10/07/forkingnetbsd/)

Index: wikisrc/users/cjep/git4pkgsrc.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/cjep/git4pkgsrc.mdwn,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- wikisrc/users/cjep/git4pkgsrc.mdwn	25 May 2024 12:54:22 -0000	1.7
+++ wikisrc/users/cjep/git4pkgsrc.mdwn	25 May 2024 14:33:58 -0000	1.8
@@ -10,41 +10,7 @@
 
 A key difference between Git and CVS is that your machine maintains a full local copy of the source code repository. Changes are maintained locally and are *pushed* back to the remote repository. Changes from the remote repository can be *pulled* and merged with your local copy.
 
-<!-- XXX does not work on our wiki
-<svg width="1000" height="100" xmlns="http://www.w3.org/2000/svg">
-      <defs>
-        <marker id='head' orient='auto' markerWidth='2' markerHeight='4' refX='0.1' refY='2'>
-          <path d='M0,0 V4 L2,2 Z' fill='black' />
-        </marker>
-      </defs>
-      <g>
-        <rect x="0" y="0" width="180" height="100" fill="white" style="stroke-width:3;stroke:rgb(0,0,0)"></rect>
-        <text x="10" y="55" font-family="Verdana" font-size="24" fill="black" lengthAdjust="spacingAndGlyphs">Working tree</text>
-      </g>
-      <g>
-        <text x="200" y="15" font-family="Verdana" font-size="16" fill="black">commit</text>
-<path marker-end='url(#head)' stroke-width='3' fill='none' stroke='black'  d='M180,25 290,25' />
-        <path marker-end='url(#head)' stroke-width='3' fill='none' stroke='black'  d='M300,75 190,75' />
-        <text x="200" y="92" font-family="Verdana" font-size="16" fill="black">update</text>
-      </g>
-      <g>
-        <rect x="300" y="0" width="220" height="100" fill="white" style="stroke-width:3;stroke:rgb(0,0,0)"></rect>
-        <text x="310" y="55" font-family="Verdana" font-size="24" fill="black">Local repository</text>
-      </g>
-      <g>
-        <text x="570" y="15" font-family="Verdana" font-size="16" fill="black">push</text>
-        <path marker-end='url(#head)' stroke-width='3' fill='none' stroke='black'  d='M520,25 640,25' />
-        <path marker-end='url(#head)' stroke-width='3' fill='none' stroke='black'  d='M650,75 530,75' />
-        <text x="570" y="92" font-family="Verdana" font-size="16" fill="black">pull</text>
-      </g>
-      <g>
-        <rect x="650" y="0" width="240" height="100" fill="white" style="stroke-width:3;stroke:rgb(0,0,0)"></rect>
-        <text x="660" y="55" font-family="Verdana" font-size="24" fill="black">Remote repository</text>
-      </g>
-    </svg>
-
-  </para>
--->
+[[!img repositories.svg size=490x align=right]]
 
 Initially the repository will be accessible via SSH by NetBSD developers only. To submit patches please see [below](#index10h1).
 
--- /dev/null	2024-05-29 13:24:18.037339641 +0000
+++ wikisrc/users/cjep/repositories.svg	2024-05-29 13:35:05.499126543 +0000
@@ -0,0 +1,32 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<svg width="1000" height="100" xmlns="http://www.w3.org/2000/svg">
+      <defs>
+        <marker id='head' orient='auto' markerWidth='2' markerHeight='4' refX='0.1' refY='2'>
+          <path d='M0,0 V4 L2,2 Z' fill='black' />
+        </marker>
+      </defs>
+      <g>
+        <rect x="0" y="0" width="180" height="100" fill="white" style="stroke-width:3;stroke:rgb(0,0,0)"></rect>
+        <text x="10" y="55" font-family="Verdana" font-size="24" fill="black" lengthAdjust="spacingAndGlyphs">Working tree</text>
+      </g>
+      <g>
+        <text x="200" y="15" font-family="Verdana" font-size="16" fill="black">commit</text>
+<path marker-end='url(#head)' stroke-width='3' fill='none' stroke='black'  d='M180,25 290,25' />
+        <path marker-end='url(#head)' stroke-width='3' fill='none' stroke='black'  d='M300,75 190,75' />
+        <text x="200" y="92" font-family="Verdana" font-size="16" fill="black">update</text>
+      </g>
+      <g>
+        <rect x="300" y="0" width="220" height="100" fill="white" style="stroke-width:3;stroke:rgb(0,0,0)"></rect>
+        <text x="310" y="55" font-family="Verdana" font-size="24" fill="black">Local repository</text>
+      </g>
+      <g>
+        <text x="570" y="15" font-family="Verdana" font-size="16" fill="black">push</text>
+        <path marker-end='url(#head)' stroke-width='3' fill='none' stroke='black'  d='M520,25 640,25' />
+        <path marker-end='url(#head)' stroke-width='3' fill='none' stroke='black'  d='M650,75 530,75' />
+        <text x="570" y="92" font-family="Verdana" font-size="16" fill="black">pull</text>
+      </g>
+      <g>
+        <rect x="650" y="0" width="240" height="100" fill="white" style="stroke-width:3;stroke:rgb(0,0,0)"></rect>
+        <text x="660" y="55" font-family="Verdana" font-size="24" fill="black">Remote repository</text>
+      </g>
+    </svg>

Index: wikisrc/users/cjep/git4pkgsrc.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/cjep/git4pkgsrc.mdwn,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- wikisrc/users/cjep/git4pkgsrc.mdwn	25 May 2024 12:24:44 -0000	1.6
+++ wikisrc/users/cjep/git4pkgsrc.mdwn	25 May 2024 12:54:22 -0000	1.7
@@ -46,7 +46,7 @@
   </para>
 -->
 
-Initially the repository will be accessible via SSH by NetBSD developers only. To submit patches please see [below](#submitting-patches). 
+Initially the repository will be accessible via SSH by NetBSD developers only. To submit patches please see [below](#index10h1).
 
 # Initial Setup
 
@@ -87,7 +87,7 @@
 git config --local user.email "[email protected]"
 ```
 
-We only allow "rebasing" (see [Syncing with the remote repository](#syncing-with-the-remote-repository) below). Please set this in your local configuration:
+We only allow "rebasing" (see [Syncing with the remote repository](#index5h1) below). Please set this in your local configuration:
 
 ```
 git config pull.rebase true

Index: wikisrc/users/cjep/git4pkgsrc.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/cjep/git4pkgsrc.mdwn,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- wikisrc/users/cjep/git4pkgsrc.mdwn	25 May 2024 12:21:34 -0000	1.5
+++ wikisrc/users/cjep/git4pkgsrc.mdwn	25 May 2024 12:24:44 -0000	1.6
@@ -1,11 +1,10 @@
-
-# Using Git with the NetBSD Packages Collection
+[[!meta title="Using Git with the NetBSD Packages Collection"]]
 
 *This document is a proposed draft. Please feel free to send comments to cjep@*.
 
 [[!toc ]]
 
-## Background
+# Background
 
 In April 2024, the [NetBSD Packages Collection](https://pkgsrc.org) management team (pkgsrc-pmc) decided to migrate from [CVS](https://www.nongnu.org/cvs/) to [Git](https://git-scm.com/) for managing the source code of the NetBSD Packages Collection. This document covers the basic commands to manipulate the sources using Git.
 
@@ -49,7 +48,7 @@
 
 Initially the repository will be accessible via SSH by NetBSD developers only. To submit patches please see [below](#submitting-patches). 
 
-## Initial Setup
+# Initial Setup
 
 Install ```pkgsrc/devel/git-base``` for a minimal installation of ```git```. To do this from source, you will need to [download pkgsrc first](http://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc.tar.xz). For non-NetBSD platforms you will beed to bootstrap - please see [the documentation](http://www.pkgsrc.org/#index1h1) for more details
 
@@ -94,7 +93,7 @@
 git config pull.rebase true
 ```
 
-## Basic usage
+# Basic usage
 
 To add, remove or move files:
 
@@ -111,7 +110,7 @@
 git status
 ```
 
-## Committing changes
+# Committing changes
 
 New files need to be added with ```git add```. 
 
@@ -144,7 +143,7 @@
 git commit -m "Make lots of cool changes at once" file1 file2 file3 dir1
 ```
 
-## Syncing with the remote repository
+# Syncing with the remote repository
 
 You can synchronise your current branch from the remote repository with ```git pull```.  To synchronise your local repository fully with the remote repository use ```git fetch```. 
 You can submit your local changes to the remote repository with ```git push```.
@@ -208,7 +207,7 @@
 $ git push
 ```
 
-## Adding a new package
+# Adding a new package
 
 To add a new package, ensure that your tree is up to date. The process
 is similar to the one using CVS.
@@ -229,11 +228,11 @@
 $ git push
 ```
 
-## Branches
+# Branches
 
 Any changes you make with git are done to the current branch in your local copy of the repository. The *main* branch is essentially the trunk of the repository. Although you can make local branches, you will not be able to push them to the remote repository. We will only use branches to maintain quarterly releases. Pkgsrc developers should continue to commit to *main* in the same way they have been committing to *head* with CVS.
 
-## Quarterly Releases
+# Quarterly Releases
 
 The NetBSD Packages Collection has [quarterly stable releases](http://www.pkgsrc.org/quarterly/). The release comprises of a branch so that a consistent set of packages can be built and managed. The naming convention of the branch is ```pkgsrc-YYYYQN``` where *YYYY* is the year and *N* is the quarter number.
 
@@ -246,7 +245,7 @@
 
 Never commit directly onto a release branch. Always commit onto *main*. If you need a change in a release branch please refer to the next section.
 
-## Submitting a pull-up request to a release branch
+# Submitting a pull-up request to a release branch
 
 Please refer to the [developer's pull-up guide](https://www.netbsd.org/developers/releng/pullups.html). Pull-ups for pkgsrc should be sent to the ```pullup-pkgsrc``` e-mail group. You can send a pull-up request either by:
 
@@ -298,7 +297,7 @@
 $ git push
 ```
 
-## Submitting patches
+# Submitting patches
 
 We are in the early stages of our migration to Git. We expect to offer public pullup requests at some point in the future. But for now, if you do not have access to the NetBSD Packages Collection source tree directly, you can still submit patches. For example:
 

Index: wikisrc/users/cjep/git4pkgsrc.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/cjep/git4pkgsrc.mdwn,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- wikisrc/users/cjep/git4pkgsrc.mdwn	25 May 2024 12:18:44 -0000	1.4
+++ wikisrc/users/cjep/git4pkgsrc.mdwn	25 May 2024 12:21:34 -0000	1.5
@@ -1,6 +1,10 @@
 
 # Using Git with the NetBSD Packages Collection
 
+*This document is a proposed draft. Please feel free to send comments to cjep@*.
+
+[[!toc ]]
+
 ## Background
 
 In April 2024, the [NetBSD Packages Collection](https://pkgsrc.org) management team (pkgsrc-pmc) decided to migrate from [CVS](https://www.nongnu.org/cvs/) to [Git](https://git-scm.com/) for managing the source code of the NetBSD Packages Collection. This document covers the basic commands to manipulate the sources using Git.

Index: wikisrc/users/cjep/git4pkgsrc.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/cjep/git4pkgsrc.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/users/cjep/git4pkgsrc.mdwn	25 May 2024 12:11:18 -0000	1.3
+++ wikisrc/users/cjep/git4pkgsrc.mdwn	25 May 2024 12:18:44 -0000	1.4
@@ -7,6 +7,7 @@
 
 A key difference between Git and CVS is that your machine maintains a full local copy of the source code repository. Changes are maintained locally and are *pushed* back to the remote repository. Changes from the remote repository can be *pulled* and merged with your local copy.
 
+<!-- XXX does not work on our wiki
 <svg width="1000" height="100" xmlns="http://www.w3.org/2000/svg">
       <defs>
         <marker id='head' orient='auto' markerWidth='2' markerHeight='4' refX='0.1' refY='2'>
@@ -40,12 +41,13 @@
     </svg>
 
   </para>
+-->
 
-Initially the repository will be accessible via SSH by NetBSD developers only. To submit patches please see [below](#submitpatches). 
+Initially the repository will be accessible via SSH by NetBSD developers only. To submit patches please see [below](#submitting-patches). 
 
 ## Initial Setup
 
-Install ```pkgsrc/devel/git-base``` for a minimal installation of ```git```. To do this from source, you will need to [download pkgsrc first]](http://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc.tar.xz). For non-NetBSD platforms you will beed to bootstrap - please see [the documentation](http://www.pkgsrc.org/#index1h1) for more details
+Install ```pkgsrc/devel/git-base``` for a minimal installation of ```git```. To do this from source, you will need to [download pkgsrc first](http://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc.tar.xz). For non-NetBSD platforms you will beed to bootstrap - please see [the documentation](http://www.pkgsrc.org/#index1h1) for more details
 
 ```
 # From pkgsrc
@@ -82,7 +84,7 @@
 git config --local user.email "[email protected]"
 ```
 
-Also we will only be allowing "rebasing" (see Syncing with the remote repository below). Please set this in your local configuration:
+We only allow "rebasing" (see [Syncing with the remote repository](#syncing-with-the-remote-repository) below). Please set this in your local configuration:
 
 ```
 git config pull.rebase true
@@ -204,6 +206,9 @@
 
 ## Adding a new package
 
+To add a new package, ensure that your tree is up to date. The process
+is similar to the one using CVS.
+
 ```
 $ git pull
 $ cd .../pkgsrc/category
@@ -290,7 +295,6 @@
 ```
 
 ## Submitting patches
-{#submitpatches}
 
 We are in the early stages of our migration to Git. We expect to offer public pullup requests at some point in the future. But for now, if you do not have access to the NetBSD Packages Collection source tree directly, you can still submit patches. For example:
 

Index: wikisrc/users/cjep/git4pkgsrc.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/cjep/git4pkgsrc.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/users/cjep/git4pkgsrc.mdwn	25 May 2024 12:06:33 -0000	1.2
+++ wikisrc/users/cjep/git4pkgsrc.mdwn	25 May 2024 12:11:18 -0000	1.3
@@ -41,7 +41,7 @@
 
   </para>
 
-Initially the repository will be accessible via SSH by NetBSD developers only. To submit patches please see XXX insert web link later XXX:
+Initially the repository will be accessible via SSH by NetBSD developers only. To submit patches please see [below](#submitpatches). 
 
 ## Initial Setup
 
@@ -71,7 +71,7 @@
 Use ```git clone``` to obtain the source tree via ```git``` as follows:
 
 ```
-git clone nyftp.netbsd.org:/home/git/pkgsrc.git # XXX Change link XXX
+git clone nyftp.netbsd.org:/home/git/pkgsrc.git 
 ```
 
 Set up your user and e-mail address. Please use your pkgsrc.org e-mail address and not your netbsd.org one.
@@ -290,6 +290,7 @@
 ```
 
 ## Submitting patches
+{#submitpatches}
 
 We are in the early stages of our migration to Git. We expect to offer public pullup requests at some point in the future. But for now, if you do not have access to the NetBSD Packages Collection source tree directly, you can still submit patches. For example:
 

Index: wikisrc/users/cjep/git4pkgsrc.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/cjep/git4pkgsrc.mdwn,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- wikisrc/users/cjep/git4pkgsrc.mdwn	25 May 2024 11:56:58 -0000	1.1
+++ wikisrc/users/cjep/git4pkgsrc.mdwn	25 May 2024 12:06:33 -0000	1.2
@@ -107,25 +107,15 @@
 
 ## Committing changes
 
-```git commit``` on its own will tell you which files have been modified and which files are not yet part of the repository:
+New files need to be added with ```git add```. 
 
 ```
-$ git commit
-On branch main
-Your branch is ahead of 'origin/main' by 1 commit.
-  (use "git push" to publish your local commits)
-
-Changes not staged for commit:
-  (use "git add <file>..." to update what will be committed)
-  (use "git restore <file>..." to discard changes in working directory)
-	modified:   README.md
-
-Untracked files:
-  (use "git add <file>..." to include in what will be committed)
-	newfile
+git add newfile
+# next commit will automatically include newfile
+git commit
 ```
 
-New files need to be added with ```git add```. You can either add existing files with ```git add``` to stage them for the commit or specify them on the command line:
+You can either stage existing files with ```git add``` for your next commit or specify them on the command line:
 
 ```
 git add README.md
@@ -141,17 +131,19 @@
 git commit -m "Make cool changes to the documentation" README.md
 ```
 
-You can stage and commit all changes with ```-a```:
+You can stage and commit all changes with ```-a``` but the preferred method
+is to specify the filenames explicitly.
 
 ```
-git commit -m "Make lots of cool changes at once" -a
+git commit -m "Make lots of cool changes at once" file1 file2 file3 dir1
 ```
 
 ## Syncing with the remote repository
 
-You can synchronise your current branch from the remote repository with ```git pull```.
+You can synchronise your current branch from the remote repository with ```git pull```.  To synchronise your local repository fully with the remote repository use ```git fetch```. 
 You can submit your local changes to the remote repository with ```git push```.
-To synchronise your local repository fully with the remote repository use ```git fetch```. 
+
+Before you use ```git push```, you can examine the change that will be pushed with ```git log -p upstream/main```.
 
 When you ```git pull```, you may have to resolve conflicts between the remote changes and your local changes before continuing. Additionally when you ```git push```, the remote repository may have changes that you do not have. You will need to ```git pull``` first.
 
@@ -220,11 +212,10 @@
 # setup DESCR, Makefile, PLIST, distinfo, etc and add them
 $ git add DESCR Makefile PLIST distinfo buildlink3.mk
 $ git add patches/p*
-$ git commit -m "Adding new package pkgname" .
 $ cd ..
 # add "SUBDIR+=pkgname" line to the parent Makefile
 $ vi Makefile 
-$ git commit -m "Adding new package pkgname" Makefile
+$ git commit -m "category/pkgname: add new package" Makefile pkgname
 $ make CTYPE=Added PKG_DEVELOPER=yes commit-changes-entry
 $ git push
 ```
@@ -250,14 +241,14 @@
 
 Please refer to the [developer's pull-up guide](https://www.netbsd.org/developers/releng/pullups.html). Pull-ups for pkgsrc should be sent to the ```pullup-pkgsrc``` e-mail group. You can send a pull-up request either by:
 
-- Sending a commit hase to ```git cherry-pick```
+- Sending a commit hash to ```git cherry-pick```
 - Sending a unified diff file if a more complicated patch is required.
 
 The commit hash can be found in the output of ```git commit```:
 
 ```
 $ git commit -m "ix off-by-one security problem in lang/nawk." -a
-[main ba3116fda897] spurois change
+[main ba3116fda897] spurious change
 1 file changed, 1 insertion(+)
 ```
 

--- /dev/null	2024-05-29 13:24:18.037339641 +0000
+++ wikisrc/users/cjep/git4pkgsrc.mdwn	2024-05-29 13:35:07.534970073 +0000
@@ -0,0 +1,313 @@
+
+# Using Git with the NetBSD Packages Collection
+
+## Background
+
+In April 2024, the [NetBSD Packages Collection](https://pkgsrc.org) management team (pkgsrc-pmc) decided to migrate from [CVS](https://www.nongnu.org/cvs/) to [Git](https://git-scm.com/) for managing the source code of the NetBSD Packages Collection. This document covers the basic commands to manipulate the sources using Git.
+
+A key difference between Git and CVS is that your machine maintains a full local copy of the source code repository. Changes are maintained locally and are *pushed* back to the remote repository. Changes from the remote repository can be *pulled* and merged with your local copy.
+
+<svg width="1000" height="100" xmlns="http://www.w3.org/2000/svg">
+      <defs>
+        <marker id='head' orient='auto' markerWidth='2' markerHeight='4' refX='0.1' refY='2'>
+          <path d='M0,0 V4 L2,2 Z' fill='black' />
+        </marker>
+      </defs>
+      <g>
+        <rect x="0" y="0" width="180" height="100" fill="white" style="stroke-width:3;stroke:rgb(0,0,0)"></rect>
+        <text x="10" y="55" font-family="Verdana" font-size="24" fill="black" lengthAdjust="spacingAndGlyphs">Working tree</text>
+      </g>
+      <g>
+        <text x="200" y="15" font-family="Verdana" font-size="16" fill="black">commit</text>
+<path marker-end='url(#head)' stroke-width='3' fill='none' stroke='black'  d='M180,25 290,25' />
+        <path marker-end='url(#head)' stroke-width='3' fill='none' stroke='black'  d='M300,75 190,75' />
+        <text x="200" y="92" font-family="Verdana" font-size="16" fill="black">update</text>
+      </g>
+      <g>
+        <rect x="300" y="0" width="220" height="100" fill="white" style="stroke-width:3;stroke:rgb(0,0,0)"></rect>
+        <text x="310" y="55" font-family="Verdana" font-size="24" fill="black">Local repository</text>
+      </g>
+      <g>
+        <text x="570" y="15" font-family="Verdana" font-size="16" fill="black">push</text>
+        <path marker-end='url(#head)' stroke-width='3' fill='none' stroke='black'  d='M520,25 640,25' />
+        <path marker-end='url(#head)' stroke-width='3' fill='none' stroke='black'  d='M650,75 530,75' />
+        <text x="570" y="92" font-family="Verdana" font-size="16" fill="black">pull</text>
+      </g>
+      <g>
+        <rect x="650" y="0" width="240" height="100" fill="white" style="stroke-width:3;stroke:rgb(0,0,0)"></rect>
+        <text x="660" y="55" font-family="Verdana" font-size="24" fill="black">Remote repository</text>
+      </g>
+    </svg>
+
+  </para>
+
+Initially the repository will be accessible via SSH by NetBSD developers only. To submit patches please see XXX insert web link later XXX:
+
+## Initial Setup
+
+Install ```pkgsrc/devel/git-base``` for a minimal installation of ```git```. To do this from source, you will need to [download pkgsrc first]](http://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc.tar.xz). For non-NetBSD platforms you will beed to bootstrap - please see [the documentation](http://www.pkgsrc.org/#index1h1) for more details
+
+```
+# From pkgsrc
+cd pkgsrc/devel/git-base
+make install
+
+# From pkgsrc on non-NetBSD platforms
+cd pkgsrc/devel/git-base
+bmake install
+
+# Or pkgin
+pkgin install git-base
+```
+
+Alternatively use ```pkgsrc/devel/git``` for ```git```, it's documentation and other contributed tools.
+
+Move your existing ```pkgsrc``` directory out of the way. 
+
+```
+mv pkgsrc pkgsrc.old
+```
+
+Use ```git clone``` to obtain the source tree via ```git``` as follows:
+
+```
+git clone nyftp.netbsd.org:/home/git/pkgsrc.git # XXX Change link XXX
+```
+
+Set up your user and e-mail address. Please use your pkgsrc.org e-mail address and not your netbsd.org one.
+
+```
+cd pkgsrc
+git config --local user.name "My Name"
+git config --local user.email "[email protected]"
+```
+
+Also we will only be allowing "rebasing" (see Syncing with the remote repository below). Please set this in your local configuration:
+
+```
+git config pull.rebase true
+```
+
+## Basic usage
+
+To add, remove or move files:
+
+```
+git add new-file.c
+git rm old-file.c
+git mv old-file.c new-file.c
+```
+
+To inspect the state of your tree or examine changes since the last commit:
+
+```
+git diff
+git status
+```
+
+## Committing changes
+
+```git commit``` on its own will tell you which files have been modified and which files are not yet part of the repository:
+
+```
+$ git commit
+On branch main
+Your branch is ahead of 'origin/main' by 1 commit.
+  (use "git push" to publish your local commits)
+
+Changes not staged for commit:
+  (use "git add <file>..." to update what will be committed)
+  (use "git restore <file>..." to discard changes in working directory)
+	modified:   README.md
+
+Untracked files:
+  (use "git add <file>..." to include in what will be committed)
+	newfile
+```
+
+New files need to be added with ```git add```. You can either add existing files with ```git add``` to stage them for the commit or specify them on the command line:
+
+```
+git add README.md
+git commit
+
+# or
+git commit README.md
+```
+
+```git``` will open your file editor to edit the commit message. However it can be specified directly on the command line:
+
+```
+git commit -m "Make cool changes to the documentation" README.md
+```
+
+You can stage and commit all changes with ```-a```:
+
+```
+git commit -m "Make lots of cool changes at once" -a
+```
+
+## Syncing with the remote repository
+
+You can synchronise your current branch from the remote repository with ```git pull```.
+You can submit your local changes to the remote repository with ```git push```.
+To synchronise your local repository fully with the remote repository use ```git fetch```. 
+
+When you ```git pull```, you may have to resolve conflicts between the remote changes and your local changes before continuing. Additionally when you ```git push```, the remote repository may have changes that you do not have. You will need to ```git pull``` first.
+
+Git will attempt to include the changes from the remote repository. You may receive this error message the first time you use ```git pull``` if you have not set up git already:
+
+
+```
+warning: Pulling without specifying how to reconcile divergent branches is
+discouraged. You can squelch this message by running one of the following
+commands sometime before your next pull:
+
+  git config pull.rebase false  # merge (the default strategy)
+  git config pull.rebase true   # rebase
+  git config pull.ff only       # fast-forward only
+
+You can replace "git config" with "git config --global" to set a default
+preference for all repositories. You can also pass --rebase, --no-rebase,
+or --ff-only on the command line to override the configured default per
+invocation.
+```
+
+The ```rebase``` and ```merge``` methods are ways of integrating changes from divergent branches. Please see the git-merge(1) and git-rebase(1) manual pages for more details. The "Fast-Forward only" method is useful if you are just following the remote repository but are not making local changes. We use (and enforce) the ```rebase``` method for the NetBSD Packages Collection. You can set this as follows:
+
+```
+git config pull.rebase true
+```
+
+If the local repository and branch contain conflicting changes, you will need to fix the conflicts by hand, readd the files and commit them to the local repository. For example, here we make a local change that conflicts when we attempt to push our repository. We fetch the changes, resolve the conflicts and push our changes again. The ```rebase``` method requires us to readd the conflicting files and use ```git rebase --continue```. Please see the git-rebase(1) manual page for the detail.
+
+```
+$ git commit -m "mychange" test
+[master a013462] mychange
+ 1 file changed, 1 insertion(+)
+$ git push
+...
+error: failed to push some refs to 'githut.co.uk:randomrepo/repo.git'
+hint: Updates were rejected because the remote contains work that you do
+hint: not have locally. This is usually caused by another repository pushing
+hint: to the same ref. You may want to first integrate the remote changes
+hint: (e.g., 'git pull ...') before pushing again.
+hint: See the 'Note about fast-forwards' in 'git push --help' for details.
+$ git pull
+

(Diff truncated)

--- /dev/null	2024-05-29 13:24:18.037339641 +0000
+++ wikisrc/users/cjep.mdwn	2024-05-29 13:35:07.820008631 +0000
@@ -0,0 +1,7 @@
+# Wiki page for Chris Pinnock (cjep)
+
+## Things of potential interest
+
+* [Transitioning from a.out to ELF on NetBSD](https://chrispinnock.com/2022/08/20/netbsdaout/)
+* [NetBSD/i386 from 1.0 to present](https://chrispinnock.com/2022/09/30/netbsdhist/)
+* [Forking NetBSD](https://chrispinnock.com/2022/10/07/forkingnetbsd/)

Index: wikisrc/ports/evbmips/images/edgerouter4.jpg
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbmips/images/edgerouter4.jpg,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
Binary files /tmp/cvsSZi1qq and /tmp/cvstJBNL2 differ

Index: wikisrc/ports/evbppc.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbppc.mdwn,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- wikisrc/ports/evbppc.mdwn	30 Mar 2024 19:27:00 -0000	1.29
+++ wikisrc/ports/evbppc.mdwn	22 May 2024 09:23:45 -0000	1.30
@@ -8,10 +8,13 @@
 changes_future="11.0"
 thumbnail="//www.netbsd.org/images/ports/evbppc/405gp.gif"
 about="""
-NetBSD/evbppc is intended to be a port of NetBSD to various PowerPC-based
-evaluation boards and appliances.
+NetBSD/evbppc is a port of NetBSD to various PowerPC-based evaluation
+boards and appliances.
 """
 supported_hardware="""
+
+### Nintendo Wii
+
 ### Artesyn's PM/PPC board
 
 The following devices are supported:

Index: wikisrc/ports/evbmips.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbmips.mdwn,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -r1.30 -r1.31
--- wikisrc/ports/evbmips.mdwn	22 May 2024 09:20:19 -0000	1.30
+++ wikisrc/ports/evbmips.mdwn	22 May 2024 09:21:34 -0000	1.31
@@ -10,7 +10,7 @@
 future_rel="11.0"
 changes_cur="10.0"
 changes_future="11.0"
-thumbnail="//wiki.netbsd.org/ports/evbarm/images/edgerouter4.jpg"
+thumbnail="//wiki.netbsd.org/ports/evbmips/images/edgerouter4.jpg"
 about="""
 NetBSD/evbmips is a port of NetBSD to various MIPS-based evaluation
 boards and SoCs.

Index: wikisrc/ports/evbmips.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbmips.mdwn,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- wikisrc/ports/evbmips.mdwn	30 Mar 2024 19:27:00 -0000	1.29
+++ wikisrc/ports/evbmips.mdwn	22 May 2024 09:20:19 -0000	1.30
@@ -10,10 +10,10 @@
 future_rel="11.0"
 changes_cur="10.0"
 changes_future="11.0"
-thumbnail="//www.netbsd.org/images/ports/evbmips/malta.gif"
+thumbnail="//wiki.netbsd.org/ports/evbarm/images/edgerouter4.jpg"
 about="""
-NetBSD/evbmips is intended to be a port of NetBSD to various MIPS-based
-evaluation boards.
+NetBSD/evbmips is a port of NetBSD to various MIPS-based evaluation
+boards and SoCs.
 """
 supported_hardware="""
  * [MIPS Malta evaluation board](http://www.mips.com/products/development-kits/malta/) with either the [4Kc](http://www.mips.com/ProductCatalog/P_MIPS324KFamily/productBrief) (MIPS32) or [5Kc](http://www.mips.com/ProductCatalog/P_MIPS645KFamily/productBrief) (MIPS64) CPU board (running in 32-bit mode only).
@@ -24,6 +24,11 @@
  * Plat'Home OpenMicroServer (OMSAL-400)
  * [[Loongson|loongson]] MIPS64 based devices
 
+### Cavium Octeon based designs
+
+ * [Ubiquiti EdgeRouter 4](https://dl.ubnt.com/guides/edgemax/EdgeRouter_ER-4__QSG.pdf)
+ * [Ubiquiti EdgeRouter Lite (ERLite-3)](https://dl.ubnt.com/datasheets/edgemax/EdgeRouter_Lite_DS.pdf)
+
 ### Atheros AR531x based designs
 
  * [Atheros AR5001AP](http://www.atheros.com/pt/ar5001AP.html)
@@ -31,6 +36,10 @@
  * [Linksys WRT55AG](http://www.linksys.com/)
  * [Meraki Mini](http://www.meraki.net/mini.html)
  * [Senao/Engenius 5354AP1 Aries2](http://datacom.engeniustech.com/products_detail.php?name=35&cat=Wireless%20AP/Client%20Bridge/Router)
+
+### Virtual hardware
+
+ * [MIPSSIM](https://qemu.readthedocs.io/en/v7.2.9/system/target-mips.html) (QEMU)
 """
 additional="""
   * [Running NetBSD on emulated hardware](http://www.NetBSD.org/ports/emulators.html)
--- /dev/null	2024-05-29 13:24:18.037339641 +0000
+++ wikisrc/ports/evbmips/images/edgerouter4.jpg	2024-05-29 13:35:09.001883934 +0000
@@ -0,0 +1,161 @@
+ÿØÿà
+
+			
+
+		


+ÿÛ
+—I ÎPõŽ^s•¸ä@
+—‹ISh¹˜å‡09YÊN\f
+*X\ß5
PyçtSƒät¤‡gè肇/8áädÜ7ÅʘÈ
+õiïÚ¯É8=Nu9õA¸u1È­4Ë*X3g6d*a,nšf©œ‚¥3&cžažÈ
+J¿±/ZÞ
+¹ÞfÜÝ\ÃáœÐ;ëxHøB^q*ú·’#ÜÕGÖ—˜éÔ;’n¡[\¨Ú·NʦÞiäþ9xÔvË*oš¶ãw¥H*¬ù«v(vÖqYÛXÍ~ØîÅcŒÖ¬y]|!.¸š^MG”ìm[wŒê
麏Ôh†£ë]3 G—Z?›>%¹‹Þ¾ý<󊥩j$n¬ù«8 +5ð
µÃµ’­ÄƒßY9ûsÇ
+ï;ŽG¸píIKÉ
+‰¨îÐŒ=¨¨ýIE1®ô˦-Êß9?‡/zö$Z¸\æ\ßÏ¢Àlâ·yvšŠÀNêå$
ÄXaâ€$¤î®+Øà•n®
+SÕÊk‘…Öà+¬ñ·m~Ðî&½«ìøhŒÖwœàŽFBAÆ7e]ÁIî ¤¥<çžà´«yÜ?/“iú‡“EÆŸ1®Ó"*6ºÔ­%Ž¥KMGê.Ÿq0õ†áøÆéÔÍ÷_M›Jp¨æ³Y¬Ök>˜J«ÂÞsKmÅÛkœV6Œo®T ‡7ø
+È@Æ
<áA_µ;°1ÚOŠ$8B”æ·$'
+*c	JO#ØíP$Ðí¯Ë”¯º³ßŒ-Uv¤mÊsŠ)ä,•
Šz{PóÈRŸY;àTMaa1:yBbõ&Úº‰¬ôÄÂÛ­<ŸèïºÊ×f«Ö¥¹^–_òP9'Šç&°d×µî9òVq\Öí£Ì´ò¨›4˜R–’
+UŸ‘ää`¸¬ò’žkrRŸÊ¥dà¥Y.جdní «¼ò…„ïRÀ'‚6…eJÊ’±ÝA@#jœ£¸òóõ";­¥Èú®÷1ú‰}j£õ&!µ¾—’#Ë‹-yu½[lÌßµÝÆçN?JQ*PÜsä¬àãÓµ5Î3ŠÀ¬ùk$sž;R>ÆW°úæ³ZUÝ>Ó÷v&\ތΔÓè½j'®ç4ÔU©…¦ÈS)Pð(R›Y9 „Ð=½¨J¹®R¢	 îPâÜÉBÈ*îÁ
+J²~ÉÜ”¥|§q
+çÈ…n kãFR„¯º·(,grBC¢›y°¨º’í
1z~eqú’Š®´Óæ-Æß8|¯Èb+WԹ¯Êun潇)­ Qï¬æ¹¡•ÐV+®@ &ugœâPV+3´y’
+!@`¤öá!'¹?
š
+!{p¤œŽÀž\IÀ£ÜARVw6á%'½8Å£YRžâ•a(õ ‡é›ÝÖ%hMQ6ò令ÖÐ4ã—]Ar½º¯%(]©®B~Åguci)ÞAÍ{W8&½…ci#ÈA$ý©9¬¥ÈÛ^G
yQ¸,(%æÔ<éÚ5çlVi+ZW‹ƒQãêYvófrUÂól—I…nm­ò"^,q’©V¹ðÝ9IùO ´Ò‚™W…ÄÑmÀ°q@e>èÂBN{мe^Ä
ã §	ÚVrB’¯u`¥H†R{Ó¸$!åÇÒIrIéÿ
+Kt’>õHBëÆ7}9MxÜE`
ûDAɬíQ)ZSË@¨”i;[CÒJÔÛIn”öúö
=1þ{éÕÔÿ
+ñ¸¬p‘ÇbG;8
_	4@¥s_
+Ê{‚¹ÆƒšM
Ämø“ÉIÛ´“GµJç¿È5¥<ŽÍ¿´AØ¢>GŸK@!N©nV{ÆG§nÓÅ~—Ö=:Åÿ
+Ý…íÂÚuõ~NÊCg+tѬ䝇š9¯Ì„„WM,²bGôëýϼ³&èêÚ(òÝÞ·?"u­¸=bÛ'ÍK¬ºÂþdµ“¸,PUo&‚À¤ÊtRg9_U`x\¢ÎêRU_
+Ô2 ®ìw ÐíPÝIÆ=ÂyOhO;NÀ•åc"•ƒ[ŠV¤¬œà…¥T0’76mo{”N)é%e¶ÒŠqº'…c
+÷VAüß+Fôÿ
+­‰­¼÷„琱€â«x¤¼E&c¢„êK°Ô€	¥§¸…mÁ*¥v©cug#¸+
+Æ×täÒ6×8ƒÊ~$«i
¡j%A!o*ABR€÷4¢
+Uš9ÏÛö`¨°Ë²Ѻ
«?Ü{Ôý-§nfoI4ûÕ7¤WÖ*n’ÔÖñ÷bà‡Ø‚.¼/Ñ%C¸|º;ý–鬬öç.W¹³î1v[´ÛL­*H)÷“mˆ*D'#¨¤ñ¦°¬åA;ù¯*&K‰¤ÍtWÖ0T“GÅǍi¬m¤æ†Üw-)ÁIÆÜœ/f嶕Í|*P¦Úu-¤©r·£¸
+%@ý§QmßVë|ˬ½'£¡é¶~öu–ÑsºY¥¥	ý¸!7
	ª­Éu§X_·\lÉ›.j¾] q©5ô&ÔÞ·àJÐú¶å¨Î›ãU‡Bõ
Ò;[t~—¶ê·^šý$oª+mæ« ÖÔÑAÇvíüoP­ù¤»ŠL§E	†¼Ñ]BÔZVV“YÂÔ9ݵDm^H¯e¦›m-ÓÒÐ
N*ê–í/ãÇM«†á¨féÝ5oÓPÿ
+Ü3´Ø3µa9P;ÆBëʺM%õ
+L·këR)
+Œh ìñ)5ì
+€	@zF)
óè
§3ž0sIMi}'?SÉ´Ú Y!NãM¼™úJ\LþÛÖgô³TD3¬—‹j½þfžq‡ak‹ôDÿ
+ Ý*×íÒô>¯¸j7竇ÑI!@ újW¢>“p>ƒ*V‹éâaÂ%Àƒ=¹ý5ÒsªáÑÕUç:¶
y»•©^ƒ‚ušWSΦÞu“Zê8´~‰HRúst«TK²ËÓcúíòÝ24øíÛÖÚ­©UtÆ3Ño]Ü8u)ÈâƒQÌ9ŽPö¥z#áùoeG&l¡#iôþãM<™úIÜîAYÒÝUͳ]­ªÈ?"™ÑÒ#Üb<Ïzr›lz7Q®HB¯ÚéJÒúçZOH«NL‘üÝäwⶩ"ÊŸÕ>ÁíJôGÃè—ÅZíSï“t®¦#~$@5?Ii«Né‰ê›ÒMA¦émIn
+@\á½B†Ò‹ç-Ü^mÆ!ÍŽ)6ÛVжÔÙÕczVZ;¦bä䏊èÁ—½:>üúuG¢¦{£ï‡¨â~>÷¶RpÏt€
++`:ñ¢+[ÞfR«Æ¿ºM&XÚSÀ7@¥
Î7Ü6zömC5‘‘7®[”‡F5Č̎²·éÇÙASrá›Ev°òŠàC#!Ôá„c°½<z+žÌ—<
à+½»SÚm“W›6mÛ<•L«´Ç¬Öí„JüÐ8C®5³)ˆÕPŠ¹X<1Y¬C¨q¬&nÃö˜Ñê
X£"¶ªhŸ8­B$²á»Gf4T²±˜‚«jì³M–;É/oÝ1¤‡;L
+¾$TA:ð*‡ßEï*ìJÀõWÂÑ£5±güµ»'ö\\uÝA-Äbˆ±QÓ°„ÃÀ˜2¡¢ÛÈÞrÄ@õEí°óY´ß–€‹t@À–4PÁ˜âL<ky—^͒ЇTF4W>fQ
„&ÁêÛëdä³Ê
,òãî¡õ¾jÌ¡ãºep=Æ¿ñ5“Ã×£Jû„ܮfTä:4·'ø±Ìçg¬©c‰ü<èåù¥L‰÷ÛÃËþ´¦˜×Lc‰Æ$Ð
UDAé:T!èª0SÖEp›ÀŒ
+!«¸ŒŒQG€8VðpÖc
GT+ð'iš¬v
+Çõk×Vÿ
+ªÅ\V·o´GÍ+j:ãC°î
+ ñ†"aôÌPûè¾òÐ{îĬP5|¦¶,ÿ
+8ëÄvqÄôPºîêžõ1Ç°}µ­Ìº¢0ük§\xªÂŽZ=­TrPÒÞ-¥^à þ*×艅ÍjOéÑ(°Žµ€ýÖŽñ ‰1ԸǖŠ‹Bjª‘L|EzéwÇ° TW¤ë®,¨º®_XãçpöVÌÈ)ùÆn>£ü¤=ãlš„ÈÃÐÁ‹PBøŠÄa×C¶Ý˜„ä£lËŽŒnÁ:
3‡§1°„+eˆN7 #ºCÝQ²Ä×­BGÃ0ä¨4`ÕðÏŠól¬ê¦ êÍKí1Š˜ÔYHOF
‹õáJ¬aèK
‡\h·7d[‚tŠ65ÏÛÛÁ:
1XG·0¬":¡[lô¢½cêeGdb¦5s]å»X5nf¤©®{0áÓB^Q³~¼´Ö–å5êyúcªaëÑ_Û¯¶‡Öò9,ÏñJf•ì7T3¼ÛË0Åþ“e—ÏÏbwªnF…_&jºù©û£IFúÎh|Òÿ
+´9@q]½¦èjöAÑJãX¤[ÑS܈¸EcÚð¢§Q‡Ñˆ¸Ã€0
+!&½©…´>‰¶É}¦·ëŠÐ`”¸3––áoÃ@
+ò¢Ãxþ†Ë	46¦öŒY@Ñ^¨Ü~1
º0¨$Íܨ÷ËÀÇöª,›¹\E¸ž½šaýAÁ¼tÒ–X¿Í‹HÆQ÷9ïAë	V·¾]Hge%™&ΐöùLifKçìܵŒ-žƒùÄk×HÈfz¶¥÷¨}sš3RÏÓ,Áøeâ‹'„'«Jû„ܦfTäm[†“÷»Üþ`${¨1fðÒ2qÊeÎS¶Þ'‡€®,|†µ1qˆUhrÕ¬.Ž C
Ò+âG
®Õ—LQjþñ\DÇXˆuB¶€Ø†-a«¿–N
Ú8Þf­Þ„b[:ãV[®*ª¤CÄŠÚ„Ï5eSQÕ—‰EpÚ+ŽñÆ訣à{e£ì5wòÕµ'mE«rÅöV8ý'~yb«ÄR‹ä[›S/;R“Ö=1Ç’·ÙÜÀç×¢°*‡ÛV.VN^@ÑUDzOÉ¿šÂT¯I¸ø?)[!m€$Ûèê
D[³ÜQ/KÉÒ J'»d’
+´z+Ö«Cáˆ4zè)"ølËV„E€ïÙÙÁzEX»vŒAùi™ncEy+`ìüLúïneðÆÖ'¦£2YðÂÄøáP}§4¯ÃÀÐíÍììÀJ„·¼ñ{ƒ	fš?ÌW’¶cgÁ·‚„[u/².µV5tÙmoö>êÛÚ™ð•øx›À” ‘VÊrÇ´÷a¦·e~qÚ+ÉXUçƒï(Dî¥öEIñ«§!>Rà•‹)œ{
Èð¬ ó~!LTE”íÓÝÝ=5ÞØNó8ÖŒñ.ZǺǫ̀<óž”à³_y÷ã
+¶säóKäÒÊ?(0þš;ÌÓ‡\‰ªÿ
+݃gUm£ËV²À6ˆY·ÀËRéCÉ E¾'HV®V
Zì
ê·¦3¸·’¢¥°Ä9ƒ
+,Wg³ÒÜÖÝ l>H£=T¹MýòÜ%ÌPëí©S'μËÍ•	jÞjQHóNk8IÆfe½\¿	k­yÙyÒ—ºóÇ¢]–ŠŸ*¹9
+þd|EmK¡½]=%¦2¦bÜCP*ËÓÚ4BÜù‹rÕ°Ãâ`Ñ¡xh
+
w¶·x_›Fá×°¬Nª- ‘XzØø2©«£\Ĩx®;ÇPpè­†€nÙoÀÖóù`àÌÂj$0»Î*ªÐcËPd€m/²*ÖÚ#)Xí¨`κ

+
ºiLÈ_Ø@JƁa|ÃÝØ
»ä«¢Ç¬Â¢uà+y?¡|ªÕÅŽ‚¶¢SŸgË+üŒ¿¿3åiyd¹Õn‡HMÍKÊÍiR?˜áLÆ´­‰Œ:k­ì­¹G£#enײhšm5°€ÅU6j›»ÀàåpdVÀr×dАU@¬ò:1ƒ*š¼pg$¯ 5¼†+¬Ç]GT+aÊ©Ä5Ñ' Ôp”¯û,MmBâkw¡ª#@šµ×^êÐõ‘XúáE Ë\×ÅuaëPÌ*Ñdmpf,D<
­æ鎺ŽŠØbPѸžZÐJFý–&¶Õ‚ñH\MºîËV<´7ŠL{¨O+hoŠ)W–µ
5|Uaî¬=cpv
•hØN=æ,D<
¢ãNc®$xŠõOÔ5×å®e“ú-ר[Þ& ö\{‹MD¬—Ëf_95Ñ»J™1g†0C~âéŠ<á[É›d˜˜išr/6îÇþXEæô•$~j\”ɉ“¸p$ÿ
+;Jވ"
+HAØEh塼+h–ññ·¶ß	Xí 
4w@ŠŠøÀ%öэÐÐjà ¸Ök¯Šõ,`~rë½õz…Dí–[I A×÷ÂôS
"(¸-×W©V›éºðè«%Ç^èÖšÕݏœb–“ÉPRâ_œC_Ë[p“*8PÆ£9b¿A£×@³û	Z¹—xü0VÝѵ7·´@µ	[OñJƒÑ…nä1·´÷ƒÓFX—bv¢£o’‚®‚·R5â|ª:ž&¡,ÁF­Õ
+Ù–KVЂöWÒŸuo¼¿.Y¼òj?­þPÊĈ"¿ìüß:N›#R¬uñ<jTãØpÜ•:z‚dÆq³\֏Î9Ì´¼œ¹r¦åš]ÒœŽÜAóÇN•Ëe³ùlôä2¥Mšø‚ŒìÓ_®á­e3lˆWyòTÅ’@ºa$‹»¤[Ä*F~n~L¸Y¹™|&1›b‚¸b8š\‰™#@Î÷wWydq×›¿ÉÍÝKšeolÙ'Æ“3''6d¹†ÕdDㆠ¶]‡MwÃxŠÛ•ÈcCyÃHŠ-¼º:ˆZó<ûµÃ1ÔTU W,F>ŒÈô¦:ây*تêë‹rÖ0•-¿e£[aÕt+‹rPHÛ袶-ËP˜˜7u-ÐøŠÛÛ<e){jé‹ ÅD+Mëp$©W,´r
+Çø¸UÊâ_¤/Ehi[Ìnñ«ƒ«Làοen1ûhˆD¶­¡<•jéã‚(_
òF­•‚qo:€ÀP1µ0#ø°¥½`;	ÑB=îÊùaPÏ÷L*lô÷“åÉ·ü·ûGèHçyÊ7ô?AääsÓd¤ÎðSRwYÉÃêí|¡~Þ`PÊO•+5—‹1—0jKÔuŠ3óù)¿["ÂÒȲÝöóOeI2sùu–&ÚÂt¶WÆx|1¶}UœÌf9ÂWÖfO²À÷Y.¶¶
+õÙ%b‰–o}×Áz
E@iƒ¶Ë
¶Kú˃B (í»µ¸(í˜5 ‡w+Î01髈)/´
+ây(F*ƒº¡»Ü´7Êu!ŠõÂ?ªX5˜ì ŠÕΦcpu§q
¡XmÍàì‘’ŠÉkm¯îŸFÕíÌe„y*Ù	~÷{ëf¥v¶Jšã»a¯7„K—Ø¡­°ùF?Gx
+ÞOè_*€Ämm9þœ(€bݦòˆvÛ¢¡ÝN?Å…E»½•ô°­¡«ÑY†ÿ
+ÔX8Aþ…äK^‚PÕÓÓgáÙuÈ¿³-ZxPi‹{îÄmä¯NoWÓ ÖS½6—øŠ€ufÃå±1zÞL75Y/Ç¢šÃŒv˜ðš/m¼ð¬vPr¶´4«ç…m·dyaD1ÇщY5;sRš_Ö
+ýÞƒXAçzL°Â¡'lžÕ×[Gweÿ
+ây+ÑAÝ
+ÝîZŒñl¾
+V=|Ì<”4EuU²ðN'ΠAŒ%¢ÂŽÏž5Ä€Ö§zO½TB¬v½`75„õÒe²ÒšdÙ†ÔE±¤ç.v7?ª®«#ï¯÷Ó>s™ò®í«„µ¹F4NK3šÊù¯Qˏ¶‰Ég²¹¡×dôcï¨æù“4 qU¼r¬y‘Ê‹‘²ÄúÆhë²³’¤ýKœn•,²¶ÍÃCQSFc)õQ5ŒÄ–"êúYÓ?tÖk"ù­ÖnJ›C¡´´0©ÜàÓ7s&µÍº$
+|öŠJNyÖ¹´‚[â½ÓLæÜÞc,ÀD+âý´2™IFdçkUW‰¡":î3k„ÉSd+y\>Ê™	’¦¤²èàëí¨­
vhãQ+VÖËVÔˆ¬
_Ñ5³;ó
+ÅC~‰ ÓÖó+LÒÞÜcW#!™é2Öí.Ç·t}ôm@=7aljÙ$…ÖøÝõV¤³ÞnéapQ©"ë…Z¾®_ÛQq»•Ä2ây(A­–;¶˜ÝËWL"\®Ljé ÛðÄ47¶¯ÃX•5vaXþ®
¡@¹S7²¡­«K±Ð[uµ½™ú‰…\ƶ°O/:Ãä{
³ÓZ]3ÙÑ°âcµåFÓÆ榎	Œzëh@c‡&C›ä³Ÿ€à<ÏUoZ³Î=dï.¥êýô9ÛrÙˆüI`Ñúºf2mç*l~ôh·6s´‰Ç‚ÎRžÑ/7™æÍQÆG­ö.5»Ÿ-¥·¢â÷K˜Ê|Á…+æó'2ˆí>–CýOÀÔù³gÜÓ”L†êö|’³™W¶l–¹#f¤s‚IŒ„¬Ÿù¶•'å‚æó½ãµ\å6Ám$,8FêÍ6vdôysU¥4 !×SsYxŠIRågËà:×ì¯U2DßÑ™Èa^»/6_é!¨4pÖ€p®ª‹.”1Ö°jÚE5ƒ:ôÆ»êÞ8VܣэXÐÆ•vð‘èð«‰
oqFÍo&£¼{mÚÓFŠ­
+Á{žìR!zEzs8ª¾œµŒ&Nì–Oƶ	v:Á¢¶B<î,VÜ*ÉE˜úqºÚŒÇS
k¯€­äށåò8†Êéò0hj
+v}.š1ËÇß[cv|ñ«›/
+<Œ¼ó&žì±×öWÕ²ktÆþlæïL?õÃýÏsÊIž‡³1mDdY½,»•öi쫹«žc1/ý¡öVÎ@f“Ґàû
n³ÙIÙv:	¨V<¿»È¬+5•›¸r
ê˜wE0ÎoÁàeÃÈþ0öÕ¹^tøÃÖ/Ëϧ’³‹5JÆ@ã‡îaYQÿ
+71ÌË,2Rãtcx,xTþq‘“'0Œ¦ùklq†<µ›S9vÓeÑŒuä¢Ù<æ[7ËonÚ?ÝˁÆ[÷U§8Ò£çP
(*ˆ5‰w!ú&„ãÒ+²Þ½bè¦Ýµ·y„¹¢<KÆ·rŪ{A±¢
+c–\¾m8næA¹™süך‘n¥¥yt5‡ÒYÒ\£¡Š°Ô±³<~µbyjÞ{þÎÉ™üJ
÷ýµê³3ù½úÉÖ"¦æ2\ç/5/1.Ñl<ük.îÁ@ÍœO‰¥É¬Òò¥f §ÒƹÛÏÔ}ã\ñõÁt€ªf{°héDIH/È&HšòØv”ÀÔéÙ¬ÃΘ;Dá0W:L„l•-¡áun¹«ë9<Ýã)ã¾èÿ
+Þ–‹FèŸ:$ß/ÃhQ\Ï9n¦Ý³pÙ"„̾vFif6ÊÊ´±ä¬¼²L7˜¤>B<êõ|ŠÙ)›˜a³/í=T2|ß*œÃÞ˜|ÏøÌ9Úò³úÞX'–¿ºýg$ß«™pþ¨ÕÜÙιyÿ
+û4öUÜÕÏCô3ÿ
+ª3¦X,ÅM
‘· ePÊp>Ë74žGÁA6ÈÌŸÌEƒñŸt,5t[•Î”8hŽ¬y{6
+ZŸÈüú
+š™ü86Mt«\xÎ/B½9nZ©z­»àh.–ù̍Ã2Gê«VU²
+çR~ÀE—H˜ø²ƒ¸`opÏÝ0(šEÈÉ­2V±äD†Ég˸Žµ†CxbÌI`×"û«YàP`å?¹ë à²Þ!d’„—-šaí$CsaäË`ƒuI8ÁnEŸVCâ-'Äúë$Ø`;˜}΍T’5%â*@z€—Ü“W"
&ãçĆB„Ò'Z¦É†ˆÂ!Rw*Î’"-Ë*>ä'œ
üÑPË_Ô‘\äë){ÍÔsV_Üü‘
~mXèžàú
+7ä™Qcé<ÄH4뉀H{¦‡tyèƒab܉à‡¦R'ñdhœ†~ì’$èÓ²iT!ÎC|Åe9·°š8ýeÇ$6Aõá@w'GÇ—É­Í
+ÏÐ¥“à–ãAä‡Õ,ƒfã)R‰Ó“Õó¥Ëç<
+„Ô؁Mä²`
+&bñ@ì ¹×.Jç…BrŽÂÞi€°b»ç6éƒã6·é«å
+%ðâ“4±æ)XI0L˜¢¥bŒÐ;•¨m ØÌøO3u,¤fÖ? Mĉ æy°ØC•&j‚¹à˜XЍg Áfið#­Ó€‘]ŽìG¼åsYqr“œN\2XÈeƒ}³ifC»Ãs5Xr‰qHǯ!bh	S<KMÇ0ú¡ÒKάPÐè…,|ÌNžÆKÝH”G ñ0Ù‹
+û
Ê9þ¡üØU
0î.k_jî
+nIÂ>æX«ñNÂ|°ÌE¶BæaHŠ¼eûÐŒV8KÃÛzŠÄt­<t¿j¹
†lšW"÷žÁ©†ëâqe$­
V„m<U€o›ÝÚyÿ
+0˜¢DÝıNŒKÞjƲì4ºŽ§	VúMp!cÐæI¢€Iðk0hœëéåÂ
+2F«/*”]
žo‘ƒo(ó8}b£W|ÄÙó>©ºBÇ|ÿ
+3(<šÙ
+P‚ú
O†ð?¨xŒ®YЀ—ÒÌ:ü꙲G($’“k$š¯ýÄŒ7²xö)—=Q1±Ü’‡GäXqSÄÔˆÖ§ÆV5äÀZ— ,`ßY®ªËÁ *cDr«\@Âok©¥…²¡’[(ß’&uÂ\‚BÈ
¤x4ðj©êlYyk,Ši“!ÞÍÄÝlÙ³øš6lõrÅy8Mˆšƒ‹++h'†‹8S­e|º@uHб@1ŒíX(t×Á5Ÿ”&Éé9M’b¶ýˆ¼á¨`ä@&á"¬ÒmOG(6
+ì¯)͏îÖvЖg<4
+´´{ì
+ºõis%'4;Èü¿òe‹†c‰Ñçñ6jÚ)Æ,DçF“5Î"ÌŒ
>œf©ž÷­[–w<‰[PO¥T

+ÝS8<@]>xe÷bž2x>´¸‚õæ"™ê³áÍ’<uÂY«¦“Äi¢ªž¸Mœn£yV8ƒÁ"^å-œ!Œ÷d›¡\ÅÅ;˜yÄ(Ä&Þˆd4ð’ÂÙÿ
+*ëhKÁ%:Üt§†‘¨©ˆ“¶«‹èæ¦î$Ur¤0&ÍY£°²9±.´4¿Âl¿%¡«Kfø*0²€Þ&Ž2–1Óþþî©w6¹FSªë¼ú¸=›÷õ[€Ã¨ß÷fÑ †¿Þê±t/Ÿõ~Do?öñ#¿b**¿õÍš%á¹å'|ŸWノ—Ý/ºëA$š	ÃÕMBr€ñ‰®Ê
+ã
ä
IAäc…öÕ:ï™%‰+<A|YrâH—ÉTQÓXŸ-eážtk6 .8í·J
+9´6óu”÷·‹
+€zAßÉv9-ç¹õX„›¥BƒÐ07¤âðnŸººÓÓeþ÷OÐ@¡FMLŠÐ°Ùb<O“ìÿ
+Gô֝!Ñ
+»G…ƒĹÌz(PÑÒ“²’*P
+t*hÇBÑb0˜Ì[¿C'å˜nLL»éR
+Ô—PFÍ3É\»w(V
+ñ”õk–àIe''¾ººR–db¬%–ðkrømXÌ.LÇQ­Õ/× #„œð
+Ž‚>¿Ò⪭针+$Â\á«"ãMῳ\¾¯ìˆý߀"”&q»‡ÕÁø¢*½½í¦îµ]Zªj‚lfIf¯á£´?Ép€”KªMveW™¥cÃÛ¿áÁü(?û@€M›£QoŽ\Í“íª÷Qº^†`k¢4ŸÎs4tŏÁRäÔ%	~Ú\þ„ƒ€Or“ÏtWopæO[Ôˆ”…Îâdù¹äuÒå¯u°@cl´é’N''Lëã´ÿ
+oc³öwLÀ@ðmçÙ™æó<ÙÛY ÏZT€Í'Ùõu`´_±ô¸“/âkö½«RN®O›÷OÀ²Aèà9
ö…Ô’¶qÓM®>¨tƒüêÇ4Á4žŸÍa0rd$ÕÑÍ.™càþi(ÚÀþÿ
+§ø·$Zî‘O)eD2p2G™óJÇ×2r}¾oï(Z‘‘ÈÅÂ4C—–XórKœD°µ® 
+wz!ÿ
+I$’	ဠ	 ’A
+ÝfqyI
 <ÍXÆ0	åX‚t‹ŒT†‰ÑÉ£u‘Ø(ו8V]o.÷E•W¡¦÷Âň¦†yMq’Ç–ÈÞç7ŽÇÀ
+Åš	õ¥ÆC^¤à|´>Oý
*°fcŠ'#Dœ"ÄXh´ŒùÀöÄ„€”&ÉÓ¥Àg‘ž^¨%TÍ@¤ÝŒ•Ñy`®4xÏ­MÐMÁR¢bO†é0ÀÂY+=w«4Ø‚äH7~n{HcgÅ8Ð0êÇ}ÓB±þ!ç9뺭/‹[r=÷Õ;÷mâ4mÄáñLD	ÐbAí›;æ•͏R|°ðQ,b^yb€f5¤ÈìRJèßbÞÀ˜pÂÅÛ‘Âq
‚dL¼É¸šxsÙÈä¦4Ÿ=³ï›˜¿Î0,;Õ
+H…fY€°xŠ´$ˆ9#Nä;f›ÏÂUU®O¬Ý­°3YA+åuLwDà§ÂˆÃ£Éî:¥½lÈ
+{ý/BS4Ê7']t?¿F|up9ÛI²1ßT‹ºS?jD,ƒ#Ó8ÙåÕG©fâÊ4s@oNL©‰fºê‰Èd‰Ì ÏÓñqP‰È2úf:ÝÊàkZ	~1dje€¤ÅCçï5‚Øm>£ÙßUˆiá’%Þ'¾ê·•I×!R¥€Iæ(yŒPÕ†0Ç=jžÐ}U5‰
$1Ͳìbd ýú®„Àè0GðóÌØ8ˆŽÄÀàóª$Fƒ"H‚yÿ
+›ßXÈܒ¦µûY|·‚†Ó³Í*ØËç`Š¼A”ê‹ÆY
ñ$Ìs8³¼C3e€¡ñNªJó˜7Ý*«Bá’LŽ3%&¶
+p9iÀÝ®,D´:<ÖK\”ào}Ö˜sÃÌ¢Sˆ›b”üÎlÕ7IÇŸt!ÔácQÕÃx×7úM\Kax!	Ÿ>:²n¡,
ƒþw•*
°,h¢!ž£µ$õúW%T–#&G¯w1…N‚÷M®\é
žcõ§%@x$,cž¨ŠÉFj¤ÉŸ­`&žL=^uH“žÝá‹‘K
+B98ÌuH‰h“«<Ù¹¶~P‘YÁ˜BK´œ}ÎüUІ˜`¦Hüy°ßjÌŽ(JI#ô}w@pÓ³À/OÅw›@P`›~Ýù¢@?ÌiÜŸÝX™)ÐS%\ýs戀
+&6ÌâÍžU”O›¡z¡îö4G·ÅwU!dl–Édí6>l!<ÉûŒý÷ª¥é<“BT:ëv".!ƒ'xûª齉
+!®‹d„˜Ra|~´Gh{x‰'SÁQ	—7yE1Ÿ­Œ
+Cº` ‘ÉÚÄR„Ô¬2™ãŸ5”3s…
x>)ðâ1$tî{y°²Á‘º/¦2ü4ó^Zf2„ÖÈÏ»¸‘Œ»ŒQjsûR*È:æCç»R"Èò&
qêŸÌÌ\äõ†¯“<
`k¸¤ >xËÕkƒ};LS´Œ\ªD\³ó‹ë€NÕL…zÓðòR®ì}p
+=¹Îj„	”>8Àó¼øª,ÑYwÇíyhƒåJ¡CÛµéÿ
+DËø(­ƒCO!ÅvñÞ«<ñ6t‡ñDŒI¾þD"w®éì²ûB÷g¦-—,#óÍ4~¨ˆ¢3-S÷»œ
+ŒXLfâð؈´É*N	Â€NW†yא5N›J÷a'Ǡ-<sÉŒ@—™È„Qš%‰ÄÙ-–™'rÂÏÝCñ@Q«Ç6I<ÓZÑþÁ¥/œWÜë×ÇŠm=Åt¿_½³‚^V¸â¢KeÎ{ó×vv3`µÂh„0
+a??­€;Á¼S?¸S+>rÉÔrpc4Á84Þ¥ÅÛ#
+Ø=qfïgæ¥йdyê©ED¸ü7<¸æãW
U¡ìºDÏ8v$3ýh&4ØÊD0ÞŽi4/pZ‡–Íd
L	£"rß}VB!]ÌBþµ€*QŽ<4a÷ÍIÂ(Lpe QƒY‰VT¡ßœë5CØr.@ðcCÍ0éµT_A2dB:"oÍ„…!j•äEÙ*žŽ2óví¨bå ¼¡»nò›èM'ŸþžàB;”
bˆ1\²ààÐÀr„¹BX4ª‰â,eîþII‘ðâ€[21òÂ!5Ⱦ	ÓÕ¬ñŠˆºÒ!óžÝ×ÙŽŠBâuø¬’ºÛ%	óÏT…BNƒŒw‚¾ä¥h~7Րl<P„DƘêæ
+G¸’pÇßUy´ÔÙ
¢’Á|GXw5]$È-;üWD¶ô$·ìê¹^Ù?»’Pó·ŒjÃ¤ø,†#1¤êÏBÇOò§8–|	T/œÃæèøÉ}†Ê3Z|ÕœÔZ¤ã\ÅËe“¸(‘3M”F#a÷çu)H4

 €â€¾±G•
åBÅ^¿æ‚
<Ù6½©¢¹*)ù*‰…Z Ø¥@Î<™µG+Oe=	†¦i!g59ðÑ»Ï7,	óaÝÒ§Äâº:èQòe§Å–ô‰™øé"lúﲊá8TÂÈÇlV1„
+sP{ÖtàK3Ûâ 
+§ÄLµ°þòT⠍qζP#’`†N|N›dÃö`üú¤¹Ø1”ú¸Çâ‹q ‚òƒ¾WäyOœ‘p•†ÌŒ‰õÝš+0
+CÅ
ò¨¶ŽÆøÿ
+Î¾«YÑ8¼ef7ÕL¦déôÒ'y;î 2Ü€åßVage·÷ë0¿‹‘..‘Âñ‘ŸÜóqC<¤õXÏÍE/•ñ6ø|4lâ@¾g`þi\˜›’ÃÚYË…’8×}Ôôy$	/qe–Ŷ’>;§ Â{Ïv*Ìå=VëâORÅ—†).ÅÙT}ˆ9דY¹LD³:ù,„²læÌP"{Ê
×-*É•q{±ž³Ùäš4bAŒ•ýÀ¤Ýº!¤/URøÆÁÖƒw
+gòG -–ƒ/Á5
$|f#$ÔÅóÝ‘/¬g#¬Æn àÂftÎ*
àêÓ`Ç XhÂ4D¸õQ¹Åðd¥Œ Ž’œfAékp!€¥?|´X•‚"Lv”'蹇z9÷J
+Anl±‹œLgÓJÎs|´òû (Pƒ)×9=º£—_žj"9ûkòP
”ÑJyßï\óPÜM9ÿ
+sù¸y˜L;¸dOîª
§2±ÉóY;ph±3Ç‹¤ƒ¶<f9)«*¾Añõõø!|2ƒ>9+¡h¯å'0bSŒLò,†NÃHYEå‹'sB9$£‘Ø*m8%×66Ò]HÀ‘™šìµò¹l˜ÊNG0XíaGˆ¬Ï
+ªà§–½ñ[pƒ<¤µ™×ˆêƒƒ3	u
‚v¼b Ì®hžz¦k+¬½îhoo›2ÜhǁÉ`)‚H>ÿ
+%™›”ÅlŽd4áƒæ7TGÖSÌfgóâ©ÑrYÆ×à0ƒ1»
+A32ȹßés‹Q.QÁ¼MÞ¢¦d)ÿ
+1<’!Ïú¥‰ˆ1Œ/ùkö¶dª4Ö£VAäÌA™â¦Fhw¬~õ¶ñC)fÐsø©ÝP×4Œjy§ÐP"'u3
ýQHOiZp‡ÏóµØçä¥ -!ÃüÞhj'ŽØ¤Ì®	æ`važ½R)mŽŒyßù›O)Û¤N
+Kš”6D2#‘3aR£&‡!œï7`3Ä
+'B0UA‰
+•áƒ½ Y_ƒvaѐÀzbJDÆb^xÌtÔìºn‰„õ⦠€ÁÇ8‚Yú§,èy
=Ô2øÅÇE>'²ÊTÌÔNÒ„xyy€M1†vÅeJÿ
+x¨èž:£ev†¸µÝp,!Qkž|Pä±SÜžCš„¦ËcÞߢ`¸FÖ}~”™XFð#ÀåÔØ|!k$àE=?‹ ¼
J$>ôµËˆÊðŒÎÙŠg“62'IZ!Q?²„@:GC‡îj×:\›¼*e‹ú¦8ò«ø±H¬êòøx³Ü0&P,p?x¤¤Ã;~ÉÂ$$é—äê←°h§cåeÓ“œD0óäøn€uf"=y LH’jaý?ɐsñËü9¨c%ÂñÉ&uÏ/8œWVi4^nÖ|‡RÕ
Ô™H¡È™+±R§j»|Ùo¥Ÿ
…“¿ð/	cÃaÆz×çw@æÃ%
+„¤W/ùöRýÙ}ÙñEä°8Š!ÄѲaðâÌ
+ä6÷NW¼µnO󵜏”òÙVIä?n|XA’¹ö£—⦐pBcŸô®ƒ!Â?Ÿ›ŠÄÄ{Ä{š¥s`„uüÔ“•C
+9m
+ÂGëODG”°¸0¶1†„ÚâRô÷Ã{Œcê¤êÆn÷þG:®ÈÃe¨àæw
+´<ï
v3Ýž,ÓÕqs6DÎ/ýèÈXà *€g®7dǪ5ÛÀ:E<% 6êF&p4+€O†)ù	]$<×&^“‡ç!ª‹CÉÈܾ+
Þ¥ñÍ
+m$<ÒÜŒ>+á~t(O ò¿Õð|Ÿ›õ
+/î,š”É“ñ\¤”ÆÑOæ­o!:F§ex0Ðx
+Ý©ŽDN¦rl¦š!2¼
ÐsPg’'`8þU4±»²d}\êiCº`K4r£^¬'
+2fTTfY݈Dº'I_*6lfP'GWJK{­0½!””g¦˜€Jy²BAe›„áÈB
+kô€.
+Û@áo;¥N(wÄ`èåtÜ#$û?Á¨ì††EeFJB+Dâ{ª՝D`qŠ³O|æÁ¡²"Fë×¥Ly'TÉÕÊångš)’˜ lεW©	‹
+¢®M5}°´¨®Xíæû§z…¦öç$AE.ìòaÒIñxÔ±?u°0„O(ßn‘½¦ôþ'íA6>ã$Ja‡u	“¹‰pk¶I‡¼³aäP…$"T@‰:

(Diff truncated)

Index: wikisrc/matrix.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/matrix.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/matrix.mdwn	6 Jun 2021 13:49:51 -0000	1.3
+++ wikisrc/matrix.mdwn	12 May 2024 23:53:04 -0000	1.4
@@ -6,14 +6,9 @@
 NetBSD on Matrix
 ================
 
-NetBSD has a [Space](https://matrix.to/#/#netbsd-space:nil.im) on Matrix. However, since Spaces are [still in beta](https://matrix.org/blog/2021/05/17/the-matrix-space-beta), you can currently only see the rooms you already joined. Here is a list of all current NetBSD rooms:
-
-* [NetBSD space](https://matrix.to/#/#netbsd-space:nil.im)
-* [NetBSD main room](https://matrix.to/#/#netbsd:nil.im)
-* [pkgsrc main room](https://matrix.to/#/#pkgsrc:nil.im)
-* [Bridged #netbsd IRC channel](https://matrix.to/#/#netbsd:libera.chat)
-* [Bridged #pkgsrc IRC channel](https://matrix.to/#/#pkgsrc:libera.chat)
-* [Bridged #netbsd-code IRC channel](https://matrix.to/#/#netbsd-code:libera.chat)
+* [NetBSD space](https://matrix.to/#/#space:netbsd.org)
+* [NetBSD main room](https://matrix.to/#/#netbsd:netbsd.org)
+* [pkgsrc main room](https://matrix.to/#/#pkgsrc:netbsd.org)
 
 How do I join?
 ==============

Index: wikisrc/attic_museum.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/attic_museum.mdwn,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- wikisrc/attic_museum.mdwn	8 May 2024 11:19:03 -0000	1.26
+++ wikisrc/attic_museum.mdwn	10 May 2024 11:20:55 -0000	1.27
@@ -1,6 +1,6 @@
 [[!meta title="The Attic Museum"]]
 
-Over time, several kernel components were removed from NetBSD, often because
+Over time, several components were removed from NetBSD, often because
 they were too hard to maintain, not always functional, and because the features
 they implemented were not particularly wanted anymore.
 
@@ -18,14 +18,22 @@
 
 [[!table data="""
 Component	|Category		|Removed Since	|Most Functional Version	|References
-
+vinum		|Utility		|02/2006	|				|[Commit](https://mail-index.netbsd.org/source-changes/2006/02/25/msg198055.html)
+netns		|Network Protocol	|08/2006	|				|[Commit](https://mail-index.netbsd.org/source-changes/2006/08/26/msg172577.html)
+netccit		|Network Protocol	|08/2006	|				|[Commit](https://mail-index.netbsd.org/source-changes/2006/08/26/msg172578.html)
+sh5, evbsh5	|Port			|04/2007	|				|[Commit](https://mail-index.netbsd.org/source-changes/2007/04/08/msg184091.html)
 I386_CPU	|80386 CPU support	|11/2007	|NetBSD 2			|[Commit](https://mail-index.netbsd.org/source-changes/2007/11/15/msg193018.html)
 systrace	|Monitoring framework	|12/2007	|NetBSD 3.0.1			|[Commit](https://mail-index.netbsd.org/source-changes/2007/12/31/msg195466.html)
 compat_hpux	|Compatibility Layer	|12/2007	|NetBSD 1.3			|[Commit](https://mail-index.netbsd.org/source-changes/2007/12/31/msg195459.html)
 pc532		|Port			|01/2008	|NetBSD 2			|[Commit](https://mail-index.netbsd.org/source-changes/2008/01/10/msg000637.html)
+esl		|Audio Driver		|09/2008	|NetBSD 1.6			|[Commit](https://mail-index.netbsd.org/source-changes/2008/09/30/msg210849.html)
+playstation2	|Port			|12/2009	|				|[Commit](https://mail-index.netbsd.org/source-changes/2009/12/05/msg003960.html)
+tn3270		|Utility		|01/2010	|				|[Commit](https://mail-index.netbsd.org/source-changes/2010/01/16/msg005468.html)
 compat_darwin	|Compatibility Layer	|04/2011	|				|[Commit](https://mail-index.netbsd.org/source-changes/2011/04/26/msg021404.html)
 compat_irix	|Compatibility Layer	|04/2011	|NetBSD 1.6			|[Commit](https://mail-index.netbsd.org/source-changes/2011/04/26/msg021405.html)
 compat_pecoff	|Compatibility Layer	|04/2011	|				|[Commit](https://mail-index.netbsd.org/source-changes/2011/04/26/msg021406.html)
+xbox (i386)	|Port			|11/2011	|NetBSD 5			|[Commit](https://mail-index.netbsd.org/source-changes/2011/11/18/msg029016.html)
+window		|Utility		|02/2012	|				|[Commit](https://mail-index.netbsd.org/source-changes/2012/02/16/msg031827.html)
 netiso		|Network Protocol	|03/2013	|				|[Commit](https://mail-index.netbsd.org/source-changes/2013/03/01/msg041917.html)
 vm86		|x86 CPU Mode		|08/2017	|NetBSD 7			|Many, was widespread, not reinstatable
 acorn26		|Port			|01/2018	|NetBSD 7			|[Commit](https://mail-index.netbsd.org/source-changes/2018/01/24/msg091429.html)

Index: wikisrc/users/schmonz/testing_chdir_bugfix.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/schmonz/testing_chdir_bugfix.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/users/schmonz/testing_chdir_bugfix.mdwn	28 Jan 2013 11:41:04 -0000	1.3
+++ wikisrc/users/schmonz/testing_chdir_bugfix.mdwn	10 May 2024 11:18:58 -0000	1.4
@@ -2,3 +2,5 @@
 warnings about `chdir()` to a nonexistent or empty-named directory.
 
 Seems like [this commit](https://github.com/schmonz/ikiwiki/commit/b30cacdf8da07f40af03f1b26021d8ec4d8b8b4c) helps.
+
+Is this still one of the problems?

Index: wikisrc/users/wiz/pkgsrc-migration.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/wiz/pkgsrc-migration.mdwn,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- wikisrc/users/wiz/pkgsrc-migration.mdwn	9 May 2024 10:40:54 -0000	1.17
+++ wikisrc/users/wiz/pkgsrc-migration.mdwn	9 May 2024 10:42:55 -0000	1.18
@@ -54,6 +54,10 @@
 Documentation
 ===
 - pkgsrc-specific documentation for developers and git
+  - pkgsrc guide sections
+    - 23.3. General notes when adding, updating, or removing packages
+    - 23.5. Committing: Adding a package to CVS
+    - 23.8. Moving a package in pkgsrc
 - update branch-cutting instructions
 - update releng instructions
 

--- /dev/null	2024-05-29 13:24:18.037339641 +0000
+++ wikisrc/users/wiz/developer.mk.diff	2024-05-29 13:35:10.449340947 +0000
@@ -0,0 +1,102 @@
+Index: developer.mk
+===================================================================
+RCS file: /cvsroot/pkgsrc/mk/misc/developer.mk,v
+retrieving revision 1.26
+diff -u -r1.26 developer.mk
+--- developer.mk	16 Jun 2022 04:56:49 -0000	1.26
++++ developer.mk	9 May 2024 10:37:04 -0000
+@@ -5,9 +5,9 @@
+ #
+ # cce:
+ # commit-changes-entry:
+-#	Updates the CHANGES and TODO files from CVS, appends an entry to the
+-#	CHANGES file, removes any TODO entries that were completed with this
+-#	update, and finally commits the changes to CVS.
++#	Appends an entry to the CHANGES file, removes any TODO entries
++#	that were completed with this update, and finally commits the
++#	changes to git.
+ #
+ #	CTYPE
+ #		The type of entry to add:
+@@ -35,10 +35,6 @@
+ #		entries are removed.
+ #		The default is ${PKGSRCDIR}/TODO.
+ #
+-#	USE_NETBSD_REPO
+-#		Explicitly use cvs.netbsd.org:/cvsroot for all cvs commands
+-#		issued by changes-entry and co.
+-#
+ #	Example usage:
+ #		% cd /usr/pkgsrc/category/package
+ #		% make cce CTYPE=Added
+@@ -46,14 +42,9 @@
+ # changes-entry:
+ #	Like commit-changes-entry, except for actually committing the changes.
+ #
+-# changes-entry-noupdate:
+-#	Like changes-entry, except that the CHANGES and TODO files are not
+-#	updated from CVS.  Typically used to add several change entries in a
+-#	single batch.
+-#
+-#	The CHANGES and TODO files are presumed to be up to date and writable.
+-#	Note that the first assumption is often wrong and that the second is
+-#	wrong for those that set CVSREAD.
++#	The CHANGES and TODO files are presumed to be up to date.
++#	Note that the first assumption is often wrong, but will be
++#	fixed by the git rebase.
+ #
+ #
+ # upload-distfiles:
+@@ -77,12 +68,6 @@
+ _CDATE_cmd=		${DATE} -u +%Y-%m-%d
+ _NETBSD_LOGIN_NAME_cmd=	${ID} -nu
+ 
+-USE_NETBSD_REPO?=	no
+-
+-.if !empty(USE_NETBSD_REPO:M[Yy][Ee][Ss])
+-_NB_CVSROOT=	-d ${NETBSD_LOGIN_NAME:Q}@cvs.NetBSD.org:/cvsroot
+-.endif
+-
+ .if !empty(CTYPE:tl:Mup*)				# updated
+ _CE_MSG1=	Updated ${PKGPATH} to ${PKGVERSION}
+ .elif !empty(CTYPE:tl:Mrem*) || !empty(CTYPE:tl:Mrm)	# removed
+@@ -111,16 +96,7 @@
+ # commit operation will have a sensible message with all of the
+ # previous operations.
+ 
+-# XXX Fail if uid is 0, or perhaps != CVS meta files owner, to catch
+-# the case of invoking these targets as root.
+-
+-# Targets for the update, add, commit elementary operations.
+-changes-entry-update: .PHONY ce-error-check
+-	@${STEP_MSG} "Updating ${PKGSRC_CHANGES:T} and ${PKGSRC_TODO:T}"
+-	${RUN} cd ${PKGSRC_CHANGES_DIR} && cvs ${_NB_CVSROOT} update ${PKGSRC_CHANGES:T} ${PKGSRC_TODO:T}
+-	${RUN} cd ${PKGSRC_CHANGES_DIR} && test -w ${PKGSRC_CHANGES:T} || cvs ${_NB_CVSROOT} edit ${PKGSRC_CHANGES:T}
+-	${RUN} cd ${PKGSRC_CHANGES_DIR} && test -w ${PKGSRC_TODO:T} || cvs ${_NB_CVSROOT} edit ${PKGSRC_TODO:T}
+-
++# Targets for the add and commit elementary operations.
+ changes-entry-add: .PHONY ce-error-check
+ 	@${STEP_MSG} "Adding the change"
+ 	${RUN} ${ECHO} "	"${_CE_MSG:Q} >> ${PKGSRC_CHANGES}
+@@ -130,7 +106,7 @@
+ 
+ changes-entry-commit: .PHONY ce-error-check
+ 	@${STEP_MSG} "Committing the change"
+-	${RUN} cd ${PKGSRC_CHANGES_DIR} && cvs ${_NB_CVSROOT} commit -m "doc: "${_CE_MSG1:Q} ${PKGSRC_CHANGES:T} ${PKGSRC_TODO:T}
++	${RUN} cd ${PKGSRC_CHANGES_DIR} && git commit -m "doc: "${_CE_MSG1:Q} ${PKGSRC_CHANGES:T} ${PKGSRC_TODO:T}
+ 
+ ce-error-check: .PHONY
+ .if defined(_CE_ERRORS) && !empty(_CE_ERRORS:M*)
+@@ -143,10 +119,10 @@
+ changes-entry-noupdate: .PHONY ce-error-check changes-entry-add todo-entry-remove
+ 	@${DO_NADA}
+ 
+-changes-entry: .PHONY ce-error-check changes-entry-update changes-entry-add todo-entry-remove
++changes-entry: .PHONY ce-error-check changes-entry-add todo-entry-remove
+ 	@${DO_NADA}
+ 
+-commit-changes-entry cce: .PHONY ce-error-check changes-entry-update changes-entry-add todo-entry-remove changes-entry-commit
++commit-changes-entry cce: .PHONY ce-error-check changes-entry-add todo-entry-remove changes-entry-commit
+ 	@${DO_NADA}
+ 
+ .PHONY: upload-distfiles
Index: wikisrc/users/wiz/pkgsrc-migration.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/wiz/pkgsrc-migration.mdwn,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- wikisrc/users/wiz/pkgsrc-migration.mdwn	5 May 2024 17:57:52 -0000	1.16
+++ wikisrc/users/wiz/pkgsrc-migration.mdwn	9 May 2024 10:40:54 -0000	1.17
@@ -121,5 +121,6 @@
     - TODO `tv-derecurse`
     - TODO `tv-libtool-1-5-18-tmpdirfix`
   - tag heads so no commits are lost? Other method?
-- add .gitattributes file for doc/
+- DONE add .gitattributes file for doc/ (prepared)
+- DONE update developer.mk for git (`make changes-entry`), see [[diff|developer.mk.diff]]
 - turn off CVS/anoncvs server

Index: wikisrc/attic_museum.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/attic_museum.mdwn,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- wikisrc/attic_museum.mdwn	8 May 2024 11:16:47 -0000	1.25
+++ wikisrc/attic_museum.mdwn	8 May 2024 11:19:03 -0000	1.26
@@ -65,9 +65,9 @@
 toasterlcd	|Device Driver		|05/2020	|				|[Commit](http://mail-index.netbsd.org/source-changes/2020/05/23/msg117603.html)
 toastersensors	|Device Driver		|05/2020	|				|[Commit](http://mail-index.netbsd.org/source-changes/2020/05/23/msg117602.html)
 TOASTER		|Kernel Config		|05/2020	|				|[Commit](http://mail-index.netbsd.org/source-changes/2020/05/23/msg117601.html)
-libglut		|X11 component		|10/2022	|				|[Commit](https://mail-index.netbsd.org/source-changes/2020/10/25/msg123388.html)
-libXevie	|X11 component		|10/2022	|				|[Commit](https://mail-index.netbsd.org/source-changes/2020/10/27/msg123454.html)
-libXTrap	|X11 component		|10/2022	|				|[Commit](https://mail-index.netbsd.org/source-changes/2020/10/28/msg123478.html)
+libglut		|X11 component		|10/2020	|				|[Commit](https://mail-index.netbsd.org/source-changes/2020/10/25/msg123388.html)
+libXevie	|X11 component		|10/2020	|				|[Commit](https://mail-index.netbsd.org/source-changes/2020/10/27/msg123454.html)
+libXTrap	|X11 component		|10/2020	|				|[Commit](https://mail-index.netbsd.org/source-changes/2020/10/28/msg123478.html)
 ARM OABI	|Port ABI		|06/2021	|				|[Commit](https://mail-index.netbsd.org/source-changes/2021/06/07/msg130057.html)
 uscanner	|Device Driver		|06/2021	|				|[Commit](https://mail-index.netbsd.org/source-changes/2021/06/29/msg130513.html)
 xfwp		|X11 component		|02/2023	|				|[Commit](https://mail-index.netbsd.org/source-changes/2023/02/04/msg143143.html)

Index: wikisrc/attic_museum.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/attic_museum.mdwn,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- wikisrc/attic_museum.mdwn	2 Aug 2022 21:56:56 -0000	1.24
+++ wikisrc/attic_museum.mdwn	8 May 2024 11:16:47 -0000	1.25
@@ -46,6 +46,7 @@
 compat_ibcs2	|Compatibility Layer	|12/2018	|				|[Commit](https://mail-index.netbsd.org/source-changes/2018/12/29/msg101841.html)
 satlink		|Device Driver		|01/2019	|				|[Commit](https://mail-index.netbsd.org/source-changes/2019/01/27/msg102772.html)
 compat_osf1	|Compatibility Layer	|03/2019	|				|[Commit](https://mail-index.netbsd.org/source-changes/2019/03/25/msg104511.html)
+sup		|Utility		|10/2019	|				|[Commit 1](https://mail-index.netbsd.org/source-changes/2019/10/15/msg110000.html), [Commit 2](https://mail-index.netbsd.org/source-changes/2019/10/15/msg110001.html), [Commit 3](https://mail-index.netbsd.org/source-changes/2019/10/15/msg110002.html)
 uyurex		|Device Driver		|01/2020	|				|[Commit](http://mail-index.netbsd.org/source-changes/2020/01/17/msg112930.html)
 strip		|Network Driver		|01/2020	|				|[Commit](http://mail-index.netbsd.org/source-changes/2020/01/19/msg113009.html)
 esh		|Network Driver		|01/2020	|				|[Commit](https://mail-index.netbsd.org/source-changes/2020/01/19/msg113013.html)
@@ -56,12 +57,19 @@
 filemon		|Pseudo Device		|01/2020	|				|[Commit](https://mail-index.netbsd.org/source-changes/2020/01/19/msg113041.html)
 FDDI		|Network Protocol	|01/2020	|				|[Commit](https://mail-index.netbsd.org/source-changes/2020/01/20/msg113058.html)
 fpa		|Network Driver		|01/2020	|				|[Commit](https://mail-index.netbsd.org/source-changes/2020/01/20/msg113058.html)
-azalia		|Audio Driver		|02/2020	|				|[Commit](http://mail-index.netbsd.org/source-changes/2020/02/09/msg113848.html)
 urio		|Device Driver		|01/2020	|				|[Commit](http://mail-index.netbsd.org/source-changes/2020/01/29/msg113476.html)
+azalia		|Audio Driver		|02/2020	|				|[Commit](http://mail-index.netbsd.org/source-changes/2020/02/09/msg113848.html)
+smbfs		|File System		|04/2020	|				|[Userland Commit](https://mail-index.netbsd.org/source-changes/2020/04/04/msg115805.html), [Kernel Commit](https://mail-index.netbsd.org/source-changes/2020/04/04/msg115806.html)
+ISD-ATA		|Device Driver		|04/2020	|				|[Commit](https://mail-index.netbsd.org/source-changes/2020/04/13/msg116136.html)
 uyap		|Device Driver		|05/2020	|				|[Commit](http://mail-index.netbsd.org/source-changes/2020/05/16/msg117393.html)
 toasterlcd	|Device Driver		|05/2020	|				|[Commit](http://mail-index.netbsd.org/source-changes/2020/05/23/msg117603.html)
 toastersensors	|Device Driver		|05/2020	|				|[Commit](http://mail-index.netbsd.org/source-changes/2020/05/23/msg117602.html)
 TOASTER		|Kernel Config		|05/2020	|				|[Commit](http://mail-index.netbsd.org/source-changes/2020/05/23/msg117601.html)
+libglut		|X11 component		|10/2022	|				|[Commit](https://mail-index.netbsd.org/source-changes/2020/10/25/msg123388.html)
+libXevie	|X11 component		|10/2022	|				|[Commit](https://mail-index.netbsd.org/source-changes/2020/10/27/msg123454.html)
+libXTrap	|X11 component		|10/2022	|				|[Commit](https://mail-index.netbsd.org/source-changes/2020/10/28/msg123478.html)
+ARM OABI	|Port ABI		|06/2021	|				|[Commit](https://mail-index.netbsd.org/source-changes/2021/06/07/msg130057.html)
 uscanner	|Device Driver		|06/2021	|				|[Commit](https://mail-index.netbsd.org/source-changes/2021/06/29/msg130513.html)
+xfwp		|X11 component		|02/2023	|				|[Commit](https://mail-index.netbsd.org/source-changes/2023/02/04/msg143143.html)
+mkstr, xstr	|Utility		|05/2023	|				|[Commit](https://mail-index.netbsd.org/source-changes/2023/05/24/msg144918.html)
 """]]
-

Members: 
	ports/evbarm/beaglebone.mdwn:1.19->1.20 

Index: wikisrc/ports/evbarm/beaglebone.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/beaglebone.mdwn,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- wikisrc/ports/evbarm/beaglebone.mdwn	23 Dec 2018 02:46:57 -0000	1.19
+++ wikisrc/ports/evbarm/beaglebone.mdwn	7 May 2024 02:41:50 -0000	1.20
@@ -1,10 +1,12 @@
-[[!meta title="NetBSD/evbarm on BeagleBone, BeagleBone Black, and PocketBeagle"]]
+[[!meta title="NetBSD/evbarm on Beagle family"]]
 
 [[images/beaglebone.jpg]]
 
 This page attempts to document and coordinate efforts towards NetBSD on
 [BeagleBone](http://beagleboard.org/bone) ,
-[BeagleBone Black](http://beagleboard.org/black) , and
+[BeagleBone Black](http://beagleboard.org/black) , 
+[BeagleBone Green](https://beaglebone.io/green) ,
+BeagleBone White, and
 [PocketBeagle](http://beagleboard.org/pocket).
 
 (BeagleBone [image](http://www.flickr.com/photos/sparkfun/8267577194/) by
@@ -20,8 +22,8 @@
  - USB (host)
  - I²C
  - CPU frequency scaling (various speeds between 300MHz and 1GHz)
- - Random number generator [[!template id=man name="trng" section="4"]]
- - GPIO (<i>-current since Nov 1, 2015</i>)
+ - Random number generator [[!template id=man name="tirng" section="4"]]
+ - GPIO
 
 # TODO
  - SPI

Index: wikisrc/users/wiz/pkgsrc-migration.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/wiz/pkgsrc-migration.mdwn,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- wikisrc/users/wiz/pkgsrc-migration.mdwn	5 May 2024 17:38:38 -0000	1.15
+++ wikisrc/users/wiz/pkgsrc-migration.mdwn	5 May 2024 17:57:52 -0000	1.16
@@ -87,7 +87,39 @@
     origin/pkgsrc_2003Q4. Most don't differ at all, in the few cases
     where they do the `-` version looks better. So clean up the other ones:
 
-    `git branch -al | grep _ | while read a; do echo git branch -d "$a"; done`
+    `git branch -al | grep _ | grep -v pkg_install-renovation | while read a; do echo git branch -d "$a"; done`
+    - `pkgsrc-` is a misbranch of `pkgsrc-2017Q3`, delete it:
+
+      `git branch -d pkgsrc`
+    - `pkgsrc-pkgsrc-2019Q4` is a misbranch of `pkgsrc-2019Q4`, delete it:
+
+       `git branch -d pkgsrc-pkgsrc-2019Q4`
+    - some thirdparty software was sometimes imported, but we didn't continue with this process -- except for libarchive.
+
+      `git branch -d BMAKE BZIP2 MRENDEL ZLIB tnftp`
+
+      keep `KIENTZLE` (libarchive) or remove it?
+
+    - early in pkgsrc's development, packages were added from FreeBSD ports and imported to keep them in sync. This practice had stopped by 2005.
+
+      `git branch -d FREEBSD`
+    - A couple autoconf/automake files in pkgsrc/mk were imported on this in 2006 but later updates didn't use imports.
+
+      `git branch -d FSF`
+    - This was the branch that was used for all imports (i.e. package additions) until we stopped using `cvs import` for adding packages:
+
+      `git branch -d TNF`
+
+    - TODO `buildlink2`
+    - TODO `cube-native-xorg`
+    - TODO `cwrapper`
+    - TODO `jlam-pkgviews`
+    - TODO `pkg_install-renovation`
+    - TODO `pkgviews`
+    - TODO `pkgviews-mk`
+    - TODO `pkgviews`
+    - TODO `tv-derecurse`
+    - TODO `tv-libtool-1-5-18-tmpdirfix`
   - tag heads so no commits are lost? Other method?
 - add .gitattributes file for doc/
 - turn off CVS/anoncvs server

Index: wikisrc/users/wiz/pkgsrc-migration.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/wiz/pkgsrc-migration.mdwn,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- wikisrc/users/wiz/pkgsrc-migration.mdwn	4 May 2024 15:05:15 -0000	1.14
+++ wikisrc/users/wiz/pkgsrc-migration.mdwn	5 May 2024 17:38:38 -0000	1.15
@@ -82,6 +82,12 @@
 get lost otherwise)
 
 - delete old branches
+  - current conversion has some duplicate branches that only differ by
+    `_` vs. `-` in the names, e.g. origin/pkgsrc-2003Q4 and
+    origin/pkgsrc_2003Q4. Most don't differ at all, in the few cases
+    where they do the `-` version looks better. So clean up the other ones:
+
+    `git branch -al | grep _ | while read a; do echo git branch -d "$a"; done`
   - tag heads so no commits are lost? Other method?
 - add .gitattributes file for doc/
 - turn off CVS/anoncvs server

Index: wikisrc/users/wiz/pkgsrc-migration.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/wiz/pkgsrc-migration.mdwn,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- wikisrc/users/wiz/pkgsrc-migration.mdwn	4 May 2024 14:58:56 -0000	1.13
+++ wikisrc/users/wiz/pkgsrc-migration.mdwn	4 May 2024 15:05:15 -0000	1.14
@@ -14,18 +14,20 @@
     - no reply, so we'll take it as-is
 - DONE `doc/CHANGES-*`: add a `.gitattributes` file in `doc` with
 
-	CHANGES-* merge=union
+	`CHANGES-* merge=union`
 
 - DONE mailmap (mapping CVS Unix users to name and email - see localsrc/cvs_server/migration)
 - DONE mailmap needs to be applied
 
-	git filter-repo --force --mailmap $PATH_TO_MAILMAP
+	`git filter-repo --force --mailmap $PATH_TO_MAILMAP`
 
 - DONE rename trunk to main:
 
-	git branch main trunk
-	git switch main
-	git branch -d trunk
+	`git branch main trunk`
+
+    `git switch main`
+
+    `git branch -d trunk`
 
 
 git server

Index: wikisrc/users/wiz/pkgsrc-migration.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/wiz/pkgsrc-migration.mdwn,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- wikisrc/users/wiz/pkgsrc-migration.mdwn	4 May 2024 14:53:27 -0000	1.12
+++ wikisrc/users/wiz/pkgsrc-migration.mdwn	4 May 2024 14:58:56 -0000	1.13
@@ -14,18 +14,18 @@
     - no reply, so we'll take it as-is
 - DONE `doc/CHANGES-*`: add a `.gitattributes` file in `doc` with
 
-  CHANGES-* merge=union
+	CHANGES-* merge=union
 
 - DONE mailmap (mapping CVS Unix users to name and email - see localsrc/cvs_server/migration)
 - DONE mailmap needs to be applied
 
-    git filter-repo --force --mailmap $PATH_TO_MAILMAP
+	git filter-repo --force --mailmap $PATH_TO_MAILMAP
 
 - DONE rename trunk to main:
 
-    git branch main trunk
-    git switch main
-    git branch -d trunk
+	git branch main trunk
+	git switch main
+	git branch -d trunk
 
 
 git server

Index: wikisrc/users/wiz/pkgsrc-migration.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/wiz/pkgsrc-migration.mdwn,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- wikisrc/users/wiz/pkgsrc-migration.mdwn	4 May 2024 09:12:22 -0000	1.11
+++ wikisrc/users/wiz/pkgsrc-migration.mdwn	4 May 2024 14:53:27 -0000	1.12
@@ -7,17 +7,25 @@
 
 Either use the existing conversion, or make a new one using `wip/cvs2git`.
 
-(DONE in this section refers to the test repository.)
+(DONE in this section means we know how to do it.)
 
 - DONE conversion exists, but joerg wants to do a cleaned up version
-  - DONE (no reply) asked joerg if he's still interested in doing that
+  - asked joerg if he's still interested in doing that
+    - no reply, so we'll take it as-is
 - DONE `doc/CHANGES-*`: add a `.gitattributes` file in `doc` with
 
   CHANGES-* merge=union
 
-- DONE authormap (mapping CVS Unix users to name and email)
-- DONE authormap needs to be applied
-- DONE rename trunk to main
+- DONE mailmap (mapping CVS Unix users to name and email - see localsrc/cvs_server/migration)
+- DONE mailmap needs to be applied
+
+    git filter-repo --force --mailmap $PATH_TO_MAILMAP
+
+- DONE rename trunk to main:
+
+    git branch main trunk
+    git switch main
+    git branch -d trunk
 
 
 git server
@@ -37,7 +45,7 @@
 - DONE linear history: use hook script from pkgsrc-wip
 - DONE warning about merge conflict in commits
 - DONE warning about work directories included in commits
-- emails to GNATS when commits include magic pattern relating to a PR
+- DONE emails to GNATS when commits include magic pattern relating to a PR
 - DONE `pkg_add p5-MIME-Lite` for notifications
 - DONE branch support
 

Index: wikisrc/users/wiz/pkgsrc-migration.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/wiz/pkgsrc-migration.mdwn,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- wikisrc/users/wiz/pkgsrc-migration.mdwn	3 May 2024 14:44:52 -0000	1.10
+++ wikisrc/users/wiz/pkgsrc-migration.mdwn	4 May 2024 09:12:22 -0000	1.11
@@ -9,16 +9,15 @@
 
 (DONE in this section refers to the test repository.)
 
-- pkgsrc
-  - conversion exists, but joerg wants to do a cleaned up version
-    - asked joerg if he's still interested in doing that
-  - DONE `doc/CHANGES-*`: add a `.gitattributes` file in `doc` with
-
-    CHANGES-* merge=union
-
-  - DONE authormap (mapping CVS Unix users to name and email)
-  - DONE authormap needs to be applied
-  - DONE rename trunk to main
+- DONE conversion exists, but joerg wants to do a cleaned up version
+  - DONE (no reply) asked joerg if he's still interested in doing that
+- DONE `doc/CHANGES-*`: add a `.gitattributes` file in `doc` with
+
+  CHANGES-* merge=union
+
+- DONE authormap (mapping CVS Unix users to name and email)
+- DONE authormap needs to be applied
+- DONE rename trunk to main
 
 
 git server
@@ -29,8 +28,7 @@
 - new hardware?
   - no; use cvs and anoncvs machines
 - new DNS entry
-- public access:
-  - provide [[read-only git|https://github.com/netbsd/]] that's not on github
+- public access: provide read-only access that's not on github
 
 git server hooks
 ===
@@ -65,7 +63,7 @@
 - make git repository available to all developers
 - make pkgsrc CVS read-only
 - github
-  - after final conversion happens, either force-push or make a new repository and deprecate the old one
+  - after final conversion happens, either force-push or make a new repository and deprecate the old one, or remove completely?
 
 Post-Conversion
 ===
@@ -73,5 +71,7 @@
 CVS-to-git step is finalized, because they are manual work and would
 get lost otherwise)
 
-- nothing known right now?
+- delete old branches
+  - tag heads so no commits are lost? Other method?
+- add .gitattributes file for doc/
 - turn off CVS/anoncvs server

Index: wikisrc/users/wiz/pkgsrc-migration.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/wiz/pkgsrc-migration.mdwn,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- wikisrc/users/wiz/pkgsrc-migration.mdwn	3 May 2024 13:58:49 -0000	1.9
+++ wikisrc/users/wiz/pkgsrc-migration.mdwn	3 May 2024 14:44:52 -0000	1.10
@@ -38,7 +38,7 @@
 - DONE email notifications: use hook script from pkgsrc-wip
 - DONE linear history: use hook script from pkgsrc-wip
 - DONE warning about merge conflict in commits
-- warning about work directories included in commits
+- DONE warning about work directories included in commits
 - emails to GNATS when commits include magic pattern relating to a PR
 - DONE `pkg_add p5-MIME-Lite` for notifications
 - DONE branch support

Index: wikisrc/users/wiz/pkgsrc-migration.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/wiz/pkgsrc-migration.mdwn,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- wikisrc/users/wiz/pkgsrc-migration.mdwn	24 Apr 2024 12:53:40 -0000	1.8
+++ wikisrc/users/wiz/pkgsrc-migration.mdwn	3 May 2024 13:58:49 -0000	1.9
@@ -37,7 +37,7 @@
 
 - DONE email notifications: use hook script from pkgsrc-wip
 - DONE linear history: use hook script from pkgsrc-wip
-- warning about merge conflict in commits
+- DONE warning about merge conflict in commits
 - warning about work directories included in commits
 - emails to GNATS when commits include magic pattern relating to a PR
 - DONE `pkg_add p5-MIME-Lite` for notifications

Index: wikisrc/laptops.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/laptops.mdwn,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- wikisrc/laptops.mdwn	3 May 2024 09:24:38 -0000	1.35
+++ wikisrc/laptops.mdwn	3 May 2024 12:45:37 -0000	1.36
@@ -13,9 +13,10 @@
 
 ## Graphics
 
-NetBSD 9.0 supports Intel integrated graphics up to Kaby Lake,
-Nvidia graphics up to Maxwell, and AMD graphics up to GCNv1.
-NetBSD 10.0 supports Intel integrated graphics up to Tiger Lake.
+NetBSD 9.0 supports Intel integrated graphics up to (including)
+Kaby Lake, Nvidia graphics up to Maxwell, and AMD graphics up to GCNv1.
+NetBSD 10.0 supports Intel integrated graphics up to Tiger Lake
+and Nvidia graphics up to Pascal.
 
 Anything newer than this will work, but will use `llvmpipe`
 instead of hardware acceleration for OpenGL.

Index: wikisrc/laptops.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/laptops.mdwn,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- wikisrc/laptops.mdwn	26 Jan 2022 16:32:57 -0000	1.34
+++ wikisrc/laptops.mdwn	3 May 2024 09:24:38 -0000	1.35
@@ -15,6 +15,7 @@
 
 NetBSD 9.0 supports Intel integrated graphics up to Kaby Lake,
 Nvidia graphics up to Maxwell, and AMD graphics up to GCNv1.
+NetBSD 10.0 supports Intel integrated graphics up to Tiger Lake.
 
 Anything newer than this will work, but will use `llvmpipe`
 instead of hardware acceleration for OpenGL.

Index: wikisrc/users/spz/admin.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/spz/admin.mdwn,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- wikisrc/users/spz/admin.mdwn	11 Jun 2023 15:33:13 -0000	1.13
+++ wikisrc/users/spz/admin.mdwn	1 May 2024 17:06:46 -0000	1.14
@@ -1,23 +1,23 @@
 this contains a random collection of info about the NetBSD.org servers. Unless specified they are at TastyLime and owned by TNF.
 Note the time of last commit, the info may be seriously out of date.
 
-we currently (2018-12-23) have:
+we currently (2024-05-01) have:
 
 public services:
 
 - homeworld (mail.NetBSD.org, ns.NetBSD.org)<br>
   That's a standard postfix with gld, amavisd, spamassassin for mail, a majordomo with a few local patches (and the despamming patterns from hell), plus bind for the nameservice.
 
-- mollari (wiki.NetBSD.org, releng.NetBSD.org, www.NetBSD.org, gnats.NetBSD.org, mail-index.NetBSD.org)<br>
+- mollari (wiki.NetBSD.org, releng.NetBSD.org, gnats.NetBSD.org, back-end for www.NetBSD.org and mail-index.NetBSD.org which are on the Fastly CDN)<br>
   Apache, with ikiwiki for this wiki, plus req for the releng site, gnats, and a very much hacked upon mhonarc
 
 - vir (blog.NetBSD.org, monitor.NetBSD.org, rt.NetBSD.org)<br>
-  Apache, with Apache Roller on tomcat on native openjdk8 for blog, Xymon for monitor and rt (what a surprise :) ) for rt. rt is used as coordination tool of a few teams and restricted to members of those teams.
+  Apache, with Apache Roller on tomcat on native openjdk for blog, Xymon for monitor and rt (what a surprise :) ) for rt. rt is used as coordination tool of a few teams and restricted to members of those teams.
 
-- morden (ftp.NetBSD.org, rsync.NetBSD.org)<br>
+- morden (ftp.NetBSD.org, rsync.NetBSD.org, back-end for cdn.NetBSD.org)<br>
   the ftp, http and rsync function themselves are fairly straightforward. It runs a few automatic updates for the src and pkgsrc regions that generate the daily CVS update mails and do a bunch of checks on pkgsrc, too.
 
-- nyftp.NetBSD.org<br>
+- nyftp.NetBSD.org (back-end for nycdn.NetBSD.org)<br>
   ftp, http and rsync, fairly dumb. It's situated at Columbia University, hence the 'ny' in the name
 
 - anoncvs.NetBSD.org<br>
@@ -35,46 +35,40 @@
   the master Mercurial repository, experimental; only developers (TNF members) with valid account auth can connect here.
 
 - build.NetBSD.org (aka b45) + b41-b48<br>
-  build is the master/coordinator of the build slaves, and they produce the NetBSD-daily contents (situated at Columbia University)
-
-- pkgbuild.NetBSD.org<br>
-  that's a Xen dom0 running domUs which pbulk-build pkgsrc-stable packages for supported NetBSD releases for amd64 and i386 (also at Columbia University)
-
-- armbulk1.NetBSD.org and armbulk2.NetBSD.org<br>
-  two Jetson TK1 running NetBSD-8/evbarm-earmv7hf building earmv6hf and earmv7hf packages.
+  build is the coordinator/manager of the build workers, and they produce the NetBSD-daily contents (situated at Columbia University)
 
 - franklin.NetBSD.org<br>
   the backup server, basically lots'o disk storing encrypted dumps
 
-- babylon5.NetBSD.org<br>
-  most of the TNF-run anita checks run here
-
-- lyta.NetBSD.org<br>
-  situated at WWU, runs even more anita checks
+- babylon4.NetBSD.org @WWU, babylon5.NetBSD.org @Regensburg<br>
+  the TNF-run anita checks run on these
 
 - sheridan.NetBSD.org<br>
-  Xen server running mollari, vir, and a few smaller administrative functions
+  Xen server running vir, and a few smaller administrative functions
 
 - xenhost.NetBSD.org<br>
-  Xen server running hg and anonhg, the experiment-with-Mercurial systems
-
-- talia.NetBSD.org<br>
-  situated at WWU, kamil@ uses it for lldb buildbot et al
+  Xen server running mollari, hg and anonhg, the experiment-with-Mercurial systems
 
 - lochley.NetBSD.org<br>
   situated at WWU, runs the repo conversions under joerg@'s direction
 
-- shadow.NetBSD.org<br>
-  Xen server situated at WWU, just has a dom0 right now
+- tessa.NetBSD.org<br>
+  a webserver for finance-exec situated at WWU
 
-- byron.NetBSD.org<br>
-  Xen server situated at WWU, runs the "scanner" VM
+- shadow.NetBSD.org<br>
+  the i386 + x86_64, 9.0 + 10.0 package builder situated at WWU
 
-- ironheart.NetBSD.org<br>
-  situated at WWU, currently off because it beeps and annoys people working in the server room it's housed in. May have a failed fan.
+- victory.NetBSD.org<br>
+  the evbarm* and aarch64 package builder situated at WWU
 
 - console servers at TastyLime, Columbia University and WWU<br>
   these are small devices (two of them evbarm-based) with USB2Serials and conserver8. conserver is most approved :)
 
 - cole.NetBSD.de<br>
   off-site, off-continent backup for the most precious data in case ca.us gets the big one. Racked at Regensburg, Germany, owned by spz@
+
+- archive.NetBSD.de<br>
+  back-end for archive.NetBSD.org, a VM on cole
+
+- wip.pkgsrc.org<br>
+  the git server for pkgsrc-WIP, a VM on cole

Members: 
	global.css:1.32->1.33 

Index: wikisrc/global.css
===================================================================
RCS file: /cvsroot/wikisrc/global.css,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -r1.32 -r1.33
--- wikisrc/global.css	26 Apr 2021 14:30:07 -0000	1.32
+++ wikisrc/global.css	27 Apr 2024 06:39:45 -0000	1.33
@@ -1,4 +1,4 @@
-/* $NetBSD: global.css,v 1.32 2021/04/26 14:30:07 nia Exp $ */
+/* $NetBSD: global.css,v 1.33 2024/04/27 06:39:45 rillig Exp $ */
 
 /* Remember to keep htdocs/globals.css and wikisrc/globals.css in sync. */
 /* See https://wiki.NetBSD.org/wiki/cvs/. */
@@ -190,11 +190,15 @@
 }
 
 #content p {
-  line-height: 1.3em;
   margin: 1em 0 1.5em 0;
   padding: 0;
 }
 
+#content p,
+#content li {
+  line-height: 1.3em;
+}
+
 #platinumDonorLogo {
   text-align: left;
   width: 150px;