[PATCH] Q2 Qoth for 2026

---
 news/2026-q2.mdwn | 325 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 325 insertions(+)
 create mode 100644 news/2026-q2.mdwn

diff --git a/news/2026-q2.mdwn b/news/2026-q2.mdwn
new file mode 100644
index 00000000..2fc8ea10
--- /dev/null
+++ b/news/2026-q2.mdwn
@@ -0,0 +1,325 @@
+[[!meta copyright="Copyright © 2026 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+<!-- TODO before committing
+
+These wiki pages need to be added to hurd.gnu.org:
+
+hurd/translator/9pfs
+hurd/translator/eth-multiplexer
+logo/ethernet-multiplexor.svg
+
+-->
+
+Hello and welcome to another Qoth!  Here's what's been happening in Q2
+of 2026!
+
+Joshua Branson added a pretty cool svg logo for our [[ethernet
+multiplexor|hurd/translator/eth-multiplexer]].  He built that image
+with a Hurd laptop (Thinkpad 420) running on real iron via Inkscape!
+The Hurd wiki could certainly use more artwork.  Perhaps you have a
+favorite Hurd translator that you believes needs some artwork!
+
+Sergey Bugaev announced his [WIP
+9pfs](https://lists.gnu.org/archive/html/bug-hurd/2026-06/msg00012.html),
+and it has a [[wiki page|hurd/translator/9pfs]]! He writes:
+
+    Some years ago, I experimented with implementing a 9P translator for
+    the Hurd. Hopefully there is no need to tell this list what 9P is :)
+
+    Besides just browsing files on the few existing servers out there, a
+    potential use case is virtio-9p, to enable shared directory trees
+    between VMs and the host. But that would need someone to implement
+    virtio support in the Hurd.
+
+    I wanted to complete 9pfs before publishing, but that ultimately
+    didn't happen, so now it's time to turn it over to the community. I
+    now went and made the repository public on GitHub:
+    https://github.com/bugaevc/9pfs
+
+    What's implemented is basic browsing (readdir, stat), path resolution
+    (dir_lookup), and reading files (io_read). And below that, the whole
+    tracking for nodes, peropens, protids, fids, tags, and 9p RPCs.
+
+    Improvements are welcome, send patches to this list with [PATCH 9pfs]
+    in the subject. A good starting point would be to continue porting
+    things that I had implemented in the old netfs-based version (see
+    netfs.c) but didn't yet port to the new one.
+
+He then got a little more motivated, and he added some write support!
+
+Etienne Brateau added
+[validation](https://lists.gnu.org/archive/html/bug-hurd/2026-05/msg00098.html)
+to [msync](https://man7.org/linux/man-pages/man2/msync.2.html), so
+that the Hurd better follows POSIX.
+
+Diego Nieto Cid worked on allowing privileged users to set its task
+priority (nice value).  His patches landed in
+[glibc](https://lists.gnu.org/archive/html/bug-hurd/2026-05/msg00100.html)
+and [GNU
+Mach](https://lists.gnu.org/archive/html/bug-hurd/2026-05/msg00099.html).
+
+He also fixed a [tiny
+bug](https://lists.gnu.org/archive/html/bug-hurd/2026-04/msg00232.html)
+in our test suite. He fixed an adjtime bug, which is helpful to [the
+OpenNTP
+port](https://lists.gnu.org/archive/html/bug-hurd/2026-05/msg00061.html).
+He fixed
+[two more](https://lists.gnu.org/archive/html/bug-hurd/2026-04/msg00133.html)
+[bugs](https://lists.gnu.org/archive/html/bug-hurd/2026-05/msg00117.html).
+
+
+Paulo Duarte sent a RFC patch series trying to commit Sergey’s
+previous AArch64 work. He writes:
+
+    This series adds the gnumach kernel-side implementation for the
+    aarch64 ABI Sergey landed in April 2024, plus the test-suite arms.
+    Patch 01 brings in the aarch64-only sources from bugaevc/wip-aarch64
+    verbatim, with Sergey as Author; the rest is mine.
+
+    The meaningful divergence from wip-aarch64 is what I left out:
+    roughly 150 files of cross-arch refactoring across kern/, ipc/, vm/,
+    device/intr.{c,h}, and the i386 tree. Each got replaced with a
+    smaller per-arch shim under aarch64/ so kern/bootstrap.c,
+    device/intr.{c,h}, kern/lock.h, and the i386 trees all stay
+    bit-identical to current master. The shared-file footprint outside
+    aarch64/ is four files: a new ELF constant, two missing decls plus
+    their include, and a linker-symbol filter extension...
+
+    Tested: 12/12 pass on x86_64, i686, and aarch64 under qemu. No
+    bare-metal validation yet. I plan to build bootable images and boot
+    the kernel on Apple M1 / Raspberry Pi (aarch64) and an x86_64 box
+    (x86_64 + i686). Help on any of these welcome.
+
+
+He also fixed a [tiny cross compilation issue](https://lists.gnu.org/archive/html/bug-hurd/2026-05/msg00077.html).
+
+
+gfleury fixed some [tmpfs
+typos](https://lists.gnu.org/archive/html/bug-hurd/2026-05/msg00038.html).
+He also fixed a [kernel crash on a null pointer
+deference](https://lists.gnu.org/archive/html/bug-hurd/2026-05/msg00101.html).
+
+Joan Lledó continued his work [on](https://lists.gnu.org/archive/html/bug-hurd/2026-04/msg00067.html) [porting](https://lists.gnu.org/archive/html/bug-hurd/2026-06/msg00146.html) [dhcpcd](https://lists.gnu.org/archive/html/bug-hurd/2026-06/msg00028.html).
+
+Mikhail Karpov added some checks for [mmap in several places](https://lists.gnu.org/archive/html/bug-hurd/2026-06/msg00165.html).
+
+He also worked on adding storeio to the [bootstrap
+chain](https://lists.gnu.org/archive/html/bug-hurd/2026-04/msg00221.html).
+This is actually quite interesting.  Currently the Hurd sets device
+entries in `/dev/` statically.  For example, I am writing this qoth on
+a Hurd machine that is using two `/dev/` entries for my filesystem:
+`/dev/wd0s1` for swap and `/dev/wd0s5` for my root filesystem.
+However, `/dev/wd0s1` through `/dev/wd0s16` exist on my computer!
+Once Mikhail's project is done, then the Hurd will dynamically
+populate SATA devices at boot time!  No more need for static
+translators! [He
+writes](https://lists.gnu.org/archive/html/bug-hurd/2026-05/msg00041.html):
+
+
+    I've expanded the functionality of the partfs translator to work
+	with multiple disks and their partitions. Thus, by running the
+    command:
+	settrans -c partfs /hurd/partfs /root/disk1.img /root/disk2.img /root/disk3.img 
+
+
+    The translator directory will have the following directory tree:
+    partfs
+    ├── 0
+    │ ├── 1
+    │ ├── 2
+    │ └── ...
+    ├── 1
+    │ ├── 1
+    │ ├── 2
+    │ └── ...
+    ├── 2
+    │ ├── 1
+    │ ├── 2
+    │ └── ...
+    Since the disks are directories, the cd and ls commands work in the translator node.
+
+    I also tested mounting, reading, and writing using the commands:
+    `settrans -c ext01 /hurd/ext2fs -w -T typed file:/root/partfs/0/1`
+    and
+    `settrans -c ext1_1 /hurd/ext2fs -w -T typed part:1:file:/root/partfs/1`
+
+
+
+It actually is even cooler!  Samuel (our fearless leader) is [seeking
+feedback](https://lists.gnu.org/archive/html/bug-hurd/2026-04/msg00187.html)
+for how to name these newer `/dev/` entries. Samuel [writes](https://lists.gnu.org/archive/html/bug-hurd/2026-04/msg00187.html):
+
+    One thing that would be really needed for efficiency is to implement
+    netfs_file_get_storage_info, so that libstore would be able to get the
+    underlying storage information, and directly get data from there rather
+    than partfs having to pass data with io_read/write.
+
+    I'm then wondering how this would fit in the "grand scheme". Our current
+    approach, /dev/hd0s* being always there, is indeed not really good
+    because it doesn't easily tell the user which partitions are actually
+    there. We used to have to have this because partitions used to be
+    handled by the kernel, and then we have moved to
+    storerio+parted-supported partitions, which brings much more
+    flexibility.
+
+    Perhaps we could use
+
+    settrans -c /dev/hd0s /hurd/partfs /dev/hd0
+
+    and then we'd have /dev/hd0s/1, which is almost like before, but allows
+    the entries to be dynamic. Actually, we could even have some
+
+    settrans -c /dev/hd /hurd/probedisk hd
+
+    and then we'd have /dev/hd/0, and we could have /dev/hd/0s being partfs,
+    so we'd eventually have
+
+    /dev/hd/0s/1
+
+    But I'm also thinking that perhaps it could be integrated more with
+    storeio, i.e. /dev/hd0 can as well also act as a directory with partfs
+    behavior, so you could have
+
+    /dev/hd0/1
+
+    and with the probedisk translator, you could have
+
+    /dev/hd/0/1
+
+    What do people think about it?
+
+
+The mysterious developer “include” [allowed passing “-s” to
+init](https://lists.gnu.org/archive/html/bug-hurd/2026-06/msg00082.html).
+Previously, passing "-s" to init was silently ignored.
+
+
+Mike Kelly has been hard at work [porting OpenBSD’s
+OpenNTP](https://lists.gnu.org/archive/html/bug-hurd/2026-04/msg00185.html).
+The Hurd doesn't currently have a openNTP daemon, so thanks Mike!
+
+He also was debugging a [weird memory error with
+rump](https://lists.gnu.org/archive/html/bug-hurd/2026-04/msg00029.html),
+and he provided a ["brown-tape"
+solution](https://lists.gnu.org/archive/html/bug-hurd/2026-06/msg00136.html)
+for it. Hopefully, he (or you dear reader), can reach out to the
+NetBSD people to fix this bug.  This just goes to show that when two
+projects use the same code, both projects benefit!
+
+He also got a [glibc patch
+committed](https://lists.gnu.org/archive/html/bug-hurd/2026-04/msg00012.html).
+Essentially `SIGSTOP`/`SIGCONT` was duplicating portions of files,
+which is now fixed.  However, there are still some [other
+issues](https://lists.gnu.org/archive/html/bug-hurd/2026-04/msg00149.html)
+with building some haskell packages.
+
+
+
+Bradley Morgan fixed a [tiny implementation bug with
+cat](https://lists.gnu.org/archive/html/bug-hurd/2026-06/msg00120.html). He
+also tweaked procfs to [show hidden
+files](https://lists.gnu.org/archive/html/bug-hurd/2026-06/msg00122.html).
+
+Johannes Schauer Marin Rodrigues has been working on getting [s-build to run on amd64 Hurd](https://lists.debian.org/debian-hurd/2026/06/msg00000.html).
+
+
+Milos Nikic ported
+[Neovim](https://lists.gnu.org/archive/html/bug-hurd/2026-04/msg00141.html).
+
+He also worked on
+[bug](https://lists.gnu.org/archive/html/bug-hurd/2026-04/msg00179.html)
+[fixes](https://lists.gnu.org/archive/html/bug-hurd/2026-04/msg00195.html)
+to
+[libdiskfs](https://lists.gnu.org/archive/html/bug-hurd/2026-04/msg00020.html),
+and he fixed a deadlock bug in the [“ext3/ext4” filesystem
+journal](https://lists.gnu.org/archive/html/bug-hurd/2026-06/msg00171.html).
+
+
+In the last qoth we had talked about how the Milos was working on
+adding an ext3/ext4 binary compatible journal.  Samuel has committed
+it!  Samuel wrote:
+
+    There is a couple things that I fixed on the fly:
+
+    - We want to use pthread_cond_clockwait rather than
+      pthread_cond_timedwait, to be able to use CLOCK_MONOTONIC instead of
+      CLOCK_REALTIME, to avoid being hit by ntpdate and such.
+
+    - In diskfs_S_dir_rename, there was an addition of:
+
+      pthread_mutex_unlock (&fnp->lock);
+
+      which was clearly bogus: we were unlocking it again below.
+
+    There are a couple things that we'd want to fix now:
+
+    - when calling diskfs_file_update, don't we have to be inside a
+      transaction? Otherwise if we pass wait=1 and use a journal, we won't
+      be waiting AIUI? Notably, in diskfs_S_dir_rmdir we don't use a
+      transaction. And ideally we'd have an assertion that makes sure we
+      respect this.
+
+    - we should define some helper for this recurring pattern:
+
+      if ((docommit) && (diskfs_synchronous || diskfs_journal_needs_sync (txn)))
+        diskfs_journal_commit_transaction (txn);
+      else
+        diskfs_journal_stop_transaction (txn);
+
+    - journal_drain_deferred_blocks should document what it does, not just
+      its call conditions :), and more generally the functions that are
+      not already documented in a .h and not just a _locked variant of a
+      documented function.
+
+Leonardo Lopes Pereira did some [spring
+cleaning](https://lists.gnu.org/archive/html/bug-hurd/2026-04/msg00083.html)
+to remove some [dead
+code](https://lists.gnu.org/archive/html/bug-hurd/2026-04/msg00084.html).
+
+
+
+Samuel Thibault mentioned [in an
+email](https://lists.debian.org/debian-hurd/2026/04/msg00016.html)
+that the Hurd can support nvmes with rump, but that the work was just
+not done yet.  Perhaps you, dear reader, would like to help us
+accomplish this task?
+
+The mysterious user yelini worked on [porting the D language compiler](https://lists.gnu.org/archive/html/bug-hurd/2026-06/msg00069.html).
+
+
+Damien Zammit worked on [tweaking the Hurd’s WIP CI](https://lists.gnu.org/archive/html/bug-hurd/2026-06/msg00139.html).
+
+He also
+[fixed](https://lists.gnu.org/archive/html/bug-hurd/2026-06/msg00106.html)
+[several](https://lists.gnu.org/archive/html/bug-hurd/2026-06/msg00100.html)
+[bugs](https://lists.gnu.org/archive/html/bug-hurd/2026-06/msg00117.html)
+to make it possible to run the Hurd’s test suite from GNU/Linux
+running on an AArch64 computer.
+
+He also is working on integrating qemu’s Hurd support into [upstream
+qemu’s
+CI](https://lists.gnu.org/archive/html/bug-hurd/2026-06/msg00102.html),
+so that the support does not bitrot.
+
+
+Sophiel Zhou fixed [a tiny pfinet permission checking
+issue](https://lists.gnu.org/archive/html/bug-hurd/2026-06/msg00027.html)
+and taught [pfinet to not fail under memory pressure](https://lists.gnu.org/archive/html/bug-hurd/2026-06/msg00043.html):
+
+    This series fixes two latent crash bugs in pfinet where mmap
+    return values go unchecked, may causing crash when memory is tight.
+
+    Both bugs follow the same pattern: mmap is called to grow a buffer,
+    but the returned pointer is dereferenced before (or without) checking
+    for MAP_FAILED.  Under normal operation mmap rarely fails, so these
+    have gone unnoticed, but under address-space pressure pfinet would
+    crash.
+
-- 
2.53.0