Skip to content

The trap of reading product.mk from the wrong tkldev #13

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
marcos-mendez merged 2 commits into from
Sep 29, 2026
Merged

The trap of reading product.mk from the wrong tkldev #13

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
ea680e4
docs: the trap of reading product.mk from the wrong tkldev
marcos-mendez Sep 28, 2026
92fb316
docs: traps, fab 1.1.1+keel1 has the stock unit phase, not none
marcos-mendez Sep 29, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 33 additions & 0 deletions docs/traps.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -326,6 +326,39 @@ today, which is what makes this easy to miss and easy to dismiss.
**Hit** 2026-09-27, the LAMP composition measurement: 199 and 183 differing
files, which are 198 and 182.

## Two machines answer to `tkldev`, and they run different fab

**Signature.** A claim about the build order, or about anything else in
`product.mk`, that is internally coherent, cites a real file at a real path,
survives a review, and does not describe what the build does. Nothing in the
change depends on the wrong part, which is why it survives: the facts the work
rests on are checked and correct, and the sentence around them is not.

**Cause.** The LXC container on a workstation and the build host both answer to
`tkldev`, and they run different fab. Reading `/usr/share/fab/product.mk` on
the nearer one answers a question about the other. Measured 2026-09-28:

| Machine | fab | `product.mk` md5 | Unit phases in `root.patched/body` |
| --- | --- | --- | --- |
| local `tkldev` container | `1.1.1`, stock | `0657df1a` | one, after the common removelists |
| fab `1.1.1+keel1` (b07a733) | `1.1.1+keel1` | `c04cb601` | one, after the common removelists, as in stock (the file differs from stock only in `SOURCE_DATE_EPOCH`) |
| build host | `1.1.1+keel2` | `a06bfe03` | three (overlays, conf scripts, removelists), before the common removelists |

**Fix.** Take the reading from the machine that builds, and name the fab
version beside it so the next reader can tell which file was read. A version
string alone is not enough: the first correction named `1.1.1+keel1`, the one
release that does not carry the order it was describing, and was wrong again in
the same way. Quote the md5 of the file the reading came from; `md5sum
/usr/share/fab/product.mk` on the build host settles it in one line, and
`dpkg-query -W fab` says which version that is.

**Hit** 2026-09-28 in the core login change (keel-core#9). The order written
into `conf.d/main`, `COVERAGE.md` and the commit message put the common
removelists before the units, read faithfully from the container's file. The
two facts the change rested on were true in both versions, so the first review
passed it; the second caught it, and then caught the version string in the
correction.

## Things we did wrong and would do again unless written down

- **Discarding a local commit on a guess.** A checkout on the build host had a
Expand Down