META: Python 3.12 package status #6421
Assignees
Labels
Comments
|
@hgy59 @mreid-tt @SynoCommunity/developers Considering the following, strongly suggesting to migrate to python 3.12 which would be a lot less impactful and wait anothe year or so before switching to a newer python version considering impacts on older DSM6 archs. python311:
python312:
python313:
|
|
I've added a first set of relatively "easy" wins for early testing: |
|
Are we considering a big-bang approach where we prepare all the packages for Python 3.1.2 and release them simultaneously? Or should we prioritize quick wins, releasing simpler packages first and gradually tackling the more complex ones? Regarding the current FlexGet PR I have, should I proceed with that change now, or wait until all the packages are ready for release? The main advantage of a big-bang approach is that users would only need to have both Python 3.1.1 and 3.1.2 installed temporarily, rather than having to maintain them for an extended period. However, this approach could introduce more risk and delays, especially with more complex packages. I’d appreciate your thoughts on this. |
no I'm not, I'd rather have a few easy wins first, like the one i started with.
i would be tempted to suggest you release as-is first using python 3.11, and in a week or two once issues if any have been found with your 3.11 release (or the easy wins above) you migrate "as-is" to py312. That's why would recommend. |
|
@th0ma7 I have taken the octoprint package. Tested on VitualDSM 7.2.2. |
|
@th0ma7, thanks for the feedback. I'll start with those I've touched before |
I just tested with deluge PR on my armv7 NAS. First off python runs ok, basic testing showed it being functional. When installing deluge this came into the logs: That can only mean one thing: it either failed to build on github or failed to copy it over to the wheelhouse directory.... looking further into the github logs, it was built sucessfully: So is the file there or not? indeed it is! So why wasn't it able to install it? Something is odd, maybe you're hiting a similar issue? may just be with newer pip? EDIT: Getting the exact same error on my x64 nas. EDIT2: Was missing |
|
Hmm, I've just completed a test build of FlexGet on DSM 6 in #6427 and everything seemed to install and upgrade fine. I'm attaching the install and upgrade logs to the PR for your review if it would help. |
|
@mreid-tt that's great news! In the last round of wheel build update I didn't change "anything" in how builds are being made, I just changed how the makefiles are being processed. That being said I did one change that I reminded: removal of the EDIT: I just noticed I had not updated the |
|
@th0ma7 I am working on homeassistant first, trying to build homeassistant 2023.7.3 with python312 (before updating HA I want to know whether it works at runtime - or has issues like octoprint or deluge) |
Having an early PR I could chime in? |
|
@hgy59 when invoking |
|
@th0ma7, building for Build LogShould I mark |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
It could well be? Can you check if there is a cython also installed? |
|
My problems seem to be related to my local environment(s) It could be one of the following
So I will restart with a "clean" environment... Sorry for the noise, but I didn't want to create a PR before knowing wheter the current version runs with py312. PS: |
This is not the problem |
Since the |
|
WARNING: just found that python312-wheel package (and may be others) did not included numpy, greenlet etc. |
python311-wheels is not affected, only python312-wheels and python313-wheels |
|
@mreid-tt thnx for your involvment in this, it is really appreciated (further as it allows others to learn how this works). Although with @hgy59 finding and my recent new understanding #6430 (comment) we should pause just a little in order to get this last tidbit fixed. Hopefully I may be able to fix this within a week or so (bein optimistic a bit). |
|
@th0ma7, understood. I’ve been testing a Bazarr branch with these changes for a PR: master...mreid-tt:spksrc:bazarr-update. Everything appeared to build successfully: https://github.com/mreid-tt/spksrc/actions/runs/13002372904/job/36263335064. However, when I installed and ran the software, I noticed that It appears that it's not being included in the build process at all during the run. |
This was my finding in #6430 that numpy fails to build so far. But IMHO you don't need the conditional include (and can add numpy to the regular requirements file) but must limit the package to DSM >= 7 and exclude comcerto2k (limitation of numpy). |
|
@mreid-tt maybe we can ask bazzar development to remove the numpy dependency and find an alternate library? I don't expect that for homeassistant, the other package that requires numpy. |
So just to be clear, when the code has TC_GCC > 5.0, this is is the same as saying DSM > 6?
Hmm, I guess this can be an approach since
Would this be all that would be needed? |
If only this was that simple... Indeed, all dsm6 uses a gcc compiler version 4.9.x or older. Although with dsm7, almost all archs were migrated to gcc 7.5 then 8.x with dsm 7.1. however Synology seems to have forgotten comcerto2k who was left with a 4.9 gcc. Thus we had to create a new set of functions to compare the gcc version as using only tcversion would not suffice. |
|
@th0ma7, I've modified my branch to create a hybrid python311/python312 package based on the rules you outlined above. Based on this logic we have the following build results for Build status for numpy with python 3.1x
For the issue reported with the Cython version this I believe was already covered in the referenced #6430. What was more concerning to me was the Exec format error. This was noted in the same issue however there was no resolution to it. It seems to only happen in Build status for numpy with python 3.1x
From what I can tell there is a sanity test executable which is compiled, then tested and fails. My suspicion is that it compiles an In our codebase I see one mention of this as part of a patch for SynoCli Disk Tools here: From what I can tell it just disables the compile testing but I don't know if there is a better way for numpy. I came across a number of promising URLs but this is a little beyond my expertise: Hopefully this can assist with actually getting a build of numpy 1.26.4. |
Seams to be related to using cross env instead of build env and might have similar reason as the wrong cython version... |
|
Looking more into
In the repo there are some interesting files which may be of use: I hope you can make sense of this and possibly develop a |
|
I was looking at the Building from source documentation for v1.26 and v2.2 and did a few test runs in Ubuntu as follows: Build Log (v1.26)Build Log (v2.2) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Python 3.12 package status
checkmark: ✔️
xmark: ❌️
Packages formally using python 3.x
2023.7.3 fails to cross compile some wheels for python312:
Framework clean-up
The text was updated successfully, but these errors were encountered: