wheel building: Pile of small fixes to recent changes

[th0ma7]

Description

Fixes:

• FlexGet: Update to v3.13.16 #6403 (comment)
• python-wheel.mk fix for maturin built based wheels
• standardise crossenv calls
• standardise PATH definitions and call to cross-python3
• updates to python311
• updates to python312 and python312-wheels
• updates to python313 and create python313-wheels
• does not halt on errors while preparing the crossenv
• gcc-4.9.x archs requires msgpack==1.0.5 or it fails to install the crossenv.
• force break when crossenv or wheel build fails
• manage compile, install, plist cookies for spksrc.python-wheel.mk
• allow building newer pillow versions

Follows-up:

• dynamic crossenv + python3*-wheels + python310-313 updates #6282
• wheel.mk: Migrate to using status cookie #6389

Checklist

• Build rule all-supported completed successfully
• New installation of package completed successfully
• Package upgrade completed successfully (Manually install the package again)
• Package functionality was tested
• Any needed documentation is updated/created

Type of change

• Bug fix
• New Package
• Package update
• Includes small framework changes
• This change requires a documentation update (e.g. Wiki)

[hgy59]

The build of pendulum as python wheel succeeded locally for armv7-7.1 and aarch64-7.1 so far.

[th0ma7]

@mreid-tt and @hgy59 FYI I have found a false positive whereas compilation would continue although errors may have been trigerred. This is due to - in front of -@MAKEFLAGS= $(MAKE) ... which makes it to ignore errors.

Currently working on figuring out exactly a) how to ensure it does halt on errors and b) where the errors are. At first glance it looks relatively easy to solve and limited in scope. I'll keep you posted once solved (fix to be in this PR).

[th0ma7]

I may have now solved the issue where wheel builds should halt properly on errors. This brought light to other wheel build issues such as with pydantic-core, now also fixed (had to migrate from pip using requirements file to python-wheel.mk using cross).

Remaining there may still be a weird case involving numpy with python311 only... next on my todo list. Beyond that I believe with this PR that code is becoming quite stable (fingers-crossed).

[th0ma7]

@hgy59 This PR is now ready for review. Many small changes and fixed many small'ish long-standing issues. Been testing it for a few days and cannot find anything left.

[th0ma7]

@hgy59 and @mreid-tt with the completion of the PR I believe time ma be appropriate to initiate work on migrating to python313. We'd need an issue to track updates like done previously #5043 and I would suggest releasing easy ones first to shake out any remaining issues. Thoughts?

[th0ma7]

pending: python313-wheels requires a bit more love and got a fix pending for pillow with older gcc <= 4.9.x

[mreid-tt]

I'm guessing that based on the cadence of Python development it would be prudent to go to 3.13. I agree with you that the finalisation of python313-wheels would be very useful for the migration of existing packages. Your wheels for 3.11 was very helpful to me when I attempted a package update recently.

[th0ma7]

There's also a need to be strategic with regards to impacts...

python311:

• newer pillow now finally compile on all archs!!! Although gcc < 4.9 (armv5 and probably hi3535, to be confirmed) no longer works unless refering back to version 9.x of pillow as workaround for older platforms.

python312:

• newer numpy finally compile to the detriment that older compatible with gcc-4.9.x no longer works (now DSM7 only)
• armv5 no longer supported
• impacted packages: bazarr, homeassistant

python313:

• greenlet only work with newer gcc (now DSM7 only)
• armv5 no longer supported
• impacted packages: bazarr, ffsync, flexget, homeassistant, sickchill

Migration directly to python313 would be nice, but more python packages will stop supporting DSM6. While python312 would be less impactful.

[hgy59]

we have some python-wheel packages with (empty) PLIST file and some without PLIST.
since there is no warning printed about missing PLIST file we can safly remove those.
And we have some "version selector" Makefiles (using spksrc.main-depends.mk) that have no PLIST files but a warning ""No PLIST for $(NAME)"" is printed out.

we can cleanup this in another PR:

• remove empty PLIST files for spksrc.python-wheel.mk packages
• suppress the warning "NO PLIST for ..." for main.depends packages.

[hgy59]

@th0ma7 still an issue with wheel status cookies.

When I run make on a package after a successful build, or after successful build and running make spkclean, I do not expect the ===> Processing wheel for {package-name} and all the ===> Processing requirement [...] logs.

It should only create the INFO file, the scripts, wizard, ... (files outside package.tgz) and finally update the spk package.
Similar to skipping the build of all the dependencies when the cookie .depend_done exists, it must not trigger the wheel building in this case. I guess we are lacking a cookie like .wheel_done.

Otherwise it takes too long and overwhelms with logs, when working on the service-setup or on the wizard files for packages that successfully build so far....

Remarks:
It does not build the wheels again and it logs Nothing to be done for 'wheel'. for all the wheels, but it should not trigger those targets.

[th0ma7]

indeed, i had that previously but it was a pain to play with when wanting to redo/debug/test some other wheels. But that is dam easy to bring back, further what your suggesting is changing the wheel level so it can be cleaned-up at spkclean which is clever.

It doesn't avoid python migration to occur though, and I'll submit a PR for that in no time, easy to tackle.