Debian Trixie: deprecated packages in Measuring Resonances dependencies

Developers
1

Hi everyone,

I’m in the process of updating MainsailOS on Debian Trixie ( feat(Trixie)!: upgrade to debian trixie by meteyou · Pull Request #351 · mainsail-crew/MainsailOS · GitHub ) and ran into a couple of issues with deprecated/obsolete packages related to the “Measuring Resonances” setup in Klipper.

Context

Issues

  • libatlas-base-dev deprecated
    I’ve seen recommendations to use libopenblas-dev as a replacement. This package does get installed already per the guide, but I’m not sure if it’s a full drop-in for Klipper’s needs.

  • “numpy<1.26” no longer supported on Trixie
    It looks like we should move to at least NumPy 2.x on Debian Trixie. Has anyone already updated the Klipper resonance tooling to be compatible with NumPy 2.x?

So far I haven’t encountered issues outside of “Measuring Resonances”. I’d like to keep this thread as a running collection point for Trixie-related problems until we’ve identified and resolved them all.

2

Perhaps on newer version of debian this is no longer necessary. FWIW, the documentation already recommends installing libopenblas-dev:

sudo apt install python3-numpy python3-matplotlib libatlas-base-dev libopenblas-dev

So, you could try installing without libatlas-base-dev, perhaps? I’m unsure if that would affect very old distributions of debian, for example.

Note that until some time we did not fix Numpy version, but apparently it caused some issues in some cases, and the version was fixed. I do not think that Klipper uses any specific features that would block migration to Numpy 2.x, but I’m unsure whether this would cause any issues with some environments. Separately, this is installed via pip, does the version of debian even matter? Note that system-wide version of Numpy (installed via apt) is not fixed as per command above.

1 Like
3

Separately, this is installed via pip, does the version of debian even matter?

The python version is here important. Per default, Trixie uses py3.13 and venv will be created with this version (per default). So its a python <> numpy issue.

4

So, these issues originate from the need of supporting very different versions of the OS’es and environments through a single recipe. If you are pre-building a Mainsail OS image with Klipper and its dependencies preinstalled, I see no issue just installing the latest version of Numpy for Klipper environment and skipping libatlas-base-dev installation. You’d need to check that the resonance testing still works, and report issues if it doesn’t, but I’m reasonably confident that it’ll work out.

That said, I do not have a good solution for the general case of Klipper documentation. I’m afraid that forcefully bumping Numpy version to some of 2.x.x for Klipper env will result in dropping support of some older versions of debian, which, I’m afraid, are still plenty. And I’m unsure if any environment issues reappear, and I cannot test all possible combinations myself either. The same goes for libatlas-base-dev - I suppose dropping it should be harmless for newer versions of OS’es, but I’m unsure if it could affect very old versions still around.

5

thx for your detailed answer! I will test it and will report!

6

Do you by any chance know what some of the problems were? Right now it sounds to me like numpy couldn’t be installed into some python environments and that’s it.
If it is just about installation, then it’s pretty easy to test. Indeed it worked without any problems on our end, with the newest numpy and without libatlas-base-dev.
If it’s a problem during runtime with some weird edge cases, resulting in errors due to newer numpy versions being stricter during calculation, testing would be way harder.

Right now it’s hard for us (at least for me) to understand what the actual problem was that lead to the documentation changed and what we should test to make sure that there are no problems.

7

today i run the normal input shaper tests and created the charts without any issues:

pi@zero:~$ ~/klipper/scripts/calibrate_shaper.py /tmp/resonances_x_*.csv -o ~/printer_data/config/shaper_calibrate_x.png
Fitted shaper 'zv' frequency = 81.2 Hz (vibrations = 3.5%, smoothing ~= 0.030)
To avoid too much smoothing with 'zv', suggested max_accel <= 25700 mm/sec^2
Fitted shaper 'mzv' frequency = 79.2 Hz (vibrations = 0.0%, smoothing ~= 0.035)
To avoid too much smoothing with 'mzv', suggested max_accel <= 18500 mm/sec^2
Fitted shaper 'ei' frequency = 97.2 Hz (vibrations = 0.0%, smoothing ~= 0.036)
To avoid too much smoothing with 'ei', suggested max_accel <= 17200 mm/sec^2
Fitted shaper '2hump_ei' frequency = 124.8 Hz (vibrations = 0.0%, smoothing ~= 0.039)
To avoid too much smoothing with '2hump_ei', suggested max_accel <= 16500 mm/sec^2
Fitted shaper '3hump_ei' frequency = 149.8 Hz (vibrations = 0.0%, smoothing ~= 0.042)
To avoid too much smoothing with '3hump_ei', suggested max_accel <= 15200 mm/sec^2
Recommended shaper is mzv @ 79.2 Hz
pi@zero:~$ ~/klipper/scripts/calibrate_shaper.py /tmp/resonances_y_*.csv -o ~/printer_data/config/shaper_calibrate_y.png
Fitted shaper 'zv' frequency = 66.0 Hz (vibrations = 7.4%, smoothing ~= 0.042)
To avoid too much smoothing with 'zv', suggested max_accel <= 17000 mm/sec^2
Fitted shaper 'mzv' frequency = 63.2 Hz (vibrations = 0.0%, smoothing ~= 0.051)
To avoid too much smoothing with 'mzv', suggested max_accel <= 11800 mm/sec^2
Fitted shaper 'ei' frequency = 77.6 Hz (vibrations = 0.0%, smoothing ~= 0.055)
To avoid too much smoothing with 'ei', suggested max_accel <= 11000 mm/sec^2
Fitted shaper '2hump_ei' frequency = 99.8 Hz (vibrations = 0.0%, smoothing ~= 0.057)
To avoid too much smoothing with '2hump_ei', suggested max_accel <= 10600 mm/sec^2
Fitted shaper '3hump_ei' frequency = 122.8 Hz (vibrations = 0.0%, smoothing ~= 0.059)
To avoid too much smoothing with '3hump_ei', suggested max_accel <= 10200 mm/sec^2
Recommended shaper is mzv @ 63.2 Hz

Should i test anything else to doublecheck all functions?

if you also wont to test something, you can download the test build here: feat(Trixie)!: upgrade to debian trixie · mainsail-crew/MainsailOS@6e5bb4c · GitHub

2 Likes
8

Please also run SHAPER_CALIBRATE AXIS=<..> from the Klipper console to check that this part also works as expected. But otherwise looks like everything is working fine.

1 Like
9

looks like it also works:

image
image938×455 27 KB

Thank you very much!

1 Like