A layer manifest records the fab version but not the commit #12

New issue

Open

opened 2026-09-28 05:11:02 -03:00 by marcos-mendez · 0 comments

marcos-mendez commented

2026-09-28 05:11:02 -03:00

(Migrated from github.com)

bt-layer:214 records the builder in every layer manifest as a version
string and nothing else:

fab_version "$(fab --version)"

core.manifest on the mirror carries fab_version 1.1.1+keel1. That string
is provenance only if it resolves to a commit, and on 2026-09-27 it did not:
the package the build host runs was built at 17:14 from a commit that reached
the default branch at 19:58, and neither packaged version was tagged at all.
Keel-Linux/fab#9 fixes the tagging side, with bin/check-release-tags
enforcing that every released version names a commit, and the two historic
tags fab/1.1.1+keel1 and fab/1.1.1+keel2 now exist.

That makes version to commit a total function as long as no package is ever
built from an untagged or dirty tree. Recording the commit directly closes
the case the tag cannot.

What has to be true

The manifest carries a fab_commit field beside fab_version.
Nothing in keel has to change. keel/docs/layers.md, "Optional
fields": a key that is not in the required table is kept as it was read and
written back unchanged, so bt-layer can record something new without that
code changing and without older manifests becoming unreadable. Absent means
none, as for units and build_units.
So the change is at bt-layer:214 and in this repository only.

Two other things in this repository that name the package `fab`

Both are consequences of Keel-Linux/fab#8, where the Debian package becomes
keel-fab while every command name stays exactly as it is.

bin/generate-buildenv:135 and :156 run fab --version the same way.
Unaffected by the rename once fab#9 lands, since that stops fab --version
asking apt about a hard-coded package name, but worth reading together with
the above.
bt-img:48 and :113-118 compare get_version fab against REQ_FAB_V=0.8
and fall back to downloading fab_${REQ_FAB_V}_stretch_amd64.deb from
upstream's releases. The path is dead on trixie, guarded by
HOST_VER -eq 10, but it assumes a .deb filename and a package name that
will both be wrong. bt-ec2:114-117 has a related existing bug: its
get_version awk pattern is the hard-coded literal
/[[:space:]]fab[[:space:]]/ regardless of the package it was given.

Order

After Keel-Linux/fab#9, so that fab --version is truthful before anything
else reads it. Not urgent: the tag invariant and its CI job cover the layers
built from here on, and the two already-built layers are covered by the
historic tags.

`bt-layer:214` records the builder in every layer manifest as a version string and nothing else: fab_version "$(fab --version)" `core.manifest` on the mirror carries `fab_version 1.1.1+keel1`. That string is provenance only if it resolves to a commit, and on 2026-09-27 it did not: the package the build host runs was built at 17:14 from a commit that reached the default branch at 19:58, and neither packaged version was tagged at all. Keel-Linux/fab#9 fixes the tagging side, with `bin/check-release-tags` enforcing that every released version names a commit, and the two historic tags `fab/1.1.1+keel1` and `fab/1.1.1+keel2` now exist. That makes version to commit a total function **as long as no package is ever built from an untagged or dirty tree**. Recording the commit directly closes the case the tag cannot. ## What has to be true - The manifest carries a `fab_commit` field beside `fab_version`. - **Nothing in `keel` has to change.** `keel/docs/layers.md`, "Optional fields": a key that is not in the required table is kept as it was read and written back unchanged, so `bt-layer` can record something new without that code changing and without older manifests becoming unreadable. Absent means `none`, as for `units` and `build_units`. - So the change is at `bt-layer:214` and in this repository only. ## Two other things in this repository that name the package `fab` Both are consequences of Keel-Linux/fab#8, where the Debian package becomes `keel-fab` while every command name stays exactly as it is. - `bin/generate-buildenv:135` and `:156` run `fab --version` the same way. Unaffected by the rename once fab#9 lands, since that stops `fab --version` asking apt about a hard-coded package name, but worth reading together with the above. - `bt-img:48` and `:113-118` compare `get_version fab` against `REQ_FAB_V=0.8` and fall back to downloading `fab_${REQ_FAB_V}_stretch_amd64.deb` from upstream's releases. The path is dead on trixie, guarded by `HOST_VER -eq 10`, but it assumes a `.deb` filename and a package name that will both be wrong. `bt-ec2:114-117` has a related existing bug: its `get_version` awk pattern is the hard-coded literal `/[[:space:]]fab[[:space:]]/` regardless of the package it was given. ## Order After Keel-Linux/fab#9, so that `fab --version` is truthful before anything else reads it. Not urgent: the tag invariant and its CI job cover the layers built from here on, and the two already-built layers are covered by the historic tags.