Members: 
	ports/xen/howto.mdwn:1.213->1.214 

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.213
retrieving revision 1.214
diff -u -r1.213 -r1.214
--- wikisrc/ports/xen/howto.mdwn	7 Dec 2023 12:54:50 -0000	1.213
+++ wikisrc/ports/xen/howto.mdwn	7 Dec 2023 17:25:52 -0000	1.214
@@ -115,7 +115,10 @@
 """]]
 
 As of December 2023, 4.18 was relatively new and 4.15 is known to work
-well.
+well.  In particular, 4.18 has only been tested on -current, is
+expected to work on netbsd-10, may be problematic on netbsd-9 and
+probably will not work on netbsd-8.  Therefore, using 4.15 is the
+standard approach.
 
 See also the [Xen Security Advisory page](http://xenbits.xen.org/xsa/).
 

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.212
retrieving revision 1.213
diff -u -r1.212 -r1.213
--- wikisrc/ports/xen/howto.mdwn	24 Aug 2023 23:08:39 -0000	1.212
+++ wikisrc/ports/xen/howto.mdwn	7 Dec 2023 12:54:50 -0000	1.213
@@ -104,21 +104,23 @@
 but note that both packages must be installed together and must have
 matching versions.
 
-Versions available in pkgsrc:
+Of the [versions released by
+upstream](https://xenbits.xen.org/docs/unstable/support-matrix.html),
+a subset are available in pkgsrc:
 
 [[!table data="""
