A build-order reading taken from the wrong tkldev #12

New issue

Closed

opened 2026-09-28 02:35:33 -03:00 by marcos-mendez · 0 comments

marcos-mendez commented

2026-09-28 02:35:33 -03:00

(Migrated from github.com)

Two machines in this project answer to the hostname tkldev: the LXC
container on a workstation, and the build host. They run different fab,
and share/product.mk differs between them, so reading the build order
out of the wrong one gives an answer that is internally coherent, cites a
real file, and does not describe what the build does.

It happened on 2026-09-28 in Keel-Linux/keel-core#9. The build order
written into conf.d/main, COVERAGE.md and the commit message was read
from the container's /usr/share/fab/product.mk and put the common
removelists before the units. On the build host they come after, and
there are three unit phases rather than one. Nothing in the change
depended on the wrong position, and the two facts it rested on were
correct, so it survived one review; the second review caught it. The
correction then named fab 1.1.1+keel1, the one release that does not
have the order it was describing, and that had to be corrected as well.

Measured:

Machine	fab	`product.mk` md5	unit phases
local `tkldev` container	`1.1.1` (stock)	`0657df1a`	one, after the common removelists
fab `1.1.1+keel1` (b07a733)	`1.1.1+keel1`	`c04cb601`	none
build host	`1.1.1+keel2`	`a06bfe03`	three, before the common removelists

docs/traps.md exists for exactly this: a fault with a recognisable
signature that cost hours and would cost hours again. Closes when the
trap is written down with its signature, its cause, its fix and the date.

Two machines in this project answer to the hostname `tkldev`: the LXC container on a workstation, and the build host. They run different fab, and `share/product.mk` differs between them, so reading the build order out of the wrong one gives an answer that is internally coherent, cites a real file, and does not describe what the build does. It happened on 2026-09-28 in Keel-Linux/keel-core#9. The build order written into `conf.d/main`, `COVERAGE.md` and the commit message was read from the container's `/usr/share/fab/product.mk` and put the common removelists before the units. On the build host they come after, and there are three unit phases rather than one. Nothing in the change depended on the wrong position, and the two facts it rested on were correct, so it survived one review; the second review caught it. The correction then named `fab 1.1.1+keel1`, the one release that does not have the order it was describing, and that had to be corrected as well. Measured: | Machine | fab | `product.mk` md5 | unit phases | | --- | --- | --- | --- | | local `tkldev` container | `1.1.1` (stock) | `0657df1a` | one, after the common removelists | | fab `1.1.1+keel1` (b07a733) | `1.1.1+keel1` | `c04cb601` | none | | build host | `1.1.1+keel2` | `a06bfe03` | three, before the common removelists | `docs/traps.md` exists for exactly this: a fault with a recognisable signature that cost hours and would cost hours again. Closes when the trap is written down with its signature, its cause, its fix and the date.