Published, thanks!
Joshua Branson, le ven. 03 juil. 2026 16:32:51 -0400, a ecrit:
> ---
> news/2026-q2.mdwn | 328 ++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 328 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..4b2adccf
> --- /dev/null
> +++ b/news/2026-q2.mdwn
> @@ -0,0 +1,328 @@
> +[[!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 Inkscape whilst using a Hurd laptop (Thinkpad 420) running on
> +real iron! 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)
> +([source code](https://github.com/bugaevc/9pfs)),
> +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 their 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
> +OpenNTPD
> +port](https://lists.gnu.org/archive/html/bug-hurd/2026-05/msg00061.html),
> +and 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).
> +
> +Almudena Garcia is developing a [WIP trivfs implementation in
> +rust](https://gitlab.com/AlmuHS/hurd-translator-in-rust). The work is
> +not complete yet, but it is possible to write Hurd translators in Rust!
> +
> +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?
> +
> +
> +Mike Kelly has been hard at work [porting OpenBSD’s
> +OpenNTPD](https://lists.gnu.org/archive/html/bug-hurd/2026-04/msg00185.html),
> +which required some glibc work. The Hurd doesn't currently have a
> +NTP daemon, so thanks Mike!
> +
> +He also debugged 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.
> +
> +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).
> +Also Roy Maples, the dhcpcd maintainer did a lot of helpful work to
> +help us out. Thanks Roy!
> +
> +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),
> +and he [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.
> +
> +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). It
> +is a rather long email thread, so grab some popcorn and dig in!
> +
> +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
>
>
--
Samuel
What's this script do?
unzip ; touch ; finger ; mount ; gasp ; yes ; umount ; sleep
Hint for the answer: not everything is computer-oriented. Sometimes you're
in a sleeping bag, camping out.
(Contributed by Frans van der Zande.)