-Xen Version	|Package Name	|Xen CPU Support	|EOL'ed By Upstream
-4.13		|xenkernel413	|x86_64			|YES - last update 2022-12-19
-4.15		|xenkernel415	|x86_64			|NO
+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.13 is EOL and will be removed from pkgsrc soon after 2023Q3 is
-branched.  Anyone using it should immediately begin migrating to 4.15.
+As of December 2023, 4.18 was relatively new and 4.15 is known to work
+well.
 
 See also the [Xen Security Advisory page](http://xenbits.xen.org/xsa/).
 
-Older Xen had a python-based management tool called xm; this has long
-since been replaced by xl and is not discussed further.
+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
 
@@ -144,9 +146,9 @@
 multiple CPUs if provided.  The XEN3_DOMU kernel is built
 with "options MULITPROCESSOR".
 
-Note that while Xen 4.15 is current, the kernel support is still
-called XEN3, because the hypercall interface has not changed
-significantly.
+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.
 
 # Creating a NetBSD dom0
 

Index: wikisrc/security/cgdroot.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/security/cgdroot.mdwn,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- wikisrc/security/cgdroot.mdwn	24 Mar 2019 20:00:04 -0000	1.19
+++ wikisrc/security/cgdroot.mdwn	27 Nov 2023 18:40:04 -0000	1.20
@@ -1,5 +1,7 @@
 [[!meta title="Root Filesystem Encryption"]]
 
+**NOTE:** This page is outdated -- it should use the `fs cgdroot.fs` directive in [[!template id=man name="boot.cfg" section="5"]], rather than a custom-built miniroot kernel module with the ramdisk embedded.  Please update me to do that!
+
 It is possible to run NetBSD with [complete root filesystem encryption][1], thanks to the `cgdroot.kmod` kernel module. It really is a memory disk (also knows as RAM disk) that is expected to be loaded in the kernel while booting. It is named after CGD, the "cryptographic device driver", which implements encryption for storage in the NetBSD kernel.
 
 The mechanism described here still requires one unencrypted partition to boot from (typically `wd0a`). Full disk encryption would make it more difficult for an attacker to modify the unencrypted part of the disk to plant a backdoor. With only partial encryption, the original [[!template id=man name="cgdconfig" section="8"]] binary may be modified to send the passphrase away, allowing an attacker with a disk dump to recover the data.

Index: wikisrc/users/jun.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/jun.mdwn,v
retrieving revision 1.136
retrieving revision 1.137
diff -u -r1.136 -r1.137
--- wikisrc/users/jun.mdwn	10 Nov 2023 15:16:02 -0000	1.136
+++ wikisrc/users/jun.mdwn	27 Nov 2023 04:06:16 -0000	1.137
@@ -4,12 +4,40 @@
 
 # 2023
 
-## Kansai Open Forum 2023
+## Open Source Conference 2023 Fukuoka NetBSD Booth&BoF
+- 2023 Dec.9 Sat 10:00-18:00 JST (UTC+9) 
+- Fukuoka Soft Research Park [[https://www.fukuoka-srp.co.jp/]]
+- [[https://event.ospn.jp/osc2023-fukuoka/]]
+- Tour Guide [[]]
+- togetter [[]]
+
+# Nagoya *BSD Users' Group monthly meeting
+- [[http://nagoya.bug.gr.jp/]]
+
+#2024
+
+## Open Source Conference 2024 Osaka NetBSD Booth&BoF
+- 2024 Jan.27 Sat 10:00-18:00 JST (UTC+9) 
+- Osaka Sangyo Sozoukan  [[https://www.sansokan.jp/map/]]
+- [[https://event.ospn.jp/osc2024-osaka/]]
+- Tour Guide [[]]
+- togetter [[]]
+
+## Kansai Open Forum 2024
 - [[https://www.k-of.jp/]]
-- 2023 Nov.10 Fri. - Nov.11 Sat.
+- 2024 Nov.8 Fri. - Nov.9 Sat.
 - Booth and BSD BoF
-- Tour Guide [[https://cdn.netbsd.org/pub/NetBSD/misc/jun/OSC/KOF2023.pdf]]
-- togetter [[https://togetter.com/li/2254094]]
+- Tour Guide [[]]
+- togetter [[]]
+
+# Past Events in 2023
+
+## Open Source Conference 2023 Niigata NetBSD Booth&BoF
+- 2022 Nov.12 Sun 10:00-18:00 JST (UTC+9) 
+- Niigata City Public Library [[https://www.niigatacitylib.jp/?page_id=166]]
+- [[https://event.ospn.jp/osc2023-niigata/]]
+- Tour Guide [[https://cdn.netbsd.org/pub/NetBSD/misc/jun/OSC/OSC2023niigata.pdf]]
+- togetter [[https://togetter.com/li/2260623]]
 
 ## Open Source Conference 2023 Hiroshima NetBSD Booth&BoF
 - 2022 Nov.12 Sun 10:00-18:00 JST (UTC+9) 
@@ -17,11 +45,16 @@
 - [[https://event.ospn.jp/osc2023-hiroshima/]]
 - Tour Guide [[https://cdn.netbsd.org/pub/NetBSD/misc/jun/OSC/OSC2023hiroshima.pdf]]
 - togetter [[https://togetter.com/li/2254094]]
+- [[https://speakerdeck.com/tsutsui/kof2023]]
+- [[http://www.pastel-flower.jp/~isaki/NetBSD/osc23hi/]]
 
-# Nagoya *BSD Users' Group monthly meeting
-- [[http://nagoya.bug.gr.jp/]]
-
-# Past Events in 2023
+## Kansai Open Forum 2023
+- [[https://www.k-of.jp/]]
+- 2023 Nov.10 Fri. - Nov.11 Sat.
+- Booth and BSD BoF
+- Tour Guide [[https://cdn.netbsd.org/pub/NetBSD/misc/jun/OSC/KOF2023.pdf]]
+- togetter [[https://togetter.com/li/2254094]]
+- [[https://speakerdeck.com/tsutsui/kof2023]]
 
 ## Open Source Conference 2023 Shimane NetBSD Booth
 - 2023 Oct.28 Sat 10:00-17:30 JST (UTC+9)

Index: wikisrc/releng/netbsd-10.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/releng/netbsd-10.mdwn,v
retrieving revision 1.98
retrieving revision 1.99
diff -u -r1.98 -r1.99
--- wikisrc/releng/netbsd-10.mdwn	21 Oct 2023 09:12:07 -0000	1.98
+++ wikisrc/releng/netbsd-10.mdwn	11 Nov 2023 11:28:31 -0000	1.99
@@ -99,7 +99,7 @@
 
 ## Ongoing projects and unmerged branches
 
-* [Wifi renewal on hg](/Wifi_renewal_on_hg) - will not make it into mainline before the branch, but is planned to be merged into -current shortly after branching for netbsd-10
+* [Wifi renewal on hg](/Wifi_renewal_on_hg) - will not make it into mainline before the branch, but is planned to be merged into -current soon.
 * ~~[Updating drmkms to Linux 5.6](https://github.com/riastradh/netbsd-src/tree/redrm56) - has been merged to HEAD~~
 * [Removing PF](http://mail-index.netbsd.org/tech-kern/2019/04/04/msg024986.html) - will not happen before the branch
 	- pf was deprecated in 9 so it could be removed in 10.
@@ -122,9 +122,8 @@
 
 ## Current status and timeline
 
-* we seem to be close to what we realistically can get for 10.0
-* we plan switching to release candidate state in the last week of september
-* if all goes well, this could result in a 10.0 release mid october
+* 10.0 release candidate 1 is available
+* the 10.0 release is planed for the last week of november if nothing bad happens and we would need another RC
 
 ## Last netbsd-10 Test Results overview
 For all tests, see [releng's tests page](//releng.netbsd.org/test-results.html).
@@ -136,19 +135,19 @@
   <tbody>
     <tr>
         <td><a href="//www.netbsd.org/~martin/aarch64-atf-netbsd10/">aarch64</a>, real hardware</td>
-        <td>2023-09-08</td><td>3</td><td> </td>
+        <td>2023-11-03</td><td>0</td><td> </td>
     </tr>
     <tr>
         <td><a href="//www.netbsd.org/~martin/sparc64-atf-netbsd10/">sparc64</a>, real hardware</td>
-        <td>2023-09-08</td><td>7</td><td> </td>
+        <td>2023-11-03</td><td>4</td><td> </td>
     </tr>
     <tr>
         <td><a href="//www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/netbsd-10/">xen</a></td>
-        <td>2023-09-05</td> <td>8</td><td></td>
+        <td>2023-11-07</td> <td>3</td><td></td>
     </tr>
     <tr>
         <td><a href="//www.netbsd.org/~martin/evbarm-atf-netbsd10/">evbarm</a>, real hardware</td>
-        <td>2023-09-08</td><td>77</td><td></td>
+        <td>2023-11-03</td><td>75</td><td><small>(similar to HEAD numbers, mostly caused by softfloat and specific evbarm issues)</small></td>
     </tr>
   </tbody>
 </table>

Index: wikisrc/users/jun.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/jun.mdwn,v
retrieving revision 1.135
retrieving revision 1.136
diff -u -r1.135 -r1.136
--- wikisrc/users/jun.mdwn	10 Nov 2023 15:11:58 -0000	1.135
+++ wikisrc/users/jun.mdwn	10 Nov 2023 15:16:02 -0000	1.136
@@ -8,15 +8,15 @@
 - [[https://www.k-of.jp/]]
 - 2023 Nov.10 Fri. - Nov.11 Sat.
 - Booth and BSD BoF
-- Tour Guide [[]]
-- togetter [[]]
+- Tour Guide [[https://cdn.netbsd.org/pub/NetBSD/misc/jun/OSC/KOF2023.pdf]]
+- togetter [[https://togetter.com/li/2254094]]
 
 ## Open Source Conference 2023 Hiroshima NetBSD Booth&BoF
 - 2022 Nov.12 Sun 10:00-18:00 JST (UTC+9) 
 - Satellite Campus Hiroshima [[https://www.pu-hiroshima.ac.jp/site/satellite/accessmap.html]]
 - [[https://event.ospn.jp/osc2023-hiroshima/]]
-- Tour Guide [[]]
-- togetter [[]]
+- Tour Guide [[https://cdn.netbsd.org/pub/NetBSD/misc/jun/OSC/OSC2023hiroshima.pdf]]
+- togetter [[https://togetter.com/li/2254094]]
 
 # Nagoya *BSD Users' Group monthly meeting
 - [[http://nagoya.bug.gr.jp/]]

Index: wikisrc/users/jun.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/jun.mdwn,v
retrieving revision 1.134
retrieving revision 1.135
diff -u -r1.134 -r1.135
--- wikisrc/users/jun.mdwn	23 Oct 2023 02:47:40 -0000	1.134
+++ wikisrc/users/jun.mdwn	10 Nov 2023 15:11:58 -0000	1.135
@@ -4,13 +4,6 @@
 
 # 2023
 
-## Open Source Conference 2023 Shimane NetBSD Booth
-- 2023 Oct.28 Sat 10:00-17:30 JST (UTC+9)
-- Matsue Terrsa 4f, Shimane ,Japan
-- [[https://event.ospn.jp/osc2023-shimane/]]
-- Tour Guide [[]]
-- togetter [[]]
-
 ## Kansai Open Forum 2023
 - [[https://www.k-of.jp/]]
 - 2023 Nov.10 Fri. - Nov.11 Sat.
@@ -30,6 +23,13 @@
 
 # Past Events in 2023
 
+## Open Source Conference 2023 Shimane NetBSD Booth
+- 2023 Oct.28 Sat 10:00-17:30 JST (UTC+9)
+- Matsue Terrsa 4f, Shimane ,Japan
+- [[https://event.ospn.jp/osc2023-shimane/]]
+- Tour Guide [[https://cdn.netbsd.org/pub/NetBSD/misc/jun/OSC/OSC2023shimane.pdf]]
+- togetter [[https://togetter.com/li/2247549]]
+
 ## Open Source Conference 2023 Tokyo/Fall NetBSD Booth
 - 2023 Oct.21 Sat 10:00-16:00 JST (UTC+9)
 - Ota City Industrial Plaza (PiO) [[https://www.pio-ota.net/english-access/]]

Index: wikisrc/users/jun.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/jun.mdwn,v
retrieving revision 1.133
retrieving revision 1.134
diff -u -r1.133 -r1.134
--- wikisrc/users/jun.mdwn	3 Oct 2023 01:30:21 -0000	1.133
+++ wikisrc/users/jun.mdwn	23 Oct 2023 02:47:40 -0000	1.134
@@ -4,11 +4,10 @@
 
 # 2023
 
-## Open Source Conference 2023 Tokyo/Fall NetBSD Booth
-- 2023 Oct.21 Sat 10:00-16:00 JST (UTC+9)
-- Ota City Industrial Plaza (PiO) [[https://www.pio-ota.net/english-access/]]
-- [[https://event.ospn.jp/osc2023-fall/]]
-- [[https://ospn.connpass.com/event/295184]]
+## Open Source Conference 2023 Shimane NetBSD Booth
+- 2023 Oct.28 Sat 10:00-17:30 JST (UTC+9)
+- Matsue Terrsa 4f, Shimane ,Japan
+- [[https://event.ospn.jp/osc2023-shimane/]]
 - Tour Guide [[]]
 - togetter [[]]
 
@@ -31,6 +30,14 @@
 
 # Past Events in 2023
 
+## Open Source Conference 2023 Tokyo/Fall NetBSD Booth
+- 2023 Oct.21 Sat 10:00-16:00 JST (UTC+9)
+- Ota City Industrial Plaza (PiO) [[https://www.pio-ota.net/english-access/]]
+- [[https://event.ospn.jp/osc2023-fall/]]
+- [[https://ospn.connpass.com/event/295184]]
+- Tour Guide [[https://cdn.netbsd.org/pub/NetBSD/misc/jun/OSC/OSC2023tokyofall.pdf]]
+- togetter [[https://togetter.com/li/2240886]]
+
 ## Open Source Conference 2023 Online/Fall BSD BoF
 - 2022 Sep.30 Sat 14:00-14:45 JST (UTC+9) 
 - [[https://event.ospn.jp/osc2023-online-fall/session/1098479]]

Index: wikisrc/releng/netbsd-10.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/releng/netbsd-10.mdwn,v
retrieving revision 1.97
retrieving revision 1.98
diff -u -r1.97 -r1.98
--- wikisrc/releng/netbsd-10.mdwn	14 Sep 2023 10:55:15 -0000	1.97
+++ wikisrc/releng/netbsd-10.mdwn	21 Oct 2023 09:12:07 -0000	1.98
@@ -40,7 +40,7 @@
 * [[!template id=pr number=56815]]: Lenovo ThinkCentre with i915drmkms graphics fails to boot
 * [[!template id=pr number=56901]]: i915: Asynchronous wait on fence timed out (slowly dying X server)
 * [[!template id=pr number=56997]]: i915 framebuffer only shows a few dotted lines at the top
-* [[!template id=pr number=57059]]: amdgpu graphics ring test failing
+* ~~[[!template id=pr number=57059]]: amdgpu graphics ring test failing~~
 * [[!template id=pr number=57142]]: firefox-107.0.1 crashes on startup sometimes crashing 10.0_BETA along with it
 * [[!template id=pr number=57143]]: Screen rotation causes loss of acceleration on i915
 * [[!template id=pr number=57182]]: nouveau doesn't switches LVDS on

Index: wikisrc/ports/sparc64/sparc64sun4v.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/sparc64/sparc64sun4v.mdwn,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- wikisrc/ports/sparc64/sparc64sun4v.mdwn	12 Oct 2023 17:37:27 -0000	1.9
+++ wikisrc/ports/sparc64/sparc64sun4v.mdwn	12 Oct 2023 17:40:58 -0000	1.10
@@ -19,7 +19,9 @@
 ### Network
 Setup a boot environment with TFTP, DHCP and NFS as described in <https://www.netbsd.org/docs/network/netboot/>.  
 Note that the instruction might be a bit outdated, so some notes are present here: <https://mail-index.netbsd.org/netbsd-docs/2020/10/29/msg000560.html> and <https://mail-index.netbsd.org/netbsd-docs/2020/10/31/msg000561.html>.  
-The root filesystem served by the NFS server can be populated by extracting the sets from the sparc64/binary/sets directory.
+The root filesystem served by the NFS server can be populated by extracting the sets from the sparc64/binary/sets directory.  
+Issue a 'boot net:dhcp' command to boot from the network.
+
 ## On emulated hardware
 ### QEMU
 Can be used for basic verification of the kernel.  

Index: wikisrc/ports/sparc64/sparc64sun4v.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/sparc64/sparc64sun4v.mdwn,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- wikisrc/ports/sparc64/sparc64sun4v.mdwn	11 Oct 2023 18:44:27 -0000	1.8
+++ wikisrc/ports/sparc64/sparc64sun4v.mdwn	12 Oct 2023 17:37:27 -0000	1.9
@@ -1,5 +1,5 @@
 # Goal
-Make NetBSD/sparc64 run on all sun4v-based systems.
+Make NetBSD/sparc64 run on sun4v-based systems.
 
 # Status
 Currently (as of 2023-10-10) the kernel boots fine using a single CPU (ignoring any additional available CPUs).  
@@ -17,7 +17,7 @@
 Oracle documentation for the logical domain is here: <https://docs.oracle.com/en/virtualization/oracle-vm-server-sparc/index.html>  
 OpenBSD has some notes on using the logical domain feature here: <https://undeadly.org/cgi?action=article;sid=20121214153413> and <https://flak.tedunangst.com/post/OpenBSD-on-a-Sun-T5120>
 ### Network
-Setup a boot environment with RARP, TFTP, DHCP and NFS as described in <https://www.netbsd.org/docs/network/netboot/>.  
+Setup a boot environment with TFTP, DHCP and NFS as described in <https://www.netbsd.org/docs/network/netboot/>.  
 Note that the instruction might be a bit outdated, so some notes are present here: <https://mail-index.netbsd.org/netbsd-docs/2020/10/29/msg000560.html> and <https://mail-index.netbsd.org/netbsd-docs/2020/10/31/msg000561.html>.  
 The root filesystem served by the NFS server can be populated by extracting the sets from the sparc64/binary/sets directory.
 ## On emulated hardware
@@ -25,7 +25,7 @@
 Can be used for basic verification of the kernel.  
 Information is available here: <https://wiki.qemu.org/Documentation/Platforms/SPARC> and <http://tyom.blogspot.com/search?q=niagara>.  
 Note that the 'niagara' is required machine type.  
-Use the NetBSD miniroot filesystem to replace the Solaris 10 image from the opensparc distribution.
+Use the NetBSD miniroot filesystem to replace the Solaris 10 image from the opensparc distribution <https://www.oracle.com/servers/technologies/opensparc-overview.html>.
 
 
 

Index: wikisrc/ports/sparc64.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/sparc64.mdwn,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -r1.36 -r1.37
--- wikisrc/ports/sparc64.mdwn	10 Oct 2023 17:55:40 -0000	1.36
+++ wikisrc/ports/sparc64.mdwn	11 Oct 2023 18:56:37 -0000	1.37
@@ -69,7 +69,7 @@
 """
 unsupported_hardware="""
 * Systems with an UltraSPARC IV CPU (unknown; may work)
-* Systems based on the sun4v architecture (CPUs: T1, T2, T3, T4, T5, M5, M6, M7, M8, S7) (in-progress)
+* Systems based on the sun4v architecture (CPUs: T1, T2, T3, T4, T5, M5, M6, M7, M8, S7) (in-progress - see <https://wiki.netbsd.org/ports/sparc64/sparc64sun4v/>)
 * Systems with a Fujitsu SPARC64 CPU (in-progress)
 * Smart card readers
 """

Index: wikisrc/projects/project/sun4v.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/sun4v.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/projects/project/sun4v.mdwn	27 Feb 2014 08:23:21 -0000	1.3
+++ wikisrc/projects/project/sun4v.mdwn	11 Oct 2023 18:53:55 -0000	1.4
@@ -14,7 +14,7 @@
 It would be nice to support these newer highly SMP processors from Sun.  A Linux
 port already exists, and Sun has contributed code to the FOSS community.
 
-(Some work has already been done and committed.)
+(Some work has already been done and committed - see <https://wiki.netbsd.org/ports/sparc64/sparc64sun4v/>
 
 """
 ]]

Index: wikisrc/ports/sparc64/sparc64sun4v.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/sparc64/sparc64sun4v.mdwn,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- wikisrc/ports/sparc64/sparc64sun4v.mdwn	11 Oct 2023 18:42:15 -0000	1.7
+++ wikisrc/ports/sparc64/sparc64sun4v.mdwn	11 Oct 2023 18:44:27 -0000	1.8
@@ -25,6 +25,7 @@
 Can be used for basic verification of the kernel.  
 Information is available here: <https://wiki.qemu.org/Documentation/Platforms/SPARC> and <http://tyom.blogspot.com/search?q=niagara>.  
 Note that the 'niagara' is required machine type.  
+Use the NetBSD miniroot filesystem to replace the Solaris 10 image from the opensparc distribution.
 
 
 

Index: wikisrc/ports/sparc64/sparc64sun4v.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/sparc64/sparc64sun4v.mdwn,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- wikisrc/ports/sparc64/sparc64sun4v.mdwn	11 Oct 2023 18:15:38 -0000	1.6
+++ wikisrc/ports/sparc64/sparc64sun4v.mdwn	11 Oct 2023 18:42:15 -0000	1.7
@@ -22,7 +22,11 @@
 The root filesystem served by the NFS server can be populated by extracting the sets from the sparc64/binary/sets directory.
 ## On emulated hardware
 ### QEMU
-TBD
+Can be used for basic verification of the kernel.  
+Information is available here: <https://wiki.qemu.org/Documentation/Platforms/SPARC> and <http://tyom.blogspot.com/search?q=niagara>.  
+Note that the 'niagara' is required machine type.  
+
+
 
 
 

Index: wikisrc/ports/sparc64/sparc64sun4v.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/sparc64/sparc64sun4v.mdwn,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- wikisrc/ports/sparc64/sparc64sun4v.mdwn	11 Oct 2023 17:35:43 -0000	1.5
+++ wikisrc/ports/sparc64/sparc64sun4v.mdwn	11 Oct 2023 18:15:38 -0000	1.6
@@ -9,7 +9,7 @@
 
 # Running
 ## On real hardware
-### CD-ROM/DVD
+### CD-ROM
 Create an install disc from the official ISO image and issue a 'boot cdrom' command from OpenBoot,
 ### Miniroot
 If the sun4v system has more than one logical domain configured, a secondary logical domain can use the 'miniroot' image as a virtual disk to boot from.  
@@ -17,7 +17,9 @@
 Oracle documentation for the logical domain is here: <https://docs.oracle.com/en/virtualization/oracle-vm-server-sparc/index.html>  
 OpenBSD has some notes on using the logical domain feature here: <https://undeadly.org/cgi?action=article;sid=20121214153413> and <https://flak.tedunangst.com/post/OpenBSD-on-a-Sun-T5120>
 ### Network
-TBD
+Setup a boot environment with RARP, TFTP, DHCP and NFS as described in <https://www.netbsd.org/docs/network/netboot/>.  
+Note that the instruction might be a bit outdated, so some notes are present here: <https://mail-index.netbsd.org/netbsd-docs/2020/10/29/msg000560.html> and <https://mail-index.netbsd.org/netbsd-docs/2020/10/31/msg000561.html>.  
+The root filesystem served by the NFS server can be populated by extracting the sets from the sparc64/binary/sets directory.
 ## On emulated hardware
 ### QEMU
 TBD

Index: wikisrc/ports/sparc64/sparc64sun4v.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/sparc64/sparc64sun4v.mdwn,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- wikisrc/ports/sparc64/sparc64sun4v.mdwn	11 Oct 2023 17:33:41 -0000	1.4
+++ wikisrc/ports/sparc64/sparc64sun4v.mdwn	11 Oct 2023 17:35:43 -0000	1.5
@@ -22,3 +22,6 @@
 ### QEMU
 TBD
 
+
+
+

Index: wikisrc/ports/sparc64/sparc64sun4v.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/sparc64/sparc64sun4v.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/ports/sparc64/sparc64sun4v.mdwn	11 Oct 2023 17:31:14 -0000	1.3
+++ wikisrc/ports/sparc64/sparc64sun4v.mdwn	11 Oct 2023 17:33:41 -0000	1.4
@@ -13,7 +13,7 @@
 Create an install disc from the official ISO image and issue a 'boot cdrom' command from OpenBoot,
 ### Miniroot
 If the sun4v system has more than one logical domain configured, a secondary logical domain can use the 'miniroot' image as a virtual disk to boot from.  
-Configuration of secondary virtual domain can be done by running e.g. Solaris 11.3/11.4 or OpenBSD as the primary logical machine.  
+Configuration of secondary virtual domain can be done by running e.g. Solaris 11.3/11.4 or OpenBSD as the primary logical domain.  
 Oracle documentation for the logical domain is here: <https://docs.oracle.com/en/virtualization/oracle-vm-server-sparc/index.html>  
 OpenBSD has some notes on using the logical domain feature here: <https://undeadly.org/cgi?action=article;sid=20121214153413> and <https://flak.tedunangst.com/post/OpenBSD-on-a-Sun-T5120>
 ### Network

Index: wikisrc/ports/sparc64/sparc64sun4v.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/sparc64/sparc64sun4v.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/ports/sparc64/sparc64sun4v.mdwn	10 Oct 2023 19:31:21 -0000	1.2
+++ wikisrc/ports/sparc64/sparc64sun4v.mdwn	11 Oct 2023 17:31:14 -0000	1.3
@@ -1,5 +1,5 @@
 # Goal
-Make NetBSD/sparc64 run on all sun4v based systems.
+Make NetBSD/sparc64 run on all sun4v-based systems.
 
 # Status
 Currently (as of 2023-10-10) the kernel boots fine using a single CPU (ignoring any additional available CPUs).  
@@ -9,11 +9,13 @@
 
 # Running
 ## On real hardware
-### CDROM/DVD
-Create a install disc from the official ISO image and issue a 'boot cdrom' command from OpenBoot,
+### CD-ROM/DVD
+Create an install disc from the official ISO image and issue a 'boot cdrom' command from OpenBoot,
 ### Miniroot
-If the sun4v system has more than one logical machine configured, a secondary logical machine can use the 'miniroot' image as a virtual disk to boot from.  
-Configuration of secondary virtual machine can be done by running e.g. Solaris 11.3/11.4 or OpenBSD as the primary logical machine.
+If the sun4v system has more than one logical domain configured, a secondary logical domain can use the 'miniroot' image as a virtual disk to boot from.  
+Configuration of secondary virtual domain can be done by running e.g. Solaris 11.3/11.4 or OpenBSD as the primary logical machine.  
+Oracle documentation for the logical domain is here: <https://docs.oracle.com/en/virtualization/oracle-vm-server-sparc/index.html>  
+OpenBSD has some notes on using the logical domain feature here: <https://undeadly.org/cgi?action=article;sid=20121214153413> and <https://flak.tedunangst.com/post/OpenBSD-on-a-Sun-T5120>
 ### Network
 TBD
 ## On emulated hardware

Index: wikisrc/ports/sparc64/sparc64sun4v.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/sparc64/sparc64sun4v.mdwn,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- wikisrc/ports/sparc64/sparc64sun4v.mdwn	10 Oct 2023 19:03:42 -0000	1.1
+++ wikisrc/ports/sparc64/sparc64sun4v.mdwn	10 Oct 2023 19:31:21 -0000	1.2
@@ -2,8 +2,21 @@
 Make NetBSD/sparc64 run on all sun4v based systems.
 
 # Status
-Currently (as of 2023-10-10) the kernel boots fine using a single CPU (ignoring any additional available CPUs). 
-The only two systems known to boot the kernel so far are T2000 (T1 CPU) and S7-2 (S7 CPU).
-On T2000 the initial userland process (init) crashes after returning from a system call (access()) where an instruction MMU trap causes the register window to be incorrectly filled. On S7-S the intial userland process (init) runs fine and starts the installation program (sysinst), but hangs during the extraction of the sets.
+Currently (as of 2023-10-10) the kernel boots fine using a single CPU (ignoring any additional available CPUs).  
+The only two systems known to boot the kernel so far are T2000 (T1 CPU) and S7-2 (S7 CPU).  
+* On T2000 the initial userland process (init) crashes after returning from a system call (access()) where an instruction MMU trap causes the register window to be incorrectly filled.  
+* On S7-S the intial userland process (init) runs fine and starts the installation program (sysinst), but hangs during the extraction of the sets.  
 
+# Running
+## On real hardware
+### CDROM/DVD
+Create a install disc from the official ISO image and issue a 'boot cdrom' command from OpenBoot,
+### Miniroot
+If the sun4v system has more than one logical machine configured, a secondary logical machine can use the 'miniroot' image as a virtual disk to boot from.  
+Configuration of secondary virtual machine can be done by running e.g. Solaris 11.3/11.4 or OpenBSD as the primary logical machine.
+### Network
+TBD
+## On emulated hardware
+### QEMU
+TBD
 

Index: wikisrc/ports/sparc64/projects.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/sparc64/projects.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/ports/sparc64/projects.mdwn	10 Oct 2023 18:32:47 -0000	1.3
+++ wikisrc/ports/sparc64/projects.mdwn	10 Oct 2023 19:10:45 -0000	1.4
@@ -4,7 +4,7 @@
 
 ### Kernel
 
-* sun4v: Support for the successor to the sun4u architecture  is being worked on [[sparc64sun4v]]
+* sun4v: Support for the successor to the sun4u architecture  is being worked on ([[sparc64sun4v]])
 * Make sure registers %g6 and %g7 are free in all kernel asm code and use them for curlwp/curcpu
 * Cleanup locore.s: Locore.s needs a cleanup.
 * KGDB: The code for kgdb needs to be fixed back up.

--- /dev/null	2023-10-10 19:04:02.935034811 +0000
+++ wikisrc/ports/sparc64/sparc64sun4v.mdwn	2023-10-10 19:04:14.438258611 +0000
@@ -0,0 +1,9 @@
+# Goal
+Make NetBSD/sparc64 run on all sun4v based systems.
+
+# Status
+Currently (as of 2023-10-10) the kernel boots fine using a single CPU (ignoring any additional available CPUs). 
+The only two systems known to boot the kernel so far are T2000 (T1 CPU) and S7-2 (S7 CPU).
+On T2000 the initial userland process (init) crashes after returning from a system call (access()) where an instruction MMU trap causes the register window to be incorrectly filled. On S7-S the intial userland process (init) runs fine and starts the installation program (sysinst), but hangs during the extraction of the sets.
+
+

Index: wikisrc/ports/sparc64/projects.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/sparc64/projects.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/ports/sparc64/projects.mdwn	1 Jul 2015 09:31:10 -0000	1.2
+++ wikisrc/ports/sparc64/projects.mdwn	10 Oct 2023 18:32:47 -0000	1.3
@@ -4,7 +4,7 @@
 
 ### Kernel
 
-* Sun4v: Support for T1000 - T5000 is beeing worked on
+* sun4v: Support for the successor to the sun4u architecture  is being worked on [[sparc64sun4v]]
 * Make sure registers %g6 and %g7 are free in all kernel asm code and use them for curlwp/curcpu
 * Cleanup locore.s: Locore.s needs a cleanup.
 * KGDB: The code for kgdb needs to be fixed back up.

Index: wikisrc/ports/sparc64.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/sparc64.mdwn,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- wikisrc/ports/sparc64.mdwn	8 Nov 2022 22:35:56 -0000	1.35
+++ wikisrc/ports/sparc64.mdwn	10 Oct 2023 17:55:40 -0000	1.36
@@ -69,7 +69,7 @@
 """
 unsupported_hardware="""
 * Systems with an UltraSPARC IV CPU (unknown; may work)
-* Systems with an UltraSPARC T1-T5 CPU (in-progress)
+* Systems based on the sun4v architecture (CPUs: T1, T2, T3, T4, T5, M5, M6, M7, M8, S7) (in-progress)
 * Systems with a Fujitsu SPARC64 CPU (in-progress)
 * Smart card readers
 """

Members: 
	tutorials/kerberos_realm.mdwn:1.4->1.5 

Index: wikisrc/tutorials/kerberos_realm.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_realm.mdwn,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- wikisrc/tutorials/kerberos_realm.mdwn	23 Aug 2023 12:46:41 -0000	1.4
+++ wikisrc/tutorials/kerberos_realm.mdwn	8 Oct 2023 18:55:59 -0000	1.5
@@ -77,7 +77,7 @@
        jruser/admin@EXAMPLE.COM's Password: 
        Verifying - jruser/admin@EXAMPLE.COM's Password: 
 
-   The admin principal `jruser/adminEXAMPLE.COM` has no intrinsic
+   The admin principal `jruser/admin@EXAMPLE.COM` has no intrinsic
    connection to `jruser@EXAMPLE.COM` but by convention is chosen to be
    authorized like a [[!template id=man name="su" section="1"]]-style
    superuser version of `jruser` for administrative tasks with the help

Index: wikisrc/users/jun.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/jun.mdwn,v
retrieving revision 1.132
retrieving revision 1.133
diff -u -r1.132 -r1.133
--- wikisrc/users/jun.mdwn	4 Sep 2023 05:24:26 -0000	1.132
+++ wikisrc/users/jun.mdwn	3 Oct 2023 01:30:21 -0000	1.133
@@ -4,15 +4,6 @@
 
 # 2023
 
-## Open Source Conference 2023 Online/Fall BSD BoF
-- 2022 Sep.30 Sat 14:00-14:45 JST (UTC+9) 
-- [[https://event.ospn.jp/osc2023-online-fall/session/1098479]]
-- [[https://event.ospn.jp/osc2023-online-fall/]]
-- Join meeting via Youtube video [[https://www.youtube.com/c/OSPNjp]]
-- Join meeting via ZOOM [[https://ospn.connpass.com/event/295182]]
-- Tour Guide [[]]
-- togetter [[]]
-
 ## Open Source Conference 2023 Tokyo/Fall NetBSD Booth
 - 2023 Oct.21 Sat 10:00-16:00 JST (UTC+9)
 - Ota City Industrial Plaza (PiO) [[https://www.pio-ota.net/english-access/]]
@@ -40,6 +31,14 @@
 
 # Past Events in 2023
 
+## Open Source Conference 2023 Online/Fall BSD BoF
+- 2022 Sep.30 Sat 14:00-14:45 JST (UTC+9) 
+- [[https://event.ospn.jp/osc2023-online-fall/session/1098479]]
+- [[https://event.ospn.jp/osc2023-online-fall/]]
+- Youtube video [[https://youtu.be/ACcbr-JRNyk]]
+- Tour Guide [[https://cdn.netbsd.org/pub/NetBSD/misc/jun/OSC/OSC2023tokyofall.pdf]]
+- togetter [[https://togetter.com/li/2231931]]
+
 ## Open Developers Conference 2023 NetBSD BoF
 - 2023 Aug.26 Sat 12:00-12:45 JST (UTC+9)
 - docomo R&D OPEN LAB ODAIBA [[https://docomo-openlab.jp/about/#access]]

Index: wikisrc/projects/project/rfc5927.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/rfc5927.mdwn,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- wikisrc/projects/project/rfc5927.mdwn	1 Oct 2023 13:42:41 -0000	1.1
+++ wikisrc/projects/project/rfc5927.mdwn	1 Oct 2023 14:25:00 -0000	1.2
@@ -18,6 +18,9 @@
 
 This project will close
  [PR kern/35392](https://gnats.netbsd.org/35392).
+
+The IPv4 countermeasures were previously implemented here:
+<https://mail-index.NetBSD.org/source-changes/2005/07/19/msg166102.html>
 """
 ]]
 

--- /dev/null	2023-10-01 13:40:01.389936106 +0000
+++ wikisrc/projects/project/rfc5927.mdwn	2023-10-01 13:44:02.555399928 +0000
@@ -0,0 +1,24 @@
+[[!template id=project
+
+title="RFC 5927 countermeasures against IPv6 ICMP attacks on TCP"
+
+contact="""
+[tech-kern](mailto:tech-net@NetBSD.org)
+"""
+
+category="kernel"
+difficulty="medium"
+duration="1 month"
+
+description="""
+Assess and, if appropriate, implement RFC 5927 countermeasures against
+ IPv6 ICMP attacks on TCP.
+Write ATF tests for any countermeasures implemented, as well as ATF
+ tests for the existing IPv4 countermeasures.
+
+This project will close
+ [PR kern/35392](https://gnats.netbsd.org/35392).
+"""
+]]
+
+[[!tag gsoc]]

Index: wikisrc/tutorials/pkgsrc/pbulk.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/pkgsrc/pbulk.mdwn,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- wikisrc/tutorials/pkgsrc/pbulk.mdwn	10 Jun 2020 14:30:19 -0000	1.17
+++ wikisrc/tutorials/pkgsrc/pbulk.mdwn	29 Sep 2023 10:44:58 -0000	1.18
@@ -34,7 +34,7 @@
 Fortunately, a tool called *mksandbox* will simplify this process. *mksandbox*
 is located in the *pkgtools/mksandbox* package, and it is called like this:
 
-	# mksandbox [optionnal flags] /path/to/sandbox
+	# mksandbox [optional flags] /path/to/sandbox
 
 For example, to create a sandbox in */home/bulk* without the X11 system, run:
 

--- /dev/null	2023-09-29 10:38:04.788789007 +0000
+++ wikisrc/projects/project/pam-tests.mdwn	2023-09-29 10:38:54.491242888 +0000
@@ -0,0 +1,26 @@
+[[!template id=project
+
+title="Automatic tests for PAM"
+
+contact="""
+[tech-kern](mailto:tech-userlevel@NetBSD.org)
+"""
+
+mentors="""
+[Taylor R Campbell](mailto:riastradh@NetBSD.org)
+"""
+
+category="userland"
+difficulty="medium"
+duration="1-2 months"
+
+description="""
+Implement automatic tests with ATF for all the PAM modules under
+ src/lib/libpam/modules.
+
+The modules, such as pam_krb5, are not currently automatically tested,
+ despite being security-critical, which has led to severe regressions.
+"""
+]]
+
+[[!tag gsoc]]

Index: wikisrc/certctl-transition.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/certctl-transition.mdwn,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- wikisrc/certctl-transition.mdwn	26 Sep 2023 10:50:07 -0000	1.8
+++ wikisrc/certctl-transition.mdwn	26 Sep 2023 10:58:40 -0000	1.9
@@ -112,7 +112,7 @@
 ### Fresh installation with [[!template id=man name="sysinst" section="8"]]
 
 [[!template id=man name="sysinst" section="8"]] extracts an empty
- /etc/openssl/certs from bsae.tgz and default /etc/openssl/certs.conf
+ /etc/openssl/certs from base.tgz and default /etc/openssl/certs.conf
  from etc.tgz, and then runs `certctl rehash`.
 
 That way, fresh installations have trust anchors installed and

Index: wikisrc/certctl-transition.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/certctl-transition.mdwn,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- wikisrc/certctl-transition.mdwn	26 Sep 2023 10:47:42 -0000	1.7
+++ wikisrc/certctl-transition.mdwn	26 Sep 2023 10:50:07 -0000	1.8
@@ -87,7 +87,7 @@
    the mozilla-rootcerts-openssl package if you're using that, or just
    delete /etc/openssl/certs if you're using mozilla-rootcerts or
    ca-certificates.
-- Make sure you don't have `manual` set in /etc/openssl/certs.conf.
+- Make sure you have /etc/openssl/certs.conf without `manual` set.
   (Default is in /usr/share/examples/certctl/certs.conf.)
 - Run `certctl rehash`.
 
@@ -218,7 +218,7 @@
  configuration.
 
 The following transitions have been tested (from the
- [commit](https://mail-index.netbsd.org/source-changes/2023/09/03/msg147374.html)):
+ [commit](https://mail-index.NetBSD.org/source-changes/2023/09/03/msg147374.html)):
 
 1. fresh install:
    empty /etc/openssl/certs;
@@ -298,10 +298,10 @@
 
 ## [[!template id=man name="certctl" section="8"]] proposal and discussions
 
-<https://mail-index.netbsd.org/tech-userlevel/2023/08/22/msg014140.html>
+<https://mail-index.NetBSD.org/tech-userlevel/2023/08/22/msg014140.html>
 
 Followup discussions:
 
-- <https://mail-index.netbsd.org/tech-userlevel/2023/08/26/msg014143.html>
-- <https://mail-index.netbsd.org/tech-userlevel/2023/08/26/msg014145.html>
-- <https://mail-index.netbsd.org/tech-pkg/2023/08/29/msg028081.html>
+- <https://mail-index.NetBSD.org/tech-userlevel/2023/08/26/msg014143.html>
+- <https://mail-index.NetBSD.org/tech-userlevel/2023/08/26/msg014145.html>
+- <https://mail-index.NetBSD.org/tech-pkg/2023/08/29/msg028081.html>

Index: wikisrc/certctl-transition.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/certctl-transition.mdwn,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- wikisrc/certctl-transition.mdwn	26 Sep 2023 10:46:01 -0000	1.6
+++ wikisrc/certctl-transition.mdwn	26 Sep 2023 10:47:42 -0000	1.7
@@ -65,19 +65,14 @@
 - all certificates from Mozilla certdata.txt in
    /usr/share/certs/mozilla/all, including those not trusted by Mozilla
    by default or trusted only with restrictions
-
 - default TLS trust anchors symlinked in
    /usr/share/certs/mozilla/server
-
 - default S/MIME trust anchors symlinked in
    /usr/share/certs/mozilla/email
-
 - default code-signing trust anchors symlinked in
    /usr/share/certs/mozilla/code (unused, and empty)
-
 - a command [[!template id=man name="certctl" section="8"]] to manage
    exclusions and create hashed symlinks in /etc/openssl/certs
-
 - a default /etc/openssl/certs.conf configuration file for
    [[!template id=man name="certctl" section="8"]] pointing at
    /usr/share/certs/mozilla/server
@@ -87,6 +82,7 @@
 You can switch to using
  [[!template id=man name="certctl" section="8"]]
  if you want as follows:
+
 - Clear the existing /etc/openssl/certs -- e.g., remove
    the mozilla-rootcerts-openssl package if you're using that, or just
    delete /etc/openssl/certs if you're using mozilla-rootcerts or

Members: 
	certctl-transition.mdwn:1.5->1.6 

Index: wikisrc/certctl-transition.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/certctl-transition.mdwn,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- wikisrc/certctl-transition.mdwn	26 Sep 2023 10:38:19 -0000	1.5
+++ wikisrc/certctl-transition.mdwn	26 Sep 2023 10:46:01 -0000	1.6
@@ -82,17 +82,34 @@
    [[!template id=man name="certctl" section="8"]] pointing at
    /usr/share/certs/mozilla/server
 
-You can change the list of source directories in
- /etc/openssl/certs.conf, e.g. to add site-specific certificates in
- addition to the Mozilla ones.
-
-You can exclude individual trust anchors with, e.g.,
- `certctl untrust /usr/share/certs/mozilla/all/TrustCor_RootCert_CA-1.pem`.
-
-You can ask [[!template id=man name="certctl" section="8"]] not to
- touch /etc/openssl/certs by putting the line `manual` in
- /etc/openssl/certs.conf, if you want to manage it yourself some other
- way, like one of the pkgsrc packages.
+**If you upgrade from NetBSD<=9 to NetBSD 10, it will avoid changing
+ your existing configuration of /etc/openssl/certs.**
+You can switch to using
+ [[!template id=man name="certctl" section="8"]]
+ if you want as follows:
+- Clear the existing /etc/openssl/certs -- e.g., remove
+   the mozilla-rootcerts-openssl package if you're using that, or just
+   delete /etc/openssl/certs if you're using mozilla-rootcerts or
+   ca-certificates.
+- Make sure you don't have `manual` set in /etc/openssl/certs.conf.
+  (Default is in /usr/share/examples/certctl/certs.conf.)
+- Run `certctl rehash`.
+
+Other configuration choices you may want to make:
+
+- You can change the list of source directories in
+   /etc/openssl/certs.conf, e.g. to add site-specific certificates in
+   addition to the Mozilla ones.
+  Make sure to rerun `certctl rehash` if you do this.
+
+- You can exclude individual trust anchors with, e.g.,
+   `certctl untrust /usr/share/certs/mozilla/all/TrustCor_RootCert_CA-1.pem`.
+  (No need to run `certctl rehash`, but no harm if you do.)
+
+- You can ask [[!template id=man name="certctl" section="8"]] not to
+   touch /etc/openssl/certs by putting the line `manual` in
+   /etc/openssl/certs.conf, if you want to manage it yourself some
+   other way, like one of the pkgsrc packages.
 
 ## Transitions
 

Index: wikisrc/certctl-transition.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/certctl-transition.mdwn,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- wikisrc/certctl-transition.mdwn	26 Sep 2023 10:33:06 -0000	1.4
+++ wikisrc/certctl-transition.mdwn	26 Sep 2023 10:38:19 -0000	1.5
@@ -119,6 +119,8 @@
 - relies on [[!template id=man name="postinstall" section="8"]] to
    apply updates
 
+Draft patch: <https://www.NetBSD.org/~riastradh/tmp/20230926/certctl_init.patch>
+
 ### Upgrade with [[!template id=man name="sysinst" section="8"]]
 
 Upgrade with [[!template id=man name="sysinst" section="8"]] goes

Members: 
	certctl-transition.mdwn:1.3->1.4 

Index: wikisrc/certctl-transition.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/certctl-transition.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/certctl-transition.mdwn	26 Sep 2023 09:59:03 -0000	1.3
+++ wikisrc/certctl-transition.mdwn	26 Sep 2023 10:33:06 -0000	1.4
@@ -105,12 +105,12 @@
 That way, fresh installations have trust anchors installed and
  configured out of the box.
 
-### Fresh installation with mkimage images (arm64.img, etc.)
+### Fresh installation with live images (live-image, mkimage, arm64.img, etc.)
 
 XXX OOPS -- this doesn't work currently.
 
-Plan: create a mkimage-specific rc.d script that runs `certctl rehash`
- if /etc/openssl/certs is an empty directory.
+Plan: create an rc.d script that runs `certctl rehash` if
+ /etc/openssl/certs is an empty directory.
 
 - cheap to test, so not a burden to run on every boot
 - does the right thing on a fresh installation

Index: wikisrc/certctl-transition.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/certctl-transition.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/certctl-transition.mdwn	26 Sep 2023 09:57:36 -0000	1.2
+++ wikisrc/certctl-transition.mdwn	26 Sep 2023 09:59:03 -0000	1.3
@@ -1,4 +1,4 @@
-[[!toc]]
+[[!toc levels=2]]
 
 ## NetBSD<=9 situation
 

Index: wikisrc/certctl-transition.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/certctl-transition.mdwn,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- wikisrc/certctl-transition.mdwn	26 Sep 2023 09:51:35 -0000	1.1
+++ wikisrc/certctl-transition.mdwn	26 Sep 2023 09:57:36 -0000	1.2
@@ -1,3 +1,5 @@
+[[!toc]]
+
 ## NetBSD<=9 situation
 
 Prior to NetBSD 10, NetBSD did not ship any CA certificates for TLS
@@ -26,37 +28,29 @@
 
   - installs certificates from Mozilla certdata.txt as PEM files under
      $PREFIX/share/ca-certificates/mozilla
-
   - provides an update-ca-certificates(8) command to create hashed
      symlinks to them under /etc/openssl/certs
-
   - configured by $PKG_SYSCONFDIR/ca-certificates.conf and
      $PKG_SYSCONFDIR/ca-certificates-dir.conf
-
   - (GPL, so not fit for shipping in base)
 
 - security/mozilla-rootcerts
 
   - installs Mozilla certdata.txt at
      $PREFIX/share/mozilla-rootcerts/certdata.txt
-
   - installs a single-file bundle of concatenated PEM files at
      $PREFIX/share/mozilla-rootcerts/cacert.pem
-
   - provides a mozilla-rootcerts(8) command to extract the individual
      certificates and create hashed symlinks to them under
      /etc/openssl/certs and a single-file bundle of concatenated PEM
      files at /etc/openssl/certs/ca-certificates.crt
-
   - doesn't support excluding individual trust anchors
-
   - includes non-TLS trust anchors (e.g., S/MIME)
 
 - security/mozilla-rootcerts-openssl
 
   - special package based on security/mozilla-rootcerts that installs
      the hashed symlinks and ca-cdirectly in /etc/openssl/certs
-
   - makes pkg_* tools unhappy if you remove or change anything in
      /etc/openssl/certs
 
@@ -289,10 +283,10 @@
 
 ## [[!template id=man name="certctl" section="8"]] proposal and discussions
 
-https://mail-index.netbsd.org/tech-userlevel/2023/08/22/msg014140.html
+<https://mail-index.netbsd.org/tech-userlevel/2023/08/22/msg014140.html>
 
 Followup discussions:
 
-- https://mail-index.netbsd.org/tech-userlevel/2023/08/26/msg014143.html
-- https://mail-index.netbsd.org/tech-userlevel/2023/08/26/msg014145.html
-- https://mail-index.netbsd.org/tech-pkg/2023/08/29/msg028081.html
+- <https://mail-index.netbsd.org/tech-userlevel/2023/08/26/msg014143.html>
+- <https://mail-index.netbsd.org/tech-userlevel/2023/08/26/msg014145.html>
+- <https://mail-index.netbsd.org/tech-pkg/2023/08/29/msg028081.html>

--- /dev/null	2023-09-26 09:50:02.715320616 +0000
+++ wikisrc/certctl-transition.mdwn	2023-09-26 09:52:20.830068234 +0000
@@ -0,0 +1,298 @@
+## NetBSD<=9 situation
+
+Prior to NetBSD 10, NetBSD did not ship any CA certificates for TLS
+ trust anchors, so tools such as
+ [[!template id=man name="pkg_add" section="8"]]
+ and
+ [[!template id=man name="ftp" section="1"]]
+ would simply not do TLS validation in HTTPS requests.
+
+Applications using OpenSSL look in /etc/openssl/certs by default for
+ hashed certificate links as trust anchors, and pkgsrc's
+ security/openssl/builtin.mk sets SSLCERTS to /etc/openssl/certs to
+ reflect that.
+Some applications also consult /etc/openssl/certs/ca-certificates.crt
+ for a single-file bundle of concatenated PEM files.
+
+Note: /etc/openssl/certs is only for TLS trust anchors.
+There is no standard directory that applications will consult for,
+ e.g., S/MIME trust anchors for email.
+
+Several pkgsrc packages provide trust anchors and different ways to
+ manage /etc/openssl/certs, mostly from the Mozilla certdata.txt
+ repository:
+
+- security/ca-certificates
+
+  - installs certificates from Mozilla certdata.txt as PEM files under
+     $PREFIX/share/ca-certificates/mozilla
+
+  - provides an update-ca-certificates(8) command to create hashed
+     symlinks to them under /etc/openssl/certs
+
+  - configured by $PKG_SYSCONFDIR/ca-certificates.conf and
+     $PKG_SYSCONFDIR/ca-certificates-dir.conf
+
+  - (GPL, so not fit for shipping in base)
+
+- security/mozilla-rootcerts
+
+  - installs Mozilla certdata.txt at
+     $PREFIX/share/mozilla-rootcerts/certdata.txt
+
+  - installs a single-file bundle of concatenated PEM files at
+     $PREFIX/share/mozilla-rootcerts/cacert.pem
+
+  - provides a mozilla-rootcerts(8) command to extract the individual
+     certificates and create hashed symlinks to them under
+     /etc/openssl/certs and a single-file bundle of concatenated PEM
+     files at /etc/openssl/certs/ca-certificates.crt
+
+  - doesn't support excluding individual trust anchors
+
+  - includes non-TLS trust anchors (e.g., S/MIME)
+
+- security/mozilla-rootcerts-openssl
+
+  - special package based on security/mozilla-rootcerts that installs
+     the hashed symlinks and ca-cdirectly in /etc/openssl/certs
+
+  - makes pkg_* tools unhappy if you remove or change anything in
+     /etc/openssl/certs
+
+Users can also manage /etc/openssl/certs manually or in other ways,
+ e.g. to include internal site trust anchors not fit for the public
+ internet.
+
+## NetBSD 10 and [[!template id=man name="certctl" section="8"]]
+
+NetBSD 10 ships with:
+
+- all certificates from Mozilla certdata.txt in
+   /usr/share/certs/mozilla/all, including those not trusted by Mozilla
+   by default or trusted only with restrictions
+
+- default TLS trust anchors symlinked in
+   /usr/share/certs/mozilla/server
+
+- default S/MIME trust anchors symlinked in
+   /usr/share/certs/mozilla/email
+
+- default code-signing trust anchors symlinked in
+   /usr/share/certs/mozilla/code (unused, and empty)
+
+- a command [[!template id=man name="certctl" section="8"]] to manage
+   exclusions and create hashed symlinks in /etc/openssl/certs
+
+- a default /etc/openssl/certs.conf configuration file for
+   [[!template id=man name="certctl" section="8"]] pointing at
+   /usr/share/certs/mozilla/server
+
+You can change the list of source directories in
+ /etc/openssl/certs.conf, e.g. to add site-specific certificates in
+ addition to the Mozilla ones.
+
+You can exclude individual trust anchors with, e.g.,
+ `certctl untrust /usr/share/certs/mozilla/all/TrustCor_RootCert_CA-1.pem`.
+
+You can ask [[!template id=man name="certctl" section="8"]] not to
+ touch /etc/openssl/certs by putting the line `manual` in
+ /etc/openssl/certs.conf, if you want to manage it yourself some other
+ way, like one of the pkgsrc packages.
+
+## Transitions
+
+### Fresh installation with [[!template id=man name="sysinst" section="8"]]
+
+[[!template id=man name="sysinst" section="8"]] extracts an empty
+ /etc/openssl/certs from bsae.tgz and default /etc/openssl/certs.conf
+ from etc.tgz, and then runs `certctl rehash`.
+
+That way, fresh installations have trust anchors installed and
+ configured out of the box.
+
+### Fresh installation with mkimage images (arm64.img, etc.)
+
+XXX OOPS -- this doesn't work currently.
+
+Plan: create a mkimage-specific rc.d script that runs `certctl rehash`
+ if /etc/openssl/certs is an empty directory.
+
+- cheap to test, so not a burden to run on every boot
+- does the right thing on a fresh installation
+- doesn't get in the way of manually configured /etc/openssl/certs
+- doesn't require /etc to be writable later on
+- relies on [[!template id=man name="postinstall" section="8"]] to
+   apply updates
+
+### Upgrade with [[!template id=man name="sysinst" section="8"]]
+
+Upgrade with [[!template id=man name="sysinst" section="8"]] goes
+ through [[!template id=man name="postinstall" section="8"]] (q.v.,
+ below).
+
+### [[!template id=man name="etcupdate" section="8"]]
+
+If you use [[!template id=man name="etcupdate" section="8"]] to update
+ etc.tgz on upgrades, it may install the default
+ /etc/openssl/certs.conf for you, which asks
+ [[!template id=man name="certctl" section="8"]]
+ to take charge of /etc/openssl/certs.
+
+- If /etc/openssl/certs was empty, this is probably what you want.
+  (Make sure to run
+   [[!template id=man name="postinstall" section="8"]]
+   after
+   [[!template id=man name="etcupdate" section="8"]]
+   as usual, of course!)
+
+- If /etc/openssl/certs was nonempty, there is now a conflict between
+   what you were previously doing, and what the new default
+   /etc/openssl/certs.conf does.
+  [[!template id=man name="certctl" section="8"]]
+   will fail noisily (e.g., when you later run
+   [[!template id=man name="postinstall" section="8"]]),
+   because you've asked it to be responsible for /etc/openssl/certs
+   which it can't do without potentially causing harm to your existing
+   configuration:
+
+      # certctl rehash
+      certctl: existing certificates; set manual or remove them
+
+  In this case, you can either:
+
+  - clear the existing configuration (e.g., delete the
+    mozilla-rootcerts-openssl package, or empty /etc/openssl/certs) so
+    that [[!template id=man name="certctl" section="8"]] can take over,
+    and rerun [[!template id=man name="postinstall" section="8"]] or
+    `certctl rehash`; or
+
+  - put the line `manual` in /etc/openssl/certs.conf, if you want to
+    continue to use your existing method of managing
+    /etc/openssl/certs and not have
+    [[!template id=man name="certctl" section="8"]]
+    take over.
+
+### [[!template id=man name="postinstall" section="8"]]
+
+The [[!template id=man name="postinstall" section="8"]] script must be
+ run on every upgrade after extracting sets and updating etc (whether
+ with [[!template id=man name="etcupdate" section="8"]] or another
+ method of updating the system configuration).
+
+The logic in [[!template id=man name="postinstall" section="8"]] is
+ designed to gracefully handle every reasonable upgrade scenario I
+ could think of via two new items:
+
+- `opensslcertsconf` runs first to ensure that /etc/openssl/certs.conf
+   exists -- as the default (/usr/share/examples/certctl/certs.conf) if
+   /etc/openssl/certs was empty, and with `manual` set if
+   /etc/openssl/certs was already populated.
+
+- `opensslcertsrehash` runs next to rehash /etc/openssl/certs if
+   needed, accordin to /etc/openssl/certs.conf.
+
+  Note: This only works with DESTDIR=/, because it relies on the
+   [[!template id=man name="openssl" section="1"]]
+   command-line tool, which is not built as part of the cross-compiler

(Diff truncated)

Index: wikisrc/releng/netbsd-10.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/releng/netbsd-10.mdwn,v
retrieving revision 1.96
retrieving revision 1.97
diff -u -r1.96 -r1.97
--- wikisrc/releng/netbsd-10.mdwn	9 Sep 2023 17:34:15 -0000	1.96
+++ wikisrc/releng/netbsd-10.mdwn	14 Sep 2023 10:55:15 -0000	1.97
@@ -45,6 +45,7 @@
 * [[!template id=pr number=57143]]: Screen rotation causes loss of acceleration on i915
 * [[!template id=pr number=57182]]: nouveau doesn't switches LVDS on
 * [[!template id=pr number=57207]]: Unable to get display from a NetBSD system through a DP 1.4 KVM switch
+* [[!template id=pr number=57268]]: i915 GPU hangs
 * ~~[[!template id=pr number=57402]]: null pointer dereference in i915_gem_busy_ioctl~~ (needs pullup)
 
 ## Regressions since netbsd-9

Index: wikisrc/releng/netbsd-10.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/releng/netbsd-10.mdwn,v
retrieving revision 1.95
retrieving revision 1.96
diff -u -r1.95 -r1.96
--- wikisrc/releng/netbsd-10.mdwn	1 Sep 2023 17:02:36 -0000	1.95
+++ wikisrc/releng/netbsd-10.mdwn	9 Sep 2023 17:34:15 -0000	1.96
@@ -2,18 +2,16 @@
 
 ## Hard Release Blockers
 
-Currently we consider the magnitude of DRM/KMS bugs (see below) as a blocker.
-Maybe not all of them will be fixed before the release, but the new user impact with the current state
-is just too bad.
-
-The old entropy estimator from netbsd-9 must be revived, on the grounds
-that the one introduced in -current has too much of an impact on user
-experience. Machines without HWRNG will continue to print a warning on
-boot.
-
-We will pull up OpenSSL 3.x as soon as that has proven to work in -current,
-and may also import an update to libfido, as NetBSD 10.0 will be the first release
-that can make use of WebAuthN/Fido keys out of the box.
+*None*
+
+We consider the magnitude of DRM/KMS bugs (see below) as bad, but this is
+as good as it will realistically get for a 10.0 release.
+
+The entropy issues have been resolved by restoring the estimator from netbsd-9. Machines without HWRNG will continue to print a warning on boot.
+
+We have pulled up OpenSSL 3.x, bind, heimdahl, libfido and also bumped a lot of shared library revisions (which usually is not allowed on a release branch).
+
+Trust anchors (for https) are now shipped with the system.
 
 ## Showstopper bugs and PRs
 
@@ -113,7 +111,7 @@
 		- note that most of the above are ipf things, not pf things.
 		- ...
 * [Waiting for Randot](http://mail-index.netbsd.org/tech-security/2021/01/11/msg001100.html)
-	- The old entropy estimator from NetBSD 9 will be revived.
+	- ~~The old entropy estimator from NetBSD 9 will be revived.~~
 	- ~~we need to decide on how randomness would work before branch.~~
 	- ~~getentropy is missing from NetBSD but will be in POSIX.~~
 	- ~~[suggested installer changes](https://www.NetBSD.org/~martin/sysinst-entropy.patch)~~
@@ -124,8 +122,8 @@
 ## Current status and timeline
 
 * we seem to be close to what we realistically can get for 10.0
-* considering switching to release candidate state mid september
-* if all goes well, this could result in a 10.0 release in early october
+* we plan switching to release candidate state in the last week of september
+* if all goes well, this could result in a 10.0 release mid october
 
 ## Last netbsd-10 Test Results overview
 For all tests, see [releng's tests page](//releng.netbsd.org/test-results.html).
@@ -137,19 +135,19 @@
   <tbody>
     <tr>
         <td><a href="//www.netbsd.org/~martin/aarch64-atf-netbsd10/">aarch64</a>, real hardware</td>
-        <td>2023-08-17</td><td>2</td><td> </td>
+        <td>2023-09-08</td><td>3</td><td> </td>
     </tr>
     <tr>
         <td><a href="//www.netbsd.org/~martin/sparc64-atf-netbsd10/">sparc64</a>, real hardware</td>
-        <td>2023-08-17</td><td>6</td><td> </td>
+        <td>2023-09-08</td><td>7</td><td> </td>
     </tr>
     <tr>
         <td><a href="//www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/netbsd-10/">xen</a></td>
-        <td>2023-08-04</td> <td>8</td><td></td>
+        <td>2023-09-05</td> <td>8</td><td></td>
     </tr>
     <tr>
         <td><a href="//www.netbsd.org/~martin/evbarm-atf-netbsd10/">evbarm</a>, real hardware</td>
-        <td>2023-08-17</td><td>77</td><td></td>
+        <td>2023-09-08</td><td>77</td><td></td>
     </tr>
   </tbody>
 </table>

Index: wikisrc/users/jun.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/jun.mdwn,v
retrieving revision 1.131
retrieving revision 1.132
diff -u -r1.131 -r1.132
--- wikisrc/users/jun.mdwn	30 Aug 2023 02:43:46 -0000	1.131
+++ wikisrc/users/jun.mdwn	4 Sep 2023 05:24:26 -0000	1.132
@@ -5,10 +5,11 @@
 # 2023
 
 ## Open Source Conference 2023 Online/Fall BSD BoF
-- 2022 Sep.30 Sat XX:00-XX:45 JST (UTC+9) 
+- 2022 Sep.30 Sat 14:00-14:45 JST (UTC+9) 
+- [[https://event.ospn.jp/osc2023-online-fall/session/1098479]]
 - [[https://event.ospn.jp/osc2023-online-fall/]]
 - Join meeting via Youtube video [[https://www.youtube.com/c/OSPNjp]]
-- Join meeting via ZOOM [[]]
+- Join meeting via ZOOM [[https://ospn.connpass.com/event/295182]]
 - Tour Guide [[]]
 - togetter [[]]
 
@@ -16,6 +17,7 @@
 - 2023 Oct.21 Sat 10:00-16:00 JST (UTC+9)
 - Ota City Industrial Plaza (PiO) [[https://www.pio-ota.net/english-access/]]
 - [[https://event.ospn.jp/osc2023-fall/]]
+- [[https://ospn.connpass.com/event/295184]]
 - Tour Guide [[]]
 - togetter [[]]
 
@@ -26,6 +28,13 @@
 - Tour Guide [[]]
 - togetter [[]]
 
+## Open Source Conference 2023 Hiroshima NetBSD Booth&BoF
+- 2022 Nov.12 Sun 10:00-18:00 JST (UTC+9) 
+- Satellite Campus Hiroshima [[https://www.pu-hiroshima.ac.jp/site/satellite/accessmap.html]]
+- [[https://event.ospn.jp/osc2023-hiroshima/]]
+- Tour Guide [[]]
+- togetter [[]]
+
 # Nagoya *BSD Users' Group monthly meeting
 - [[http://nagoya.bug.gr.jp/]]
 
@@ -36,7 +45,7 @@
 - docomo R&D OPEN LAB ODAIBA [[https://docomo-openlab.jp/about/#access]]
 - [[https://event.ospn.jp/odc2023/]]
 - [[https://ospn.connpass.com/event/291437/]]
-- Youtube video [[https://youtu.be/QkVPOQZnzh8]]
+- Youtube video [[https://youtu.be/QkVPOQZnzh8]] c2k by yamori
 - Tour Guide [[https://cdn.netbsd.org/pub/NetBSD/misc/jun/OSC/ODC2023.pdf]]
 - togetter [[https://togetter.com/li/2208216]]
 

Index: wikisrc/releng/netbsd-10.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/releng/netbsd-10.mdwn,v
retrieving revision 1.94
retrieving revision 1.95
diff -u -r1.94 -r1.95
--- wikisrc/releng/netbsd-10.mdwn	20 Aug 2023 12:01:26 -0000	1.94
+++ wikisrc/releng/netbsd-10.mdwn	1 Sep 2023 17:02:36 -0000	1.95
@@ -26,6 +26,7 @@
 * [[!template id=pr number=56653]]: kernel crash in ipv6 fragment reassembly
 * ~~[[!template id=pr number=56713]]: kqueue/kevent does not work with null mounts~~
 * ~~[[!template id=pr number=55707]]: xcalls storm or pgdaemon high CPU consumption~~
+* [[!template id=pr number=56737]]: WDCTL_RST errors in 9.99.92 and 9.99.93
 * [[!template id=pr number=57127]]: ptyfs fails
 
 ## Open issues with new DRM/KMS

Index: wikisrc/users/jun.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/jun.mdwn,v
retrieving revision 1.130
retrieving revision 1.131
diff -u -r1.130 -r1.131
--- wikisrc/users/jun.mdwn	4 Aug 2023 01:43:06 -0000	1.130
+++ wikisrc/users/jun.mdwn	30 Aug 2023 02:43:46 -0000	1.131
@@ -4,14 +4,6 @@
 
 # 2023
 
-## Open Developers Conference 2023 NetBSD BoF
-- 2023 Aug.26 Sat XX:00-XX:45 JST (UTC+9)
-- docomo R&D OPEN LAB ODAIBA [[https://docomo-openlab.jp/about/#access]]
-- [[https://event.ospn.jp/odc2023/]]
-- [[https://ospn.connpass.com/event/291437/]]
-- Tour Guide [[]]
-- togetter [[]]
-
 ## Open Source Conference 2023 Online/Fall BSD BoF
 - 2022 Sep.30 Sat XX:00-XX:45 JST (UTC+9) 
 - [[https://event.ospn.jp/osc2023-online-fall/]]
@@ -39,6 +31,15 @@
 
 # Past Events in 2023
 
+## Open Developers Conference 2023 NetBSD BoF
+- 2023 Aug.26 Sat 12:00-12:45 JST (UTC+9)
+- docomo R&D OPEN LAB ODAIBA [[https://docomo-openlab.jp/about/#access]]
+- [[https://event.ospn.jp/odc2023/]]
+- [[https://ospn.connpass.com/event/291437/]]
+- Youtube video [[https://youtu.be/QkVPOQZnzh8]]
+- Tour Guide [[https://cdn.netbsd.org/pub/NetBSD/misc/jun/OSC/ODC2023.pdf]]
+- togetter [[https://togetter.com/li/2208216]]
+
 ## Open Source Conference 2023 Online/Kyoto NetBSD BoF
 - 2023 Jul.29 Sat 14:00-14:45 JST (UTC+9) 
 - [[https://event.ospn.jp/osc2023-online-kyoto/session/992861]]

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.211
retrieving revision 1.212
diff -u -r1.211 -r1.212
--- wikisrc/ports/xen/howto.mdwn	29 Jul 2023 23:40:24 -0000	1.211
+++ wikisrc/ports/xen/howto.mdwn	24 Aug 2023 23:08:39 -0000	1.212
@@ -108,10 +108,13 @@
 
 [[!table data="""
 Xen Version	|Package Name	|Xen CPU Support	|EOL'ed By Upstream
-4.13		|xenkernel413	|x86_64			|last update December 2022
-4.15		|xenkernel415	|x86_64			|last update November 2022
+4.13		|xenkernel413	|x86_64			|YES - last update 2022-12-19
+4.15		|xenkernel415	|x86_64			|NO
 """]]
 
+4.13 is EOL and will be removed from pkgsrc soon after 2023Q3 is
+branched.  Anyone using it should immediately begin migrating to 4.15.
+
 See also the [Xen Security Advisory page](http://xenbits.xen.org/xsa/).
 
 Older Xen had a python-based management tool called xm; this has long

Index: wikisrc/tutorials/kerberos_realm.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_realm.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/tutorials/kerberos_realm.mdwn	23 Aug 2023 12:44:02 -0000	1.3
+++ wikisrc/tutorials/kerberos_realm.mdwn	23 Aug 2023 12:46:41 -0000	1.4
@@ -1,8 +1,10 @@
 # How to create a Kerberos realm for single sign-on running on NetBSD
 
 You want to organize your users and services into a
-[[Kerberos|kerberos]] realm to enable single sign-on to your web sites
-and other services at hostnames under example.com.
+[[Kerberos|kerberos]] realm to enable
+[[single sign-on|tutorials/kerberos_client]] to your
+[[web sites and other services|tutorials/kerberos_services]] at
+hostnames under example.com.
 How do you set it up?
 
 1. Pick a realm name.
Index: wikisrc/tutorials/kerberos_services.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_services.mdwn,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- wikisrc/tutorials/kerberos_services.mdwn	23 Aug 2023 12:02:26 -0000	1.1
+++ wikisrc/tutorials/kerberos_services.mdwn	23 Aug 2023 12:46:41 -0000	1.2
@@ -1,9 +1,11 @@
 # How to set up Kerberos authentication in network services
 
-Your organization has a [[Kerberos|kerberos]] realm EXAMPLE.COM.
+Your organization has a [[Kerberos|kerberos]] realm EXAMPLE.COM, or you
+[[set one up|tutorials/kerberos_realm]].
 You operate a service such as ssh, SMTP/IMAP/POP, or a web site.
 How do you kerberize the service to let users authenticate with
-Kerberos instead of juggling passwords?
+[[Kerberos single sign-on|tutorials/kerberos_client]] instead of
+juggling passwords?
 
 The answer will vary from service to service, and may sometimes be
 phrased in terms of GSS-API, but it will always have three parts:

Index: wikisrc/tutorials/kerberos_realm.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_realm.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/tutorials/kerberos_realm.mdwn	23 Aug 2023 12:41:15 -0000	1.2
+++ wikisrc/tutorials/kerberos_realm.mdwn	23 Aug 2023 12:44:02 -0000	1.3
@@ -78,8 +78,8 @@
    The admin principal `jruser/adminEXAMPLE.COM` has no intrinsic
    connection to `jruser@EXAMPLE.COM` but by convention is chosen to be
    authorized like a [[!template id=man name="su" section="1"]]-style
-   superuser version of `jruser` administrative tasks with the help of
-   [[!template id=man name="kadmind" section="8"]].
+   superuser version of `jruser` for administrative tasks with the help
+   of [[!template id=man name="kadmind" section="8"]].
 
 Now you can do `kinit jruser@EXAMPLE.COM` for
 [[client-side single sign-on|tutorials/kerberos_client]], and set up

Index: wikisrc/tutorials/kerberos_realm.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_realm.mdwn,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- wikisrc/tutorials/kerberos_realm.mdwn	23 Aug 2023 12:02:26 -0000	1.1
+++ wikisrc/tutorials/kerberos_realm.mdwn	23 Aug 2023 12:41:15 -0000	1.2
@@ -76,11 +76,11 @@
        Verifying - jruser/admin@EXAMPLE.COM's Password: 
 
    The admin principal `jruser/adminEXAMPLE.COM` has no intrinsic
-   connection to `jruser@EXAMPLE.COM' but by convention is chosen to be
+   connection to `jruser@EXAMPLE.COM` but by convention is chosen to be
    authorized like a [[!template id=man name="su" section="1"]]-style
    superuser version of `jruser` administrative tasks with the help of
    [[!template id=man name="kadmind" section="8"]].
 
 Now you can do `kinit jruser@EXAMPLE.COM` for
-[client-side single sign-on|tutorials/kerberos_client], and set up
-[kerberized services|tutorials/kerberos_services]!
+[[client-side single sign-on|tutorials/kerberos_client]], and set up
+[[kerberized services|tutorials/kerberos_services]]!

Index: wikisrc/kerberos.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/kerberos.mdwn,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- wikisrc/kerberos.mdwn	23 Aug 2023 12:04:08 -0000	1.7
+++ wikisrc/kerberos.mdwn	23 Aug 2023 12:05:48 -0000	1.8
@@ -6,6 +6,6 @@
 supported by many applications including web browsers and mail
 readers.
 
-* [How to use Kerberos for single sign-on in a NetBSD client|tutorials/kerberos_client]
-* [How to create a Kerberos realm for single sign-on running on NetBSD|tutorials/kerberos_realm]
-* [How to set up Kerberos authentication in network services|tutorials/kerberos_services]
+* [[How to use Kerberos for single sign-on in a NetBSD client|tutorials/kerberos_client]]
+* [[How to create a Kerberos realm for single sign-on running on NetBSD|tutorials/kerberos_realm]]
+* [[How to set up Kerberos authentication in network services|tutorials/kerberos_services]]

Index: wikisrc/kerberos.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/kerberos.mdwn,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- wikisrc/kerberos.mdwn	23 Aug 2023 12:02:26 -0000	1.6
+++ wikisrc/kerberos.mdwn	23 Aug 2023 12:04:08 -0000	1.7
@@ -6,6 +6,6 @@
 supported by many applications including web browsers and mail
 readers.
 
-* [How to use Kerberos for single sign-on in a NetBSD client](tutorials/kerberos_client)
-* [How to create a Kerberos realm for single sign-on running on NetBSD](tutorials/kerberos_realm)
-* [How to set up Kerberos authentication in network services](tutorials/kerberos_services)
+* [How to use Kerberos for single sign-on in a NetBSD client|tutorials/kerberos_client]
+* [How to create a Kerberos realm for single sign-on running on NetBSD|tutorials/kerberos_realm]
+* [How to set up Kerberos authentication in network services|tutorials/kerberos_services]

Index: wikisrc/kerberos.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/kerberos.mdwn,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- wikisrc/kerberos.mdwn	6 Jun 2023 01:08:51 -0000	1.5
+++ wikisrc/kerberos.mdwn	23 Aug 2023 12:02:26 -0000	1.6
@@ -1,7 +1,11 @@
-*These pages on The NetBSD Foundation's internal Kerberos deployment are being migrated to <https://www.NetBSD.org/developers/kerberos.html>.*
+*The pages on The NetBSD Foundation's internal Kerberos deployment have been migrated to <https://www.NetBSD.org/developers/kerberos.html>.*
 
-## NETBSD.ORG Kerberos
+[Kerberos](https://en.wikipedia.org/wiki/Kerberos) is a
+[single sign-on](https://en.wikipedia.org/wiki/Single_sign-on)
+authentication protocol, used by many organizations and natively
+supported by many applications including web browsers and mail
+readers.
 
-* [[password]]
-* [[system]]
-* [[web_browser]]
+* [How to use Kerberos for single sign-on in a NetBSD client](tutorials/kerberos_client)
+* [How to create a Kerberos realm for single sign-on running on NetBSD](tutorials/kerberos_realm)
+* [How to set up Kerberos authentication in network services](tutorials/kerberos_services)
Index: wikisrc/tutorials/kerberos_client.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_client.mdwn,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- wikisrc/tutorials/kerberos_client.mdwn	23 Aug 2023 06:37:12 -0000	1.6
+++ wikisrc/tutorials/kerberos_client.mdwn	23 Aug 2023 12:02:26 -0000	1.7
@@ -41,6 +41,38 @@
   See [[!template id=man name="krb5.conf" section="5"]] for more
   information about the syntax of ~/.krb5/config.
 
+- If you are using Kerberos to log into multiple independent realms for
+  different purposes at once, you can ensure that services in one realm
+  can't spoof services in the other in any of several ways:
+
+  1. Use the `[domain_realm]` section in ~/.krb5/config to assign
+     different domains to different realms, and disable DNS
+     name-to-realm mapping:
+
+         [libdefaults]
+                 dns_lookup_realm = false
+
+         [domain_realm]
+                 example.com = EXAMPLE.COM
+                 .example.com = EXAMPLE.COM
+                 evil.net = EVIL.NET
+                 .evil.net = EVIL.NET
+
+     The entry for example.com matches just example.com directly, and
+     the entry for .example.com matches any subdomain one level under
+     example.com such as foo.example.com but not foo.bar.example.com.
+
+  1. Create separate config files ~/.krb5/config.example and
+     ~/.krb5/config.evil, and run programs with the KRB5_CONFIG
+     environment variable set to whichever one you want to use for that
+     program:
+
+         $ KRB5_CONFIG=$HOME/.krb5/config.example firefox &
+         $ KRB5_CONFIG=$HOME/.krb5/config.evil ssh foo.evil.net
+
+     Make sure to set `[libdefaults] dns_lookup_realm = false` in each
+     config file too in this case.
+
 ## ssh
 
 To enable [[!template id=man name="ssh" section="1"]] to use Kerberos
--- /dev/null	2023-09-18 20:32:00.487406898 +0000
+++ wikisrc/tutorials/kerberos_realm.mdwn	2023-09-18 20:32:41.364587954 +0000
@@ -0,0 +1,86 @@
+# How to create a Kerberos realm for single sign-on running on NetBSD
+
+You want to organize your users and services into a
+[[Kerberos|kerberos]] realm to enable single sign-on to your web sites
+and other services at hostnames under example.com.
+How do you set it up?
+
+1. Pick a realm name.
+   This is normally the uppercase version of your organization's domain
+   name in the DNS, EXAMPLE.COM.
+
+   _Note:_ Unlike DNS domain names, Kerberos realm names are
+   case-sensitive.
+
+1. Pick a host to run the Kerberos Key Distribution Center, say
+   kdc.example.com.
+
+   Make sure TCP and/or UDP traffic to kdc.example.com goes to the
+   host, in case it is behind a NAT or firewall or similar.
+
+1. To make it easier for users, create DNS records in the
+   example.com. zone:
+
+       ; name           ttl     class   type    rrdata
+       _kerberos        300     IN      TXT     "EXAMPLE.COM"
+       _kerberos._tcp   300     IN      SRV     1 0 88 kdc
+       _kerberos._udp   300     IN      SRV     1 0 88 kdc
+
+   For access to services under `example.com`, clients will consult
+   `_kerberos.example.com` TXT records to find the realm name
+   (see `dns_lookup_realm` in
+   [[!template id=man name="krb5.conf" section="5"]])
+
+   To find the KDC for the realm EXAMPLE.COM, clients and services will
+   consult `_kerberos._tcp.example.com` or `_kerberos._udp.example.com`
+   SRV records
+   (see `dns_lookup_kdc` in
+   [[!template id=man name="krb5.conf" section="5"]]).
+
+   If you don't set this up, you will need to distribute
+   [[!template id=man name="krb5.conf" section="5"]] files to all users
+   with the realm name and domain-to-realm mapping; see the
+   `[domain_realm]` and `[realms]` sections in the
+   [[!template id=man name="krb5.conf" section="5"]] man page for
+   details.
+
+1. On kdc.example.com, create /etc/krb5.conf with the following content:
+
+       [libdefaults]
+               default_realm = EXAMPLE.COM
+               name_canon_rules = as-is:
+
+   Check it by running:
+
+       # verify_krb5_conf /etc/krb5.conf
+
+1. Initialize the KDC:
+
+       # kadmin -l init EXAMPLE.COM
+       Realm max ticket life [unlimited]:
+       Realm max renewable ticket life [unlimited]:
+
+   Hit return when prompted to use the defaults.
+
+   This will create the database at the default location under
+   `/var/heimdal`.
+
+1. Create a user principal and an admin principal.
+   We'll call the user `jruser` for J. Random User.
+
+       # kadmin -l add --use-defaults jruser
+       jruser@EXAMPLE.COM's Password: 
+       Verifying - jruser@EXAMPLE.COM's Password: 
+       # kadmin -l add --use-defaults jruser/admin
+       jruser/admin@EXAMPLE.COM's Password: 
+       Verifying - jruser/admin@EXAMPLE.COM's Password: 
+
+   The admin principal `jruser/adminEXAMPLE.COM` has no intrinsic
+   connection to `jruser@EXAMPLE.COM' but by convention is chosen to be
+   authorized like a [[!template id=man name="su" section="1"]]-style
+   superuser version of `jruser` administrative tasks with the help of
+   [[!template id=man name="kadmind" section="8"]].
+
+Now you can do `kinit jruser@EXAMPLE.COM` for
+[client-side single sign-on|tutorials/kerberos_client], and set up
+[kerberized services|tutorials/kerberos_services]!
--- /dev/null	2023-09-18 20:32:00.487406898 +0000
+++ wikisrc/tutorials/kerberos_services.mdwn	2023-09-18 20:32:41.395882799 +0000
@@ -0,0 +1,77 @@
+# How to set up Kerberos authentication in network services
+
+Your organization has a [[Kerberos|kerberos]] realm EXAMPLE.COM.
+You operate a service such as ssh, SMTP/IMAP/POP, or a web site.
+How do you kerberize the service to let users authenticate with
+Kerberos instead of juggling passwords?
+
+The answer will vary from service to service, and may sometimes be
+phrased in terms of GSS-API, but it will always have three parts:
+
+1. Determine the service's principal name, based on the protocol, the
+   service's hostname, and the realm name.
+
+   For example, IMAP uses imap/_hostname_.
+   So if your users are connecting to the IMAP host imap.example.com,
+   the service principal name will be imap/imap.example.com
+   (or imap/imap.example.com@EXAMPLE.COM if fully qualified with a
+   realm name).
+
+2. Get a key for the service principal from the Kerberos KDC using
+   [[!template id=man name="kadmin" section="8"]]:
+   first `kadmin add` to generate a key for the service principal, and
+   then `kadmin ext` to extract it into a keytab.
+
+   The key is a secret shared between the service and the KDC.
+   Anyone who knows the key can spoof the service, so you must keep
+   it secret.
+
+3. Put the keytab in a file readable by the server software, for
+   example /etc/dovecot/dovecot.keytab, and point the software at the
+   keytab and service principal name.
+
+   Some software that uses GSS-API will instead use the GSS-API
+   spelling of a service principal name.
+   For example, IMAP uses IMAP@_hostname_, and HTTPS uses
+   HTTP@_hostname_.

(Diff truncated)

Members: 
	tutorials/kerberos_client.mdwn:1.5->1.6 

Index: wikisrc/tutorials/kerberos_client.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_client.mdwn,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- wikisrc/tutorials/kerberos_client.mdwn	22 Aug 2023 20:54:54 -0000	1.5
+++ wikisrc/tutorials/kerberos_client.mdwn	23 Aug 2023 06:37:12 -0000	1.6
@@ -99,6 +99,7 @@
    with the following content:
 
        [libdefaults]
+               default_realm = EXAMPLE.COM
                name_canon_rules = as-is:
 
 1. Uncomment the pam_krb5.so lines

Index: wikisrc/tutorials/kerberos_client.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_client.mdwn,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- wikisrc/tutorials/kerberos_client.mdwn	22 Aug 2023 20:45:55 -0000	1.4
+++ wikisrc/tutorials/kerberos_client.mdwn	22 Aug 2023 20:54:54 -0000	1.5
@@ -13,6 +13,7 @@
 1. Get a ticket:
 
        $ kinit jruser@EXAMPLE.COM
+       jruser@EXAMPLE.COM's Password: 
 
 Now any kerberized applications such as ssh and Firefox can
 authenticate as jruser@EXAMPLE.COM on your behalf to services!

Index: wikisrc/tutorials/kerberos_client.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_client.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/tutorials/kerberos_client.mdwn	22 Aug 2023 20:43:07 -0000	1.3
+++ wikisrc/tutorials/kerberos_client.mdwn	22 Aug 2023 20:45:55 -0000	1.4
@@ -19,15 +19,16 @@
 
 [[!toc startlevel=2 levels=1]]
 
-#### Notes
+##### Notes
 
-- Note: If your realm isn't set up for Kerberos DNS autoconfiguration,
-  you may need to specify the KDC address in the `[realms]` section,
-  and a domain to realm mapping in the `[domain_realm]` section.
+- If your realm isn't set up for Kerberos DNS autoconfiguration, you
+  may need to specify the KDC address in the `[realms]` section of
+  ~/.krb5/config, and a domain to realm mapping in the `[domain_realm]`
+  section.
   Consult your realm administrator for details.
 
-- Note: Some realms are set up to require DNS canonicalization, which
-  is traditional but also a
+- Some realms are set up to require DNS canonicalization, which is
+  traditional but also a
   [security vulnerability](https://github.com/heimdal/heimdal/issues/1130).
   For such realms, add another `name_canon_rules` in the
   `[libdefaults]` section of ~/.krb5/config matching the EXAMPLE.COM
@@ -68,7 +69,7 @@
 
 1. Go to `about:config`.
 1. Search for `negotiate-auth`.
-1. Set `network.negotiate-auth.trusted-uris to the string
+1. Set `network.negotiate-auth.trusted-uris` to the string
    `.example.com`.
    (Note: Not `network.negotiate-auth.delegation-uris`.)
 1. If you need more sites like `https://*.example.org/` too, set it to
@@ -76,14 +77,13 @@
 
 Now go to a page that requires kerberized login!
 
-#### Notes
+##### Notes
 
-- Note: This applies to web sites that use SPNEGO-based
+- This applies to web sites that use SPNEGO-based
   `WWW-Authenticate: Negotiate` authentication in
   [RFC 4559](https://datatracker.ietf.org/doc/html/rfc4559).
 
-- Note: This is restricted to HTTPS, and will not work with HTTP
-  sites.
+- This is restricted to HTTPS, and will not work with HTTP sites.
 
 ## Kerberos for local login
 
@@ -108,9 +108,9 @@
 [[!template id=man name="klist" section="1"]] that you automatically
 got tickets!
 
-#### Notes
+##### Notes
 
-- Note: The keytab is required for local login security.
+- The keytab is required for local login security.
   If you are willing to rely only on physical security of the machine,
   and use local login strictly as a convenience to get tickets for
   yourself without actually authenticating whoever is typing on the
@@ -120,8 +120,8 @@
   [[!template id=man name="pam_krb5" section="8"]] for more
   information.
 
-- Note: If your local login name does not match your Kerberos principal
-  name in the realm, you can configure `auth_to_local` mappings in
+- If your local login name does not match your Kerberos principal name
+  in the realm, you can configure `auth_to_local` mappings in
   /etc/krb5.conf, and control which principals are allowed to log in as
   your local login name by adding them one per line in ~/.k5login.
   See [[!template id=man name="krb5.conf" section="5"]] for more

Index: wikisrc/tutorials/kerberos_client.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_client.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/tutorials/kerberos_client.mdwn	22 Aug 2023 20:40:45 -0000	1.2
+++ wikisrc/tutorials/kerberos_client.mdwn	22 Aug 2023 20:43:07 -0000	1.3
@@ -1,6 +1,6 @@
 # How to use Kerberos for single sign-on in a NetBSD client
 
-Your organization has a [[kerberos|Kerberos]] realm called EXAMPLE.COM.
+Your organization has a [[Kerberos|kerberos]] realm EXAMPLE.COM.
 You have a login password for the principal jruser@EXAMPLE.COM.
 How do you log in and authenticate to services?
 
@@ -17,9 +17,9 @@
 Now any kerberized applications such as ssh and Firefox can
 authenticate as jruser@EXAMPLE.COM on your behalf to services!
 
-[[!toc levels=2]]
+[[!toc startlevel=2 levels=1]]
 
-### Notes
+#### Notes
 
 - Note: If your realm isn't set up for Kerberos DNS autoconfiguration,
   you may need to specify the KDC address in the `[realms]` section,
@@ -76,7 +76,7 @@
 
 Now go to a page that requires kerberized login!
 
-### Notes
+#### Notes
 
 - Note: This applies to web sites that use SPNEGO-based
   `WWW-Authenticate: Negotiate` authentication in
@@ -108,7 +108,7 @@
 [[!template id=man name="klist" section="1"]] that you automatically
 got tickets!
 
-### Notes
+#### Notes
 
 - Note: The keytab is required for local login security.
   If you are willing to rely only on physical security of the machine,

Index: wikisrc/tutorials/kerberos_client.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_client.mdwn,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- wikisrc/tutorials/kerberos_client.mdwn	22 Aug 2023 20:34:40 -0000	1.1
+++ wikisrc/tutorials/kerberos_client.mdwn	22 Aug 2023 20:40:45 -0000	1.2
@@ -17,15 +17,19 @@
 Now any kerberized applications such as ssh and Firefox can
 authenticate as jruser@EXAMPLE.COM on your behalf to services!
 
+[[!toc levels=2]]
+
+### Notes
+
 - Note: If your realm isn't set up for Kerberos DNS autoconfiguration,
   you may need to specify the KDC address in the `[realms]` section,
-  and a domain to realm mapping in the `[domain_realm]` section;
-  consult your realm administrator for details.
+  and a domain to realm mapping in the `[domain_realm]` section.
+  Consult your realm administrator for details.
 
 - Note: Some realms are set up to require DNS canonicalization, which
   is traditional but also a
   [security vulnerability](https://github.com/heimdal/heimdal/issues/1130).
-  For these realms, add another `name_canon_rules` in the
+  For such realms, add another `name_canon_rules` in the
   `[libdefaults]` section of ~/.krb5/config matching the EXAMPLE.COM
   realm:
 
@@ -72,6 +76,8 @@
 
 Now go to a page that requires kerberized login!
 
+### Notes
+
 - Note: This applies to web sites that use SPNEGO-based
   `WWW-Authenticate: Negotiate` authentication in
   [RFC 4559](https://datatracker.ietf.org/doc/html/rfc4559).
@@ -102,6 +108,8 @@
 [[!template id=man name="klist" section="1"]] that you automatically
 got tickets!
 
+### Notes
+
 - Note: The keytab is required for local login security.
   If you are willing to rely only on physical security of the machine,
   and use local login strictly as a convenience to get tickets for

--- /dev/null	2023-09-18 20:32:00.487406898 +0000
+++ wikisrc/tutorials/kerberos_client.mdwn	2023-09-18 20:32:43.483752721 +0000
@@ -0,0 +1,120 @@
+# How to use Kerberos for single sign-on in a NetBSD client
+
+Your organization has a [[kerberos|Kerberos]] realm called EXAMPLE.COM.
+You have a login password for the principal jruser@EXAMPLE.COM.
+How do you log in and authenticate to services?
+
+1. Create a directory ~/.krb5 and a file ~/.krb5/config with the
+   following content to enable Kerberos on the client side:
+
+       [libdefaults]
+               name_canon_rules = as-is:
+
+1. Get a ticket:
+
+       $ kinit jruser@EXAMPLE.COM
+
+Now any kerberized applications such as ssh and Firefox can
+authenticate as jruser@EXAMPLE.COM on your behalf to services!
+
+- Note: If your realm isn't set up for Kerberos DNS autoconfiguration,
+  you may need to specify the KDC address in the `[realms]` section,
+  and a domain to realm mapping in the `[domain_realm]` section;
+  consult your realm administrator for details.
+
+- Note: Some realms are set up to require DNS canonicalization, which
+  is traditional but also a
+  [security vulnerability](https://github.com/heimdal/heimdal/issues/1130).
+  For these realms, add another `name_canon_rules` in the
+  `[libdefaults]` section of ~/.krb5/config matching the EXAMPLE.COM
+  realm:
+
+      [libdefaults]
+              name_canon_rules = nss:match_realm=EXAMPLE.COM
+
+  See [[!template id=man name="krb5.conf" section="5"]] for more
+  information about the syntax of ~/.krb5/config.
+
+## ssh
+
+To enable [[!template id=man name="ssh" section="1"]] to use Kerberos
+authentication when logging into any host under *.example.com, add the
+following stanza to the end of ~/.ssh/config
+([[!template id=man name="ssh_config" section="5"]]):
+
+    Match host *.example.com
+            GSSAPIAuthentication yes
+
+Now log in to foo.example.com without a password!
+
+If you trust the remote host to act on your behalf, and you need to
+authenticate to kerberized applications on the remote host, you can
+also forward your Kerberos tickets with:
+
+    Match host *.example.com
+            GSSAPIAuthentication yes
+            GSSAPIDelegateCredentials yes
+
+Now run kerberized applications on foo.example.com through ssh without
+a password!
+
+## Firefox
+
+To log into kerberized web sites at `https://*.example.com/`:
+
+1. Go to `about:config`.
+1. Search for `negotiate-auth`.
+1. Set `network.negotiate-auth.trusted-uris to the string
+   `.example.com`.
+   (Note: Not `network.negotiate-auth.delegation-uris`.)
+1. If you need more sites like `https://*.example.org/` too, set it to
+   a comma-separated string like `.example.com, .example.org`.
+
+Now go to a page that requires kerberized login!
+
+- Note: This applies to web sites that use SPNEGO-based
+  `WWW-Authenticate: Negotiate` authentication in
+  [RFC 4559](https://datatracker.ietf.org/doc/html/rfc4559).
+
+- Note: This is restricted to HTTPS, and will not work with HTTP
+  sites.
+
+## Kerberos for local login
+
+To use Kerberos for local logins, e.g. at the console or in a display
+manager such as [[!template id=man name="xdm" section="8"]], when your
+local login name matches your Kerberos principal name in the realm:
+
+1. Get a keytab from your realm administrator at /etc/krb5.keytab.
+
+1. Create a system-wide /etc/krb5.conf file
+   ([[!template id=man name="krb5.conf" section="5"]])
+   with the following content:
+
+       [libdefaults]
+               name_canon_rules = as-is:
+
+1. Uncomment the pam_krb5.so lines
+   ([[!template id=man name="pam_krb5" section="8"]]) in
+   /etc/pam.d/display_manager.
+
+Now log out and log back in again as jruser@EXAMPLE.COM, and see with
+[[!template id=man name="klist" section="1"]] that you automatically
+got tickets!
+
+- Note: The keytab is required for local login security.
+  If you are willing to rely only on physical security of the machine,
+  and use local login strictly as a convenience to get tickets for
+  yourself without actually authenticating whoever is typing on the
+  keyboard, you can skip the keytab and set the `allow_kdc_spoof`
+  option on the pam_krb5.so line in /etc/pam.d/display_manager.
+  See [[!template id=man name="pam.conf" section="5"]] and
+  [[!template id=man name="pam_krb5" section="8"]] for more
+  information.
+
+- Note: If your local login name does not match your Kerberos principal
+  name in the realm, you can configure `auth_to_local` mappings in
+  /etc/krb5.conf, and control which principals are allowed to log in as
+  your local login name by adding them one per line in ~/.k5login.
+  See [[!template id=man name="krb5.conf" section="5"]] for more
+  information.

--- /dev/null	2023-09-18 20:32:00.487406898 +0000
+++ wikisrc/users/mbalmer/blog.mdwn	2023-09-18 20:32:43.815115867 +0000
@@ -0,0 +1,18 @@
+This page is a mirror of my blog at www.vnode.ch. It pulls in articles from
+blog's feed and publishes them here (with a feed, too).
+
+<!--
+[[!aggregate
+name="Marc Balmer's Blog"
+dir="blog"
+url="http://www.vnode.ch/"
+feedurl="http://www.vnode.ch/rss.xml"
+tag="blog"
+]]
+-->
+
+[[!inline
+pages="internal(./blog/*)"
+description="Marc Balmer's Blog"
+]]
+

I found that a 2019 Dell UHD 630 successfully detected 4 different
resolutions, 3 ancient and 1 modern; mention the details in case it is
helpful.

Note why gop 0 isn't the default, even though it seems to work in
almost all cases.

Members: 
	tutorials/x11/how_to_use_wsfb_uefi_bios_framebuffer.md:1.4->1.5 

Index: wikisrc/tutorials/x11/how_to_use_wsfb_uefi_bios_framebuffer.md
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/x11/how_to_use_wsfb_uefi_bios_framebuffer.md,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- wikisrc/tutorials/x11/how_to_use_wsfb_uefi_bios_framebuffer.md	16 Aug 2022 11:17:26 -0000	1.4
+++ wikisrc/tutorials/x11/how_to_use_wsfb_uefi_bios_framebuffer.md	21 Aug 2023 12:31:40 -0000	1.5
@@ -48,7 +48,9 @@
 >
 ```
 
-The `*` indicates the (safe) mode that the bootloader will use by default. Note that on my laptop, mode `0` has a pitch (aka stride) of 1376 pixels. This means that on my graphics card (Asus X202E laptop), the framebuffer is _linear_, but, **not** fully contiguous. The 10 unusable pixels at the end of each row have to taken into account, or else, you'll be treated to a characteristic jagged, streaky display.
+The `*` indicates the (safe) mode that the bootloader will use by default.  Generally, if the UEFI/BIOS is working properly, it will have queried the monitor via EDID and populated the list of modes from that.   On a 2019-era Dell with Intel UHD 630, it successfully detected 1680x1050, 1280x1024, and 1600x1200 over VGA (3 separate old monitors) and 2560x1440 over DisplayPort, and worked with all of them.
+
+Note that on one laptop, mode `0` has a pitch (aka stride) of 1376 pixels. This means that on this graphics card (Asus X202E laptop), the framebuffer is _linear_, but, **not** fully contiguous. The 10 unusable pixels at the end of each row have to taken into account, or else, you'll be treated to a characteristic jagged, streaky display.
 
 Choose the best mode, which is generally mode `0`:
 
@@ -68,7 +70,7 @@
 >
 ```
 
-If the mode you've chosen works, then you can add that `gop 0` or `vesa mode` command to `boot.cfg` so that it is activated automatically.
+If the mode you've chosen works, then you can add that `gop 0` or `vesa mode` command to `boot.cfg` so that it is activated automatically.   This is not the default because if the UEFI/BIOS is buggy it is difficult to deal with.
 
 This is what `dmesg` will show, if you've disabled DRM (see below), or don't have it:
 

Explain the issues with importing and disklabel partitions more
clearly.

Members: 
	zfs.mdwn:1.46->1.47 

Index: wikisrc/zfs.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/zfs.mdwn,v
retrieving revision 1.46
retrieving revision 1.47
diff -u -r1.46 -r1.47
--- wikisrc/zfs.mdwn	1 Aug 2023 21:36:44 -0000	1.46
+++ wikisrc/zfs.mdwn	21 Aug 2023 10:58:31 -0000	1.47
@@ -23,29 +23,31 @@
 NetBSD-8 has an old version of ZFS, and it is not recommended for use
 at all.  There is no evidence that anyone is interested in helping
 with ZFS on 8.  Those wishing to use ZFS on NetBSD 8 should therefore
-update to NetBSD-9.
+update to NetBSD-9.  This page therefore contains no useful status or
+hints about 8.
 
 ## NetBSD-9
 
 NetBSD-9 has ZFS that is considered to work well.  There have been
 fixes since 9.0_RELEASE.  As always, people running NetBSD-9 are
 likely best served by the most recent version of the netbsd-9 stable
-branch.  As of 2021-03, ZFS in the NetBSD 9.1 release is very close to
-netbsd-9, except that the mkdir fix is newly in netbsd-9.
+branch.  This page assumes anyone using 9 is using 9.3 or netbsd-9
+after 9.3; issues fixed in earlier versions have been removed.
 
-There was a crash with mkdir over NFS with maproot, resolved in March
-2021 in 9 and current.  See http://gnats.netbsd.org/55042
+Extended attributes are not supported.
+\todo Link to PR.
 
 There is a workaround where removing a file will commit the ZIL
 (normally this would not be done), to avoid crashes due to vnode
-reclaims.  \todo Link to PR.
+reclaims.
+\todo Link to PR.
 
 There has been a report of an occasional panic somewhere in
 zfs_putpages.
 
 ## NetBSD-10
 
-NetBSD-10 (as of 2023-07) probably has similar ZFS code to 9.
+NetBSD-10 (as of 2023-07) very likely has similar ZFS code to 9.
 
 There is initial support for [[ZFS root|Root_on_zfs]], via booting
 from ffs and pivoting.
@@ -168,29 +170,24 @@
 will only try to do 4096-byte writes.  \todo Verify this and find the
 actual change and explain better.
 
-## pool importing problems
+## pool importing problems with disklabel partitions
 
 While one can "zpool pool0 /dev/wd0f" and have a working pool, this
-pool cannot be exported and imported straigthforwardly.  "zpool
-export" works fine, and deletes zpool.cache.  "zpool import", however,
-only looks at entire disks (e.g. /dev/wd0), and might look at slices
-(e.g. /dev/dk0).  It does not look at partitions like /dev/wd0f, and
-there is no way on the command line to ask that specific devices be
-examined.  Thus, export/import fails for pools with disklabel
-partitions.
-
-One can make wd0 be a link to wd0f temporarily, and the pool will then
-be importable.  However, "wd0" is stored in zpool.cache and on the
-next boot that will attempt to be used.  This is obviously not a good
-approach.
-
-One an mkdir e.g. /etc/zfs/pool0 and in it have a symlink to
-/dev/wd0f.  Then, zpool import -d /etc/zfs/pool0 will scan
-/etc/zfs/pool0/wd0f and succeed.  The resulting zpool.cache will have
-that path, but having symlinks in /etc/zfs/POOLNAME seems acceptable.
-
-\todo Determine a good fix, perhaps man page changes only, fix it
-upstream, in curent/10/9, before removing this discussion.
+pool cannot (after having been exported) be imported
+straigthforwardly.  "zpool export" works fine, and deletes
+zpool.cache.  "zpool import", however, only looks at entire disks
+(e.g. /dev/wd0), and wedges (e.g. /dev/dk0).  It does not look at
+partitions like /dev/wd0f.
+
+One an mkdir e.g. `/etc/zfs/pool0` and in it have a symlink to
+`/dev/wd0f`.  Then, `zpool import -d /etc/zfs/pool0` will scan
+`/etc/zfs/pool0/wd0f` and succeed.  The resulting `zpool.cache` will
+have that path, but having symlinks in /etc/zfs/POOLNAME seems
+acceptable.
+
+\todo Link to a PR that says that the `zpool import` man page claims
+that devices in `/dev` are searched, when disklabel partitions are
+excluded.
 
 ## mountpoint conventions
 

Index: wikisrc/users/mlelstv/sandbox.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/mlelstv/sandbox.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/users/mlelstv/sandbox.mdwn	10 Sep 2017 12:27:45 -0000	1.2
+++ wikisrc/users/mlelstv/sandbox.mdwn	20 Aug 2023 12:59:36 -0000	1.3
@@ -1,3 +1,5 @@
 sandy boxy
 
 test 2 3 4
+
+toast 4 5 6

--- wikisrc/users/mbalmer/blog.mdwn	2023-09-18 20:32:45.167123644 +0000
+++ /dev/null	2023-09-18 20:32:00.487406898 +0000
@@ -1,18 +0,0 @@
-This page is a mirror of my blog at www.vnode.ch. It pulls in articles from
-blog's feed and publishes them here (with a feed, too).
-
-<!--
-[[!aggregate
-name="Marc Balmer's Blog"
-dir="blog"
-url="http://www.vnode.ch/"
-feedurl="http://www.vnode.ch/rss.xml"
-tag="blog"
-]]
--->
-
-[[!inline
-pages="internal(./blog/*)"
-description="Marc Balmer's Blog"
-]]
-
Index: wikisrc/users/mlelstv/supported-video.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/mlelstv/supported-video.mdwn,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- wikisrc/users/mlelstv/supported-video.mdwn	23 Sep 2014 11:40:48 -0000	1.4
+++ wikisrc/users/mlelstv/supported-video.mdwn	20 Aug 2023 12:57:44 -0000	1.5
@@ -1,6 +1,6 @@
 # Support video systems
 
-This is not a complete list, just what is known to me.
+This is never a complete list, just what is known to me.
 
 <table>
 <tr>

Index: wikisrc/releng/netbsd-10.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/releng/netbsd-10.mdwn,v
retrieving revision 1.93
retrieving revision 1.94
diff -u -r1.93 -r1.94
--- wikisrc/releng/netbsd-10.mdwn	20 Jul 2023 12:05:21 -0000	1.93
+++ wikisrc/releng/netbsd-10.mdwn	20 Aug 2023 12:01:26 -0000	1.94
@@ -34,7 +34,7 @@
 
 * ~~[[!template id=pr number=53126]]: uefi boot breaks graphics~~
 * [[!template id=pr number=56566]]: amdgpu/drm: X screen corruption, resets and errors
-* [[!template id=pr number=56648]]: i915drmkms fails to detect output (needs pullup)
+* ~~[[!template id=pr number=56648]]: i915drmkms fails to detect output (needs pullup)~~
 * [[!template id=pr number=56672]]: i915drmkms hangs on boot
 * [[!template id=pr number=56724]]: Thinkpad x260 hard-hang during boot w/ i915drmkms
 * [[!template id=pr number=56729]]: amdgpu X driver nearly (but not quite) working
@@ -122,8 +122,9 @@
 
 ## Current status and timeline
 
-* branch has been created, no fixed date for release yet
-* pullups are being processed, autobuilds are running (including arm images)
+* we seem to be close to what we realistically can get for 10.0
+* considering switching to release candidate state mid september
+* if all goes well, this could result in a 10.0 release in early october
 
 ## Last netbsd-10 Test Results overview
 For all tests, see [releng's tests page](//releng.netbsd.org/test-results.html).
@@ -135,19 +136,19 @@
   <tbody>
     <tr>
         <td><a href="//www.netbsd.org/~martin/aarch64-atf-netbsd10/">aarch64</a>, real hardware</td>
-        <td>2023-06-22</td><td>2</td><td> </td>
+        <td>2023-08-17</td><td>2</td><td> </td>
     </tr>
     <tr>
         <td><a href="//www.netbsd.org/~martin/sparc64-atf-netbsd10/">sparc64</a>, real hardware</td>
-        <td>2023-06-23</td><td>6</td><td> </td>
+        <td>2023-08-17</td><td>6</td><td> </td>
     </tr>
     <tr>
         <td><a href="//www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/netbsd-10/">xen</a></td>
-        <td>2023-06-21</td> <td>8</td><td></td>
+        <td>2023-08-04</td> <td>8</td><td></td>
     </tr>
     <tr>
         <td><a href="//www.netbsd.org/~martin/evbarm-atf-netbsd10/">evbarm</a>, real hardware</td>
-        <td>2023-06-22</td><td>63</td><td></td>
+        <td>2023-08-17</td><td>77</td><td></td>
     </tr>
   </tbody>
 </table>

--- /dev/null	2023-09-18 20:32:00.487406898 +0000
+++ wikisrc/users/charlotte.mdwn	2023-09-18 20:32:45.957099086 +0000
@@ -0,0 +1 @@
+Hola, this is Charlotte's spot

Index: wikisrc/Installation_on_UEFI_systems.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/Installation_on_UEFI_systems.mdwn,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- wikisrc/Installation_on_UEFI_systems.mdwn	14 Aug 2023 19:56:34 -0000	1.6
+++ wikisrc/Installation_on_UEFI_systems.mdwn	15 Aug 2023 13:19:07 -0000	1.7
@@ -25,7 +25,7 @@
 
 After booting from the USB stick there is nothing special you need to do to get UEFI booting set up properly. The installer will recognize the way you booted your install medium (either BIOS or UEFI) and prepare the installation on your hard disk for the same boot method.
 
-NB: If for some reason you have booted via BIOS and want to install UEFI, you will have to do it manually; see the NetBSD 8 section.  But try to boot the USB stick the same way you want the installation.  Typically, this will just work.
+NB: If for some reason you have booted via BIOS and want to install UEFI, you will have to do it manually; see the NetBSD 8 section.  But try to boot the USB stick the same way you want the installation.  Typically, this will just work.  Beware that some systems may have confusing UEFI/BIOS screens that imply that you need to enable legacy mode to boot from USB, but typically UEFI from USB will work straightforwardly.  Disabling "Secure Boot" is necessary, and typically that is all that is needed.
 
 First you need to select the target disk. The installation USB stick will usually show up as sd0.
 

Index: wikisrc/Installation_on_UEFI_systems.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/Installation_on_UEFI_systems.mdwn,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- wikisrc/Installation_on_UEFI_systems.mdwn	14 Aug 2023 17:22:28 -0000	1.5
+++ wikisrc/Installation_on_UEFI_systems.mdwn	14 Aug 2023 19:56:34 -0000	1.6
@@ -3,7 +3,7 @@
 Modern x86 machines have UEFI instead of BIOS firmware.
 The boot procedure is slightly different, and the installation needs to take care of this.   The boot process for pre-UEFI systems is usually called "MBR".
 
-Starting with NetBSD 9.0 the installer should be able to handle this automatically. Earlier NetBSD versions were able to boot in this setups, but needed a bit of manual help to get everything installed.   The main part of this page assumes 9, and a recent version of 9.
+Starting with NetBSD 9.0 the installer should be able to handle this automatically. Earlier NetBSD versions were able to boot in this setups, but needed a bit of manual help to get everything installed.   The main part of this page assumes a recent version of 9, or 10 or current.
 
 NetBSD/amd64 provides two installation images:
 `NetBSD-9.3_STABLE-amd64-install.img.gz` and

Members: 
	Installation_on_UEFI_systems.mdwn:1.4->1.5 

Index: wikisrc/Installation_on_UEFI_systems.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/Installation_on_UEFI_systems.mdwn,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- wikisrc/Installation_on_UEFI_systems.mdwn	11 Feb 2020 11:03:02 -0000	1.4
+++ wikisrc/Installation_on_UEFI_systems.mdwn	14 Aug 2023 17:22:28 -0000	1.5
@@ -1,17 +1,23 @@
 # Installing NetBSD on a x86 system with UEFI
 
 Modern x86 machines have UEFI instead of BIOS firmware.
-The boot procedure is slightly different, and the installation needs to take care of this.
+The boot procedure is slightly different, and the installation needs to take care of this.   The boot process for pre-UEFI systems is usually called "MBR".
 
-Starting with NetBSD 9.0 the installer should be able to handle this automatically. Earlier NetBSD versions were able to boot in this setups, but needed a bit manual help to get everything installed.
+Starting with NetBSD 9.0 the installer should be able to handle this automatically. Earlier NetBSD versions were able to boot in this setups, but needed a bit of manual help to get everything installed.   The main part of this page assumes 9, and a recent version of 9.
 
-As of now NetBSD/amd64 provide separate images for installation, depending on how your machine boots. This will be integrated into a single image in the (near?) future. If you look at the <a href="//nycdn.NetBSD.org/pub/NetBSD-daily/HEAD/latest/images/">images</a> directory of your NetBSD release you will find 
-a `NetBSD-XXX-amd64-uefi-install.img.gz`, which is intended to be written to a USB disk and booted via UEFI. Alternatively there are `NetBSD-XXX-amd64-install.img.gz` and `NetBSD-XXX-i386-install.img.gz`, also intended to be written to USB sticks and booted via BIOS. Or if your machine has a DVD drive, there are `NetBSD-XXX-i386.iso` and `NetBSD-XXX-amd64.iso`, intended to be burned to a CD or DVD.
+NetBSD/amd64 provides two installation images:
+`NetBSD-9.3_STABLE-amd64-install.img.gz` and
+`NetBSD-9.3_STABLE-amd64-bios-install.img.gz`.
+The former should boot either via UEFI or MBR, and the latter is MBR
+only, provided for use when the combined image is problematic.
+
+If you look at the <a href="//nycdn.NetBSD.org/pub/NetBSD-daily/HEAD/latest/images/">images</a> directory of your NetBSD release you will find 
+these images, intended to be written to USB sticks and booted via UEFI or BIOS.   For machines with a DVD drive, there are `NetBSD-XXX-i386.iso` and `NetBSD-XXX-amd64.iso`, intended to be burned to a CD or DVD.
 
 Preparing the USB medium on NetBSD works like this:
 
-        # gunzip NetBSD-9.0-amd64-uefi-install.img.gz
-        # sudo dd if=NetBSD-9.0-amd64-uefi-install.img of=/dev/rsd0d bs=1m conv=sync
+        # gunzip NetBSD-9.0-amd64-install.img.gz
+        # sudo dd if=NetBSD-9.0-amd64-install.img of=/dev/rsd0d bs=1m conv=sync
 
 If you do not (yet) have a NetBSD machine installed, you can use <a href="//www.NetBSD.org/~martin/rawrite32">Rawrite32</a> on a Windows machine.
 
@@ -19,6 +25,8 @@
 
 After booting from the USB stick there is nothing special you need to do to get UEFI booting set up properly. The installer will recognize the way you booted your install medium (either BIOS or UEFI) and prepare the installation on your hard disk for the same boot method.
 
+NB: If for some reason you have booted via BIOS and want to install UEFI, you will have to do it manually; see the NetBSD 8 section.  But try to boot the USB stick the same way you want the installation.  Typically, this will just work.
+
 First you need to select the target disk. The installation USB stick will usually show up as sd0.
 
 ![screenshot of sysinst disk selection](https://netbsd.org/images/misc/uefi/uefi9_01.png "Select Disk")
@@ -37,9 +45,9 @@
 
 ## Installing NetBSD 8 on a x86 system with UEFI
 
-Unfortunately the installer on the netbsd-8 branch does not fully support an UEFI setup.
+Unfortunately the installer on the netbsd-8 branch does not fully support an UEFI setup.   Later systems do support, but won't install UEFI if booted via MBR.
 
-The tutorial below shows (__only for NetBSD 8.x!__) how to semi-manually do it. For simplicity we assume that you have booted the UEFI install image from a USB stick and want to install NetBSD onto the whole disk in the machine.
+The tutorial below shows (__only for NetBSD 8.x and cross-method!__) how to semi-manually do it. For simplicity we assume that you have booted the UEFI install image from a USB stick and want to install NetBSD onto the whole disk in the machine.
 
 ### Getting out of the Installer
 
@@ -115,6 +123,8 @@
 
 So now that we have identified the disk and got the details, we need to plan our disk layout.
 
+The UEFI partition should be FAT32.  It should be aligned to 1 MB (2048 sectors) and thus start at sector 2048.  There may or may not be a requirement that it be early in the disk, but that's where every other system puts it so just do it that way unless you are trying to stress the system fo ind out what works.   The size should be at least 128 MiB (128*1024*1024 bytes), and can be up to around 550 MiB.  A native 4K disk needs 260 MiB.  This is because FAT32 minimum size is 65527 sectors. The point is that the  machine's firmware has to read it, so you want to make that smooth.
+
 We will need two partitions, one for UEFI to boot from, and the NetBSD root disk partition. Depending on planned use for the machine, we also will want a swap partition. This should not be smaller than the machine's RAM size, so in case of a kernel panic a crash dump can be saved and recovered on next reboot. For this example let us calculate with 8 GB RAM and no special needs for more swap.
 
 So we have a 30 GB disk, we subtract 8 GB of swap and a bit of space for the UEFI boot partition. That leaves us with (rounded down) 21 GB of space for the main NetBSD partition.

Index: wikisrc/symbol_versions.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/symbol_versions.mdwn,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- wikisrc/symbol_versions.mdwn	5 Jan 2021 02:23:32 -0000	1.5
+++ wikisrc/symbol_versions.mdwn	9 Aug 2023 10:45:38 -0000	1.6
@@ -177,6 +177,13 @@
   existing programs compiled with `time@NetBSD_6` would continue to get
   the semantics they were built against.
 
+  Unfortunately, setting only a non-default version doesn't work to
+  compatibly remove obsolete symbols that never had versions in the
+  first place.
+  If a program was already linked with a reference to an unversioned
+  symbol, the runtime loader will refuse to resolve that reference by
+  the non-default version.
+
 - When a program uses
   [[!template id=man name="dlsym" section="3"]],
   it always gets the default version, if any.

Index: wikisrc/users/jun.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/jun.mdwn,v
retrieving revision 1.129
retrieving revision 1.130
diff -u -r1.129 -r1.130
--- wikisrc/users/jun.mdwn	3 Aug 2023 02:05:04 -0000	1.129
+++ wikisrc/users/jun.mdwn	4 Aug 2023 01:43:06 -0000	1.130
@@ -43,7 +43,7 @@
 - 2023 Jul.29 Sat 14:00-14:45 JST (UTC+9) 
 - [[https://event.ospn.jp/osc2023-online-kyoto/session/992861]]
 - [[https://event.ospn.jp/osc2023-online-kyoto/]]
-- Join meeting via Youtube video [[https://www.youtube.com/c/OSPNjp]] ROOM C
+- Youtube video [[https://youtu.be/TnviEtERcVw]]
 - Join meeting via ZOOM [[https://ospn.connpass.com/event/287988]]
 - Tour Guide [[https://cdn.netbsd.org/pub/NetBSD/misc/jun/OSC/OSC2023kyoto.pdf]]
 - togetter [[https://togetter.com/li/2189221]]

Index: wikisrc/users/jun.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/jun.mdwn,v
retrieving revision 1.128
retrieving revision 1.129
diff -u -r1.128 -r1.129
--- wikisrc/users/jun.mdwn	21 Jul 2023 02:38:50 -0000	1.128
+++ wikisrc/users/jun.mdwn	3 Aug 2023 02:05:04 -0000	1.129
@@ -4,27 +4,11 @@
 
 # 2023
 
-## Open Source Conference 2023 Kyoto NetBSD Booth
-- 2023 Jul.22 Sat 10:00-16:00 JST (UTC+9) 
-- Kyoto Research Park [[https://www.krp.co.jp/access/map.html]]
-- [[https://event.ospn.jp/osc2023-kyoto/]]
-- [[https://ospn.connpass.com/event/287987]]
-- Tour Guide [[]]
-- togetter [[https://togetter.com/li/2189221]]
-
-## Open Source Conference 2023 Online/Kyoto NetBSD BoF
-- 2023 Jul.29 Sat 14:00-14:45 JST (UTC+9) 
-- [[https://event.ospn.jp/osc2023-online-kyoto/session/992861]]
-- [[https://event.ospn.jp/osc2023-online-kyoto/]]
-- Join meeting via Youtube video [[https://www.youtube.com/c/OSPNjp]] ROOM C
-- Join meeting via ZOOM [[https://ospn.connpass.com/event/287988]]
-- Tour Guide [[]]
-- togetter [[https://togetter.com/li/2189221]]
-
 ## Open Developers Conference 2023 NetBSD BoF
 - 2023 Aug.26 Sat XX:00-XX:45 JST (UTC+9)
 - docomo R&D OPEN LAB ODAIBA [[https://docomo-openlab.jp/about/#access]]
 - [[https://event.ospn.jp/odc2023/]]
+- [[https://ospn.connpass.com/event/291437/]]
 - Tour Guide [[]]
 - togetter [[]]
 
@@ -55,6 +39,24 @@
 
 # Past Events in 2023
 
+## Open Source Conference 2023 Online/Kyoto NetBSD BoF
+- 2023 Jul.29 Sat 14:00-14:45 JST (UTC+9) 
+- [[https://event.ospn.jp/osc2023-online-kyoto/session/992861]]
+- [[https://event.ospn.jp/osc2023-online-kyoto/]]
+- Join meeting via Youtube video [[https://www.youtube.com/c/OSPNjp]] ROOM C
+- Join meeting via ZOOM [[https://ospn.connpass.com/event/287988]]
+- Tour Guide [[https://cdn.netbsd.org/pub/NetBSD/misc/jun/OSC/OSC2023kyoto.pdf]]
+- togetter [[https://togetter.com/li/2189221]]
+
+## Open Source Conference 2023 Kyoto NetBSD Booth
+- 2023 Jul.22 Sat 10:00-16:00 JST (UTC+9) 
+- Kyoto Research Park [[https://www.krp.co.jp/access/map.html]]
+- [[https://event.ospn.jp/osc2023-kyoto/]]
+- [[https://ospn.connpass.com/event/287987]]
+- Tour Guide [[https://cdn.netbsd.org/pub/NetBSD/misc/jun/OSC/OSC2023kyoto.pdf]]
+- togetter [[https://togetter.com/li/2189221]]
+
+
 ## Open Source Conference 2023 Hokkaido NetBSD Booth
 - 2023 Jun.24 Sat 11:00-16:00 JST (UTC+9) 
 - Sapporo Business Innovation Center [[https://www.sapporosansin.jp/access/]]

Index: wikisrc/zfs.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/zfs.mdwn,v
retrieving revision 1.45
retrieving revision 1.46
diff -u -r1.45 -r1.46
--- wikisrc/zfs.mdwn	30 Jul 2023 23:59:31 -0000	1.45
+++ wikisrc/zfs.mdwn	1 Aug 2023 21:36:44 -0000	1.46
@@ -82,10 +82,11 @@
 ### Excessive ARC usage
 
 The upstream code sets the max ARC size (and hence the initial target)
-all but 1 GB.  This results in consuming excessive amounts of memory
-on systems with less than about 8 GB, and systems of 4 GB and lower
-have been observed to lock up.  Patches to change this behavior have
-been sent to `netbsd-users@`.
+to all but 1 GB.  This results in consuming excessive amounts of
+memory on systems with less than about 8 GB, and systems of 4 GB and
+lower have been observed to lock up.  It seems likely that even
+high-memory systems would have trouble if enough data were paged in.
+Patches to change this behavior have been sent to `netbsd-users@`.
 
 See the section "Memory Usage", below.
 

Index: wikisrc/tutorials.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials.mdwn,v
retrieving revision 1.48
retrieving revision 1.49
diff -u -r1.48 -r1.49
--- wikisrc/tutorials.mdwn	16 Dec 2022 16:02:12 -0000	1.48
+++ wikisrc/tutorials.mdwn	1 Aug 2023 09:35:39 -0000	1.49
@@ -44,7 +44,7 @@
 * [[Testing new wifi]]
 * [[Converting drivers to the new wifi stack]]
 * [[Converting USB drivers to usbwifi(9)]]
-* [[Driver state matrix]]
+* (Current state of wifi drivers)[../wifi driver state matrix]
 
 ### Testing
 * [[atf]]

Index: wikisrc/zfs.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/zfs.mdwn,v
retrieving revision 1.44
retrieving revision 1.45
diff -u -r1.44 -r1.45
--- wikisrc/zfs.mdwn	28 Jul 2023 00:58:15 -0000	1.44
+++ wikisrc/zfs.mdwn	30 Jul 2023 23:59:31 -0000	1.45
@@ -72,9 +72,35 @@
 and aarch64 on netbsd-9.  In 10 and current, it is also default on
 sparc64.
 
-More or less, zfs can be enabled on an architecture when it is known
-to build and run reliably.  (Of course, users are welcome to build it
-and report.)
+More or less, it is acceptable to commit enabling zfs on an
+architecture when it is known to build and run reliably.  (Of course,
+anyone is welcome to build it and use it, and reports of success or
+unexpected failure are welcome.)
+
+## Known Problems
+
+### Excessive ARC usage
+
+The upstream code sets the max ARC size (and hence the initial target)
+all but 1 GB.  This results in consuming excessive amounts of memory
+on systems with less than about 8 GB, and systems of 4 GB and lower
+have been observed to lock up.  Patches to change this behavior have
+been sent to `netbsd-users@`.
+
+See the section "Memory Usage", below.
+
+### Difficulty freeing metadata
+
+FreeBSD has a function `arc_dnlc_evicts_thread`.  This has something
+to do with freeing objects not in ZFS that refer to metadata entries
+in the ARC, which keeps them from being evictable.  A work item is to
+understand this and adapt it to NetBSD.
+
+### Draining under memory pressure
+
+There should be a mechanism to shrink the ARC under memory pressure.
+FreeBSD hooks in a drain procedure to do this.  A work item is to
+understand this and adapt it.
 
 # Quick Start
 

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.210
retrieving revision 1.211
diff -u -r1.210 -r1.211
--- wikisrc/ports/xen/howto.mdwn	9 Jul 2023 11:12:11 -0000	1.210
+++ wikisrc/ports/xen/howto.mdwn	29 Jul 2023 23:40:24 -0000	1.211
@@ -428,6 +428,12 @@
 Entropy in domUs can be an issue; physical disks and network are on
 the dom0.  NetBSD's /dev/random system works, but is often challenged.
 
+NB: When creating a domU, free memory is consumed in the amount
+specified in the config file, provided to the domU, and 8 MB
+additional.  If that 8 MB is not available (e.g. domU configured RAM
+equals `xl list` free amount), the domU will crash in a confusing
+manner.  \todo File a bug report.
+
 ## Config files
 
 See /usr/pkg/share/examples/xen/xlexample* for a very small number of

Index: wikisrc/zfs.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/zfs.mdwn,v
retrieving revision 1.43
retrieving revision 1.44
diff -u -r1.43 -r1.44
--- wikisrc/zfs.mdwn	30 May 2023 15:04:20 -0000	1.43
+++ wikisrc/zfs.mdwn	28 Jul 2023 00:58:15 -0000	1.44
@@ -10,21 +10,25 @@
 
 This HOWTO describes the most recent state of branches, and does not
 attempt to describe formal releases.  This is a clue; if you are using
-NetBSD 9 and ZFS, you should update along the branch.
+NetBSD-9 and ZFS, you should update along the branch.  Writing
+"NetBSD-10" is a further clue.
+
+This HOWTO errs on the side of saying things if they seem 90-95% true.
+Feel free to complain if you think something is wrong!
 
 # Status of ZFS in NetBSD
 
-## NetBSD 8
+## NetBSD-8
 
-NetBSD 8 has an old version of ZFS, and it is not recommended for use
+NetBSD-8 has an old version of ZFS, and it is not recommended for use
 at all.  There is no evidence that anyone is interested in helping
 with ZFS on 8.  Those wishing to use ZFS on NetBSD 8 should therefore
-update to NetBSD 9.
+update to NetBSD-9.
 
-## NetBSD 9
+## NetBSD-9
 
 NetBSD-9 has ZFS that is considered to work well.  There have been
-fixes since 9.0_RELEASE.  As always, people running NetBSD 9 are
+fixes since 9.0_RELEASE.  As always, people running NetBSD-9 are
 likely best served by the most recent version of the netbsd-9 stable
 branch.  As of 2021-03, ZFS in the NetBSD 9.1 release is very close to
 netbsd-9, except that the mkdir fix is newly in netbsd-9.
@@ -39,21 +43,25 @@
 There has been a report of an occasional panic somewhere in
 zfs_putpages.
 
-## NetBSD-current
+## NetBSD-10
 
-NetBSD-current (as of 2021-03) has similar ZFS code to 9.
+NetBSD-10 (as of 2023-07) probably has similar ZFS code to 9.
 
 There is initial support for [[ZFS root|Root_on_zfs]], via booting
 from ffs and pivoting.
 
+## NetBSD-current
+
+NetBSD-current (as of 2023-07) has similar ZFS code to 10.
+
 ## NetBSD/xen special issues
 
-Summary: if you are using NetBSD, xen and zfs, use NetBSD-current.
+Summary: if you are using NetBSD, xen and zfs, use NetBSD-10 or newer.
 
 In NetBSD-9, MAXPHYS is 64KB in most places, but because of xbd(4) it
 is set to 32KB for XEN kernels.  Thus the standard zfs kernel modules
-do not work under xen.  In NetBSD-current, xbd(4) supports 64 KB
-MAXPHYS and this is no longer an issue.  Xen and zfs on current are
+do not work under xen.  In NetBSD-10 and newer, xbd(4) supports 64 KB
+MAXPHYS and this is no longer an issue.  Xen and zfs on 10/current are
 reported to work well together, as of 2021-02.
 
 ## Architectures
@@ -61,7 +69,8 @@
 Most people seem to be using amd64.
 
 To build zfs, one puts MKZFS=yes in mk.conf.  This is default on amd64
-and aarch64 on netbsd-9.  In current, it is also default on sparc64.
+and aarch64 on netbsd-9.  In 10 and current, it is also default on
+sparc64.
 
 More or less, zfs can be enabled on an architecture when it is known
 to build and run reliably.  (Of course, users are welcome to build it
@@ -154,7 +163,7 @@
 that path, but having symlinks in /etc/zfs/POOLNAME seems acceptable.
 
 \todo Determine a good fix, perhaps man page changes only, fix it
-upstream, in curent, and in 9, before removing this discussion.
+upstream, in curent/10/9, before removing this discussion.
 
 ## mountpoint conventions
 
@@ -166,13 +175,13 @@
 
 ## mount order
 
-NetBSD 9 mounts other file systems and then ZFS file systems.  This can
+NetBSD-9 mounts other file systems and then ZFS file systems.  This can
 be a problem if /usr/pkgsrc is on ZFS and /usr/pkgsrc/distfiles is on
 NFS.  A workaround is to use noauto and do the mounts in
 /etc/rc.local.
 
-NetBSD current after 20200301 mounts ZFS first.  The same issues and
-workarounds apply in different circumstances.
+NetBSD current after 20200301, and thus NetBSD-10 mounts ZFS first.
+The same issues and workarounds apply in different circumstances.
 
 ## NFS
 
@@ -182,13 +191,9 @@
 The "zfs share" command adds a line for each filesystem with the
 sharenfs property set to /etc/zfs/exports, and "zfs unshare" removes
 it.  This file is ignored on NetBSD-9 and current before 20210216; on
-current after 20210216 those filesystems should be exported (assuming
-NFS is enabled).  It does not appear to be possible to set options
-like maproot and network restrictions via this method.
-
-On current before 20210216, a remote mkdir of a filesystem mounted via
--maproot=0:10 causes a kernel NULL pointer dereference.  This is now
-fixed.
+current after 20210216 and thus also 10, those filesystems should be
+exported (assuming NFS is enabled).  It does not appear to be possible
+to set options like maproot and network restrictions via this method.
 
 ## zvol
 
@@ -220,14 +225,39 @@
 # Memory usage
 
 Basically, ZFS uses lots of memory and most people run it on systems
-with large amounts of memory.  NetBSD works well on systems with
-comparatively small amounts of memory.  So a natural question is how
-well ZFS works on one's VAX with 2M of RAM :-) More seriously, one
-might ask if it is reasonable to run ZFS on a RPI3 with 1G of RAM, or
-if it is reasonable on a system with 4G.
+with large amounts of memory.  This is not specifically about NetBSD;
+the same "ZFS is piggy" issues arise with other operating systems as
+well.
+
+NetBSD works well on systems with comparatively small amounts of
+memory.  So a natural question is how well ZFS works on one's VAX with
+2 MB of RAM :-).  More seriously, one might ask if it is reasonable to
+run ZFS on a RPI3 with 1G of RAM, or if it is reasonable on an amd64
+system with 4G.
+
+ZFS uses memory for various things, but a particularly significant use
+is ARC, or "Adaptive Replacement Cache".  A limit on ARC is set in the
+kernel at boot.  Enough memory can be consumed that the system
+deadlocks.
 
-The prevailing wisdom is more or less that ZFS consumes 1G plus 1G per
-1T of disk.  32-bit architectures are viewed as too small to run ZFS.
+NetBSD does not have a mechanism to see or set this limit.  FreeBSD
+has tunables, described in [FreeBSD Handbook ZFS Advanced
+section](https://docs.freebsd.org/en/books/handbook/zfs/#zfs-advanced).
+
+ARC usage manifests as pool usage.  A system with 8 GB maxes out
+around 4 GB pool usage (not just ZFS).
+
+Anecdata is that systems with 32 GB never have problems and are
+entirely safe in production.  Problems have not been reported on 16 GB
+systems and they are believed safe.  8 GB systems seem ok, but
+confidence is lower.  4 GB systems are known to lock up.
+
+Several changes would improve behavior:
+  - expose the limit as a sysctl so that an admin can tune it
+  - set the limit based on RAM, to avoid using large fractions of
+    lower-memory machines
+  - enable the system, when under memory pressure, to ask ARC to free
+    memory
 
 Besides RAM, zfs requires that architecture kernel stack size is at
 least 12KB or more -- some operations cause stack overflow with 8KB
@@ -236,13 +266,12 @@
 have 12KB kernel stack. All others use only 8KB stack, which is not
 enough to run zfs.
 
+\todo Try zfs on i386 and see what happens, and report to
+`netbsd-users@`.
+
 NetBSD has many statistics provided via sysctl; see "sysctl
 kstat.zfs".
 
-FreeBSD has tunables that NetBSD does not seem to have, described in
-[FreeBSD Handbook ZFS Advanced
-section](https://docs.freebsd.org/en/books/handbook/zfs/#zfs-advanced).
-
 # Interoperability with other systems
 
 Modern ZFS uses pool version 5000 and feature flags.

--- wikisrc/Driver_state_matrix.mdwn	2023-09-18 20:32:50.335582335 +0000
+++ /dev/null	2023-09-18 20:32:00.487406898 +0000
@@ -1,50 +0,0 @@
-# Current state of wifi drivers
-
-We currently have 26 wifi drivers in the source tree. A few of them have already been converted for the wifi renewal branch (see [[Wifi renewal on hg]], [[Converting drivers to the new wifi stack]], and [[tutorials/Converting USB drivers to usbwifi(9)]].).
-
-| Device 		 		| at 			| usbwifi	| converted	| tested	|
-|---------------------------------------|-----------------------|---------------|---------------|---------------|
-| [an](https://man.NetBSD.org/an.4)	| pci, pcmcia[1], isapnp | -		| no		| no		|
-| [ath](https://man.NetBSD.org/ath.4)	| pci[1], cardbus[1]	| -		| no		| no		|
-| [athn](https://man.NetBSD.org/athn.4)	| pci[1], cardbus, usb[1]| +/-/?		| no		| no		|
-| [atu](https://man.NetBSD.org/atu.4)	| usb[1]		| +		| no		| no		|
-| [atw](https://man.NetBSD.org/atw.4)	| pci, cardbus[1]	| -		| no		| no		|
-| [awi](https://man.NetBSD.org/awi.4)	| pcmcia		| -		| no		| no		|
-| [bwfm](https://man.NetBSD.org/bwfm.4)	| pci, sdmmc[1], usb[1]	| +/-/?		| no		| no		|
-| [bwi](https://man.NetBSD.org/bwi.4)	| pci, cardbus[1]	| -		| no		| no		|
-| [ipw](https://man.NetBSD.org/ipw.4)	| pci			| -		| yes		| no		|
-| [iwi](https://man.NetBSD.org/iwi.4)	| pci			| -		| no		| no		|
-| [iwm](https://man.NetBSD.org/iwm.4)	| pci[1]		| -		| yes		| ?		|
-| [iwn](https://man.NetBSD.org/iwn.4)	| pci[1]		| -		| yes		| ?		|
-| [malo](https://man.NetBSD.org/malo.4)	| pci			| -		| no		| no		|
-| [otus](https://man.NetBSD.org/otus.4)	| usb[1]		| +		| no		| no		|
-| [ral](https://man.NetBSD.org/ral.4)	| pci, cardbus[1]	| +/-/?		| no		| no		|
-| [rtw](https://man.NetBSD.org/rtw.4)	| pci, cardbus[1]	| -		| no		| no		|
-| [rtwn](https://man.NetBSD.org/rtwn.4)	| pci[1]		| -		| yes		| yes		|
-| [rum](https://man.NetBSD.org/rum.4)	| usb[1]		| +		| no		| no		|
-| [run](https://man.NetBSD.org/run.4)	| usb[1]		| +		| no		| no		|
-| [upgt](https://man.NetBSD.org/upgt.4)	| usb[1]		| +		| no		| no		|
-| [ural](https://man.NetBSD.org/ral.4)	| usb[1]		| +		| no		| no		|
-| [urtw](https://man.NetBSD.org/urtw.4)	| usb[1]			| +		| no		| no		|
-| [urtwn](https://man.NetBSD.org/urtwn.4) | usb[1]		| +		| yes		| yes		|
-| [wi](https://man.NetBSD.org/wi.4)	| pci, pcmcia[1]	| -		| no		| no		|
-| [wpi](https://man.NetBSD.org/wpi.4)	| pci			| -		| no		| no		|
-| [zyd](https://man.NetBSD.org/zyd.4)	| usb[1]		| +		| no		| no		|
-
-[1] = Martin has hardware in testable condition
-
-usbwifi = + means: the driver will be converted to usbwifi, which is an easy conversion
-
-usbwifi = +/-/? means: at this point it is not clear if the driver (or parts of it) will be able to use usbwifi, the bus frontend vs. backend driver split has to be reviewed to analyze if usbwifi is feaseable/practical and an improvement over manual conversion.
-
-Currently the drivers for urtwn(4) and rtwn(4) are converted, the former using usbwifi (see [[tutorials/Converting USB drivers to usbwifi(9)]]), but it is not clear if there is a unified aproach that lets the usb frontend profit from usbwifi while not stopping the usb and the other frontends from sharing most parts of the driver - this still has to be evaluated.
-
-Other drivers sharing similar chipsets accross different busses including usb have not yet been converted, they are marked with +/-/? in the usbwifi column of above table.
-
-# Looking for hardware
-
-For every chipset without a [1] mark in the table above, I am looking for hardware:
-
- * if you have spare wifi hardware for PCI, pcmcia or cardbus and would be willing to donate it to a good home, please contact me privately (I am in germany, shipping from within europe and UK should be cheap)
-
- * if you have a link where to buy a cheap USB or PCIe wifi dongle with known chipset that is not marked [1] in above table, please also contact me privately
--- /dev/null	2023-09-18 20:32:00.487406898 +0000
+++ wikisrc/wifi_driver_state_matrix.mdwn	2023-09-18 20:32:50.369276341 +0000
@@ -0,0 +1,50 @@
+[[!meta title="Current state of wifi drivers"]]
+
+We currently have 26 wifi drivers in the source tree. A few of them have already been converted for the wifi renewal branch (see [[Wifi renewal on hg]], [[Converting drivers to the new wifi stack]], and [[tutorials/Converting USB drivers to usbwifi(9)]].).
+
+| Device 		 		| at 			| usbwifi	| converted	| tested	|
+|---------------------------------------|-----------------------|---------------|---------------|---------------|
+| [an](https://man.NetBSD.org/an.4)	| pci, pcmcia[1], isapnp | -		| no		| no		|
+| [ath](https://man.NetBSD.org/ath.4)	| pci[1], cardbus[1]	| -		| no		| no		|
+| [athn](https://man.NetBSD.org/athn.4)	| pci[1], cardbus, usb[1]| +/-/?		| no		| no		|
+| [atu](https://man.NetBSD.org/atu.4)	| usb[1]		| +		| no		| no		|
+| [atw](https://man.NetBSD.org/atw.4)	| pci, cardbus[1]	| -		| no		| no		|
+| [awi](https://man.NetBSD.org/awi.4)	| pcmcia		| -		| no		| no		|
+| [bwfm](https://man.NetBSD.org/bwfm.4)	| pci, sdmmc[1], usb[1]	| +/-/?		| no		| no		|
+| [bwi](https://man.NetBSD.org/bwi.4)	| pci, cardbus[1]	| -		| no		| no		|
+| [ipw](https://man.NetBSD.org/ipw.4)	| pci			| -		| yes		| no		|
+| [iwi](https://man.NetBSD.org/iwi.4)	| pci			| -		| no		| no		|
+| [iwm](https://man.NetBSD.org/iwm.4)	| pci[1]		| -		| yes		| ?		|
+| [iwn](https://man.NetBSD.org/iwn.4)	| pci[1]		| -		| yes		| ?		|
+| [malo](https://man.NetBSD.org/malo.4)	| pci			| -		| no		| no		|
+| [otus](https://man.NetBSD.org/otus.4)	| usb[1]		| +		| no		| no		|
+| [ral](https://man.NetBSD.org/ral.4)	| pci, cardbus[1]	| +/-/?		| no		| no		|
+| [rtw](https://man.NetBSD.org/rtw.4)	| pci, cardbus[1]	| -		| no		| no		|
+| [rtwn](https://man.NetBSD.org/rtwn.4)	| pci[1]		| -		| yes		| yes		|
+| [rum](https://man.NetBSD.org/rum.4)	| usb[1]		| +		| no		| no		|
+| [run](https://man.NetBSD.org/run.4)	| usb[1]		| +		| no		| no		|
+| [upgt](https://man.NetBSD.org/upgt.4)	| usb[1]		| +		| no		| no		|
+| [ural](https://man.NetBSD.org/ral.4)	| usb[1]		| +		| no		| no		|
+| [urtw](https://man.NetBSD.org/urtw.4)	| usb[1]			| +		| no		| no		|
+| [urtwn](https://man.NetBSD.org/urtwn.4) | usb[1]		| +		| yes		| yes		|
+| [wi](https://man.NetBSD.org/wi.4)	| pci, pcmcia[1]	| -		| no		| no		|
+| [wpi](https://man.NetBSD.org/wpi.4)	| pci			| -		| no		| no		|
+| [zyd](https://man.NetBSD.org/zyd.4)	| usb[1]		| +		| no		| no		|
+
+[1] = Martin has hardware in testable condition
+
+usbwifi = + means: the driver will be converted to usbwifi, which is an easy conversion
+
+usbwifi = +/-/? means: at this point it is not clear if the driver (or parts of it) will be able to use usbwifi, the bus frontend vs. backend driver split has to be reviewed to analyze if usbwifi is feaseable/practical and an improvement over manual conversion.
+
+Currently the drivers for urtwn(4) and rtwn(4) are converted, the former using usbwifi (see [[tutorials/Converting USB drivers to usbwifi(9)]]), but it is not clear if there is a unified aproach that lets the usb frontend profit from usbwifi while not stopping the usb and the other frontends from sharing most parts of the driver - this still has to be evaluated.
+
+Other drivers sharing similar chipsets accross different busses including usb have not yet been converted, they are marked with +/-/? in the usbwifi column of above table.
+
+# Looking for hardware
+
+For every chipset without a [1] mark in the table above, I am looking for hardware:
+
+ * if you have spare wifi hardware for PCI, pcmcia or cardbus and would be willing to donate it to a good home, please contact me privately (I am in germany, shipping from within europe and UK should be cheap)
+
+ * if you have a link where to buy a cheap USB or PCIe wifi dongle with known chipset that is not marked [1] in above table, please also contact me privately

Index: wikisrc/users/jun.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/jun.mdwn,v
retrieving revision 1.127
retrieving revision 1.128
diff -u -r1.127 -r1.128
--- wikisrc/users/jun.mdwn	19 Jul 2023 01:47:36 -0000	1.127
+++ wikisrc/users/jun.mdwn	21 Jul 2023 02:38:50 -0000	1.128
@@ -5,7 +5,7 @@
 # 2023
 
 ## Open Source Conference 2023 Kyoto NetBSD Booth
-- 2023 Jul.22 Sat 11:00-16:00 JST (UTC+9) 
+- 2023 Jul.22 Sat 10:00-16:00 JST (UTC+9) 
 - Kyoto Research Park [[https://www.krp.co.jp/access/map.html]]
 - [[https://event.ospn.jp/osc2023-kyoto/]]
 - [[https://ospn.connpass.com/event/287987]]
@@ -13,13 +13,45 @@
 - togetter [[https://togetter.com/li/2189221]]
 
 ## Open Source Conference 2023 Online/Kyoto NetBSD BoF
-- 2023 Jul.29 Sat XX:00-XX:45 JST (UTC+9) 
+- 2023 Jul.29 Sat 14:00-14:45 JST (UTC+9) 
+- [[https://event.ospn.jp/osc2023-online-kyoto/session/992861]]
 - [[https://event.ospn.jp/osc2023-online-kyoto/]]
-- [[https://event.ospn.jp/osc2023-online-kyoto/]] Session: TBD
-- Youtube video [[]]
+- Join meeting via Youtube video [[https://www.youtube.com/c/OSPNjp]] ROOM C
+- Join meeting via ZOOM [[https://ospn.connpass.com/event/287988]]
 - Tour Guide [[]]
 - togetter [[https://togetter.com/li/2189221]]
 
+## Open Developers Conference 2023 NetBSD BoF
+- 2023 Aug.26 Sat XX:00-XX:45 JST (UTC+9)
+- docomo R&D OPEN LAB ODAIBA [[https://docomo-openlab.jp/about/#access]]
+- [[https://event.ospn.jp/odc2023/]]
+- Tour Guide [[]]
+- togetter [[]]
+
+## Open Source Conference 2023 Online/Fall BSD BoF
+- 2022 Sep.30 Sat XX:00-XX:45 JST (UTC+9) 
+- [[https://event.ospn.jp/osc2023-online-fall/]]
+- Join meeting via Youtube video [[https://www.youtube.com/c/OSPNjp]]
+- Join meeting via ZOOM [[]]
+- Tour Guide [[]]
+- togetter [[]]
+
+## Open Source Conference 2023 Tokyo/Fall NetBSD Booth
+- 2023 Oct.21 Sat 10:00-16:00 JST (UTC+9)
+- Ota City Industrial Plaza (PiO) [[https://www.pio-ota.net/english-access/]]
+- [[https://event.ospn.jp/osc2023-fall/]]
+- Tour Guide [[]]
+- togetter [[]]
+
+## Kansai Open Forum 2023
+- [[https://www.k-of.jp/]]
+- 2023 Nov.10 Fri. - Nov.11 Sat.
+- Booth and BSD BoF
+- Tour Guide [[]]
+- togetter [[]]
+
+# Nagoya *BSD Users' Group monthly meeting
+- [[http://nagoya.bug.gr.jp/]]
 
 # Past Events in 2023
 
@@ -96,6 +128,9 @@
 - Open Source Conference [[https://www.ospn.jp/]] 
 - OSPN.jp Youtube [[https://www.youtube.com/c/OSPNjp/search?query=NetBSD]]
 - Report on [[http://mail-index.netbsd.org/netbsd-advocacy/tindex.html]]
+- [[https://github.com/ebijun/NetBSD/blob/master/Guide/OSC/OSC2023.rst]]
+- [[https://github.com/ebijun/NetBSD/blob/master/Guide/OSC/OSC2022.rst]]
+- [[https://github.com/ebijun/NetBSD/blob/master/Guide/OSC/OSC2021.rst]]
 - [[https://github.com/ebijun/NetBSD/blob/master/Guide/OSC/OSC2020.rst]]
 - [[https://github.com/ebijun/NetBSD/blob/master/Guide/OSC/OSC2019.rst]]
 - [[https://github.com/ebijun/NetBSD/blob/master/Guide/OSC/OSC2018.rst]]
@@ -109,6 +144,9 @@
 ## NetBSD Raspberry PI Images
 - [[https://github.com/ebijun/NetBSD/blob/master/RPI/RPIimage/Image/README]]
 - [[ftp://ftp.netbsd.org/pub/NetBSD/misc/jun/raspberry-pi/]]
+- [[https://github.com/ebijun/NetBSD/blob/master/Guide/RPI/RPIupdate2023.rst]]
+- [[https://github.com/ebijun/NetBSD/blob/master/Guide/RPI/RPIupdate2022.rst]]
+- [[https://github.com/ebijun/NetBSD/blob/master/Guide/RPI/RPIupdate2021.rst]]
 - [[https://github.com/ebijun/NetBSD/blob/master/Guide/RPI/RPIupdate2020.rst]]
 - [[https://github.com/ebijun/NetBSD/blob/master/Guide/RPI/RPIupdate2019.rst]]
 - [[https://github.com/ebijun/NetBSD/blob/master/Guide/RPI/RPIupdate2018.rst]]

Index: wikisrc/releng/netbsd-10.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/releng/netbsd-10.mdwn,v
retrieving revision 1.92
retrieving revision 1.93
diff -u -r1.92 -r1.93
--- wikisrc/releng/netbsd-10.mdwn	24 Jun 2023 16:45:00 -0000	1.92
+++ wikisrc/releng/netbsd-10.mdwn	20 Jul 2023 12:05:21 -0000	1.93
@@ -34,7 +34,7 @@
 
 * ~~[[!template id=pr number=53126]]: uefi boot breaks graphics~~
 * [[!template id=pr number=56566]]: amdgpu/drm: X screen corruption, resets and errors
-* [[!template id=pr number=56648]]: i915drmkms fails to detect output
+* [[!template id=pr number=56648]]: i915drmkms fails to detect output (needs pullup)
 * [[!template id=pr number=56672]]: i915drmkms hangs on boot
 * [[!template id=pr number=56724]]: Thinkpad x260 hard-hang during boot w/ i915drmkms
 * [[!template id=pr number=56729]]: amdgpu X driver nearly (but not quite) working

Index: wikisrc/tutorials/how_to_enlarge_raidframe.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_enlarge_raidframe.mdwn,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- wikisrc/tutorials/how_to_enlarge_raidframe.mdwn	19 Jul 2023 12:51:45 -0000	1.5
+++ wikisrc/tutorials/how_to_enlarge_raidframe.mdwn	19 Jul 2023 12:57:54 -0000	1.6
@@ -35,32 +35,55 @@
 
 
 There are two ways of resizing the RAIDframe. First here is Greg Oster's recommanded method:
+
 * make sure you have a backup of your valuable data
+
 * fail wd1 in raid0 using raidctl -f /dev/wd0a raid0
+
 * migrate wd1 to GPT and resize the RAID partition
+
 * create a new raid1 with compenents NAME=raid0@wd1 and "absent"
+
 * creata a GPT and a FFS partition inside raid1
+
 * format the FFS filesystem inside raid1
+
 * copy data from raid0 FFS partiton to raid1 FFS partition
+
 * unconfigure raid0
+
 * migrate wd0 to GPT and resize the RAID partition
+
 * add NAME=raid@wd0 as a spare to raid1
+
 * reconstruct composent absent on spare NAME=raid@wd0
+
 * optionally renamae raid1 to raidà using raictl -U 0 raid1
 
+
 This approach is long, as it requires copying all the data.  It requires a few reboots, but it has the advantage that the data is always available during the migration. 
 
 A faster but less secure approach will be documented here, all the operations are done booting on an INSTALL kernel, using the ramdisk's shell. It takes aboit 10 minutes to complete, most of the time being spent in fsck and resize_ffs.
+
 * make sure you have a backup of your valuable data
+
 * unconfigure raid0
+
 * migrate wd0 and wd1 to GPT and enlarge the RAID partiton, lower the RAID partition start of 34 blocks, so that once a GPT is added in the RAID, the FFS partition star block in unchanged. 
+
 * configure a new raid0 with components NAME=raid0@wd0 and NAME=raid0@wd1 
+
 * create a GPT inside raidà with an FFS partition
+
 * DO NOT format the FFS partition, as you created it at the exact place where the pre-migration FFS partition was. You data is still there, unchanged.
+
 * You can now remount the FFS partition. It works without a hitch if you did not screw up things.
+
 * Rewrite the new RAID parity.
+
 * unmount the FFS partition and run fsck and resize_ffs to enlarge it.
 
+
 The approach is fast, but make a mistake on a partition start block and you data is gone. Note that rewriting RAID parity is fast, because it just reads the disks to check data is in sync. No copy is done. The longest operations are fsck and resize_ffs.
 
 Here are the commands. Note that if you have other GPT-enabled disks, the dk devices unit numbers way vary. We install both EFI and BIOS boostraps. The latter requires a primary bootstrap from 2023-07-01 or later (nebsd-9 and netbsd-10 branches) to boot a GPT/RAID-1/GPT/FFS setup.

Index: wikisrc/tutorials/how_to_enlarge_raidframe.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_enlarge_raidframe.mdwn,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- wikisrc/tutorials/how_to_enlarge_raidframe.mdwn	19 Jul 2023 00:50:51 -0000	1.4
+++ wikisrc/tutorials/how_to_enlarge_raidframe.mdwn	19 Jul 2023 12:51:45 -0000	1.5
@@ -35,31 +35,31 @@
 
 
 There are two ways of resizing the RAIDframe. First here is Greg Oster's recommanded method:
-- make sure you have a backup of your valuable data
-- fail wd1 in raid0 using raidctl -f /dev/wd0a raid0
-- migrate wd1 to GPT and resize the RAID partition
-- create a new raid1 with compenents NAME=raid0@wd1 and "absent"
-- creata a GPT and a FFS partition inside raid1
-- format the FFS filesystem inside raid1
-- copy data from raid0 FFS partiton to raid1 FFS partition
-- unconfigure raid0
-- migrate wd0 to GPT and resize the RAID partition
-- add NAME=raid@wd0 as a spare to raid1
-- reconstruct composent absent on spare NAME=raid@wd0
-- optionally renamae raid1 to raidà using raictl -U 0 raid1
+* make sure you have a backup of your valuable data
+* fail wd1 in raid0 using raidctl -f /dev/wd0a raid0
+* migrate wd1 to GPT and resize the RAID partition
+* create a new raid1 with compenents NAME=raid0@wd1 and "absent"
+* creata a GPT and a FFS partition inside raid1
+* format the FFS filesystem inside raid1
+* copy data from raid0 FFS partiton to raid1 FFS partition
+* unconfigure raid0
+* migrate wd0 to GPT and resize the RAID partition
+* add NAME=raid@wd0 as a spare to raid1
+* reconstruct composent absent on spare NAME=raid@wd0
+* optionally renamae raid1 to raidà using raictl -U 0 raid1
 
 This approach is long, as it requires copying all the data.  It requires a few reboots, but it has the advantage that the data is always available during the migration. 
 
 A faster but less secure approach will be documented here, all the operations are done booting on an INSTALL kernel, using the ramdisk's shell. It takes aboit 10 minutes to complete, most of the time being spent in fsck and resize_ffs.
-- make sure you have a backup of your valuable data
-- unconfigure raid0
-- migrate wd0 and wd1 to GPT and enlarge the RAID partiton, lower the RAID partition start of 34 blocks, so that once a GPT is added in the RAID, the FFS partition star block in unchanged. 
-- configure a new raid0 with components NAME=raid0@wd0 and NAME=raid0@wd1 
-- create a GPT inside raidà with an FFS partition
-- DO NOT format the FFS partition, as you created it at the exact place where the pre-migration FFS partition was. You data is still there, unchanged.
-- You can now remount the FFS partition. It works without a hitch if you did not screw up things.
-- Rewrite the new RAID parity.
-- unmount the FFS partition and run fsck and resize_ffs to enlarge it.
+* make sure you have a backup of your valuable data
+* unconfigure raid0
+* migrate wd0 and wd1 to GPT and enlarge the RAID partiton, lower the RAID partition start of 34 blocks, so that once a GPT is added in the RAID, the FFS partition star block in unchanged. 
+* configure a new raid0 with components NAME=raid0@wd0 and NAME=raid0@wd1 
+* create a GPT inside raidà with an FFS partition
+* DO NOT format the FFS partition, as you created it at the exact place where the pre-migration FFS partition was. You data is still there, unchanged.
+* You can now remount the FFS partition. It works without a hitch if you did not screw up things.
+* Rewrite the new RAID parity.
+* unmount the FFS partition and run fsck and resize_ffs to enlarge it.
 
 The approach is fast, but make a mistake on a partition start block and you data is gone. Note that rewriting RAID parity is fast, because it just reads the disks to check data is in sync. No copy is done. The longest operations are fsck and resize_ffs.
 

Index: wikisrc/users/jun.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/jun.mdwn,v
retrieving revision 1.126
retrieving revision 1.127
diff -u -r1.126 -r1.127
--- wikisrc/users/jun.mdwn	27 Jun 2023 09:20:49 -0000	1.126
+++ wikisrc/users/jun.mdwn	19 Jul 2023 01:47:36 -0000	1.127
@@ -10,7 +10,7 @@
 - [[https://event.ospn.jp/osc2023-kyoto/]]
 - [[https://ospn.connpass.com/event/287987]]
 - Tour Guide [[]]
-- togetter [[]]
+- togetter [[https://togetter.com/li/2189221]]
 
 ## Open Source Conference 2023 Online/Kyoto NetBSD BoF
 - 2023 Jul.29 Sat XX:00-XX:45 JST (UTC+9) 
@@ -18,7 +18,7 @@
 - [[https://event.ospn.jp/osc2023-online-kyoto/]] Session: TBD
 - Youtube video [[]]
 - Tour Guide [[]]
-- togetter [[]]
+- togetter [[https://togetter.com/li/2189221]]
 
 
 # Past Events in 2023

Index: wikisrc/tutorials/how_to_enlarge_raidframe.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_enlarge_raidframe.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/tutorials/how_to_enlarge_raidframe.mdwn	19 Jul 2023 00:48:57 -0000	1.3
+++ wikisrc/tutorials/how_to_enlarge_raidframe.mdwn	19 Jul 2023 00:50:51 -0000	1.4
@@ -65,7 +65,7 @@
 
 Here are the commands. Note that if you have other GPT-enabled disks, the dk devices unit numbers way vary. We install both EFI and BIOS boostraps. The latter requires a primary bootstrap from 2023-07-01 or later (nebsd-9 and netbsd-10 branches) to boot a GPT/RAID-1/GPT/FFS setup.
 
-    raidctl -G raid0 > raid0.conf.orig
+    raidctl -G raid0 > raid0.conf.orig
     raidctl -u raid0
     
     gpt create -Af wd0
@@ -88,14 +88,14 @@
     raid1=dk4
     
     newfs_msdos /dev/r${efi0}
-    mount -t msdos /dev/${efi0} /mnt && mkdir -p /mnt/EFI/BOOT  && \
-            cp /usr/mdec/bootx64.efi /mnt/EFI/BOOT && umount /mnt
+    mount -t msdos /dev/${efi0} /mnt && mkdir -p /mnt/EFI/BOOT  && \
+            cp /usr/mdec/bootx64.efi /mnt/EFI/BOOT && umount /mnt
     
     newfs_msdos /dev/r${efi1}
-    mount -t msdos /dev/${efi1} /mnt && mkdir -p /mnt/EFI/BOOT && \
-            cp /usr/mdec/bootx64.efi /mnt/EFI/BOOT && umount /mnt
+    mount -t msdos /dev/${efi1} /mnt && mkdir -p /mnt/EFI/BOOT && \
+            cp /usr/mdec/bootx64.efi /mnt/EFI/BOOT && umount /mnt
     
-    sed "s/wd0a/${raid0}/; s/wd1a/${raid1}/;" raid0.conf.orig > raid0.conf
+    sed "s/wd0a/${raid0}/; s/wd1a/${raid1}/;" raid0.conf.orig > raid0.conf
     raidctl -C raid0.conf raid0
     raidctl -A root raid0
     raidctl -I 20230710 raid0   # Unique serial number is advised!
@@ -124,7 +124,7 @@
             s|/dev/raid0a|NAME=root@raid0|;
             s|/dev/wd0b|NAME=swap@wd0|;
             s|/dev/wd1b|NAME=swap@wd1|;
-    ' /mnt/etc/fstab.orig > /mnt/etc/fstab
+    ' /mnt/etc/fstab.orig > /mnt/etc/fstab
     
     umount /mnt
     

Index: wikisrc/tutorials/how_to_enlarge_raidframe.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_enlarge_raidframe.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/tutorials/how_to_enlarge_raidframe.mdwn	19 Jul 2023 00:46:37 -0000	1.2
+++ wikisrc/tutorials/how_to_enlarge_raidframe.mdwn	19 Jul 2023 00:48:57 -0000	1.3
@@ -5,6 +5,7 @@
 The use case is a RAID-1 RAIDframe set of two 6 TB hard disks that were formatted the old way, using MBR and disklabel. This only enables using the first 2 TB of the disks, and migrating to GPT is required to use the full 6 TB. We will also need to enlarge the RAID, a tricky operation that is documented here.
 
 Our setup has two disks, wd0 and wd1, and raid0 is a RAID-1 set based on wd0a and wd1a. Here is what disklabel says about our two disks  before the migration:
+
     # disklabel wd0
     (...)
      a: 4261410815      2048       RAID

Index: wikisrc/tutorials/how_to_enlarge_raidframe.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_enlarge_raidframe.mdwn,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- wikisrc/tutorials/how_to_enlarge_raidframe.mdwn	19 Jul 2023 00:34:18 -0000	1.1
+++ wikisrc/tutorials/how_to_enlarge_raidframe.mdwn	19 Jul 2023 00:46:37 -0000	1.2
@@ -5,33 +5,32 @@
 The use case is a RAID-1 RAIDframe set of two 6 TB hard disks that were formatted the old way, using MBR and disklabel. This only enables using the first 2 TB of the disks, and migrating to GPT is required to use the full 6 TB. We will also need to enlarge the RAID, a tricky operation that is documented here.
 
 Our setup has two disks, wd0 and wd1, and raid0 is a RAID-1 set based on wd0a and wd1a. Here is what disklabel says about our two disks  before the migration:
-<code>
- a: 4261410815      2048       RAID
- b:  33554432 4261412863       swapo
-</code>
-
-After migration we will have
-<code>
-# gpt show -l wd0 
-        start         size  index  contents
-            0            1         PMBR (active)
-            1            1         Pri GPT header
-            2           32         Pri GPT table
-           34         1980      1  GPT part - efi@wd0
-         2014  11687488689      2  GPT part - raid0@wd0
-  11687490703     33554432      3  GPT part - swap@wd0
-  11721045135           32         Sec GPT table
-  11721045167            1         Sec GPT header
-
-# gpt show -l raid0
-        start         size  index  contents
-            0            1         PMBR
-            1            1         Pri GPT header
-            2           32         Pri GPT table
-           34  11687488445      1  GPT part - root@raid0
-  11687488479           32         Sec GPT table
-  11687488511            1         Sec GPT header
-</code>
+    # disklabel wd0
+    (...)
+     a: 4261410815      2048       RAID
+     b:  33554432 4261412863       swapo
+
+After migration we will have:
+
+    # gpt show -l wd0 
+            start         size  index  contents
+                0            1         PMBR (active)
+                1            1         Pri GPT header
+                2           32         Pri GPT table
+               34         1980      1  GPT part - efi@wd0
+             2014  11687488689      2  GPT part - raid0@wd0
+      11687490703     33554432      3  GPT part - swap@wd0
+      11721045135           32         Sec GPT table
+      11721045167            1         Sec GPT header
+    
+    # gpt show -l raid0
+            start         size  index  contents
+                0            1         PMBR
+                1            1         Pri GPT header
+                2           32         Pri GPT table
+               34  11687488445      1  GPT part - root@raid0
+      11687488479           32         Sec GPT table
+      11687488511            1         Sec GPT header
 
 
 There are two ways of resizing the RAIDframe. First here is Greg Oster's recommanded method:
@@ -65,85 +64,83 @@
 
 Here are the commands. Note that if you have other GPT-enabled disks, the dk devices unit numbers way vary. We install both EFI and BIOS boostraps. The latter requires a primary bootstrap from 2023-07-01 or later (nebsd-9 and netbsd-10 branches) to boot a GPT/RAID-1/GPT/FFS setup.
 
-<code>
-raidctl -G raid0 &gt; raid0.conf.orig
-raidctl -u raid0
-
-gpt create -Af wd0
-gpt create -Af wd1
-
-gpt add -t efi -l efi@wd0 -b 34 -s $(( 2048 - 34 - 34 )) wd0
-gpt add -t raid -l raid0@wd0 -b $(( 2048 - 34 )) -s 11687488689 wd0
-gpt add -t swap -l swap@wd0 wd0
-gpt biosboot -A -i 2 wd0
-
-gpt add -t efi -l efi@wd1 -b 34 -s $(( 2048 - 34 - 34 )) wd1
-gpt add -t raid -l raid0@wd1 -b $(( 2048 - 34 )) -s 11687488689 wd1
-gpt add -t swap -l swap@wd1 wd1
-gpt biosboot -A -i 2 wd1
-
-# Read the dk unit numbers from dmesg
-efi0=dk0
-efi1=dk3
-raid0=dk1
-raid1=dk4
-
-newfs_msdos /dev/r${efi0}
-mount -t msdos /dev/${efi0} /mnt &amp;&amp; mkdir -p /mnt/EFI/BOOT  &amp;&amp; \
-        cp /usr/mdec/bootx64.efi /mnt/EFI/BOOT &amp;&amp; umount /mnt
-
-newfs_msdos /dev/r${efi1}
-mount -t msdos /dev/${efi1} /mnt &amp;&amp; mkdir -p /mnt/EFI/BOOT &amp;&amp; \
-        cp /usr/mdec/bootx64.efi /mnt/EFI/BOOT &amp;&amp; umount /mnt
-
-sed "s/wd0a/${raid0}/; s/wd1a/${raid1}/;" raid0.conf.orig &gt; raid0.conf
-raidctl -C raid0.conf raid0
-raidctl -A root raid0
-raidctl -I 20230710 raid0   # Unique serial number is advised!
-raidctl -i raid0
-
-gpt create -Af raid0
-gpt add -t ffs -l root@raid0 raid0
-gpt set -a bootme -i 1 raid0
-
-# check the dk unit numbe from dmesg
-root=dk6
-
-# INSTALL ramdisk lacks resize_ffs, copy it from the target filesystem
-# This is the opportunity to check that eveyrthing went fine.
-mount -o rw,log  /dev/${root} /mnt
-cp /mnt/libexec/ld.elf_so /libexec/
-cp /mnt/sbin/resize_ffs /tmp/
-cp /mnt/lib/libc.so.12 /tmp/
-
-# Copy secondary bootstrap
-cp /usr/mdec/boot /mnt/boot
-
-# Adjust fstab
-cp /mnt/etc/fstab  /mnt/etc/fstab.orig
-sed '  
-        s|/dev/raid0a|NAME=root@raid0|;
-        s|/dev/wd0b|NAME=swap@wd0|;
-        s|/dev/wd1b|NAME=swap@wd1|;
-' /mnt/etc/fstab.orig &gt; /mnt/etc/fstab
-
-umount /mnt
-
-# Adjust console settings, this is for 115200 bps serial console
-# and FFSv2 filesystem. As noted earlier, you need a recent bootxx_ffsv2
-installboot -o console=com0,speed=115200 /dev/r${raid0} /usr/mdec/bootxx_ffsv2
-installboot -o console=com0,speed=115200 /dev/r${raid1} /usr/mdec/bootxx_ffsv2
-
-fsck -fy /dev/r${root}
-# Make sure resize_ffs finds libc.so.12
-export LD_LIBRARY_PATH=/tmp/
-/tmp/resize_ffs -y /dev/r${root}
-
-# Check new size
-mount /dev/${root} /mnt
-df -h /mnt
-umount /mnt
-
-# Reboot into normal operations
-reboot
-</code>
+    raidctl -G raid0 &gt; raid0.conf.orig
+    raidctl -u raid0
+    
+    gpt create -Af wd0
+    gpt create -Af wd1
+    
+    gpt add -t efi -l efi@wd0 -b 34 -s $(( 2048 - 34 - 34 )) wd0
+    gpt add -t raid -l raid0@wd0 -b $(( 2048 - 34 )) -s 11687488689 wd0
+    gpt add -t swap -l swap@wd0 wd0
+    gpt biosboot -A -i 2 wd0
+    
+    gpt add -t efi -l efi@wd1 -b 34 -s $(( 2048 - 34 - 34 )) wd1
+    gpt add -t raid -l raid0@wd1 -b $(( 2048 - 34 )) -s 11687488689 wd1
+    gpt add -t swap -l swap@wd1 wd1
+    gpt biosboot -A -i 2 wd1
+    
+    # Read the dk unit numbers from dmesg
+    efi0=dk0
+    efi1=dk3
+    raid0=dk1
+    raid1=dk4
+    
+    newfs_msdos /dev/r${efi0}
+    mount -t msdos /dev/${efi0} /mnt &amp;&amp; mkdir -p /mnt/EFI/BOOT  &amp;&amp; \
+            cp /usr/mdec/bootx64.efi /mnt/EFI/BOOT &amp;&amp; umount /mnt
+    
+    newfs_msdos /dev/r${efi1}
+    mount -t msdos /dev/${efi1} /mnt &amp;&amp; mkdir -p /mnt/EFI/BOOT &amp;&amp; \
+            cp /usr/mdec/bootx64.efi /mnt/EFI/BOOT &amp;&amp; umount /mnt
+    
+    sed "s/wd0a/${raid0}/; s/wd1a/${raid1}/;" raid0.conf.orig &gt; raid0.conf
+    raidctl -C raid0.conf raid0
+    raidctl -A root raid0
+    raidctl -I 20230710 raid0   # Unique serial number is advised!
+    raidctl -i raid0
+    
+    gpt create -Af raid0
+    gpt add -t ffs -l root@raid0 raid0
+    gpt set -a bootme -i 1 raid0
+    
+    # check the dk unit numbe from dmesg
+    root=dk6
+    
+    # INSTALL ramdisk lacks resize_ffs, copy it from the target filesystem
+    # This is the opportunity to check that eveyrthing went fine.
+    mount -o rw,log  /dev/${root} /mnt

(Diff truncated)

--- /dev/null	2023-09-18 20:32:00.487406898 +0000
+++ wikisrc/tutorials/how_to_enlarge_raidframe.mdwn	2023-09-18 20:32:53.472718691 +0000
@@ -0,0 +1,149 @@
+## How to enlarge RAIDframe
+
+Sometime one has to resize a filesystem. For FFS, we have resize_fss(8), but things are more complicated if the FFS filesystem is inside a RAIDframe set. This documents show how to fo deal with such a setup.
+
+The use case is a RAID-1 RAIDframe set of two 6 TB hard disks that were formatted the old way, using MBR and disklabel. This only enables using the first 2 TB of the disks, and migrating to GPT is required to use the full 6 TB. We will also need to enlarge the RAID, a tricky operation that is documented here.
+
+Our setup has two disks, wd0 and wd1, and raid0 is a RAID-1 set based on wd0a and wd1a. Here is what disklabel says about our two disks  before the migration:
+<code>
+ a: 4261410815      2048       RAID
+ b:  33554432 4261412863       swapo
+</code>
+
+After migration we will have
+<code>
+# gpt show -l wd0 
+        start         size  index  contents
+            0            1         PMBR (active)
+            1            1         Pri GPT header
+            2           32         Pri GPT table
+           34         1980      1  GPT part - efi@wd0
+         2014  11687488689      2  GPT part - raid0@wd0
+  11687490703     33554432      3  GPT part - swap@wd0
+  11721045135           32         Sec GPT table
+  11721045167            1         Sec GPT header
+
+# gpt show -l raid0
+        start         size  index  contents
+            0            1         PMBR
+            1            1         Pri GPT header
+            2           32         Pri GPT table
+           34  11687488445      1  GPT part - root@raid0
+  11687488479           32         Sec GPT table
+  11687488511            1         Sec GPT header
+</code>
+
+
+There are two ways of resizing the RAIDframe. First here is Greg Oster's recommanded method:
+- make sure you have a backup of your valuable data
+- fail wd1 in raid0 using raidctl -f /dev/wd0a raid0
+- migrate wd1 to GPT and resize the RAID partition
+- create a new raid1 with compenents NAME=raid0@wd1 and "absent"
+- creata a GPT and a FFS partition inside raid1
+- format the FFS filesystem inside raid1
+- copy data from raid0 FFS partiton to raid1 FFS partition
+- unconfigure raid0
+- migrate wd0 to GPT and resize the RAID partition
+- add NAME=raid@wd0 as a spare to raid1
+- reconstruct composent absent on spare NAME=raid@wd0
+- optionally renamae raid1 to raidà using raictl -U 0 raid1
+
+This approach is long, as it requires copying all the data.  It requires a few reboots, but it has the advantage that the data is always available during the migration. 
+
+A faster but less secure approach will be documented here, all the operations are done booting on an INSTALL kernel, using the ramdisk's shell. It takes aboit 10 minutes to complete, most of the time being spent in fsck and resize_ffs.
+- make sure you have a backup of your valuable data
+- unconfigure raid0
+- migrate wd0 and wd1 to GPT and enlarge the RAID partiton, lower the RAID partition start of 34 blocks, so that once a GPT is added in the RAID, the FFS partition star block in unchanged. 
+- configure a new raid0 with components NAME=raid0@wd0 and NAME=raid0@wd1 
+- create a GPT inside raidà with an FFS partition
+- DO NOT format the FFS partition, as you created it at the exact place where the pre-migration FFS partition was. You data is still there, unchanged.
+- You can now remount the FFS partition. It works without a hitch if you did not screw up things.
+- Rewrite the new RAID parity.
+- unmount the FFS partition and run fsck and resize_ffs to enlarge it.
+
+The approach is fast, but make a mistake on a partition start block and you data is gone. Note that rewriting RAID parity is fast, because it just reads the disks to check data is in sync. No copy is done. The longest operations are fsck and resize_ffs.
+
+Here are the commands. Note that if you have other GPT-enabled disks, the dk devices unit numbers way vary. We install both EFI and BIOS boostraps. The latter requires a primary bootstrap from 2023-07-01 or later (nebsd-9 and netbsd-10 branches) to boot a GPT/RAID-1/GPT/FFS setup.
+
+<code>
+raidctl -G raid0 &gt; raid0.conf.orig
+raidctl -u raid0
+
+gpt create -Af wd0
+gpt create -Af wd1
+
+gpt add -t efi -l efi@wd0 -b 34 -s $(( 2048 - 34 - 34 )) wd0
+gpt add -t raid -l raid0@wd0 -b $(( 2048 - 34 )) -s 11687488689 wd0
+gpt add -t swap -l swap@wd0 wd0
+gpt biosboot -A -i 2 wd0
+
+gpt add -t efi -l efi@wd1 -b 34 -s $(( 2048 - 34 - 34 )) wd1
+gpt add -t raid -l raid0@wd1 -b $(( 2048 - 34 )) -s 11687488689 wd1
+gpt add -t swap -l swap@wd1 wd1
+gpt biosboot -A -i 2 wd1
+
+# Read the dk unit numbers from dmesg
+efi0=dk0
+efi1=dk3
+raid0=dk1
+raid1=dk4
+
+newfs_msdos /dev/r${efi0}
+mount -t msdos /dev/${efi0} /mnt &amp;&amp; mkdir -p /mnt/EFI/BOOT  &amp;&amp; \
+        cp /usr/mdec/bootx64.efi /mnt/EFI/BOOT &amp;&amp; umount /mnt
+
+newfs_msdos /dev/r${efi1}
+mount -t msdos /dev/${efi1} /mnt &amp;&amp; mkdir -p /mnt/EFI/BOOT &amp;&amp; \
+        cp /usr/mdec/bootx64.efi /mnt/EFI/BOOT &amp;&amp; umount /mnt
+
+sed "s/wd0a/${raid0}/; s/wd1a/${raid1}/;" raid0.conf.orig &gt; raid0.conf
+raidctl -C raid0.conf raid0
+raidctl -A root raid0
+raidctl -I 20230710 raid0   # Unique serial number is advised!
+raidctl -i raid0
+
+gpt create -Af raid0
+gpt add -t ffs -l root@raid0 raid0
+gpt set -a bootme -i 1 raid0
+
+# check the dk unit numbe from dmesg
+root=dk6
+
+# INSTALL ramdisk lacks resize_ffs, copy it from the target filesystem
+# This is the opportunity to check that eveyrthing went fine.
+mount -o rw,log  /dev/${root} /mnt
+cp /mnt/libexec/ld.elf_so /libexec/
+cp /mnt/sbin/resize_ffs /tmp/
+cp /mnt/lib/libc.so.12 /tmp/
+
+# Copy secondary bootstrap
+cp /usr/mdec/boot /mnt/boot
+
+# Adjust fstab
+cp /mnt/etc/fstab  /mnt/etc/fstab.orig
+sed '  
+        s|/dev/raid0a|NAME=root@raid0|;
+        s|/dev/wd0b|NAME=swap@wd0|;
+        s|/dev/wd1b|NAME=swap@wd1|;
+' /mnt/etc/fstab.orig &gt; /mnt/etc/fstab
+
+umount /mnt
+
+# Adjust console settings, this is for 115200 bps serial console
+# and FFSv2 filesystem. As noted earlier, you need a recent bootxx_ffsv2
+installboot -o console=com0,speed=115200 /dev/r${raid0} /usr/mdec/bootxx_ffsv2
+installboot -o console=com0,speed=115200 /dev/r${raid1} /usr/mdec/bootxx_ffsv2
+
+fsck -fy /dev/r${root}
+# Make sure resize_ffs finds libc.so.12
+export LD_LIBRARY_PATH=/tmp/
+/tmp/resize_ffs -y /dev/r${root}
+
+# Check new size
+mount /dev/${root} /mnt
+df -h /mnt
+umount /mnt
+
+# Reboot into normal operations
+reboot
+</code>

Index: wikisrc/users/wiz/scm-migration.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/wiz/scm-migration.mdwn,v
retrieving revision 1.44
retrieving revision 1.45
diff -u -r1.44 -r1.45
--- wikisrc/users/wiz/scm-migration.mdwn	17 Jul 2023 21:45:32 -0000	1.44
+++ wikisrc/users/wiz/scm-migration.mdwn	18 Jul 2023 22:03:52 -0000	1.45
@@ -131,6 +131,8 @@
 - closing unused branches (old 'cvs import' branches that won't be used again)
 - converting .cvsignore files to .hgignore
 - adding release tags (for 'cvs imports')
+  - find all release tags
+  - DONE [[tag them automatically as far as possible|https://mail-index.netbsd.org/tech-repository/2023/07/18/msg000788.html]]
 - turn off CVS/anoncvs server :-)
 - possibly close tech-repository mailing list
 - (optional) discuss if hg should be included in the base system

Index: wikisrc/users/wiz/scm-migration.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/wiz/scm-migration.mdwn,v
retrieving revision 1.43
retrieving revision 1.44
diff -u -r1.43 -r1.44
--- wikisrc/users/wiz/scm-migration.mdwn	17 Jul 2023 06:23:01 -0000	1.43
+++ wikisrc/users/wiz/scm-migration.mdwn	17 Jul 2023 21:45:32 -0000	1.44
@@ -55,7 +55,8 @@
   - DONE repository conversion exists
   - for deployment: ikiwiki hg plug-in (schmonz@ is working on this)
 - xsrc
-  - conversion exists, but joerg wants to do a cleaned up version
+  - DONE cleaned-up repository conversion exists
+  - send fixes to admins for applying
 
 hg server
 ===

Index: wikisrc/users/wiz/scm-migration.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/wiz/scm-migration.mdwn,v
retrieving revision 1.42
retrieving revision 1.43
diff -u -r1.42 -r1.43
--- wikisrc/users/wiz/scm-migration.mdwn	16 Jul 2023 18:10:04 -0000	1.42
+++ wikisrc/users/wiz/scm-migration.mdwn	17 Jul 2023 06:23:01 -0000	1.43
@@ -48,12 +48,12 @@
         doc/CHANGES-* = :union
 - pkgsrc-wiki
   - DONE repository conversion exists
-  - for deployment: ikiwiki hg plugin (schmonz@ is working on this)
+  - for deployment: ikiwiki hg plug-in (schmonz@ is working on this)
 - src
   - conversion exists, but joerg wants to do a cleaned up version
 - wiki
   - DONE repository conversion exists
-  - for deployment: ikiwiki hg plugin (schmonz@ is working on this)
+  - for deployment: ikiwiki hg plug-in (schmonz@ is working on this)
 - xsrc
   - conversion exists, but joerg wants to do a cleaned up version
 
@@ -64,13 +64,13 @@
   - waiting for [[auditlog merge|https://foss.heptapod.net/mercurial/mercurial-devel/-/merge_requests/235]]
   - DONE authormap (mapping CVS Unix users to name and email)
   - DONE decided to use named branches instead of bookmarks
-  - script to send emails for commits (exists for src-hg, deply for all repositories)
+  - script to send emails for commits (exists for src-hg, deploy for all repositories)
   - script to send email to GNATS for messages referencing PRs (htdocs, pkgsrc, src, xsrc)
 - hardware
   - DONE do we need new hardware for the server(s)?
     - no; use cvs and anoncvs machines
-  - ? set up hg.netbsd.org from scratch
-  - ? set up anonhg.netbsd.org from scratch
+  - ? set up hg.NetBSD.org from scratch
+  - ? set up anonhg.NetBSD.org from scratch
 - DONE rename 'hgmaster' host to 'hg' in DNS
 - DONE public access:
   - hg:
@@ -93,7 +93,7 @@
   - DONE anita was not affected, but the underlying bracket tool needed changes for hg support
   - test bed needs to migrate to using hg
 - Daily/weekly jobs:
-  - daily publishing jobs for tarballs
+  - daily publishing jobs for tar balls
   - updated extracted sources? ftp.NetBSD.org?
   - all the pkgsrc automation (requires an unpacked updated tree of the right branch, doesn't care how it came into being)
   - when we migrate htdocs and htutils, update of the web pages

Index: wikisrc/users/wiz/scm-migration.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/wiz/scm-migration.mdwn,v
retrieving revision 1.41
retrieving revision 1.42
diff -u -r1.41 -r1.42
--- wikisrc/users/wiz/scm-migration.mdwn	15 Jul 2023 18:59:21 -0000	1.41
+++ wikisrc/users/wiz/scm-migration.mdwn	16 Jul 2023 18:10:04 -0000	1.42
@@ -41,7 +41,6 @@
   - conversion exists, but joerg wants to do a cleaned up version
   - update branch-cutting instructions
   - update releng instructions
-  - implement hook for forwarding commit messages referencing PRs to GNATS
   - DONE expect lots of merge problems in doc/CHANGES* - use merge tool
     `:union` to fix this, configured in `.hgrc` like this:
 
@@ -52,26 +51,26 @@
   - for deployment: ikiwiki hg plugin (schmonz@ is working on this)
 - src
   - conversion exists, but joerg wants to do a cleaned up version
-  - implement hook for forwarding commit messages referencing PRs to GNATS
 - wiki
   - DONE repository conversion exists
   - for deployment: ikiwiki hg plugin (schmonz@ is working on this)
 - xsrc
   - conversion exists, but joerg wants to do a cleaned up version
-  - implement hook for forwarding commit messages referencing PRs to GNATS
 
 hg server
 ===
 
 - software
   - waiting for [[auditlog merge|https://foss.heptapod.net/mercurial/mercurial-devel/-/merge_requests/235]]
-  - ? set up hg.netbsd.org from scratch
-  - ? set up anonhg.netbsd.org from scratch
   - DONE authormap (mapping CVS Unix users to name and email)
   - DONE decided to use named branches instead of bookmarks
-- DONE hardware
+  - script to send emails for commits (exists for src-hg, deply for all repositories)
+  - script to send email to GNATS for messages referencing PRs (htdocs, pkgsrc, src, xsrc)
+- hardware
   - DONE do we need new hardware for the server(s)?
     - no; use cvs and anoncvs machines
+  - ? set up hg.netbsd.org from scratch
+  - ? set up anonhg.netbsd.org from scratch
 - DONE rename 'hgmaster' host to 'hg' in DNS
 - DONE public access:
   - hg:

Index: wikisrc/users/wiz/scm-migration.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/wiz/scm-migration.mdwn,v
retrieving revision 1.40
retrieving revision 1.41
diff -u -r1.40 -r1.41
--- wikisrc/users/wiz/scm-migration.mdwn	15 Jul 2023 18:57:22 -0000	1.40
+++ wikisrc/users/wiz/scm-migration.mdwn	15 Jul 2023 18:59:21 -0000	1.41
@@ -48,13 +48,13 @@
         [merge-patterns]
         doc/CHANGES-* = :union
 - pkgsrc-wiki
-  - DONE repository conversion
+  - DONE repository conversion exists
   - for deployment: ikiwiki hg plugin (schmonz@ is working on this)
 - src
   - conversion exists, but joerg wants to do a cleaned up version
   - implement hook for forwarding commit messages referencing PRs to GNATS
 - wiki
-  - DONE repository conversion
+  - DONE repository conversion exists
   - for deployment: ikiwiki hg plugin (schmonz@ is working on this)
 - xsrc
   - conversion exists, but joerg wants to do a cleaned up version
@@ -109,16 +109,16 @@
 ===
 - turn on hg as main repository - switch them one by one
   - public repositories
-    - othersrc (semi-final conversion exists)
-    - htdocs (semi-final conversion exists)
+    - othersrc
+    - htdocs
     - pkgsrc - [[public|https://anonhg.netbsd.org/pkgsrc/]] & [[internal|ssh://hg.netbsd.org/pkgsrc]]
     - src - [[public|https://anonhg.netbsd.org/src/]] & [[internal|ssh://hg.netbsd.org/src]]
     - xsrc - [[public|https://anonhg.netbsd.org/xsrc/]] & [[internal|ssh://hg.netbsd.org/xsrc]]
   - internal repositories
-    - htutils (semi-final conversion exists)
-    - localsrc (semi-final conversion exists)
-    - wikisrc (needs a conversion first)
-    - pkgsrc-wiki (needs a conversion first)
+    - htutils
+    - localsrc
+    - wikisrc
+    - pkgsrc-wiki
 - github
   - after final conversion happens, either force-push or make a new repository and deprecate the old one
 

Index: wikisrc/users/wiz/scm-migration.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/wiz/scm-migration.mdwn,v
retrieving revision 1.39
retrieving revision 1.40
diff -u -r1.39 -r1.40
--- wikisrc/users/wiz/scm-migration.mdwn	15 Jul 2023 18:51:22 -0000	1.39
+++ wikisrc/users/wiz/scm-migration.mdwn	15 Jul 2023 18:57:22 -0000	1.40
@@ -48,13 +48,13 @@
         [merge-patterns]
         doc/CHANGES-* = :union
 - pkgsrc-wiki
-  - repository conversion
+  - DONE repository conversion
   - for deployment: ikiwiki hg plugin (schmonz@ is working on this)
 - src
   - conversion exists, but joerg wants to do a cleaned up version
   - implement hook for forwarding commit messages referencing PRs to GNATS
 - wiki
-  - repository conversion
+  - DONE repository conversion
   - for deployment: ikiwiki hg plugin (schmonz@ is working on this)
 - xsrc
   - conversion exists, but joerg wants to do a cleaned up version

Index: wikisrc/users/wiz/scm-migration.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/wiz/scm-migration.mdwn,v
retrieving revision 1.38
retrieving revision 1.39
diff -u -r1.38 -r1.39
--- wikisrc/users/wiz/scm-migration.mdwn	15 Jul 2023 18:10:01 -0000	1.38
+++ wikisrc/users/wiz/scm-migration.mdwn	15 Jul 2023 18:51:22 -0000	1.39
@@ -65,6 +65,8 @@
 
 - software
   - waiting for [[auditlog merge|https://foss.heptapod.net/mercurial/mercurial-devel/-/merge_requests/235]]
+  - ? set up hg.netbsd.org from scratch
+  - ? set up anonhg.netbsd.org from scratch
   - DONE authormap (mapping CVS Unix users to name and email)
   - DONE decided to use named branches instead of bookmarks
 - DONE hardware
@@ -77,16 +79,12 @@
     - [[read-write for developers|ssh://hg.netbsd.org/]]
   - [[read-only git|https://github.com/netbsd/]]
 
-github
-===
-- after final conversion happens, either force-push or make a new repository and deprecate the old one
-
 Documentation
 ===
 - [[CVS to hg migration guide|https://wiki.mercurial-scm.org/CvsInfo]]
 - [[NetBSD-specific documentation for developers and hg|https://www.netbsd.org/developers/mercurial/]]
 
-Updating repository contents & deployment
+Updating Repository Contents & Deployment
 ===
 - releng: some scripts need to be adapted
   - localsrc/releng/autobuild - martin@ is working on it
@@ -121,11 +119,13 @@
     - localsrc (semi-final conversion exists)
     - wikisrc (needs a conversion first)
     - pkgsrc-wiki (needs a conversion first)
+- github
+  - after final conversion happens, either force-push or make a new repository and deprecate the old one
 
-Post-conversion
+Post-Conversion
 ===
 Cleanups after conversions are final (these can only be done once the
-CVS-to-hg step is finalized, because they are manualy work and would
+CVS-to-hg step is finalized, because they are manual work and would
 get lost otherwise)
 
 - closing unused branches (old 'cvs import' branches that won't be used again)
@@ -135,7 +135,7 @@
 - possibly close tech-repository mailing list
 - (optional) discuss if hg should be included in the base system
 
-NOTES: BRANCH MERGING
+Notes: Branch Merging
 ===
 
 The migration keeps branch information, but there is no way to
@@ -152,7 +152,7 @@
 
 and only then start with importing the new version on the vendor branch.
 
-NOTES: CLOSING BRANCHES
+Notes: Closing Branches
 ===
 
 `hg` supports the concept of closing a branch using

Index: wikisrc/users/wiz/scm-migration.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/wiz/scm-migration.mdwn,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- wikisrc/users/wiz/scm-migration.mdwn	15 Jul 2023 18:02:57 -0000	1.37
+++ wikisrc/users/wiz/scm-migration.mdwn	15 Jul 2023 18:10:01 -0000	1.38
@@ -17,7 +17,6 @@
 - htdocs
   - DONE repository conversion exists
   - apply fixes to CVS master (admin ticket #280542)
-
 - htutils
   - DONE repository conversion exists
   - DONE nothing to fix in CVS master
@@ -29,18 +28,15 @@
     - scripts/update.changes
     - scripts/update.http
     - scripts/update.releng
-
 - localsrc
   - DONE repository conversion exists
   - apply fixes to CVS master (admin ticket #280397)
-
 - othersrc
   - DONE repository conversion exists
     - DONE split up `cvs imports` for some sources (luke@)
     - DONE missing tags on some files (dh@ fixed them)
     - DONE minor other fixes
   - apply fixes to CVS master (admin ticket #280541)
-
 - pkgsrc
   - conversion exists, but joerg wants to do a cleaned up version
   - update branch-cutting instructions
@@ -51,19 +47,15 @@
 
         [merge-patterns]
         doc/CHANGES-* = :union
-
 - pkgsrc-wiki
   - repository conversion
   - for deployment: ikiwiki hg plugin (schmonz@ is working on this)
-
 - src
   - conversion exists, but joerg wants to do a cleaned up version
   - implement hook for forwarding commit messages referencing PRs to GNATS
-
 - wiki
   - repository conversion
   - for deployment: ikiwiki hg plugin (schmonz@ is working on this)
-
 - xsrc
   - conversion exists, but joerg wants to do a cleaned up version
   - implement hook for forwarding commit messages referencing PRs to GNATS
@@ -75,12 +67,15 @@
   - waiting for [[auditlog merge|https://foss.heptapod.net/mercurial/mercurial-devel/-/merge_requests/235]]
   - DONE authormap (mapping CVS Unix users to name and email)
   - DONE decided to use named branches instead of bookmarks
-
 - DONE hardware
   - DONE do we need new hardware for the server(s)?
     - no; use cvs and anoncvs machines
-
 - DONE rename 'hgmaster' host to 'hg' in DNS
+- DONE public access:
+  - hg:
+    - [[read-only public|https://anonhg.netbsd.org/]]
+    - [[read-write for developers|ssh://hg.netbsd.org/]]
+  - [[read-only git|https://github.com/netbsd/]]
 
 github
 ===
@@ -91,32 +86,22 @@
 - [[CVS to hg migration guide|https://wiki.mercurial-scm.org/CvsInfo]]
 - [[NetBSD-specific documentation for developers and hg|https://www.netbsd.org/developers/mercurial/]]
 
-- DONE public access:
-  - hg:
-    - [[public|https://anonhg.netbsd.org/]]
-    - [[for developers|ssh://hg.netbsd.org/]]
-  - [[read-only git|https://github.com/netbsd/]]
-
 Updating repository contents & deployment
 ===
 - releng: some scripts need to be adapted
   - localsrc/releng/autobuild - martin@ is working on it
   - localsrc/releng/autobuild/autobuild.txt for hg
   - releng needs to migrate to using hg
-
 - CI: anita and bracket
   - DONE anita was not affected, but the underlying bracket tool needed changes for hg support
   - test bed needs to migrate to using hg
-
 - Daily/weekly jobs:
   - daily publishing jobs for tarballs
   - updated extracted sources? ftp.NetBSD.org?
   - all the pkgsrc automation (requires an unpacked updated tree of the right branch, doesn't care how it came into being)
   - when we migrate htdocs and htutils, update of the web pages
   - backups of the repo(s)
-
 - developer activity script for admins/membership-exec needs to be adapted or rewritten
-
 - RCS Ids
   - for src: set `-D_SOURCE_REVISION=\"$(hg log -r . -T {node})"` (computed once) instead of the RCS Ids so that "ident /netbsd" stays useful.
     - joerg@ has a WIP patch
@@ -124,19 +109,18 @@
 
 Switch from CVS to hg
 ===
-- turn on hg as main repository
-  - switch them one by one
-    - public repositories
-      - othersrc (semi-final conversion exists)
-      - htdocs (semi-final conversion exists)
-      - pkgsrc - [[public|https://anonhg.netbsd.org/pkgsrc/]] & [[internal|ssh://hg.netbsd.org/pkgsrc]]
-      - src - [[public|https://anonhg.netbsd.org/src/]] & [[internal|ssh://hg.netbsd.org/src]]
-      - xsrc - [[public|https://anonhg.netbsd.org/xsrc/]] & [[internal|ssh://hg.netbsd.org/xsrc]]
-    - internal repositories
-      - htutils (semi-final conversion exists)
-      - localsrc (semi-final conversion exists)
-      - wikisrc (needs a conversion first)
-      - pkgsrc-wiki (needs a conversion first)
+- turn on hg as main repository - switch them one by one
+  - public repositories
+    - othersrc (semi-final conversion exists)
+    - htdocs (semi-final conversion exists)
+    - pkgsrc - [[public|https://anonhg.netbsd.org/pkgsrc/]] & [[internal|ssh://hg.netbsd.org/pkgsrc]]
+    - src - [[public|https://anonhg.netbsd.org/src/]] & [[internal|ssh://hg.netbsd.org/src]]
+    - xsrc - [[public|https://anonhg.netbsd.org/xsrc/]] & [[internal|ssh://hg.netbsd.org/xsrc]]
+  - internal repositories
+    - htutils (semi-final conversion exists)
+    - localsrc (semi-final conversion exists)
+    - wikisrc (needs a conversion first)
+    - pkgsrc-wiki (needs a conversion first)
 
 Post-conversion
 ===
@@ -147,14 +131,11 @@
 - closing unused branches (old 'cvs import' branches that won't be used again)
 - converting .cvsignore files to .hgignore
 - adding release tags (for 'cvs imports')
-
 - turn off CVS/anoncvs server :-)
-
 - possibly close tech-repository mailing list
-
 - (optional) discuss if hg should be included in the base system
 
-NOTES: BRACN MERGING
+NOTES: BRANCH MERGING
 ===
 
 The migration keeps branch information, but there is no way to

Index: wikisrc/users/wiz/scm-migration.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/wiz/scm-migration.mdwn,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -r1.36 -r1.37
--- wikisrc/users/wiz/scm-migration.mdwn	14 Jul 2023 20:58:08 -0000	1.36
+++ wikisrc/users/wiz/scm-migration.mdwn	15 Jul 2023 18:02:57 -0000	1.37
@@ -4,18 +4,92 @@
 
 There are at least the following topics:
 
-- conversion:
-  - basically done, possibly one 'final' cleaned-up conversion
-    - currently waiting for [[auditlog merge|https://foss.heptapod.net/mercurial/mercurial-devel/-/merge_requests/235]]
-    - DONE authormap is finalized
-  - github mirror
-    - after final conversion happens, either force-push or make a new repository and deprecate the old one
-  - DONE clarify if we want named or unnamed branches for vendor imports - we want named
-  - get proper release tags - needs to be done manually, after the conversion - volunteers wanted
-
-- DONE documentation
-  - [[CVS to hg migration guide|https://wiki.mercurial-scm.org/CvsInfo]]
-  - [[NetBSD-specific documentation for developers and hg|https://www.netbsd.org/developers/mercurial/]]
+Repositories
+===
+hg supports conversion from CVS directly, but it doesn't handle `cvs
+import` well.
+
+`cvs2fossil` is preferred, packaged in wip/cvs2fossil and wip/cvs2hg
+
+The src and pkgsrc conversions are based on by now very old scripts
+and might need migration to the new tools.
+
+- htdocs
+  - DONE repository conversion exists
+  - apply fixes to CVS master (admin ticket #280542)
+
+- htutils
+  - DONE repository conversion exists
+  - DONE nothing to fix in CVS master
+  - The following scripts need to be updated:
+    - changes/cvschanges2html
+    - changes/pkg-changes2rss
+    - scripts/mirrorcheck (perhaps obsolete)
+    - scripts/pkgdoget
+    - scripts/update.changes
+    - scripts/update.http
+    - scripts/update.releng
+
+- localsrc
+  - DONE repository conversion exists
+  - apply fixes to CVS master (admin ticket #280397)
+
+- othersrc
+  - DONE repository conversion exists
+    - DONE split up `cvs imports` for some sources (luke@)
+    - DONE missing tags on some files (dh@ fixed them)
+    - DONE minor other fixes
+  - apply fixes to CVS master (admin ticket #280541)
+
+- pkgsrc
+  - conversion exists, but joerg wants to do a cleaned up version
+  - update branch-cutting instructions
+  - update releng instructions
+  - implement hook for forwarding commit messages referencing PRs to GNATS
+  - DONE expect lots of merge problems in doc/CHANGES* - use merge tool
+    `:union` to fix this, configured in `.hgrc` like this:
+
+        [merge-patterns]
+        doc/CHANGES-* = :union
+
+- pkgsrc-wiki
+  - repository conversion
+  - for deployment: ikiwiki hg plugin (schmonz@ is working on this)
+
+- src
+  - conversion exists, but joerg wants to do a cleaned up version
+  - implement hook for forwarding commit messages referencing PRs to GNATS
+
+- wiki
+  - repository conversion
+  - for deployment: ikiwiki hg plugin (schmonz@ is working on this)
+
+- xsrc
+  - conversion exists, but joerg wants to do a cleaned up version
+  - implement hook for forwarding commit messages referencing PRs to GNATS
+
+hg server
+===
+
+- software
+  - waiting for [[auditlog merge|https://foss.heptapod.net/mercurial/mercurial-devel/-/merge_requests/235]]
+  - DONE authormap (mapping CVS Unix users to name and email)
+  - DONE decided to use named branches instead of bookmarks
+
+- DONE hardware
+  - DONE do we need new hardware for the server(s)?
+    - no; use cvs and anoncvs machines
+
+- DONE rename 'hgmaster' host to 'hg' in DNS
+
+github
+===
+- after final conversion happens, either force-push or make a new repository and deprecate the old one
+
+Documentation
+===
+- [[CVS to hg migration guide|https://wiki.mercurial-scm.org/CvsInfo]]
+- [[NetBSD-specific documentation for developers and hg|https://www.netbsd.org/developers/mercurial/]]
 
 - DONE public access:
   - hg:
@@ -23,12 +97,14 @@
     - [[for developers|ssh://hg.netbsd.org/]]
   - [[read-only git|https://github.com/netbsd/]]
 
-- releng some scripts need to be adapted
+Updating repository contents & deployment
+===
+- releng: some scripts need to be adapted
   - localsrc/releng/autobuild - martin@ is working on it
-  - update localsrc/releng/autobuild/autobuild.txt for hg
+  - localsrc/releng/autobuild/autobuild.txt for hg
   - releng needs to migrate to using hg
 
-- anita test bed
+- CI: anita and bracket
   - DONE anita was not affected, but the underlying bracket tool needed changes for hg support
   - test bed needs to migrate to using hg
 
@@ -38,38 +114,6 @@
   - all the pkgsrc automation (requires an unpacked updated tree of the right branch, doesn't care how it came into being)
   - when we migrate htdocs and htutils, update of the web pages
   - backups of the repo(s)
-  - what else?
-
-- htutils:
-  - changes/cvschanges2html
-  - changes/pkg-changes2rss
-  - scripts/mirrorcheck (perhaps obsolete)
-  - scripts/pkgdoget
-  - scripts/update.changes
-  - scripts/update.http
-  - scripts/update.releng
-
-- wiki & pkgsrc-wiki
-  - ikiwiki hg plugin (schmonz@ is working on this)
-
-- pkgsrc
-  - DONE expect lots of merge problems in doc/CHANGES* - use merge tool `:union` to fix this, configured in `.hgrc` like this:
-
-        [merge-patterns]
-        doc/CHANGES-* = :union
-  - update branch-cutting instructions
-  - update releng instructions
-  - implement hook for forwarding commit messages referencing PRs to GNATS
-
-- src
-  - implement hook for forwarding commit messages referencing PRs to GNATS
-
-- othersrc
-  - repository conversion exists, possible cleanups:
-    - DONE split up `cvs imports` for some sources (luke@)
-    - DONE missing tags on some files (dh@ fixed them)
-    - DONE minor other fixes
-    - apply fixes to CVS master
 
 - developer activity script for admins/membership-exec needs to be adapted or rewritten
 
@@ -78,21 +122,13 @@
     - joerg@ has a WIP patch
   - DONE for pkgsrc: `USE_PKG_ADMIN_DIGEST` has been set to `yes`
 
-- DONE do we need new hardware for the server(s)?
-  - no; use cvs and anoncvs machines
-
-- DONE rename 'hgmaster' host to 'hg'
-
-- repository conversion
-  - hg supports conversion from CVS directly, but it doesn't handle `cvs import` well
-  - cvs2fossil is preferred, packaged in wip/cvs2fossil and wip/cvs2hg
-  - joerg@ wants to do 'cleaned-up' conversions of src & pkgsrc before we switch
-
+Switch from CVS to hg
+===
 - turn on hg as main repository
-  - switch them one by one?
+  - switch them one by one
     - public repositories
       - othersrc (semi-final conversion exists)
-      - htdocs (conversion in progress)
+      - htdocs (semi-final conversion exists)
       - pkgsrc - [[public|https://anonhg.netbsd.org/pkgsrc/]] & [[internal|ssh://hg.netbsd.org/pkgsrc]]
       - src - [[public|https://anonhg.netbsd.org/src/]] & [[internal|ssh://hg.netbsd.org/src]]
       - xsrc - [[public|https://anonhg.netbsd.org/xsrc/]] & [[internal|ssh://hg.netbsd.org/xsrc]]
@@ -102,13 +138,23 @@
       - wikisrc (needs a conversion first)
       - pkgsrc-wiki (needs a conversion first)
 

(Diff truncated)

Index: wikisrc/projects/project/userland_pci.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/userland_pci.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/projects/project/userland_pci.mdwn	1 Mar 2022 10:38:50 -0000	1.3
+++ wikisrc/projects/project/userland_pci.mdwn	15 Jul 2023 10:06:36 -0000	1.4
@@ -18,7 +18,7 @@
 When developing device drivers inside the kernel, mistakes will usually
  cause the whole kernel to crash unrecoverably and require a reboot.
 But device drivers need not run inside the kernel: with
- [rump](http://rumpkernel.org/), device driver code can be run as a
+ [rump](https://github.com/rumpkernel/wiki/wiki/), device driver code can be run as a
  process inside userland.
 
 However, userland code has only limited access to the hardware

Index: wikisrc/users/wiz/scm-migration.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/wiz/scm-migration.mdwn,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- wikisrc/users/wiz/scm-migration.mdwn	8 Jul 2023 07:15:52 -0000	1.35
+++ wikisrc/users/wiz/scm-migration.mdwn	14 Jul 2023 20:58:08 -0000	1.36
@@ -10,8 +10,8 @@
     - DONE authormap is finalized
   - github mirror
     - after final conversion happens, either force-push or make a new repository and deprecate the old one
-  - clarify if we want named or unnamed branches for vendor imports
-  - get proper release tags
+  - DONE clarify if we want named or unnamed branches for vendor imports - we want named
+  - get proper release tags - needs to be done manually, after the conversion - volunteers wanted
 
 - DONE documentation
   - [[CVS to hg migration guide|https://wiki.mercurial-scm.org/CvsInfo]]
@@ -25,6 +25,7 @@
 
 - releng some scripts need to be adapted
   - localsrc/releng/autobuild - martin@ is working on it
+  - update localsrc/releng/autobuild/autobuild.txt for hg
   - releng needs to migrate to using hg
 
 - anita test bed
@@ -65,7 +66,7 @@
 
 - othersrc
   - repository conversion exists, possible cleanups:
-    - split up `cvs imports` for some sources (luke@ is working on this)
+    - DONE split up `cvs imports` for some sources (luke@)
     - DONE missing tags on some files (dh@ fixed them)
     - DONE minor other fixes
     - apply fixes to CVS master
@@ -90,19 +91,36 @@
 - turn on hg as main repository
   - switch them one by one?
     - public repositories
-      - othersrc (discussion on-going)
-      - htdocs (needs a conversion first)
+      - othersrc (semi-final conversion exists)
+      - htdocs (conversion in progress)
       - pkgsrc - [[public|https://anonhg.netbsd.org/pkgsrc/]] & [[internal|ssh://hg.netbsd.org/pkgsrc]]
       - src - [[public|https://anonhg.netbsd.org/src/]] & [[internal|ssh://hg.netbsd.org/src]]
       - xsrc - [[public|https://anonhg.netbsd.org/xsrc/]] & [[internal|ssh://hg.netbsd.org/xsrc]]
     - internal repositories
-      - htutils (conversion exists)
-      - localsrc (needs a conversion first; update localsrc/releng/autobuild/autobuild.txt)
+      - htutils (semi-final conversion exists)
+      - localsrc (semi-final conversion exists)
       - wikisrc (needs a conversion first)
-      - pkgsrc-wiki (conversion exists, ask wiz@ for access)
+      - pkgsrc-wiki (needs a conversion first)
 
 - turn off CVS/anoncvs server :-)
 
 - close tech-repository mailing list
 
 - (optional) discuss if hg should be included in the base system
+
+NOTES
+===
+
+The migration keeps branch information, but there is no way to
+automatically create merge commits from the data available in CVS.
+
+Therefore, after the conversion, before the import of a new vendor
+version on the branch, hg needs to be told that the merge already
+happened. One method for this would be:
+
+    hg checkout default
+    hg merge BRANCHNAME
+    hg revert (to branch head)
+    hg commit (null-merge, just to let hg know this is already merged)
+
+and only then start with importing the new version on the vendor branch.

Members: 
	ports/xen/howto.mdwn:1.209->1.210 

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.209
retrieving revision 1.210
diff -u -r1.209 -r1.210
--- wikisrc/ports/xen/howto.mdwn	9 Jul 2023 11:08:59 -0000	1.209
+++ wikisrc/ports/xen/howto.mdwn	9 Jul 2023 11:12:11 -0000	1.210
@@ -52,8 +52,8 @@
 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
-PVH		|not yet	|>= 10			|>= 10
+PVHVM		|N/A		|yes			|10/current
+PVH		|not yet	|10/current		|10/current
 """]]
 
 In PV (paravirtualized) mode, the guest OS does not attempt to access
@@ -123,7 +123,7 @@
 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 as a dom0 supports HVM mode in domUs.
+to be the only way.  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

Add caution about dom0 balloon.

Add update status for 4.13 and 4.15.

Note that 1-cpu and pinning is not known to be useful for >= 10.

Note phy: for storage and that block device is required.

Members: 
	ports/xen/howto.mdwn:1.208->1.209 

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.208
retrieving revision 1.209
diff -u -r1.208 -r1.209
--- wikisrc/ports/xen/howto.mdwn	28 Jun 2022 16:41:01 -0000	1.208
+++ wikisrc/ports/xen/howto.mdwn	9 Jul 2023 11:08:59 -0000	1.209
@@ -52,8 +52,8 @@
 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			|current only
-PVH		|not yet	|current only		|current only
+PVHVM		|N/A		|yes			|>= 10
+PVH		|not yet	|>= 10			|>= 10
 """]]
 
 In PV (paravirtualized) mode, the guest OS does not attempt to access
@@ -78,7 +78,7 @@
 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, but NB that this refers to PVHv2.  See
+config files use pvh -- these refer to PVHv2.  See
 [PVH(v2)](https://wiki.xenproject.org/wiki/PVH_(v2\)_Domu).
 
 At system boot, the dom0 kernel is loaded as a module with Xen as the
@@ -108,25 +108,24 @@
 
 [[!table data="""
 Xen Version	|Package Name	|Xen CPU Support	|EOL'ed By Upstream
-4.13		|xenkernel413	|x86_64			|No
-4.15		|xenkernel415	|x86_64			|No
+4.13		|xenkernel413	|x86_64			|last update December 2022
+4.15		|xenkernel415	|x86_64			|last update November 2022
 """]]
 
 See also the [Xen Security Advisory page](http://xenbits.xen.org/xsa/).
 
-Older Xen had a python-based management tool called xm; this has been
-replaced by xl.
+Older Xen had a python-based management tool called xm; this has long
+since been replaced by xl and is not discussed further.
 
 ## NetBSD versions
 
 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; for a long
-time this was the only way.  NetBSD >=8 as a dom0 supports HVM mode in
-domUs.
+NetBSD Xen has always supported PV, in both dom0 and domU -- this used
+to be the only way.  NetBSD >=8 as a dom0 supports HVM mode in domUs.
 
-Support for PVHVM and PVH is available only in NetBSD-current; this is
+Support for PVHVM and PVH is available in NetBSD 10; this is
 currently somewhat experimental, although PVHVM appears reasonably
 solid.
 
@@ -135,7 +134,7 @@
 vcpus, the kernel is likely to crash because of drivers without
 adequate locking.
 
-NetBSD-current supports SMP in dom0, and XEN3_DOM0 includes "options
+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
@@ -149,7 +148,7 @@
 # Creating a NetBSD dom0
 
 In order to install a NetBSD as a dom0, one first installs a normal
-NetBSD system, and then pivot the install to a dom0 install by
+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,
@@ -174,7 +173,7 @@
 
 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 xenkernel413 and xentools413 from pkgsrc.
+install xenkernel415 and xentools415 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:
@@ -276,15 +275,16 @@
 
 ### Tuning
 
-In an attempt to add performance, one can also add `dom0_max_vcpus=1
-dom0_vcpus_pin`, to force only one vcpu to be provided (since NetBSD
-dom0 can't use more) and to pin that vcpu to a physical CPU. Xen has
-[many boot
+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. Xen has [many boot
 options](http://xenbits.xenproject.org/docs/4.13-testing/misc/xen-command-line.html),
 and other than dom0 memory and max_vcpus, they are generally not
 necessary.
 
-\todo Revisit this advice with current.
+With NetBSD 10 and up, there does not seem to be an argument that
+pinning or limiting CPUs is a good idea.
+
 \todo Explain if anyone has ever actually measured that this helps.
 
 ### rc.conf
@@ -302,6 +302,17 @@
 
 \todo Recommend for/against xen-watchdog.
 
+### balloon
+
+The Xen world widely cautions against using the balloon driver in the
+dom0.  The standard advice for production servers is to disable it in
+xl.conf.  For machines that are primarily the dom0 but occasionally
+run guests, allocating all memory to the dom0 and using balloon seems
+ok.
+
+\todo Understand and describe the interaction of balloon with zfs
+(which is memory-piggy) in a dom0.
+
 ### Testing
 
 Now, reboot so that you are running a DOM0 kernel under Xen, rather
@@ -434,14 +445,14 @@
          'file:/n0/xen/foo-wd1,0x1,w' ]
 """]]
 
-The domain will have name given in the `name` setting.  The kernel has the
-host/domU name in it, so that on the dom0 one can update the various
-domUs independently.  The `vif` line causes an interface to be provided,
-with a specific mac address (do not reuse MAC addresses!), in bridge
-mode.  Two disks are provided, and they are both writable; the bits
-are stored in files and Xen attaches them to a vnd(4) device in the
-dom0 on domain creation.  The system treats xbd0 as the boot device
-without needing explicit configuration.
+The domain will have name given in the `name` setting.  The kernel has
+the host/domU name in it, so that on the dom0 one can update the
+various domUs independently.  The `vif` line causes an interface to be
+provided, with a specific mac address (do not reuse MAC addresses!),
+in bridge mode.  Two disks are provided, and they are both writable;
+the bits are stored in files and Xen attaches them to a vnd(4) device
+in the dom0 on domain creation.  The system treats xbd0 as the boot
+device without needing explicit configuration.
 
 There is not a type line; that implicitly defines a pv domU.
 Otherwise, one sets type to the lower-case version of the domU type in
@@ -479,21 +490,14 @@
 sum of the the memory allocated to the dom0 and all domUs must be less
 than the available memory.
 
-## Balloon driver
-
-Xen provides a `balloon` driver, which can be used to let domains use
-more memory temporarily.
-
-\todo Explain how to set up a aystem to use the balloon scheme in a
-useful manner.
-
 ## Virtual disks
 
 In domU config files, the disks are defined as a sequence of 3-tuples:
 
  * The first element is "method:/path/to/disk". Common methods are
-   "file:" for a file-backed vnd, and "phy:" for something that is already
-   a device, such as an LVM logical volume.
+   "file:" for a file-backed vnd, and "phy:" for something that is
+   already a device, such as an LVM logical volume, actual device, or
+   zvol.  For phy: one must use the block device.
 
  * The second element is an artifact of how virtual disks are passed to
    Linux, and a source of confusion with NetBSD Xen usage.  Linux domUs
@@ -548,7 +552,7 @@
 
 With NAT, the domU perceives itself to be behind a NAT running on the
 dom0.  This is often appropriate when running Xen on a workstation.
-TODO: NAT appears to be configured by "vif = [ '' ]".
+\todo NAT appears to be configured by "vif = [ '' ]".
 
 The MAC address specified is the one used for the interface in the new
 domain.  The interface in dom0 will use this address XOR'd with
@@ -711,7 +715,7 @@
 
 NB: PCI passthrough only works on some Xen versions and as of 2020 it
 is not clear that it works on any version in pkgsrc.  \todo Reports

(Diff truncated)

Index: wikisrc/users/wiz/scm-migration.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/wiz/scm-migration.mdwn,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- wikisrc/users/wiz/scm-migration.mdwn	27 Jun 2023 17:54:57 -0000	1.34
+++ wikisrc/users/wiz/scm-migration.mdwn	8 Jul 2023 07:15:52 -0000	1.35
@@ -10,6 +10,8 @@
     - DONE authormap is finalized
   - github mirror
     - after final conversion happens, either force-push or make a new repository and deprecate the old one
+  - clarify if we want named or unnamed branches for vendor imports
+  - get proper release tags
 
 - DONE documentation
   - [[CVS to hg migration guide|https://wiki.mercurial-scm.org/CvsInfo]]
@@ -47,7 +49,7 @@
   - scripts/update.releng
 
 - wiki & pkgsrc-wiki
-  - ikiwiki hg plugin (schmonz is working on this)
+  - ikiwiki hg plugin (schmonz@ is working on this)
 
 - pkgsrc
   - DONE expect lots of merge problems in doc/CHANGES* - use merge tool `:union` to fix this, configured in `.hgrc` like this:
@@ -63,8 +65,10 @@
 
 - othersrc
   - repository conversion exists, possible cleanups:
-    - split up `cvs imports` for some sources, merge them?
-    - missing tags on some files, fix them? how?
+    - split up `cvs imports` for some sources (luke@ is working on this)
+    - DONE missing tags on some files (dh@ fixed them)
+    - DONE minor other fixes
+    - apply fixes to CVS master
 
 - developer activity script for admins/membership-exec needs to be adapted or rewritten
 
@@ -80,19 +84,19 @@
 
 - repository conversion
   - hg supports conversion from CVS directly, but it doesn't handle `cvs import` well
-  - cvs2fossil is preferred, packaged in wip/cvs2fossil and wip/cvs2hg, some details unclear
+  - cvs2fossil is preferred, packaged in wip/cvs2fossil and wip/cvs2hg
   - joerg@ wants to do 'cleaned-up' conversions of src & pkgsrc before we switch
 
 - turn on hg as main repository
   - switch them one by one?
     - public repositories
-      - othersrc (needs a good conversion first)
+      - othersrc (discussion on-going)
       - htdocs (needs a conversion first)
       - pkgsrc - [[public|https://anonhg.netbsd.org/pkgsrc/]] & [[internal|ssh://hg.netbsd.org/pkgsrc]]
       - src - [[public|https://anonhg.netbsd.org/src/]] & [[internal|ssh://hg.netbsd.org/src]]
       - xsrc - [[public|https://anonhg.netbsd.org/xsrc/]] & [[internal|ssh://hg.netbsd.org/xsrc]]
     - internal repositories
-      - htutils (conversion exists, ask wiz for access)
+      - htutils (conversion exists)
       - localsrc (needs a conversion first; update localsrc/releng/autobuild/autobuild.txt)
       - wikisrc (needs a conversion first)
       - pkgsrc-wiki (conversion exists, ask wiz@ for access)