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

Merged

marcos-mendez merged 2 commits from docs/trap-wrong-tkldev into main

2026-09-29 00:19:24 -03:00

marcos-mendez commented

2026-09-28 02:36:53 -03:00

(Migrated from github.com)

Closes #12.

Two machines in this project answer to the hostname tkldev, and they run
different fab. Reading /usr/share/fab/product.mk on the nearer one answers a
question about the other, and the answer is internally coherent, cites a real
file at a real path and survives a review, because the facts the work rests on
get checked and the sentence around them does not.

It cost two review rounds on Keel-Linux/keel-core#9 on 2026-09-28. The build
order written into conf.d/main, COVERAGE.md and a commit message put the
common removelists before the units, read faithfully from the container's file.
The correction then named fab 1.1.1+keel1, the one release that does not carry
the order it was describing, and was wrong a second time in the same way.

Measured, and the entry carries the table so the check is one line rather than
an instruction to be careful:

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`	one, after the common removelists, as in stock
build host	`1.1.1+keel2`	`a06bfe03`	three, before the common removelists

dpkg-query -W fab and md5sum /usr/share/fab/product.mk on the build host
settle which file a reading came from.

One file, docs/traps.md, one entry, in the form the others use. No decision
note and no number taken.

Closes #12. Two machines in this project answer to the hostname `tkldev`, and they run different fab. Reading `/usr/share/fab/product.mk` on the nearer one answers a question about the other, and the answer is internally coherent, cites a real file at a real path and survives a review, because the facts the work rests on get checked and the sentence around them does not. It cost two review rounds on Keel-Linux/keel-core#9 on 2026-09-28. The build order written into `conf.d/main`, `COVERAGE.md` and a commit message put the common removelists before the units, read faithfully from the container's file. The correction then named `fab 1.1.1+keel1`, the one release that does not carry the order it was describing, and was wrong a second time in the same way. Measured, and the entry carries the table so the check is one line rather than an instruction to be careful: | 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` | one, after the common removelists, as in stock | | build host | `1.1.1+keel2` | `a06bfe03` | three, before the common removelists | `dpkg-query -W fab` and `md5sum /usr/share/fab/product.mk` on the build host settle which file a reading came from. One file, `docs/traps.md`, one entry, in the form the others use. No decision note and no number taken.

marcos-mendez commented

2026-09-29 00:15:50 -03:00

(Migrated from github.com)

Fixed in 92fb316: the fab 1.1.1+keel1 row said no unit phase, but b07a733's product.mk has the stock one, after the common removelists (it differs from stock only in SOURCE_DATE_EPOCH). The same wrong reading is in the review comment on keel-core#9.

Fixed in 92fb316: the fab 1.1.1+keel1 row said no unit phase, but b07a733's product.mk has the stock one, after the common removelists (it differs from stock only in SOURCE_DATE_EPOCH). The same wrong reading is in the review comment on keel-core#9.