RIOT-OS
makefiles/docker.inc.mk: bump riotbuild docker image to last available
Contribution description
This includes https://github.com/RIOT-OS/riotdocker/pull/245 and https://github.com/RIOT-OS/riotdocker/pull/241.
The hashes were obtained with dist/tools/buildsystem_sanity_check/check.sh.
Testing procedure
CI should not complain.
Issues/PRs references
See #20472 for the PR that introduced the pinning mechanism.
Murdock results
:heavy_check_mark: PASSED
771c546e65f777c68d15fa3dd64d2afa689c8e63 pkg/emlearn: add patch to remove redundant check
| Success | Failures | Total | Runtime |
|---|---|---|---|
| 10192 | 0 | 10193 | 13m:48s |
Artifacts
@mguetschow: It seems that the emlearn test is using some pickled data where the data was serialized with a incompatible version of emlearn (or its dependencies), so that deserialization fails. In fact, the previous docker version already complained about the version mismatch, but we apparently got lucky and the data was still compatible.
I wonder if we should just merge https://github.com/RIOT-OS/RIOT/pull/20841 and let actual users of emlearn to worry about having a version of emlearn (or its deps) installed that is compatible with the models they use.
Are you sure it only requires the header?
There is also a python library that appears to be incompatible with the test in master - I wonder if this PR needs to include #20347 in order to pass CI.
Are you sure it only requires the header? There is also a python library that appears to be incompatible with the test in
master- I wonder if this PR needs to include #20347 in order to pass CI.
Yes, I can confirm that the header is enough. The python library in riotbuild is now incompatible with the model test in master, since that one uses the python library to generate model.h.
Including #20347 would be another fix, but that would leave the interdependencies between RIOT master and the python package versions in riotbuild in place for the future.
Yeah, let's try cherry-picking https://github.com/RIOT-OS/RIOT/pull/20347 instead.
Adding the model.h to the repo is something we can still do afterwards avoid similar issues in the feature, as updating emlearn will then be possible without touching the CI container.
Yeah, let's try cherry-picking #20347 instead.
Done, this includes #20347 now.