So, i dont know how to upgrade pyenv manually - i hope DietPi integrates the new Python Env soon
The day after tomorrow, Debian 12 will be released, which comes with 3.11.
Not sure which release of Dietpi will switch to Debian 12, but HA 2023.08 won’t be released until august.
HA pyenv is independent from global python version and will need to be updated on our scripts. Actually, we have it hardcode
Not automatically. User already can trigger the upgrade to Bookworm since a while
Is there a recipe how to upgrade python in HA?
I just updated HA to 2023.6.0 and run into a problem, which is claimed to not exist using python 3.11
see Update 2023.6 does not start · Issue #94239 · home-assistant/core · GitHub
We use a dedicated pyenv for HA having a fixed python version
Yes I know this. But I am not so familar with the pyenv. Is it possible to upgrade within pyenv? And if so, do you have a recipe how to do? In that case I would give it a try…
Whatever you do, create a backup before.
You could try to adjust our install script with your own python version until we include 3.11 for HA pyenv.
Once done, reinstall HA.
I have tried this by changing python to 3.11.4 but totally crashed my install. However, 3.11.3 worked like a charm. Backup was a great idea
I am not sure how far the support for Python 3.11 actually is at HA. Normally @MichaIng knows
Thanks for the pointer. I’ll update our pyenv Python version ASAP now that HA officially announced Python 3.11 support/switched.
That Python 3.10 causes issues already of course was not intended by HA guys, not sure how fast they will provide a fix? Probably best is if we ship a live patch, as next DietPi update is still 3 weeks to go.
EDIT: Ah just read the Python 3.11.4 issue. Hum must be very bad luck if a patch version is making a difference as they should not imply any API changes, only fixes. @innovodev do you have an error log abou this? I’m not keen to ship an old Python 3.11 patch version.
Unfortunately I restored my back image (or fortunately). But now that I have a backup image I will try the 3.11.4 again and report.
I stand corrected on this. something else must have been going on. I have tried twice with 3.11.4 and the installation went through without issues and Home Assistant launched back up.
I think I know the cause of my system crash, but I haven’t had time to investigate if it is related to 3.11.3 or 3.11.4.
After changing the Python version and doing a dietpi-software reinstall 157, after the install is complete by a few minutes, Home Assistant starts installing the pip plugins and some using gcc. I am attaching a screen shot. This is using enormous cpu and memory power. I have not noticed this before this latest version of python.
On my Odroid C2 and N2 with 2GB RAM on each, I had to increase the swap space to 4GB which seems to have done the trick. On my FriendlyArm Neo with 512MB RAM, so far this seems to be an impossible task.
Hope this helps.
that somehow is normal on HA as wheels would need to be compiled/build on first install/update.
After much laboring, the issue is on my Neo (armv71), building ha-av was failing. So it was attempting the install of ha-av 10.1.0 on every restart of HA. I found the solution here: https://community.home-assistant.io/t/unable-to-install-package-ha-av/466286/31. It was a long build, but it did take care of the issue. The issue is related to 32 vs 64 systems.
I am not sure if there is an updated version of FFMPEG that works out of the box?
Note, when running the configure command, remove --enable-mmal \ as this is related to Broadcom chips on the Raspberry Pi. On the Neo this is not needed.
Happy building!
Will there be a live patch or will this be getting integrated with the next release of dietpi ?
I’m not sure if there will be a live patch, but I think in the next version it should be possible. But @MichaIng knows better than me
PR up to bump it for next version first: DietPi-Software | Home Assistant: Bump pyenv Python version to 3.11.4 by MichaIng · Pull Request #6440 · MichaIng/DietPi · GitHub
Running install tests: DietPi-Software · MichaIng/DietPi@04c0585 · GitHub (ignore Trixie failures, I need to update the test script to support it)
Installs fine and service starts fine, hence all wheels required for the web interface are downloaded or compiled fine as well.
Not sure if I understood the issue with FFmpeg and there is none in our tests on any 32-bit ARM, and it is not too long ago that I made tests on physical hardware. However, will do a test on NanoPi M1 now (same SoC as NEO).
Dammit, on the NanoPi M1 with Python 3.11.4 it fails to compile (the module on first service start) with the same error. Strange that this does not happen in the ARMv7 and ARMv6 test containers.
Testing with Python 3.11.3. Very strange that a Python patch version makes a difference. The FFmpeg packages and libraries should be fine.