Investigate Guix derivation generation on FreeBSD

This commit is contained in:
2026-04-01 10:10:24 +02:00
parent 245a47dfbc
commit d62e9b01ed
3 changed files with 360 additions and 0 deletions

View File

@@ -366,3 +366,68 @@ Next recommended step:
1. investigate whether a tiny package can be lowered far enough on FreeBSD to produce a real derivation, and capture the exact first failure point
2. if derivation generation proves immediately blocked, document whether the blocker is generated Guix modules/configuration, store connectivity, or daemon assumptions
3. continue keeping `~/repos/bdwgc` in reserve if later FreeBSD-specific GC/thread issues appear
## 2026-04-01 — Phase 1.2 follow-up: derivation-generation investigation identified the first real checkout blockers
Completed work:
- added a reproducible checkout/bootstrap/configure investigation harness:
- `tests/guix/run-derivation-generation-investigation.sh`
- used the previously validated fixed local Guile build for the investigation:
- `/tmp/guile-freebsd-validate-install/bin/guile`
- followed the operator instruction for future store setup by parameterizing the checkout attempts to use:
- store directory: `/frx/store`
- local state directory: `/frx/var`
- sysconf directory: `/frx/etc`
- created a disposable shared clone of `~/repos/guix`
- successfully ran `./bootstrap` from that disposable checkout on FreeBSD
- attempted `configure` without `--with-courage`
- attempted `configure` again with `--with-courage`
- confirmed directly that the local fixed Guile build currently cannot load:
- `(gnutls)`
- wrote the results to:
- `docs/reports/phase1-guix-derivation-generation-investigation.md`
Important findings:
- a stock Guix checkout currently fails configuration on FreeBSD before any derivation/store/daemon work is reached, due to the explicit unsupported-platform gate:
- ``configure: error: `x86_64-freebsd15.0' is not a supported platform.``
- re-running `configure` with `--with-courage` gets past that gate, but then stops on a second blocker:
- `configure: error: The Guile bindings of GnuTLS are missing; please install them.`
- a direct module-load test with the same local Guile confirms the problem more concretely:
- `(use-modules (gnutls))` fails with `no code for module (gnutls)`
- this means the current effort is still blocked before reaching:
- usable `pre-inst-env` generation for Guix commands
- package -> bag lowering in a live checkout
- bag -> derivation lowering
- daemon connectivity
- actual `/frx/store` population
Current assessment:
- the first practical boundary between the earlier FreeBSD builder-phase prototypes and a real Guix checkout has now been located more precisely
- the project is no longer blocked by vague uncertainty at this stage; it is blocked by two concrete checkout-preparation issues:
1. unsupported-platform configure gating
2. missing Guile `(gnutls)` bindings
- importantly, the derivation-generation investigation has not yet reached the store/daemon boundary, so the next step must first clear the `(gnutls)` dependency issue
Recent commits:
- `e380e88``Add FreeBSD Guile verification harness`
- `cd721b1``Update progress after Guile verification`
- `27916cb``Diagnose Guile subprocess crash on FreeBSD`
- `02f7a7f``Validate local Guile fix on FreeBSD`
- `4aebea4``Add native GNU Hello FreeBSD build harness`
- `c944cdb``Validate Guix builder phases on FreeBSD`
- `0a2e48e``Validate GNU which builder phases on FreeBSD`
- `245a47d``Document gaps to real Guix FreeBSD builds`
Next recommended step:
1. obtain working Guile `(gnutls)` bindings compatible with the fixed local Guile build and re-run the derivation-generation investigation
2. once configuration succeeds, continue until the next failure boundary is identified among:
- `pre-inst-env` usability
- derivation emission
- daemon connectivity
- daemon-side `/frx/store` assumptions
3. continue keeping `~/repos/bdwgc` in reserve if later FreeBSD-specific GC/thread issues appear

View File

@@ -0,0 +1,135 @@
# Phase 1.2 follow-up: derivation-generation investigation from a Guix checkout on FreeBSD
Date: 2026-04-01
## Summary
This step investigated how far FreeBSD can get toward a real Guix package/derivation build from a Guix source checkout, and captured the first concrete failure boundary.
Added harness:
- `tests/guix/run-derivation-generation-investigation.sh`
Per operator instruction, all store-related configuration in this investigation used:
- store directory: `/frx/store`
and, to keep the experimental Guix state alongside that store prefix, the configure attempts also used:
- local state directory: `/frx/var`
- sysconf directory: `/frx/etc`
## Goal
The immediate goal was not to complete a full build, but to answer a narrower question left open by the previous reports:
> What is the first actual blocker when trying to move from FreeBSD builder-phase prototypes toward a real Guix checkout capable of derivation generation?
## What was attempted
A disposable shared clone of `~/repos/guix` was created under `/tmp`, then:
1. `./bootstrap` was run successfully
2. `configure` was run without `--with-courage`
3. `configure` was run again with `--with-courage`
The harness used the previously validated fixed local Guile build:
- `/tmp/guile-freebsd-validate-install/bin/guile`
## Reproduction command
```sh
METADATA_OUT=/tmp/guix-derivation-investigation.txt \
./tests/guix/run-derivation-generation-investigation.sh
```
## Result
The investigation did not reach derivation generation yet.
Instead, it identified two earlier gating failures.
### Finding 1: unsupported-platform gate in `configure`
Without `--with-courage`, configuration fails immediately on FreeBSD with:
```text
checking for the Guix system type... x86_64-freebsd15.0
configure: error: `x86_64-freebsd15.0' is not a supported platform.
```
This confirms that a stock Guix checkout currently refuses to configure on FreeBSD before any daemon/store/derivation logic is exercised.
### Finding 2: missing Guile `(gnutls)` bindings after bypassing the platform gate
When `configure` is re-run with `--with-courage`, it gets past the unsupported-platform gate but then stops with:
```text
configure: error: The Guile bindings of GnuTLS are missing; please install them.
```
A direct check with the same local fixed Guile build confirmed that:
```scheme
(use-modules (gnutls))
```
currently fails on this host with:
```text
no code for module (gnutls)
```
## Interpretation
This is useful because it pinpoints the current failure boundary more precisely than before.
The first blockers toward a real Guix checkout capable of derivation generation on FreeBSD are currently:
1. a deliberate unsupported-platform configure gate
2. a missing mandatory Guile `(gnutls)` module dependency needed by the checkout configuration
This means the project is still blocked **before**:
- `pre-inst-env` generation usable for Guix commands
- package -> bag lowering in a live Guix checkout
- bag -> derivation lowering
- store daemon connection
- `/frx/store` population or management
## What this does and does not prove
This step proves:
- a Guix checkout can be bootstrapped successfully on FreeBSD
- Guix's configure logic explicitly rejects FreeBSD unless `--with-courage` is used
- after bypassing that gate, the next immediate blocker is missing Guile GnuTLS bindings
This step does **not** yet prove:
- whether derivation generation itself works on FreeBSD
- whether daemon connectivity works
- whether `/frx/store` can be initialized and used successfully
- whether the next blocker after GnuTLS would be store-related or daemon-related
## Notes on `/frx`
No actual `/frx/store` was created or populated in this step because the checkout did not get far enough.
However, this investigation establishes the intended experimental store path for subsequent work:
- `/frx/store`
rather than Guix's usual `/gnu/store`.
## Recommended next step
The most direct next step is to obtain working Guile `(gnutls)` bindings compatible with the fixed local Guile build, then re-run this derivation-generation investigation.
That should reveal the next actual failure boundary, which is likely to be one of:
- generated checkout/runtime module issues
- derivation emission
- daemon connectivity
- daemon-side assumptions about the store or build environment