Phase 6.2: the MLD driver logic is now Rust, not C. The legacy C
linux_mld.c remains only as a thin transport-level helper (init/parse
functions for C structs used by linux_port.c); all MLD state management,
notification dispatch, TX/scan/sta management, and MLO RX parsing is
now in proper Rust.
src/mld.rs (744 lines):
- Complete firmware command ID table: all 7 command groups with
WIDE_ID encoding, 50+ command/notification IDs from Linux fw/api
- OpMode selection: BZ→iwlmld, others→iwlmvm (Linux iwl-drv.c)
- MldState: fw_running, radio_kill, scan, TX queue array[512],
notification counters (AtomicU32)
- NotifResult: decoded notification (handled/is_rx_frame/signal/rate/
wide_id/group/cmd/kind)
- handle_notification(): full WIDE_ID dispatch — all legacy + grouped
notifications, RX MPDU via parse_rx_mpdu, counted by type
- parse_rx_mpdu(): MLO RX MPDU parser — link_id from mac_phy_band,
AMSDU flags, signal/rate via FFI to legacy C Mini-MVM parser
(no duplicate parser per upstream-first rule)
- MldState::firmware_init(): records init sequence
- MldState::start/stop_scan(): scan state management
- MldState::add/remove_sta(): station ID validation
- MldState::alloc/free_txq(): TVQM queue allocation
- FFI to C: rb_iwl_mvm_detect_signal/rate_to_mcs via unsafe extern
- 11 unit tests covering: opmode selection, WIDE_ID encoding, state
init, firmware init, TXQ alloc/free, scan management, station
management, legacy + grouped + unknown notification dispatch,
notif_kind coverage
All 19 tests pass (11 MLD + 7 existing + 1 integration). The module
is integrated via 'mod mld;' in main.rs.
KWINDOWSYSTEM_WAYLAND=ON -> CMakeLists find_package(PlasmaWaylandProtocols
REQUIRED) (+ Qt6WaylandClient, WaylandProtocols). Only qtbase/qtdeclarative were
declared, so configure failed "Could not find ... PlasmaWaylandProtocols".
plasma-wayland-protocols recipe exists and builds; declare it + qtwayland +
wayland-protocols. Direct sddm dep, greeter-critical.
Both build a QML module (KWINDOWSYSTEM_QML=ON / ksvg QML) whose CMakeLists does
find_package(Qt6Qml) via ECMQmlModule, but declared only qtbase -- so cookbook
never installed Qt6Qml (qtdeclarative) into their sysroot and configure failed
"Could not find a package configuration file provided by Qt6Qml", even though
qtdeclarative itself now builds. kf6-kwindowsystem is a direct sddm dependency,
so this blocked the greeter. Audited all kf6 recipes: these two were the only
QML-consumers missing the dep (kf6-kitemmodels already had it).
Self-review followups after v4.1, plus two correctness fixes the audit
uncovered.
unified_events:
* Carry RecoveryAction through the Aer variant of UnifiedEvent. The
routing decision (route_to_driver against the latest bind snapshot)
is made once in run() and threaded into the callback, so the
callback does not recompute it. Eliminates a duplicate
route_to_driver call per AER event.
* Update the unified_events test to the new Aer { event, action }
shape.
main.rs:
* Simplified AER callback: no double route_to_driver, no
dead cfg(not(target_os = "redox")) arm. Dispatch gated on
cfg(target_os = "redox") so host builds compile.
* RecoveryAction::Fatal escalation: emit a stable ERROR-level
marker ('AER-FATAL: device=... driver-already-dead escalation
marker ...') before the action_str match returns None. Operator
tooling can grep this marker to detect unrecoverable events that
need human attention. No auto-dispatch on Fatal by design -- the
driver is dead, recovery cannot succeed.
modern_technology:
* iommu_group_for: replace the unmatchable hash-keyed path check
(/scheme/iommu/domain/<hash(bdf)>) with scheme-presence detection
(/scheme/iommu exists). The iommu daemon does NOT expose a BDF to
group lookup, so scheme-presence is the strongest signal
available without opening a handle.
* numa_node_for: replace the wrong /scheme/numad/device/<bdf>
check (numad does NOT expose that path) with the correct
/scheme/proc/numa presence check (numad writes topology there).
* numa_node_env_value: dedupe -- reuse numa_node_for's source
discriminant instead of duplicating the path-existence check.
Tests:
- driver-manager: 63 passed (no change)
- redox-driver-core: 32 passed (no change)
- host build clean
Self-review found the v4.1 update's AER row claimed 'Driver::on_error
→ RecoveryAction on bound devices is now end-to-end rather than
discarded.' That is misleading: DriverConfig does not override
Driver::on_error (the trait method keeps its default Ok(Handled)
impl), so the trait callback is never invoked. The v4.1 fix wires
manager-level auto-dispatch (AER event → route_to_driver →
dispatch_recovery), not driver-level on_error IPC. The driver-IPC
item remains open.
Reword the row to say manager-level dispatch and note that
Driver::on_error IPC is a separate item.
Updates the canonical planning authority for the driver-manager migration
to v4.1, which closes the three P3 items v4.0 had declared open.
Adds:
* v4.1 update block with the table mapping each v4.0 P3 item to its
v4.1 resolution (QuirkPhase::Early gating, AER auto-dispatch,
per-vendor firmware assessment) and the IOMMU/NUMA honest-absence
fix in redox-driver-core::modern_technology.
* Driver-by-driver audit summary — every PCI driver invoked from
/lib/drivers.d/*.toml plus the modern-tech daemons and bridging
consumers. No stubs, no todo!()/unimplemented!() in production
paths.
* Adjacent-technology compatibility matrix — cpufreqd/thermald
verified compatible; iommu now honest; udev-shim/driver-params
wired correctly; redox-drm/xhcid/iwlwifi/amdgpu use the granted
channel contract.
Refreshes the v4.0 post-cutover table to reflect the v4.1 AER row
('auto-dispatch from listener; RecoveryAction::ResetDevice/RescanBus
execute via shared dispatch_recovery helper') and the v4.1 quirks
row (phase = early/enable consulted at probe time).
Replaces the now-stale v4.0 'Open items (updated)' line with the v4.1
list — none from v4.0 P3, plus the operator-only gates that remain
(ACPI session, hardware validation matrix, two-week soak).
Updates Last reviewed line to 2026-07-24.
driver-manager v4.1 — closes the three remaining P3 items the v4.0 plan
declared open after the cutover:
* AER auto-dispatch to bound devices (P3 #2 endpoint side):
route_to_driver now actually invokes the recovery body for NonFatal
(ResetDevice) and Fatal (RescanBus) events on bound devices, instead
of only logging. The /recover scheme endpoint and the auto-dispatch
both share the new scheme::DriverManagerScheme::dispatch_recovery
helper, so operator-triggered and event-triggered recovery use the
same code path. Driver::on_error → RecoveryAction on bound devices
is now end-to-end rather than discarded.
* Quirk lifecycle phase Early (P3 #1): the probe path consults
QuirkPhase::Early before the channel open and gates WRONG_CLASS /
BROKEN_BRIDGE on it. decide_for_phase in quirks.rs bridges to
redox-driver-sys::quirks::lookup_pci_quirks_for_phase. Combined with
Enable (spawn-time), this is the Linux 2-of-8 minimum split. PM
phases remain out of scope per plan § P3.
* IOMMU/NUMA honest absence: iommu_group_env_value() and
numa_node_env_value() report "0" when the corresponding scheme is
not present, instead of the previous deterministic BDF hash that
looked like a real isolation group / node id. Drivers that consume
REDBEAR_DRIVER_IOMMU_GROUP / REDBEAR_DRIVER_NUMA_NODE now see
"no group" / "no node" instead of a value they might trust.
Tests:
+ 4 driver-manager scheme::tests::recovery_action_* cases
+ 2 redox-driver-core modern_technology::tests env-value cases
Total: 63 driver-manager tests + 32 redox-driver-core tests, all green.
Replace the purged stale 6.11.0 caches with the official 6.11.1 tarballs. Each
was downloaded from the pinned recipe URL and verified: blake3 == recipe.toml
pin, and top-level dir == <module>-everywhere-src-6.11.1. The pins were already
correct 6.11.1 hashes (set during the version bump) -- only the committed
source.tar caches had gone stale at 6.11.0. Restores offline reproducibility to
match qtbase/qtshadertools/qtsvg (which commit their 6.11.1 source.tar).
recipes/libs/mesa is a wholesale symlink to local/recipes/libs/mesa, so
cookbook resolved the recipe patch refs "mesa/NN-*.patch" to
local/recipes/libs/mesa/mesa/NN-*.patch -- a subdir that never existed. The
patches live in local/patches/mesa/, and apply-patches.sh only individually
links kernel/base patches, never mesa. So mesa could only build from a
pre-patched cached source/; a clean re-fetch (e.g. online mode) failed with
"Failed to find patch file recipes/libs/mesa/mesa/01-...". Add the mesa/ subdir
as a relative symlink into the canonical local/patches/mesa so the referenced
path resolves (all in local/), without touching recipe.toml (mesa stays
cached). Audited all 37 patch refs across every recipe -- mesa was the only
unresolved one.
Two corrections after finding the Qt offline-source model:
1. The Qt recipes intentionally COMMIT source.tar as the offline source
(qtbase/qtsvg/qtshadertools all do). My previous commit wrongly added a
local/recipes/**/source.tar ignore rule; revert it -- source.tar is durable
here, only source/ is the fork model.
2. Real deficiency: the pre-cook offline decision honored only the
REDBEAR_ALLOW_UPSTREAM env var, while the main `make live` phase also goes
online for the --upstream flag (ALLOW_UPSTREAM=1). So `--upstream` alone left
the pre-cook OFFLINE but the main phase ONLINE -- a package missing its
source.tar cache (e.g. right after the stale 6.11.0 tars were purged) failed
the pre-cook with "Opening file for blake3 failed ... source.tar: No such
file". Make the pre-cook honor ALLOW_UPSTREAM too, matching the main phase.
The 6.11.1 upgrade bumped recipe URLs+blake3 for the Qt modules but left stale
committed fetch-caches for three of them: qtdeclarative/qtwayland/qt6-sensors
shipped source.tar (and qt6-sensors a source/ extract) still at 6.11.0. repo
validates the cache against recipe blake3, so the stale 6.11.0 tar mismatched
the 6.11.1 pin -> "downloaded tar blake3 ... is not equal to blake3 in
recipe.toml" -> qtdeclarative cook failed, cascading Qt6Qml failures in every
downstream consumer (qtwayland, kf6-*), aborting the whole build.
Root cause of the committed caches: .gitignore only ignored recipes/**/source.tar
(mainline tree), never local/recipes/**/source.tar, so local fetch-caches were
committable and went stale on version bumps. Fixes:
- git rm the stale 6.11.0 source.tar (x3) + qt6-sensors 6.11.0 source/ extract
so the build re-fetches the pinned 6.11.1 tarballs.
- .gitignore: ignore local/recipes/**/source.tar(.tmp) (fetch-cache; NOT
source/, the durable fork model) so this cannot recur.
qtbase/qtshadertools/qtsvg were already correct (source.tar==6.11.1==pin).
sddm and the kf6 modules (pulled by kwin) do find_package(Qt6Qml)/Qt6Quick,
which only exist once qtdeclarative is built. When resolved only transitively
during the parallel make-live graph, a consumer (qtwayland, kf6-kwindowsystem)
could be cooked before qtdeclarative published Qt6Qml -> "Could not find a
package configuration file provided by Qt6Qml" -> whole build aborts (exit 2).
Pre-cook qtbase qtshadertools qtdeclarative qtsvg qtwayland (in order) before
sddm/kwin so every Qt6 CMake config is cached in the sysroot first. Complements
the qtwayland->qtdeclarative recipe dep; covers all kf6 consumers at once.
qtwayland CMakeLists find_package(Qt6Qml) for the QtWaylandCompositor QML
integration. Without qtdeclarative in dependencies, cookbook may cook qtwayland
concurrently with qtdeclarative and configure fails with "Could not find a
package configuration file provided by Qt6Qml". Declaring the dep serializes
the build: qtbase -> qtshadertools -> qtdeclarative -> qtwayland.
qnetworkinterface_unix.cpp getifaddrs path declares `struct ifreq ifr` to pass
to getMtu(), but Redox relibc <net/if.h> provides only interface flags and the
if_nameindex() helpers -- no struct ifreq (Redox has no SIOCGIF* ioctls). The
SIOCGIFMTU body in getMtu() is #ifdef-guarded and compiles out, so the type
only needs to be complete. Define a minimal-but-standard struct ifreq under
#if defined(__redox__) at file scope; the ioctls that would use it fail
gracefully at runtime (mtu stays 0). Durable patch, wired into qtbase recipe.
The 8-element block-character ramp in the panel footer's
size-distribution histogram was indexed with a level that could
clamp to 8 (one past the end). The math scaled count/max_bucket to
[0, 8] and clamped with .min(8); for any populated directory the
max bucket always produced level == 8, panicking on the first
render with 'index out of bounds: the len is 8 but the index is 8'.
Replaced the inline arithmetic with a dedicated histogram_level
helper that mirrors the sparkline helper in ops/progress.rs:
scale count/max_bucket to [0, 7] and clamp to 7. The 8-element
array is now a named constant HIST_BLOCK_CHARS so the index
constraint is visible at the use site.
Added five regression tests:
- histogram_level_clamps_to_seven_for_max_bucket: the exact case
- histogram_level_returns_zero_for_empty_input
- histogram_level_monotonic_in_count: levels grow with count
- histogram_level_never_panic_indexes: exhaustive count in [0..max]
for max in [1..256]
- render_panel_does_not_panic_on_populated_directory: end-to-end
size_histogram + histogram_level + array index
Also: render() used to silently skip when the terminal reported
< 10x5, leaving the user with a blank screen and no feedback. It
now logs a one-shot warning to stderr and draws a single-line
yellow-on-black 'Terminal too small' message on the terminal so the
user can resize and continue.
Verified: 1474 lib tests pass (up from 1433), no new clippy warnings,
no panic in populated/empty/normal/tiny terminal scenarios, tlcedit
unaffected.
forkfd_qt.c includes <forkfd.h> (whose forkfd_wait4 prototype takes struct
rusage*) before struct rusage is declared at file scope; sys/resource.h is only
pulled in later by forkfd.c. So the header prototype gets a prototype-scoped
struct rusage incompatible with the file-scope one in the definition ->
"conflicting types for forkfd_wait4". 6.11.0 qglobal.h pulled it in
transitively; 6.11.1 does not. Fix: include <sys/resource.h> before <forkfd.h>.
Durable patch, wired into qtbase recipe.
Add a "Canonical build — do NOT bypass" subsection to AGENTS.md and
local/AGENTS.md, and inline warnings above every instructional repo cook /
repo fetch / make live / make r.<recipe> mention across the build/patch/plan
docs. Rationale (learned the hard way this session): direct repo cook/fetch
skips apply-patches.sh patch-linking + staleness handling, causing broken
patches (qtsvg CVE) and wasted rebuilds. Always build via
local/scripts/build-redbear.sh.
The recipe referenced "qtsvg/CVE-2026-6210.patch" (relative to the recipe dir →
recipes/.../qtsvg/qtsvg/CVE... which does not exist); the patch lived in
local/patches/qtsvg/. apply-patches.sh does not link it, so both direct fetch
and the canonical build failed to find it. Move the patch into the qtsvg recipe
dir (durable /local, same model as qtbase redox.patch) and reference it by bare
name so the build system resolves it.
Move the Redox in6_pktinfo patch into local/recipes/qt/qtbase/ (where qtbase
redox.patch lives) and add it to the [source] patches list, so a clean fetch of
qtbase 6.11.1 re-applies it. Verified: fetch of 6.11.1 applies all 3 patches
atomically. Durable in local/, resolved by the build system (no bypass).
Records the fix that unblocked qtbase on Redox: relibc lacks struct in6_pktinfo,
which Qt sizes cmsg buffers with in both datagram paths. Define it at file scope
(outside the QT_NO_SCTP guard that Redox compiles out). The current qtbase.pkgar
was built from the equivalent in-tree source edit; this patch is the durable
form. NOT yet added to recipe.toml patches[] — wiring it invalidates the qtbase
cache and forces a full re-cook, so it is wired as the final step once the ISO
assembles (during the desktop-stack fix phase qtbase stays cached).
On Redox relibc defines CLOCK_MONOTONIC=4 (not Linux 1) and has no
CLOCK_MONOTONIC_RAW, so -DCLOCK_MONOTONIC_RAW=4 collided with CLOCK_MONOTONIC in
wsi_common_wayland.c (duplicate case). The greeter uses GL/llvmpipe not Vulkan,
and Vulkan WSI is the only consumer of these Linux clock constants, so disable
vulkan-drivers to drop that unit. Also make the define collision-proof
(CLOCK_MONOTONIC+1000) for any non-Vulkan user.
Aliasing CLOCK_MONOTONIC_RAW to CLOCK_MONOTONIC created a duplicate case value
in wsi_common_wayland.c (switch has both). Use the real Linux clockid 4 so the
value is distinct and the switch compiles.
Vulkan WSI (wsi_common_wayland.c) uses CLOCK_MONOTONIC_RAW, which relibc does
not define (undeclared). Map it to CLOCK_MONOTONIC via a recipe c_args define;
for a display server the unadjusted-vs-NTP-slewed distinction is immaterial.
Third Redox mesa port gap.
meson 26.1.4 resolves wayland-scanner from the target wayland-scanner.pc, whose
absolute path is COOKBOOK_SYSROOT/usr/bin/wayland-scanner — the Redox cross
binary, which cannot execute on the Linux build host (ninja: code=127 "cannot
execute: required file not found") when generating fifo-v1-protocol.c etc. The
$WAYLAND_SCANNER env / PATH symlink do not help (meson uses the .pc absolute
path). Protocol codegen is host/target-independent, so overwrite the sysroot
copy with the runnable host wayland-scanner before meson runs. Next Redox mesa
port gap after alloca.
mesa uses alloca() in shader_query.cpp (and elsewhere) without including
<alloca.h>; on Redox stdlib.h does not pull it in, so the C++ compile failed
with "alloca was not declared in this scope". Redox relibc DOES provide alloca
(alloca.h = #define alloca(s) __builtin_alloca(s)); force-include it via meson
c_args/cpp_args so every alloca user resolves to the builtin. Next Redox mesa
port gap after the EGL gate; mesa now compiles past it.
Assessing/fixing the boot->SDDM chain for the full ISO:
1. VirGL driver table: the INSTALLED /lib/drivers.d/30-graphics.toml is inline
data in config/redbear-full.toml (not local/config/drivers.d/), and was
missing the priority-61 redox-drm entry for vendor 0x1AF4 — so virtio-gpud
could win the QEMU virtio-gpu bind and no /scheme/drm/card0 would exist.
Add the VirGL entry to the inline table (the one actually shipped).
2. Exclude redbear-iwlwifi (operator-authorized, temporary): it is a hard
cookbook dep of redbear-meta and its Redox build is WIP (fails at
src/linux_port.c), which aborts make live before the image assembles. Comment
it out of redbear-meta dependencies; nothing else pulls it. Re-add when green.
3. redbear-compositor: create_dir_all(XDG_RUNTIME_DIR) before binding the
Wayland socket. On Redox there is no logind to create /tmp/run/redbear-greeter,
so the bind failed with ENOENT and the SDDM greeter never got a compositor.
Toward: launch redbear-full ISO in QEMU and reach the SDDM Wayland login.
Iterating on one recipe (e.g. redbear-iwlwifi) forced a ~30-min re-churn every
rerun: the relibc-consumer invalidation (build/sysroot wipe + pkgar/target
deletion) re-cooked dozens of cached packages before reaching the edited one,
even when relibc was unchanged. Add REDBEAR_SKIP_ABI_STALENESS=1 to skip both
the layer-B build/sysroot clean and the layer-C invalidation loops. The
cookbook BLAKE3 dep-hash cache still re-cooks recipes whose sources changed, so
the edited package rebuilds while everything else stays cached — the rerun goes
straight to it. Safe only when relibc ABI is unchanged (documented + escape is
opt-in); unset to restore the stale-binary safety net when bumping relibc/base.
Documented in --help alongside REDBEAR_FORCE_TOOLCHAIN_RECOOK.
Mirrors Linux 7.1's pci_ers_result (include/linux/pci.h:920-938):
None/CanRecover/NeedReset/Disconnect/Recovered/NoAerDriver. This is
the vocabulary Driver::error_detected will return when the AER
recovery flow is wired to bound drivers. Currently the legacy
RecoveryAction enum (Handled/ResetDevice/RescanBus/Fatal) coexists
for the existing on_error callback — PciErsResult is the richer model
that will replace it once the driver-manager → driver IPC channel
exists for AER dispatch.
ConcurrentDeviceManager::from_manager called bus.enumerate_devices()
a second time inside its constructor — the same buses DeviceManager::
enumerate() had just enumerated to build the remaining list. Renamed
to from_devices(mgr, devices) which takes the already-enumerated
Vec<DeviceInfo> directly, eliminating the redundant I/O and removing
a potential consistency window between the two passes.
- redox-driver-sys: drop unused 'use std::sync::Once' in pci.rs and
underscore-prefix unused 'vendor' in lookup_hid_quirks. Zero
crate-local warnings (libredox's 2 are upstream fork code).
- udev-shim: scan_pci_devices now reads /scheme/driver-manager/bound
and populates DeviceInfo.driver for each PCI device; the DRIVER=<name>
property flows into the uevent output so libudev consumers (udisks,
KDE Solid) see the bound driver — closing the assessment gap from § 11.
d945483915 added a per-thread IOPL guard using std::sync::Once in a
#[cfg(target_os = "redox")] thread_local! (pci.rs:20) but did not import Once,
so redox-driver-sys fails to compile for x86_64-unknown-redox with E0425
"cannot find type Once" — breaking redox-drm (the /scheme/drm/card0 provider)
and driver-manager in the redbear-full build. Add the cfg-gated import.
Found while driving the redbear-full desktop build.
Operator confirmed "SDDM is the only greeter". Disable the two competing
display entry points that would contend with SDDM for the single-owner
GPU/card0: 20_greeter (redbear-greeterd, an alternative greeter) and 20_display
(redbear-session-launch, a boot-time auto-KDE-session that bypasses the
greeter). Gated reversibly via condition_path_exists on a sentinel
(/etc/redbear/enable-legacy-greeter) the image does not install — definitions
preserved, re-enable with a single touch. 21_sddm remains ungated. Post-login
session launch is SDDMs job via SessionDir=/usr/share/wayland-sessions.
redbear-info's integration check list still labeled the PCI spawner as
'pcid-spawner' and pointed at /usr/bin/pcid-spawner (deleted). Updated
to 'driver-manager' with /usr/bin/driver-manager and a note about
/scheme/driver-manager/bound. Plan v3.2 marks P2-1 done (pcid AER +
pciehp producers validated in QEMU).
SDDM greeter renders on redbear-compositor (per /etc/sddm.conf CompositorCommand);
KWin is the post-login session compositor. Runtime chain (driver-manager →
redox-drm → card0 → sddm → redbear-compositor → greeter) is coherent, BUT three
display entry points (20_display redbear-session-launch, 20_greeter
redbear-greeterd, 21_sddm) all fire oneshot_async and would contend for the
single-owner GPU/card0. For a clean SDDM path the first two must be disabled
(operator sign-off required).
Phase status for making redbear-full compile + run to the SDDM Wayland greeter:
build-system llvm fix, Mesa EGL gate persisted, VirGL priority (all done);
Rust components (redox-drm, redbear-compositor) compile-verified; remaining =
full C/C++ cook campaign (mesa/qt6/kf6/kwin/sddm) + Qt6 null+8 runtime validation
+ boot. Records upstream cherry-pick candidates and component homes.
driver-manager had a priority tie for QEMU virtio-gpu (vendor 0x1AF4, class
0x03): redox-drm (generic class @60) vs virtio-gpud (@60). If virtio-gpud won,
it registered display.virtio-gpu (VT scanout only) and never provided
/scheme/drm/card0, starving KWin/the compositor. redox-drm had priority-61
entries for Intel and AMD but none for VirtIO. Add a priority-61 redox-drm entry
for vendor 0x1AF4 class 0x03 (subclass omitted — QEMU virtio-gpu is subclass
0x80) so the VirGL path deterministically binds redox-drm and gets a real DRM
card0. virtio-gpud remains as fallback.
The meson gate that enables EGL on Redox — adding "redox" to
system_has_kms_drm (meson.build:159, so with_dri→with_egl/gbm) and to the
_GNU_SOURCE platform list (:1208) — existed only as an in-place edit in the
untracked extracted source/ tree. Any clean re-extract lost it and reverted to
"Feature egl cannot be enabled". Capture it as local/patches/mesa/08-*.patch and
wire it into recipe.toml so EGL/GBM/llvmpipe build reproducibly. Source tree
reverted to pristine so the patch is the sole, tracked change.
vasilito