mirror of
https://github.com/Klipper4FlashForge/firmware.git
synced 2026-10-21 12:52:16 -05:00
MonstrofilandClaude Opus 5
0747bc500b
* Keep the config in a directory of our own Flashing a stock FlashForge package back over the mod left a printer that would not start. /usr/data is the DATA partition: a stock flash rewrites /usr/prog and does not touch it, so the symlinked printer.base.cfg and the ff-*.cfg beside it outlived the mod, pointing into a /usr/data/anvil that was gone -- and Klipper treats an [include] it cannot resolve as fatal. Nothing of ours runs during a stock flash, so there is no undo to write from inside the mod. Not writing there is the only version of this that works. The live config is /usr/data/anvil-data/config now, seeded once by anvil-link-prog.sh with a copy of everything in /usr/data/config: printer.cfg with the SAVE_CONFIG block of calibrated values at the end of it, and the stock includes the mod neither ships nor parses. The seed test is printer.cfg, which is copied last and through a temp name, so a machine that never finished seeds again on the next boot rather than staying half-configured, and no update ever re-seeds over a tuned file. It is outside $MODDIR, so the installer's wipe-and-extract cannot reach it and nothing has to be stashed on /tmp. Moonraker moved with it, and the lever is the data path rather than -c: moonraker registers its config root as <data path>/config and nothing configures that separately, so -c alone would move the file it READS while file_manager kept registering FlashForge's directory. With -d /usr/data/anvil-data its config directory is klippy's, which is also what Mainsail's config editor lists. gcodes and logs stay where the machine keeps them -- /usr/data/gcodes is klippy's [virtual_sdcard] path -- as symlinks inside the data path, which works because register_directory() realpaths a root that is a link. The database is carried across once, by the service, below the stray-killer: the one point where moonraker is provably not running. What an older release left in /usr/data/config STAYS there. A sweep could delete the links but could not put stock's own printer.base.cfg back, because the release that replaced it kept no copy -- and stock's run.sh force-copies its own onto every flash, which repairs that directory whether or not anything was swept. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Fn1k6kaHWhUrsmBfpxjUcG * Ask the config-directory test about this installer, not the bake test_flashforges_config_directory_is_never_written asserted that the mod's filenames are absent from /usr/data/config. On a replica baked from a release that still WROTE them, that is a question about the bake rather than about the installer under test, and it fails for a reason the change cannot fix. Remove them, run the installer over the top, then ask. The property is "an install writes nothing there", and that is now what is measured. Verified on the replica: qa/replica/test_upgrade.py is 18/18. The five test_install.py assertions about the seeded directory still need a machine baked from a package built with this branch -- work/out holds one from 2026-08-30, which symlinks into /usr/data/config as the old code did. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Fn1k6kaHWhUrsmBfpxjUcG * Ask the config directory of a machine that has one The five assertions about /usr/data/anvil-data/config could only pass on a replica baked from a package built with this branch, and the bake installs work/out/*.tgz -- whatever was built last. So they failed for a reason the change cannot fix, and the gate could only go green after a full build, which is exactly when nobody runs it. Two different fixes, because the questions are two different kinds. WHAT THE INSTALLED PACKAGE PRODUCED is still asked of the bake, but the directory is now read off the machine instead of written down: PRINTER_CFG in the installed etc/s6-rc/source/klipper/run is the command line klippy is exec'd with, and therefore the only thing that decides which directory is live. test_install.py and test_klippy_extras_import.py follow it, so the include set, the graph walk and the user's printer.cfg are asked about whichever side of the move the installed package was built on. WHAT THIS CODE DOES is a new module, test_config_directory.py, which stages anvil-link-prog.sh from the checkout and runs it -- the way test_upgrade.py stages the installer. Only the timing is mocked: it seeds from a real printer.cfg with FlashForge's real includes beside it, links the ff-*.cfg the installed package really shipped, and reads MACHINE= out of the real app_startup.sh. It asserts the seeding carries the machine's own marker, the links point into $MODDIR, the chamber config matches the model, every include resolves, a second run does not re-seed over an owner's edit, and the run adds NOTHING to /usr/data/config. That last one is a DELTA, not an absolute. A machine that has been through a release which symlinked into FlashForge's directory still holds those links and nothing can restore what they replaced. What this code owes is that it adds nothing. Verified on the replica: 135 passed, and the 10 failures are the same ones master has on this bake -- ffmpeg, numpy, the timelapse component and the hardware services, all missing from the 2026-08-30 package in work/out. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Fn1k6kaHWhUrsmBfpxjUcG * Link every .cfg the packages ship, not a list of names test_every_include_resolves_in_the_new_directory failed on CI: printer.base.cfg has [include timelapse.cfg] and no timelapse.cfg was in /usr/data/anvil-data/config, which Klipper treats as fatal. anvil-link-prog.sh linked printer.base.cfg and the ff-*.cfg by name. timelapse.cfg is anvil-timelapse's and matched neither, so it reached the live directory only through the installer's copy of $MODDIR/config -- and never at all on the `apk upgrade` path, where the link script is the only thing that runs. A named list is a file that resolves on a fresh install and goes stale the moment a package adds one. So the rule is the glob: every .cfg in $MODDIR/config is linked, and the installer skips every .cfg rather than the four names it knew. The .conf beside them stay the installer's -- moonraker-custom.conf is the owner's file to edit, so it is copied once and never linked to a package's copy. test_the_mods_configs_are_links_into_moddir asks the same way now, so a package whose config nothing includes is covered too. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YULWHVHyxKm2HE9kiPfEjP --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>