Hello GNU Hurd team, As a long-time subscriber to help-hurd mail list, I have followed the project's steady progress with deep respect and am very happy to finally have the opportunity to contribute directly toward accelerating GNU Hurd.
I run a small, dedicated hardware-backed build and testing lab focused on the Debian hurd-amd64 port gap. The lab pairs a dedicated compute host with an iterating coding agent that performs the repetitive legwork -- scraping build failures, running native builds, triaging failures, and isolating minimal reproducers -- under my direct (human) accountability :) Inspired by Brent Baccala's work highlighted in your Q1-2026 news update -- debugging x86_64 SMP issues alongside an AI assistant -- I adopted the same collaborative model here. The agent accelerates the time-consuming build triage, failure analysis, and reproducer minimization, while I remain fully accountable for every finding and patch. Everything is human-curated and reviewed before reaching the list, ensuring zero noise and maximum signal for the maintainers. The guiding principle is to maximize merged value while consuming as little maintainer review bandwidth as possible. To that end, the lab has built and staged a bank of verified results, datasets, and minimal reproducers: 1. Debian hurd-amd64 Portability Bank (For Debian BTS / Upstream): - 14 package portability fixes built green on native Hurd (e.g. msc-generator, pgstat, postgresql-18-age, barvinok, modsecurity-apache, iptux). - 3 of these have been verified against full Debian integration suites (autopkgtest PASS). - Fixes focus on clean, upstream-acceptable #if defined(__GNU__) guard widening or dynamic memory allocation replacing hardcoded PATH_MAX limits. 2. GNU Mach SMP Storage-Initialization Hang Differential (Kernel / Mach): - A clean, reproducible 4-configuration matrix on gnumach-image-1-amd64-smp showing a storage-initialization hang during rumpdisk PCI/IRQ setup on both PIIX3 and q35/AHCI controllers (where UP kernels progress further). - Recorded with exact environment specs, GRUB entry paths, and screendumps. 3. GHC Interface & Dynamic File Corruption Dataset (Subsystem Research): - A measured dataset across shipped corrupt Haskell packages (.dyn_hi interface files and .dynstr string tables) and a standalone ELF/.hi detector script. - Empirical statistical analysis showing that 16-byte zero runs in shipped binaries cluster heavily at 4 KiB page ends (offset mod 4096 = 4080), providing concrete data supporting the page-boundary write-back hypothesis discussed on this list. The lab and its compute resources are fully at the maintainers' disposal, strictly on the terms preferred by the team. Before submitting individual patches or reports, a few quick questions: - First and foremost: Do you agree with this collaborative model, and do you welcome this lab's assistance in triaging build failures and isolating reproducers for GNU Hurd? - If so, *which channel and format do you prefer* for receiving these deliverables? (e.g., individual Debian BTS bug reports tagged 'hurd' for package fixes, email threads on bug-hurd for core kernel/Mach issues, or git format-patch emails?) - What delivery cadence works best for your review capacity? The workflow can be easily tailored to whatever best fits the maintainers' needs. Thank you for your incredible work on GNU Hurd! Best regards, Federico Bonino Fede654 <https://github.com/fede654>
