The running fab version does not exist in this repository #7

New issue

Open

opened 2026-09-28 03:06:20 -03:00 by marcos-mendez · 0 comments

marcos-mendez commented

2026-09-28 03:06:20 -03:00

(Migrated from github.com)

The fab that builds every Keel layer runs at a version that does not exist in
this repository.

Measured on the build host, 2026-09-28:

dpkg-query -W fab                 ->  fab 1.1.1+keel2
head -1 debian/changelog          ->  fab (1.1.1+keel1) trixie; urgency=low
git log --oneline -- debian/changelog
                                  ->  b07a733   (the only commit, ever)

md5sum /usr/share/fab/product.mk        a06bfe0383c12aed149029c10eacd1f4
md5sum share/product.mk (checkout HEAD) a06bfe0383c12aed149029c10eacd1f4
dpkg -S /usr/share/fab/product.mk  ->  fab: /usr/share/fab/product.mk

So the installed package claims 1.1.1+keel2, its files match this
repository's HEAD, and 1.1.1+keel2 appears nowhere in the history. The
changelog was last touched by b07a733, which set 1.1.1+keel1.

Five commits landed after it, including two merged pull requests that changed
the order of the build's phases:

2fc6120  Merge pull request #4 from Keel-Linux/feat/unit-order
be8ef5b  Apply the units before the common removelists, and let a build select them
16730a5  Merge pull request #5 from Keel-Linux/feat/unit-slots
29a9462  Let a unit carry a removelist and name the variables its conf script reads

Neither pull request added a changelog entry, and the version was bumped when
the package was built rather than in git.

Why this matters more than a missing changelog usually does

The layer manifest records the builder: core.manifest on the mirror carries
fab_version 1.1.1+keel1. That field is doing real provenance work, and the
next layer built will record fab_version 1.1.1+keel2 — a version no clone of
this repository can produce. The project's claim is that every image is
rebuildable from our own archive without asking anybody; an image whose builder
cannot be reconstructed does not meet it, however reproducible everything
downstream is.

It also means the two pull requests that reordered the build phases are
invisible to anyone reading the changelog, which is exactly how the same
reordering was documented wrongly twice this week (see the handbook's
docs/traps.md entry on reading product.mk from the wrong fab).

docs/traps.md already carries the neighbouring case, "Code merged without a
changelog entry never reaches a machine". This is the inverse and worse: it
reached the machine without one.

What closes this

A changelog entry covering everything since 1.1.1+keel1, so the running
version exists in git and 1.1.1+keel2 is reconstructible — or, if it cannot
be reconstructed faithfully, a 1.1.1+keel3 that can, with the gap recorded.
This repository calls the organization's require-changelog workflow. It
currently has only tests.yml, which is why two pull requests that change
the build's behaviour merged without an entry. The gate exists in
Keel-Linux/.github; it is not wired up here.
Whatever is decided, the answer to "which fab built this layer" must be
checkable from a manifest and a git tag, in both directions.

The fab that builds every Keel layer runs at a version that does not exist in this repository. Measured on the build host, 2026-09-28: dpkg-query -W fab -> fab 1.1.1+keel2 head -1 debian/changelog -> fab (1.1.1+keel1) trixie; urgency=low git log --oneline -- debian/changelog -> b07a733 (the only commit, ever) md5sum /usr/share/fab/product.mk a06bfe0383c12aed149029c10eacd1f4 md5sum share/product.mk (checkout HEAD) a06bfe0383c12aed149029c10eacd1f4 dpkg -S /usr/share/fab/product.mk -> fab: /usr/share/fab/product.mk So the installed package claims `1.1.1+keel2`, its files match this repository's HEAD, and `1.1.1+keel2` appears nowhere in the history. The changelog was last touched by `b07a733`, which set `1.1.1+keel1`. Five commits landed after it, including two merged pull requests that changed the order of the build's phases: 2fc6120 Merge pull request #4 from Keel-Linux/feat/unit-order be8ef5b Apply the units before the common removelists, and let a build select them 16730a5 Merge pull request #5 from Keel-Linux/feat/unit-slots 29a9462 Let a unit carry a removelist and name the variables its conf script reads Neither pull request added a changelog entry, and the version was bumped when the package was built rather than in git. ## Why this matters more than a missing changelog usually does The layer manifest records the builder: `core.manifest` on the mirror carries `fab_version 1.1.1+keel1`. That field is doing real provenance work, and the next layer built will record `fab_version 1.1.1+keel2` — a version no clone of this repository can produce. The project's claim is that every image is rebuildable from our own archive without asking anybody; an image whose builder cannot be reconstructed does not meet it, however reproducible everything downstream is. It also means the two pull requests that reordered the build phases are invisible to anyone reading the changelog, which is exactly how the same reordering was documented wrongly twice this week (see the handbook's `docs/traps.md` entry on reading `product.mk` from the wrong fab). `docs/traps.md` already carries the neighbouring case, "Code merged without a changelog entry never reaches a machine". This is the inverse and worse: it reached the machine without one. ## What closes this - A changelog entry covering everything since `1.1.1+keel1`, so the running version exists in git and `1.1.1+keel2` is reconstructible — or, if it cannot be reconstructed faithfully, a `1.1.1+keel3` that can, with the gap recorded. - This repository calls the organization's `require-changelog` workflow. It currently has only `tests.yml`, which is why two pull requests that change the build's behaviour merged without an entry. The gate exists in `Keel-Linux/.github`; it is not wired up here. - Whatever is decided, the answer to "which fab built this layer" must be checkable from a manifest and a git tag, in both directions.