What happens
Both lintian steps iterate for deb in *.deb in the checkout root:
.github/workflows/pr-checks.yml (the lintian job).github/workflows/build-release.yml (the "Run lintian checks" step, run-lintian defaults to true)
Container-app repos build with ./tools/build-all.sh, which writes every package to ${REPO_ROOT}/build/ and explicitly removes the root-level copies. The glob matches nothing, the loop body never runs, failed stays 0, and the step prints ✅ Lintian checks passed.
Observed in a real run (halos-marine-containers PR #194, job 91713295409) — note there is no === Checking: line between the two:
Running lintian on built packages...
✅ Lintian checks passed
The same job's earlier output confirms packages were built:
=== Verifying package payloads ===
Package payloads verified (4 file(s) across all apps)
Who is affected
Split cleanly by build method:
| Build entry point |
Where .debs land |
Lintian |
.github/scripts/build-deb-package.sh (most repos) |
./ — the script does mv ../*.deb ./ |
works |
./tools/build-all.sh (halos-core-containers, halos-marine-containers) |
build/ |
inspects nothing |
Neither container repo overrides run-lintian, so the release-time backstop has been vacuous for both since they adopted build-all.sh. Both also pass skip-lintian: true on PRs, so nothing else covers them. These are the repos whose packaging is generated by container-packaging-tools rather than hand-written — the ones where an unreviewed packaging regression is most likely.
Suggested fix
Two parts, the second mattering more than the first:
- Look in both locations, e.g.
find . -maxdepth 2 -name '*.deb', so build/ is covered.
- Fail when zero packages were inspected. A check that reports success after checking nothing is the same failure class it exists to prevent —
tools/verify-payloads.sh in halos-marine-containers had to learn exactly this lesson after shipping a guard that passed with 0 file(s) verified. A checked -eq 0 guard would have surfaced this on the first run instead of silently for months.
Found while enabling the build job on PRs in halos-org/halos-marine-containers#194.
What happens
Both lintian steps iterate
for deb in *.debin the checkout root:.github/workflows/pr-checks.yml(thelintianjob).github/workflows/build-release.yml(the "Run lintian checks" step,run-lintiandefaults totrue)Container-app repos build with
./tools/build-all.sh, which writes every package to${REPO_ROOT}/build/and explicitly removes the root-level copies. The glob matches nothing, the loop body never runs,failedstays 0, and the step prints✅ Lintian checks passed.Observed in a real run (halos-marine-containers PR #194, job 91713295409) — note there is no
=== Checking:line between the two:The same job's earlier output confirms packages were built:
Who is affected
Split cleanly by build method:
.debs land.github/scripts/build-deb-package.sh(most repos)./— the script doesmv ../*.deb ././tools/build-all.sh(halos-core-containers,halos-marine-containers)build/Neither container repo overrides
run-lintian, so the release-time backstop has been vacuous for both since they adoptedbuild-all.sh. Both also passskip-lintian: trueon PRs, so nothing else covers them. These are the repos whose packaging is generated by container-packaging-tools rather than hand-written — the ones where an unreviewed packaging regression is most likely.Suggested fix
Two parts, the second mattering more than the first:
find . -maxdepth 2 -name '*.deb', sobuild/is covered.tools/verify-payloads.shin halos-marine-containers had to learn exactly this lesson after shipping a guard that passed with0 file(s)verified. Achecked -eq 0guard would have surfaced this on the first run instead of silently for months.Found while enabling the build job on PRs in halos-org/halos-marine-containers#194.