Joshua Branson <[email protected]> writes: > --- > news/2026-q2.mdwn | 325 ++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 325 insertions(+) > create mode 100644 news/2026-q2.mdwn
Thanks, these round-ups are nice reading :) > > diff --git a/news/2026-q2.mdwn b/news/2026-q2.mdwn > new file mode 100644 The Gentoo news just missed the last Qoth, so it's due for this one. > 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). It's OpenNTPD (per https://www.openntpd.org/). > +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). > + Roy Marples (the dhcpcd maintainer) contributed significantly to that too in the last few weeks. > +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): Nit: `/dev` > + > + 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! "an NTP daemon", but this also involved some glibc wokr. > + > +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. > +
signature.asc
Description: PGP signature
