Both upstreams set fat LTO in their release profile (strata also
codegen-units = 1), which compiles the final crate on one thread. That
is a reasonable trade for the binary users run, and build() keeps it.
check() then compiled the same crate a second time under the same
profile for the test harness, and threw it away. On the aarch64 builds,
which run under QEMU, those two serial compiles were 106 of strata's
118 minutes.
check() now builds the harness with thin LTO and 16 codegen units in
its own target directory. The shipped binary is unchanged. Measured on
the x86_64 builder for strata's test binary: 708 s serial, 223 s with
this profile. Local run: shipped strata still 7m30s from target/, tests
3m43s from target-check/, 1998 passed.
ttfx has the same upstream profile but no check(), so nothing to do.
flea 0.3.0 never published: its shelfundo suite (new in 0.3.0) failed check() on the 2026-09-18 publish build, and 0.3.1 fails the same way on the sync PR. undo_refuses_to_walk_a_stranger_back deletes a file, creates another under the same name, and expects undo to tell them apart by (dev, ino, kind). ext4 hands the freed inode number straight back to the next create, so on the droplet's /tmp the stranger is identical and undo walks it back into a directory that does not exist. tmpfs allocates inode numbers from a counter and never reuses one. The suite joins the filesystem tests that already run with TMPDIR on /dev/shm.
On aarch64 three more tests fail: two in backend::child and one in menu_registry expect spawning a missing program to be reported as not started. Under QEMU user-mode emulation glibc's posix_spawn cannot observe the child's failed execve; the spawn succeeds with exit 127. Skipped on aarch64 only.
Every channel has failed since 0.2.1 landed: one package failing fails the
whole build, and the build step aborts the release before sign, promote or
sync. Nothing has published on edge, rc or stable since 2026-09-11, and 26
built packages have been rebuilt and discarded every cycle.
backend::redo::tests::redo_refuses_changed_sources_and_destination_collisions
writes a file and immediately asks redo to notice the edit. flea decides
"changed" from ctime alone -- src/backend/undo.rs records (ctime, ctime_nsec)
as the whole identity -- and this kernel stamps ctime from the coarse clock,
so two writes microseconds apart share a timestamp and the guard sees no
change. redo returns Ok where the test demands Err, which is why it fails
almost every run rather than intermittently.
Measured on this builder: 196/200 back-to-back write pairs on /dev/shm and
192/200 on the root filesystem produced an identical ctime. That also retires
the premise of 82363cb: /dev/shm does not buy finer timestamps here, so moving
the suite to tmpfs could never have fixed this, and the comment saying it does
is corrected. A probe cannot decide this at runtime either -- one using stat
reports the filesystem as fine-grained, because the stat subprocess alone
costs more than the granule it is trying to measure.
Both halves belong upstream in thisisgm/flea: the test assumes a resolution
the kernel never promised, and the identity it exercises cannot see a
same-granule edit, which is a real hole in undo/redo rather than only a test
artifact. Skipping one test is the narrow fix; holding the package back would
have stalled the other 26.
Only this test is affected. new_file_is_recreated_but_changed_or_replaced_
files_survive_undo asserts the same refusal and passes, because enough work
separates its write from the identity capture to cross a granule.
Verified with bin/repo build --package flea: filesystem suite 63 passed,
main suite 528 passed, flea 0.2.1-3 built.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Ryan Hughes