Open Sweepr opened 7 months ago
There are some new requirements for HA, so it we'll need some time to create an update.
ha_av
and will depend on ffmpeg (5 or 6?) packageThe homeassistant package is growing in size and we have limitted space in the synocoummunity.com repository. This is mainly caused by including a lot of cross compiled wheels in the package. Especially for arm 32 archs, most of the "no-arch" wheels are not available for download (at pypi).
We probably have to drop the homeassistant package for all but the Models with x64 or aarch64 CPU. But all x64 and the newer aarch64 models have support for docker and would support hosting HA by docker. This would lead to stop providing native HA packages.
Another approach would be to create an additional repository for the Homeassistant package to host the cross compiled wheels and remove those from the packages (spk files). One issue will remain: I never found the reason, why Homeassistant with our package does not download most of the wheels on demand (therefore we install all wheels at package installation). If we find a solution for this, the installation time would be seriously shortened, and dependencies for integrations would be installed on demmand.
A custom repository for cross compiled wheels would have another benefit. Cross compiled wheels that fail to build with the spksrc dev. env. could be provided, when the build with another environment is possible. For the rare case that cross build is not possible, even native built wheels could be provided.
@th0ma7 what is your opinion on the future of the HA package?
@hgy59 this is an interesting question that fits well in the sense trying to keep spksrc relevant and figuring out how to keep (or not) older arch in a maintanable shape, and at what cost.
But, in continuation of this, in the longer term if we want to keep maintaining efficiently python packages (including HA), we definitively need to move to an online repository and redirect all wheel builds under python for instance:
python311
├── wheels/grpcio/Makefile
└── src
Taking grpcio
specifically as it affect all aspects: does not build on armv5, qoriq (actually does it even build?) - i.e would require considering alternate tools than pip
to generate some builds whereas framework needs to be adapted accordingly. Afterwards packages would simply refer to the URL online.
That's something I'm willing to tackle (once other framework clean-up and qoriq thingy are merged). But I'd need assistance on many areas, for once the web site would need to be adapted for this.
Long story short, I believe there are opportunities, how much effort are needed vs value is the question - and on that if @mreid-tt web changes are finally getting merge we may have an idea of how many people are really using this and confirm if there even is a real interest?
@mreid-tt is you ever can get stats on a per arch-dsmversion basis that would be more than awesome :smile:
Long story short, I believe there are opportunities, how much effort are needed vs value is the question - and on that if @mreid-tt web changes are finally getting merge we may have an idea of how many people are really using this and confirm if there even is a real interest?
@mreid-tt is you ever can get stats on a per arch-dsmversion basis that would be more than awesome 😄
@th0ma7, I've been actively advocating for the two open PRs to be merged into the spkrepo, but it's been a bit of a struggle to grab the attention of the backend administrators. I'll keep nudging where I can until we get them merged and published.
Regarding the stats, it seems like it might be a bit of a separate challenge. We'll likely need to dive into the logging on the Fastly CDN network we're using. Given the significant volume of downloads we manage, implementing this will require some clever coding since the initial approach of direct database recording posed a risk to server performance and was consequently removed from the PR. It's definitely something I'm willing to tackle with some support and insights into the backend, but let's focus on one thing at a time for now.
@Sweepr while trying to build homeassistant 2024.1.6 I found further issues:
In the near future we will have the homeassistant package from DSM 7 only.
@Sweepr while trying to build homeassistant 2024.1.6 I found further issues:
- the webrtc-noise-gain module requires ‘-std=c++17’ therefore requires DSM >= 7
In the near future we will have the homeassistant package from DSM 7 only.
DSM 6.2 will reach EOL by the 4th quarter this year anyway.
Thanks @hgy59 and others for the effort and quick reponse to my request!
Highly appreciated. 👌
- the webrtc-noise-gain module requires ‘-std=c++17’ therefore requires DSM >= 7
In the near future we will have the homeassistant package from DSM 7 only.
@hgy59 what if we could move to llvm/clang for DSM6? Worth investigating...
Just to understand what to expect: Is it going to be updated to 2024.1.6 (and next versions) on DSM 7 in close future? Or it is not and I need to order HA GREEN?
@hgy59 @mreid-tt
I fully understand you guys are busy, but at least tell us what the expected timeline is for the package to be updated? There has not been any status update in over 4 month's.
More and more things are starting to break because of the outdated HA, even the simplest HACS garbage intergration can no longer can be updated.
Latest version is : 2024.5.1
Last logged: 07:25:32
[545064844432] This version requires Home Assistant 2023.11.0 or newer.
Latest version is : 2024.5.1 Have you guys looked at the possibility to update the package from within HA, similar to SabNZBD, Sonarr, Radarr?
Have you guys looked at the possibility to update the package from within HA, similar to SabNZBD, Sonarr, Radarr?
This is not an option. "Home Assistant Core" is a python application. We need to cross compile a lot of python modules and include those in the package. There is no possibility to use an other update method.
And we heavily depend on the home assistant project.
ha_av
module (a home assistant specific version of the ffmpeg library bindings) and this is hard to build with spksrc framework (currently it is not supported to build python wheels that depend on ffmpeg libraries)probably we will have to limit future HA packages to aarch64 and x64 and to DSM 7.2 - so the supported models will also support docker and docker would be a better platform for HA...
Before #6040 is merged it is not possible to build a newer HA package.
Thank you for the status update!l, appreciate it!
FYI: HACS has also released a breaking change
https://github.com/hacs/integration/releases/2.0.0
HACS requires Home Assistant 2024.4.1 or later.
Consolidating here as it's not clear a second issue adds value.
Software Name
Home Assistant 2024.1.6
Brief Description
Current latest version is 2023-7.3-22, newest version https://github.com/home-assistant/core/releases/tag/2024.1.6
HACS intergration "Flightradar24" complains about version 2023-7.3-22 being to old, and must install at least version 2023-9.3
Website
https://github.com/home-assistant/core/releases/tag/2024.1.6
Documentation
https://github.com/home-assistant/core/releases/tag/2024.1.6
Build/Installation documentation
https://github.com/home-assistant/core/releases/tag/2024.1.6
Source code
https://github.com/home-assistant/core/releases/tag/2024.1.6
OpenSource License
MIT
Other License
No response