The Makefile said the release path did not need the feed; python's seven build deps disagreed

`make packages` carried the comment "NOTHING ON THE RELEASE PATH DEPENDS ON
THIS", and it was false when it was written. pkgs/3rdparty/python declares
PKG_BUILD_DEPENDS="openssl sqlite zlib libffi xz bzip2 expat"; pkg_deps
resolves those by unpacking their .ipk out of work/packages and dies when they
are absent; bin/patch.sh section 5c runs that recipe and builds none of the
seven itself. A cold checkout has never been able to run `make build`.

What it did instead was fail two hundred lines in, inside a recipe, with a
message naming a .ipk path -- so the answer ("run make packages") had to be
worked out rather than read. patch.sh now checks the feed before it touches
anything and names the command.

Counting .ipk rather than testing for the directory, because an existing but
empty work/packages is the state a cleaned tree is in, and that is the one
that produced the confusing error.

No payload change: the tree is diff -r identical either side of this commit.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Makefile

@@ -201,12 +201,17 @@ build: image config.env
 # recipe under pkgs/ into work/packages/ as .ipk files plus the feed index that
 # makes that directory an opkg repository.
 #
-# NOTHING ON THE RELEASE PATH DEPENDS ON THIS. `make build` is unchanged and
-# still ships one anvil.tar.xz; this target exists so the packages can be built
-# and gated beside it while the migration is decided. It also, unlike `build`,
-# needs NO stock FlashForge package -- which is most of the point: packaging
-# has to be runnable in CI on a bare checkout, or the gate only runs where the
-# proprietary firmware is and stops being a gate.
+# THE RELEASE PATH IS BUILT ON THIS. It used to say the opposite -- "nothing
+# on the release path depends on this" -- and that was already false when it
+# was written: pkgs/3rdparty/python declares seven build dependencies, pkg_deps
+# resolves them by unpacking their .ipk out of work/packages, and bin/patch.sh
+# builds none of the seven. `make build` on a cold checkout has never worked
+# without this target; it failed deep inside a recipe instead of saying so.
+# bin/patch.sh now checks for the feed up front and names this command.
+#
+# It still, unlike `build`, needs NO stock FlashForge package -- which is most
+# of the point: packaging has to be runnable in CI on a bare checkout, or the
+# gate only runs where the proprietary firmware is and stops being a gate.
 packages: image config.env
 	@$(RUN) ./bin/build-packages.sh $(PKG)
 

bin/patch.sh

@@ -15,6 +15,25 @@ set -euo pipefail
 SOFTWARE_DIR=work/software
 [ -d "$SOFTWARE_DIR" ] || { echo "run bin/unpack.sh first" >&2; exit 1; }
 
+# THE FEED IS A PREREQUISITE OF THIS SCRIPT, AND HAS BEEN FOR LONGER THAN IT
+# HAS BEEN SAID OUT LOUD. Section 5c runs pkgs/3rdparty/python/build.sh, whose
+# PKG_BUILD_DEPENDS is "openssl sqlite zlib libffi xz bzip2 expat" -- and this
+# file builds none of those seven. pkg_deps fills that recipe's sysroot by
+# unpacking their .ipk files out of $PKG_FEED and dies if they are not there.
+# So a cold checkout has never been able to run bin/patch.sh; it just failed
+# two hundred lines further down, inside a recipe, naming a file rather than
+# the command that makes it.
+#
+# Checked here so the failure names the fix, and checked by counting .ipk
+# rather than by testing for the directory: a $PKG_FEED that exists and is
+# empty is the state a cleaned tree is in, and it is the one that used to
+# produce the confusing error.
+if [ -z "$(ls "$PKG_FEED"/*.ipk 2>/dev/null)" ]; then
+    echo "no package feed at $PKG_FEED" >&2
+    echo "  the recipes this script runs build against it -- run 'make packages' first." >&2
+    exit 1
+fi
+
 say() { printf '>> %s\n' "$*"; }
 skip() { printf '   (skip) %s\n' "$*"; }
 

docs/building.md

@@ -254,9 +254,10 @@ reads a flag must not itself sit behind a second, different flag.
 **Builds it** — host-side, never installed:
 
 ```
-bin/            fetch-assets -> unpack -> patch -> pack, plus verify
-                build-packages.sh is the packaging lane below -- not part of
-                the four-step build
+bin/            fetch-assets -> unpack -> patch -> pack, plus verify.
+                build-packages.sh is the packaging lane below, and the four
+                steps need it to have run: patch.sh checks for the feed and
+                refuses without one
 versions.env    pinned Mainsail / HelixScreen / Moonraker versions + sha256
 vendor/         where fetch-assets.sh caches them (gitignored), plus the
                 opkg-utils checkout -- the one entry pinned by git commit
@@ -267,9 +268,9 @@ pkgs/           package recipes: one directory per component, each a
                 build.sh producing a $MODDIR-relative tree and a pkg.conf
                 naming it, plus whatever files of ours that component ships.
                 `make packages` builds them into .ipk files in work/packages/
-                with a feed index, using upstream's opkg-build. A PROOF OF
-                CONCEPT -- nothing on the release path reads it yet, and the
-                tarball `make build` produces is unchanged.
+                with a feed index, using upstream's opkg-build. The release
+                path depends on this: recipes resolve their build
+                dependencies out of the feed, so `make packages` comes first.
                 See docs/notes/85-packaging.md.
   3rdparty/       the recipes that build a pinned tarball and carry no files
                   of this repo -- thirty-four of the thirty-eight. They are