Original gitea site is down

[Tatsh]

Is this now the official location of the overlay?

[BillKenw]

Is there any more information on the status of this project?

[tabascoz]

i'm not sure, starting to draft a repo myself as I'm running several useflags out of homeassistant (normal) ebuild. I pushed some pull reqs never got an answer.
This is awesome work and would like to contribute or have it more in sync with current releases. but HA evolution is very fast paced and is hard to catch-up

[xavierforestier]

My fork is up-to-date: https://github.com/xavierforestier/HomeAssistantRepository (I'm working on 2026.1.0)
I implement CI/CD automatic checks too, so github actions checks that no deps are missing (there are 1845 packages to build homeassistant-full on a fresh gentoo :D )

[tabascoz]

Hi Xavier, we may join forces LoL - i'm doing the same in mine https://github.com/tabascoz/ha-bleeding-edge
I've been only maintaining homeassistant-full (just pushed 2026.1.0 ) but with all integration useflags but i just have time to maintain ebuilds for the dependencies i actially use. I was thinking about the pypi repository could be an answer to that... What's your thoughts ?

[tabascoz]

Hi Xavier, we may join forces LoL - i'm doing the same in mine https://github.com/tabascoz/ha-bleeding-edge I've been only maintaining homeassistant-full (just pushed 2026.1.0 ) but with all integration useflags but i just have time to maintain ebuilds for the dependencies i actially use. I was thinking about the pypi repository could be an answer to that... What's your thoughts ?

I saw you're not updatding the homeassistant-full so it would be great to merge both repos ... i'm also not sure if this is still the purpose of this official repo as it has been long time delayed from main versions.

[xavierforestier]

Hello, I'm using mine for more than a year, it generates all use flag possible according to available integrations in HA website. (Original ha-full ebuild hardcoded these flags) I've moved to a single app-misc/homeassistant ebuild + one virtual/homeassistant hardcoding use flags sets (minimal / normal / full) it allows to ease maintenance (just one main package to maintain) but virtual ebuild brokes once a month as each HA 202x.xx.0 release depreciates or adds new integrations. My purpose is to add automatisations for everything ( currently CI/CD actions detects upstream updates, and create corresponding branches, I still have to code an action trying to parse upstream (pyproject.toml) and generate corresponding ebuild, try to build and create missing branches for missing deps. CI/CD script : already checks for missing deps, try to compile ebuild. This part working fine already (except it usually  runs more than 6h to build, so github kicks it, as it reachs the free account limits). 8 janv. 2026 14:49:24 Fernando Cunha ***@***.***>:

…

[Image]*tabascoz* left a comment (onkelbeh/HomeAssistantRepository#294)[#294 (comment)] Hi Xavier, we may join forces LoL - i'm doing the same in mine https://github.com/tabascoz/ha-bleeding-edge I've been only maintaining homeassistant-full (just pushed 2026.1.0 ) but with all integration useflags but i just have time to maintain ebuilds for the dependencies i actially use. I was thinking about the pypi repository could be an answer to that... What's your thoughts ? I saw you're not updatding the homeassistant-full so it would be great to merge both repos ... i'm also not sure if this is still the purpose of this official repo as it has been long time delayed from main versions. — Reply to this email directly, view it on GitHub[#294 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AFRTBBN2VNIMR7V3DR6IPG34FZN6FAVCNFSM6AAAAACP5SXWYCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOMRTHE3DKMZXGA]. You are receiving this because you commented. [Image de pistage][https://github.com/notifications/beacon/AFRTBBL4ZPV7GRUSTARA7VT4FZN6FA5CNFSM6AAAAACP5SXWYCWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTW564Z3U.gif]

[xavierforestier]

We won't merge easly 😢

[tabascoz]

its a

Hello, I'm using mine for more than a year, it generates all use flag possible according to available integrations in HA website. (Original ha-full ebuild hardcoded these flags)

I've moved to a single app-misc/homeassistant ebuild + one virtual/homeassistant hardcoding use flags sets (minimal / normal / full) it allows to ease maintenance (just one main package to maintain) but virtual ebuild brokes once a month as each HA 202x.xx.0 release depreciates or adds new integrations.

My purpose is to add automatisations for everything ( currently CI/CD actions detects upstream updates, and create corresponding branches, I still have to code an action trying to parse upstream (pyproject.toml) and generate corresponding ebuild, try to build and create missing branches for missing deps.

CI/CD script : already checks for missing deps, try to compile ebuild. This part working fine already (except it usually runs more than 6h to build, so github kicks it, as it reachs the free account limits).

8 janv. 2026 14:49:24 Fernando Cunha @.***>:
…

Its a great idea! so you're working on new updates/dependencies also , for ex how you do with new integration dependencies? What i'm doing now is to analyze ha requirements_all.txt and hardcode in homeassistant_full ebuild, like the same as the original repo.

The idea to automatize is surely a way to go. I'll give a look to your repo and ebuild and think about ways. give a look to mine, recent commits as i update manually some dependencies that are not in gentoo main ( most of them aren't as you know )

[tabascoz]

++ 2 cents, think whatever movement to the future is beneficial for Gentoo, also HA community as i am sure some people might start abandoning the distro to adopt docker/official given the outdated status of Homeassistantrepository

[Tatsh]

I would prefer to keep using homeassistant-min though I can appreciate having just one ebuild with a lot of USE flags instead of a few variants (this would be how I would do it). Either way I only have a few things I use in HA so I want to avoid installing a ton of things. And I also do not want what would be considered 'unstable' (I do not install 9999/VCS-based packages).

These are my USE flags for homeassistant-min:

• airly
• airvisual
• alpha_vantage
• androidtv
• backup
• bluetooth
• bluetooth_le_tracker
• caldav
• cast
• ffmpeg
• github
• http
• kodi
• mariadb
• matter
• mobile_app
• mosquitto
• mqtt
• notify_events
• otp
• ping
• python_script
• recorder
• rest
• ring
• scrape
• snmp
• speedtestdotnet
• sql
• ssl
• systemd
• systemmonitor
• tile
• tplink
• upnp
• usb
• version
• wake_on_lan
• wemo
• whois
• zeroconf
• zwave_js

I would lean towards using @xavierforestier 's repository but I am still looking into it.

I have also strongly considered getting HA into my repository but it's a lot of work and I see you two are handling it well.

[tabascoz]

I agree wtih both of you, think we could think of having one ebuild avoid having multiple and get contributions/maintainers to support the use flags that are being asked. Some are very demanding, for ex yesterday i pushed Matter with python-matter-server and it requires another server, hard coded directories etc, so not so much straightforward - spend 3 hours only on it. Now is working but i need to check in other boxes.

Bot all this work can be used for any HA flavor.

@xavierforestier if you agree perhaps we could do some great stuff, join forces, check if @onkelbeh is still maintaining the official repo and if not think about future bases for a new official repo.

If @onkelbeh is happy to take contributions then it would be awesome but I am not sure , would love to hear from him.

Need to exit today to do some stuff, but I'll update the useflags that I am using now in a while