Dedicated hurd-amd64 build/test lab: staged results and delivery preferences

Federico Bonino <[email protected]> Sat, 25 Jul 2026 19:51:26 +0000
Newsgroups gmane.os.hurd.bugs
Message-ID <CAE6APk5u7sXf9HwM=1nAbfVKEVicdT0Z8HD1XLcTnToOZ6PW8w@mail.gmail.com>
--000000000000037aa2065774d4ce
Content-Type: text/plain; charset="UTF-8"

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>

--000000000000037aa2065774d4ce
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello GNU Hurd team,<br><br>As a long-time subscriber to h=
elp-hurd mail list, I have followed the project&#39;s steady progress with =
deep respect and am very happy to finally have the opportunity to contribut=
e directly toward accelerating GNU Hurd.<br><br>I run a small, dedicated ha=
rdware-backed build and testing lab focused on the Debian hurd-amd64 port g=
ap. The lab pairs a dedicated compute host with an iterating coding agent t=
hat performs the repetitive legwork -- scraping build failures, running nat=
ive=C2=A0builds, triaging failures, and isolating minimal reproducers -- un=
der my direct (human) accountability :)<br><br>Inspired by Brent Baccala&#3=
9;s work highlighted in your Q1-2026 news update -- debugging x86_64 SMP is=
sues alongside an AI assistant -- I adopted the same collaborative model he=
re. The agent accelerates the time-consuming build triage, failure analysis=
, and reproducer minimization, while I remain fully accountable for every f=
inding and patch. Everything is human-curated and reviewed before reaching =
the list, ensuring zero noise=C2=A0and maximum signal for the maintainers.<=
br><br>The guiding principle is to maximize merged value while consuming as=
 little maintainer review bandwidth as possible. To that end, the lab has b=
uilt and staged a bank of verified results, datasets, and minimal reproduce=
rs:<br><br>1. Debian hurd-amd64 Portability Bank (For Debian BTS / Upstream=
):<br>=C2=A0- 14 package portability fixes built green on native Hurd (e.g.=
 msc-generator,=C2=A0pgstat, postgresql-18-age, barvinok, modsecurity-apach=
e, iptux).<br>=C2=A0- 3 of these have been verified against full Debian int=
egration suites (autopkgtest PASS).<br>=C2=A0- Fixes focus on clean, upstre=
am-acceptable #if defined(__GNU__) guard widening or=C2=A0dynamic memory al=
location replacing hardcoded PATH_MAX limits.<br><br>2. GNU Mach SMP Storag=
e-Initialization Hang Differential (Kernel / Mach):<br>=C2=A0- A clean, rep=
roducible 4-configuration matrix on gnumach-image-1-amd64-smp showing=C2=A0=
a storage-initialization hang during rumpdisk PCI/IRQ setup on both PIIX3 a=
nd=C2=A0q35/AHCI controllers (where UP kernels progress further).<br>=C2=A0=
- Recorded with exact environment specs, GRUB entry paths, and screendumps.=
<br><br>3. GHC Interface &amp; Dynamic File Corruption Dataset (Subsystem R=
esearch):<br>=C2=A0- A measured dataset across shipped corrupt Haskell pack=
ages (.dyn_hi interface=C2=A0files and .dynstr string tables) and a standal=
one ELF/.hi detector script.<br>=C2=A0- Empirical statistical analysis show=
ing that 16-byte zero runs in shipped binaries=C2=A0cluster heavily at 4 Ki=
B page ends (offset mod 4096 =3D 4080), providing concrete=C2=A0data suppor=
ting the page-boundary write-back hypothesis discussed on this list.<br><br=
>The lab and its compute resources are fully at the maintainers&#39; dispos=
al, strictly on the terms preferred by the team.<br><br><div>Before submitt=
ing individual patches or reports, a few quick questions:<br>- First and fo=
remost: Do you agree with this collaborative model, and do you welcome=C2=
=A0this lab&#39;s assistance in triaging build failures and isolating repro=
ducers for GNU Hurd?<br>- If so, <b>which channel and format do you prefer<=
/b> for receiving these deliverables?=C2=A0(e.g., individual Debian BTS bug=
 reports tagged &#39;hurd&#39; for package fixes, email=C2=A0threads on bug=
-hurd for core kernel/Mach issues, or git format-patch emails?)<br>- What d=
elivery cadence works best for your review capacity?<br><br>The workflow ca=
n be easily tailored to whatever best fits the maintainers&#39; needs.<br><=
br>Thank you for your incredible work on GNU Hurd!<br><br>Best regards,<div=
>Federico Bonino</div><div><a href=3D"https://github.com/fede654">Fede654</=
a><br></div></div></div>

--000000000000037aa2065774d4ce--