rebuild-fluidd ships ~1GB of build-time-only packages, and the numpy setup diverges from Klipper's docs

[eliasbakken]

rebuild-fluidd ships at 1.25 GB compressed. Roughly 1 GB of what is installed is build-time only and never removed, and the numpy arrangement does not do what its comment says.

Sizes are arm64 dependency closures measured against a Debian trixie base, so they overstate wherever Rebuild already needs a dependency for other reasons - they are a ranking, not a bill.

Nothing is ever cleaned up

No apt clean, no autoremove, no purge of build dependencies anywhere in userpatches/overlay/install_components/. So everything below stays in the shipped image, and ustreamer's source tree - .git plus object files - is left in /home/printer/ustreamer.

package	closure	why it is installed
gcc-arm-none-eabi + binutils + libnewlib	527 MB	building Klipper MCU firmware (klipper.sh)
build-essential	299 MB	pip wheels, and compiling ustreamer
python3-matplotlib	225 MB	see below
plymouth-themes	56 MB	mostly fonts
libncurses-dev, libevent-dev, libbsd-dev, libusb-1.0-0-dev, libffi-dev, python3-dev, libjpeg-dev	~6 MB	build-time only

The toolchain is the big one and the decision is not technical: it is needed at build time, and at runtime only if a user rebuilds MCU firmware on the board after a Klipper update. If Recore ships pre-built firmware and a flasher, that is 527 MB serving a workflow most users never touch.

Removing build deps risks Moonraker's update manager recompiling a wheel - most arm64 wheels are prebuilt now, but that wants an actual update run to confirm rather than an assumption.

The numpy setup does not do what it says

klipper.sh:

45:  PKGLIST="python3-venv python3-dev libffi-dev build-essential python3-cffi"
48:  # In Trixie, use the system numpy for speed
49:  PKGLIST="${PKGLIST} python3-matplotlib"
54:  python3 -m venv "${PYTHONDIR}"          <- no --system-site-packages
57:  pip install -r klippy-requirements.txt
58:  pip install numpy                        <- numpy goes into the venv anyway

The venv cannot see system packages, so klippy never uses python3-matplotlib and never uses the system numpy either. The comment's intent is not achieved. That 225 MB serves only scripts/graph_accelerometer.py run on the board with the system interpreter.

Three divergences from Klipper's own instructions (docs/Measuring_Resonances.md:213):

sudo apt install python3-numpy python3-matplotlib libatlas-base-dev libopenblas-dev
~/klippy-env/bin/pip install -v "numpy<1.26"
~/klippy-env/bin/python -c 'import numpy;'

• The pin. Klipper pins "numpy<1.26"; klipper.sh:58 installs it unpinned.
• The BLAS libraries. libatlas-base-dev and libopenblas-dev are not installed. These are very likely what "use the system numpy for speed" was reaching for - Debian's numpy links against optimised BLAS while a plain pip wheel may not - and as written neither path gets it.
• The test. That import numpy one-liner is Klipper's documented verification and Rebuild runs no equivalent, in klipper.sh, validate-image.sh or CI. A silently broken input shaper would not be caught.

klippy-requirements.txt does not list numpy at all, confirming it is an optional extra for resonance work rather than a core dependency.

Suggested order

1. python3-matplotlib -> python3-numpy (~173 MB, since numpy's own closure is 52 MB). Costs the ability to plot resonance graphs on the board; most people do that on a laptop.
2. Add the import numpy check, pin to match the docs, and add the BLAS libraries. Small, and they are correctness rather than size.
3. apt clean + remove the -dev packages at the end of post_build, behind an actual Moonraker update test.
4. The ARM toolchain - product decision.

Verify before acting

These are package-metadata closures, not measured image deltas, and Armbian runs its own cleanup passes I have not accounted for. One command on a live fluidd board turns them into real numbers:

dpkg-query -Wf '${Installed-Size}\t${Package}\n' | sort -rn | head -30
du -sh /home/printer/* /opt/* 2>/dev/null | sort -rh | head

[eliasbakken]

Confirmed on a live board (rebuild-fluidd-8e73c9c, kernel 6.18.33-edge-sunxi64),
which upgrades this from build-time package sizes to what is actually on a running
image.

No cleanup happens - all four are still installed at runtime:

gcc-arm-none-eabi        installed
build-essential          installed
python3-matplotlib       installed
python3-numpy            installed

Rootfs: 6.9G total, 4.8G used, 71%.

The venv isolation is confirmed, and it makes the system packages dead weight:

/home/printer/klippy-env/pyvenv.cfg:  include-system-site-packages = false

So python3-numpy (52 MB) and python3-matplotlib (225 MB) are installed system-wide
and are invisible to klippy. They are not "the system numpy used for speed" - they
are simply unreachable from the process that would use them.

What klippy actually uses is its own pip-installed copy:

/home/printer/klippy-env/bin/python -c "import numpy" -> numpy 2.5.2

That is far past the "numpy<1.26" that docs/Measuring_Resonances.md:213 pins.

But it is not broken, which I should say plainly rather than leave implied:

import extras.shaper_calibrate  ->  OK
ShaperCalibrate(printer=None)   ->  constructed OK

with numpy 2.5.2. So the import-compatibility failure the pin exists to prevent does
not occur here. This does not prove the FFT/resonance math produces correct
results - only that the module loads and constructs - but it does mean the unpinned
numpy is not an outright breakage, and this part of the issue should be treated as a
divergence from upstream's documented setup rather than a live fault.

That leaves the size argument as the substantive one: ~1 GB of build-time-only
packages plus 277 MB of system numpy/matplotlib that nothing can reach.

[eliasbakken]

Correcting my previous comment. I wrote that the system numpy and matplotlib are
"277 MB that nothing can reach". That is wrong, and acting on it would break a feature.

What I checked was the klippy venv, and that part holds - include-system-site-packages = false, and klippy itself never imports matplotlib (zero matches under klippy/). What
I missed is that klipper/scripts/ is not run inside the venv:

$ head -1 klipper/scripts/calibrate_shaper.py
#!/usr/bin/env python3                      <- system python, not klippy-env

$ python3 -c "import matplotlib; print(matplotlib.__version__)"
3.10.1+dfsg1                                <- system python DOES see it

Ten scripts import matplotlib, including the two you use after a resonance run:
calibrate_shaper.py, graph_accelerometer.py, graph_shaper.py, graph_mesh.py,
graph_motion.py, graph_extruder.py, graph_temp_sensor.py, graphstats.py,
motan/motan_graph.py, filter_workbench.ipynb.

And the import is unconditional, so removing the package does not merely lose the PNG:

calibrate_shaper.py:11    import numpy as np, matplotlib      <- module level
calibrate_shaper.py:175   def setup_matplotlib(...)           <- submodules deferred, base import is not

The script fails at line 11 before doing any analysis at all. So python3-matplotlib
and python3-numpy are live runtime dependencies of Klipper's input-shaper tooling,
not dead weight. They are simply consumed by system python rather than by klippy.

This also weakens the "build-time only" framing for the rest: gcc-arm-none-eabi and
build-essential (826 MB together) are what let a user rebuild MCU firmware on the
board, which is a normal Klipper workflow rather than a build artefact. They may still
be worth dropping, but that is a product decision about whether on-board firmware
compilation is supported - not the free win this issue currently implies.

What survives unchanged: nothing is ever cleaned up, and the rootfs sits at 4.8G of 6.9G
(71%). But the shortlist of what is genuinely safe to remove is now much shorter than
this issue claims, and I would not remove any of the four without deciding which
workflows are dropped along with them.