fruix/docs/reports/phase5-daemon-rpc-freebsd.md

Phase 5.3: Minimal daemon/store RPC integration validated on FreeBSD

Date: 2026-04-01

Summary

This step validates that the FreeBSD-aware checkout can do more than emit a derivation: it can contact a real daemon/store path and submit an actual derivation-backed build request that succeeds into /frx/store.

Added file:

• tests/guix/run-phase5-daemon-rpc.sh

Validation command

Run command:

METADATA_OUT=/tmp/phase5-daemon-rpc-metadata.txt \
./tests/guix/run-phase5-daemon-rpc.sh

What the harness does

The harness:

1. reuses the patched checkout/runtime setup from Phase 5.1
2. starts the patched guix-daemon on a temporary Unix socket
3. invokes the checkout through the user-facing boundary:
   • ./pre-inst-env fruix repl -- ...
4. defines a minimal custom package with the same low-level FreeBSD build system style used in Phase 5.2
5. lowers that package to a derivation
6. submits the resulting derivation to the daemon through build-derivations
7. validates the built output content in /frx/store

Observed results

Observed metadata included:

• drv_path=/frx/store/...-phase5-freebsd-daemon-build-0.drv
• out_path=/frx/store/...-phase5-freebsd-daemon-build-0
• payload=phase5-daemon-build-source
• source_path=/frx/store/...-phase5-source.txt
• frontend_invocation=./pre-inst-env fruix repl -- ...

This demonstrates that:

• the checkout can contact a real daemon over a Unix socket on FreeBSD
• the daemon accepts a derivation-backed build request
• the build succeeds into /frx/store
• the resulting output is a real store item
• the source was itself materialized as a store path and referenced by the built output path

Important findings

• the FreeBSD daemon path is now operational enough to support a narrow but real end-to-end flow:
  • checkout command path
  • daemon RPC
  • derivation submission
  • build execution
  • store output materialization
• this validation intentionally used a minimal custom derivation-backed package rather than a full upstream GNU package graph, so the result isolates actual daemon/store viability from unrelated unresolved bootstrap-package assumptions
• the command path was exercised through the Fruix-facing frontend boundary (fruix repl), which is important because Phase 5 is not just about making the upstream-derived checkout work internally, but about beginning the transition to Fruix as the operator-facing identity

Conclusion

Phase 5.3 is satisfied on the current FreeBSD prototype track:

• a real checkout command path can contact a FreeBSD-aware daemon/store path
• that path accepts and executes a derivation-backed build request
• the build succeeds into /frx/store
• the Fruix-facing checkout frontend is now being exercised against the real daemon/store path rather than only against no-op or help-text commands