# Phase 1.2 follow-up: local Guile-Git stack built on FreeBSD and checkout investigation advanced again

Date: 2026-04-01

## Summary

This step addressed the next checkout blocker found after local Guile-GnuTLS support was added on FreeBSD.

Added/updated files:

- `tests/guix/build-local-guile-git.sh`
- updated `tests/guix/run-derivation-generation-investigation.sh`

The new result is:

1. `guile-bytestructures` and `guile-git` can be built successfully on FreeBSD against the previously validated fixed local Guile build
2. these modules can be installed into the same local prefix already used for the Guile-GnuTLS validation copy
3. after making both `(gnutls)` and `(git)` available, the Guix checkout configure step advances again
4. the next checkout blocker is now `Guile-JSON`

## Inputs used

### Local Guile

The same fixed local Guile build was used:

- `/tmp/guile-freebsd-validate-install/bin/guile`

### Existing local dependency prefix

To keep checkout prerequisites together, this step installed into the existing prefix already populated by the earlier Guile-GnuTLS validation step:

- `/tmp/guile-gnutls-freebsd-validate-install`

That prefix now contains at least:

- Guile-GnuTLS
- Guile bytestructures
- Guile-Git

### Guix source-of-truth package definitions

This step used the current Guix package definitions in `~/repos/guix/gnu/packages/guile.scm`:

- `guile-bytestructures`
  - version `1.0.10`
- `guile-git`
  - version `0.10.0`

Because both Guix packages use `git-fetch`, the local harness cloned the matching upstream tags and recorded the resolved commits:

- `guile-bytestructures` tag `1.0.10`
  - commit `27cadba6b69a01b38b33bb39b9766d713eb90c1b`
- `guile-git` tag `v0.10.0`
  - commit `05d4a48c811f29c8db80ee6697fe658950fb503e`

### Host-side library dependency

The host already had the needed `libgit2` package installed.  The build used:

- `libgit2` version `1.9.2`

observed via:

```text
pkg-config --modversion libgit2
```

## Build findings

### 1. Git checkouts need autotools regeneration

Both packages were built from the Git source layout reflected by the Guix package definitions, so generated configure scripts were not assumed to exist.

Observed working bootstrap paths:

- `guile-bytestructures`: `autoreconf -vfi`
- `guile-git`: `autoreconf -vfi` via the harness fallback path

This matches the fact that the Guix package definitions already list autotools components among native inputs.

### 2. No new FreeBSD-specific source patch was needed here

Unlike the earlier Guile-GnuTLS build, neither `guile-bytestructures` nor `guile-git` required a FreeBSD-specific source patch during this validation step.

### 3. The Guile-Git version/export check now passes locally

Guix `configure.ac` checks not only that `(git)` can be loaded, but also that the module exports a sufficiently recent symbol:

- `graph-descendant?`

The local validation explicitly checked that this export is present and callable enough to satisfy the configure-time requirement.

## Validation command

```sh
ENV_OUT=/tmp/guile-git-env.sh \
METADATA_OUT=/tmp/guile-git-metadata.txt \
./tests/guix/build-local-guile-git.sh
```

Default install prefix used by the harness:

```text
/tmp/guile-gnutls-freebsd-validate-install
```

## Result

The local Guile dependency stack build succeeded.

Validated module loads:

```scheme
(use-modules (bytestructures guile))
(use-modules (git))
```

Observed checks:

```text
bytestructures module check: ok
guile-git module check: ok
Existing (gnutls) module in prefix: present
```

This means the same local prefix now satisfies at least the first two mandatory Guix checkout module requirements previously encountered on FreeBSD:

- `(gnutls)`
- `(git)` with `graph-descendant?`

## Re-running the checkout investigation

After installing the Guile-Git stack, the derivation-generation investigation was re-run with:

```sh
GUILE_EXTRA_PREFIX=/tmp/guile-gnutls-freebsd-validate-install \
METADATA_OUT=/tmp/guix-derivation-investigation-with-git.txt \
./tests/guix/run-derivation-generation-investigation.sh
```

The investigation still used the requested experimental directories:

- store: `/frx/store`
- local state: `/frx/var`
- sysconf: `/frx/etc`

## Updated result

With both `(gnutls)` and `(git)` available, the Guix checkout configure step progresses farther and now fails at the next missing Guile dependency:

```text
configure: error: Guile-JSON is missing; please install it.
```

Relevant configure summary lines observed:

```text
checking whether Guile-JSON is available and recent enough... no
configure: error: Guile-JSON is missing; please install it.
```

## What this step demonstrates

This step demonstrates that:

1. the earlier `Guile-Git` blocker is genuinely cleared on FreeBSD when using the fixed local Guile build plus local dependency prefix
2. the checkout can now move one dependency layer deeper than before
3. the project is still in the checkout-prerequisite stage rather than the derivation/store/daemon stage
4. the next concrete prerequisite for reaching deeper Guix checkout usability on FreeBSD is `Guile-JSON`

## Current blocker stack

The current checkout path is now blocked by:

1. unsupported-platform configure gating unless `--with-courage` is used
2. missing `Guile-JSON` after supplying:
   - Guile-GnuTLS
   - Guile-Git

The earlier missing blockers have now been cleared locally for validation:

- `(gnutls)`
- `(git)` / recent Guile-Git export requirement

## Recommended next step

Obtain or build `Guile-JSON` compatible with the same fixed local Guile build, install it into the same local dependency prefix, and re-run the derivation-generation investigation again.

That will show whether the next boundary lies at:

- `Guile-SQLite3`
- `Guile-Gcrypt`
- `Guile-zlib`
- `Guile-lzlib`
- `Guile-semver`
- or finally something beyond configure-time Guile module prerequisites