Python 3.11 started to roll out to github actions, and .. it doesn't work.
This MAY affect just the espressif build, but I'm pinning it back at 3.10
for all builds.
Typical failure, during "Run $IDF_PATH/tools/idf_tools.py --non-interactive install required"
shows a lot of failures building gevent:
```
...
Collecting gevent<2.0,>=1.2.2
Downloading gevent-1.5.0.tar.gz (5.3 MB)
...
Building wheel for gevent (pyproject.toml): finished with status 'error'
...
src/gevent/_greenlet_primitives.c:216:12: fatal error: longintrepr.h: No such file or directory
216 | #include "longintrepr.h"
| ^~~~~~~~~~~~~~~
compilation terminated.
error: command '/usr/bin/gcc' failed with exit code 1
```
I notice that gevent is pinned at <2.0 while the current version is 22.10.2!
This is a dependency of gdbgui==0.13.2.0, which is installed by esp-idf
pinned at that version.
This isn't intended to make any overt behavioral change, but
there is a slight one in the value of CP_VERSION that will be used
during CI, because it will now include `--always --match "..."`,
so there could be a change to the uploaded name of the mpy-cross
artifacts on s3.
This targets the 64-bit CPU Raspberry Pis. The BCM2711 on the Pi 4
and the BCM2837 on the Pi 3 and Zero 2W. There are 64-bit fixes
outside of the ports directory for it.
There are a couple other cleanups that were incidental:
* Use const mcu_pin_obj_t instead of omitting the const. The structs
themselves are const because they are in ROM.
* Use PTR <-> OBJ conversions in more places. They were found when
mp_obj_t was set to an integer type rather than pointer.
* Optimize submodule checkout because the Pi submodules are heavy
and unnecessary for the vast majority of builds.
Fixes#4314
This version is supposed to
> Fetch all history for all tags and branches when fetch-depth=0
We leave the tags fetch in place so that actions _in cloned repos_
work. Cloned repos' tags do not necessarily match adafruit/circuitpython,
but we want version reporting to be able to use adafruit/circuitpython
tags when they are most relevant according to "git describe"'s heuristics.
Submodules are different, as they always point to the repo specified
in .gitmodules, so they don't need special handling to get the most
relevant tags.
In order to get tags, including in submodules, we use our own fetching
procedure on top of checkout@v2.
A problem occuring in about 1% of jobs was that some submodules inexplicably
did not have an "origin" remote configured. "git submodule sync"
configures the "origin" remote in those cases. No cause for the problem
was determined.
Besides keeping up to date on actions/checkout, @v2 is supposed to fix a bug
where "re-run" of a pull request would fail checking out the code.
