2022.12: It does matter!

It is looking like the releases since 12.0 are making more than “under the hood” updates. One of the updates changed the pip (available: 22.3 → 22.3.1) which broke one of my custom add ons (our groceries). I don’t understand why this is being changed now rather than during the beta cycle?

Pip ( Pip Installs Packages or Pip Installs Python) installs all the libs that HA uses. It was updated because of a sub dependency conflict that was causing issues. I.e. bug. Read wrong PR.

That is incorrect; nothing changed in that regard, our current pin for pip can be found here:

https://github.com/home-assistant/core/blob/fed308b59dba844e641a74a9cedab241b18b826b/homeassistant/package_constraints.txt#L34

Which currently is: pip>=21.0,<22.4
Meaning, the pip version you mentioned is well within our accepted range. This change was made in October and was already part of Home Assistant Core 2022.11.0.

Please note that pip released 22.3.1 on November the 5th: https://pip.pypa.io/en/stable/news/#v22-3-1, which isn’t related to our releases.

…/Frenck

1 Like

Updates to core dependencies cannot break add-ons. They exist in separate docker containers and so its impossible for them to be affected by a change like a bump to pip. Perhaps you mean a custom integration?

Dependency bumps are also extremely common in patch releases. Since libraries used by HA may also have issues warranting quick releases. So I’m not sure where that information is coming from about what does and doesn’t go in a patch.

Assuming you are talking about a custom integration, consider trying to include it in core to prevent this situation in the future. That way automated tests will catch this during CI for the PR before it is merged.

1 Like

I totally agree starting a new thread was the right thing to do. I don’t think anyone questioned that.

The problem was the title of the new thread. I guess there are a lot of cultural differences here, so I try not to take offense. But to me, starting a title with “I don’t like” sounds like whining. It seems like it’s a deliberate put-down of the concern. In other words, dismissive. A way to get others to ignore the thread.

The first time it happened I assumed that wasn’t the intent and I didn’t say anything. But this time I wasn’t the only one to notice. So I replied to that post and tried to elaborate about what the concern was. I’m sorry if it wasn’t taken that way, but I was trying to be constructive. Thread titles matter.

4 Likes

It does quite the opposite. I’m the one who makes those titles and I do it for the sole reason of corralling the upset people into that thread. Which usually works. There’s no other intention with the title. It’s a bit selfish of me because I don’t want to spend my time moving posts over. I’ll try a different title next time seeing that it’s a hot button. I just want to be clear that my intentions are not to dismiss the issue, but to save me some time with moderation.

Either way, instead of making a post with bold assumptions to get reactions from other community members, you can simply flag the post and explain why you’re flagging it. As you can already see, we’ve renamed things and moved things to other topics based on users requests. All of us moderators are pretty easy going. If you want something to change with any topic / post, we usually accommodate.

4 Likes

Logger: homeassistant.util.package
Source: util/package.py:98
First occurred: 10:55:02 AM (6 occurrences)
Last logged: 11:10:03 AM

Unable to install package ourgroceries==1.5.0: ERROR: Cannot install ourgroceries==1.5.0 because these package versions have conflicting dependencies. ERROR: ResolutionImpossible: for help visit Dependency Resolution - pip documentation v23.0.dev0 [notice] A new release of pip available: 22.3 → 22.3.1 [notice] To update, run: pip install --upgrade pip
All worked after Ourgroceries was updated to comply with 12.0. Broke at 12.2 or 12.3. Don’t remember. Addon not working since last update of HA. Could you please fix this? · Issue #31 · ljmerza/ha-our-groceries · GitHub

It was my post in my name that created the new thread so I should be the one with most emotions about it.

And I think @petro did the right move and I did not have any immediate negative reaction to the title he chose.

Let us focus on those colours in the UI and not the process. There is a lot that needs fixing

8 Likes

Sorry, you are misinterpreting that message. The new pip release available is something pip will always mention on errors if there is a newer version available. It is misleading/confusing at times.

The real issue is that there is a dependency conflict (being not pip itself), which is entirely possible. Lots of dependencies (and subdependencies) get updates between each release. It is up to custom integration developers to ensure dependencies are pinned loose enough and keep their dependencies up to date.

…/Frenck

Edit: @bschatzow Left a comment upstream in the issue you listed. The issue is caused by the upstream library created by the integration maintainer. I’ve posted a solution/suggestion to fix and avoid the issue.

2 Likes

I’ve also had HA crash twice the last two days, once on 2022.12.1 and once on 2022.12.4. Running on a PI4. unplugged the skyconnect-stick this morning after the second crash in case it’s related. HA-host responded to ping, but frontend was not accessible. Memory usage was at about 25%. Upgraded from OS 9.3 to 9.4 now in the hopes it might help.

Ibeacon recognition still not working on mi pi4.

the new 12.5 update has made all of the history graphs forced to UTC in the UI, and there has been no change to my General preference of PST, which is still showing PST.

Is there a way to make my History graphs also show the selected time zone again and not UTC?

I cannot spot anything in the changes of that release that should influence the timezones. From which version were you upgrading? 12.4?

The only frontend timezone related PR is Make error on general config better + default timezone by bramkragten · Pull Request #14635 · home-assistant/frontend · GitHub which added a default in case nothing was set when opening the general settings, but you said that is set to PST, so that cannot be it.

1 Like

I was being a very very dumb silly person and I apologize for wasting your time (I have also been trying to scroll through PRs to find something too).

I failed to remember I use Librewolf on this machine, which forces UTC as a browser time… I opened up another website that I use that has timed entries and it also being in UTC finally got my old dusty brain to fire to the right synapse.

It seems that the 2022.12.3 update didn’t fix the crashing, although it did last longer this time.

no errors saved just before the crash.

Tried to update to 2022.12.5 from 2022.12.3 but...
2022-12-14 12:48:06.711 ERROR (MainThread) [homeassistant.components.hassio.handler] Client error on /core/update request Server disconnected
2022-12-14 12:48:06.713 ERROR (MainThread) [homeassistant.core] Error executing service: <ServiceCall update.install (c:01GM7F8T6CTA2BXG3GVM8QKXDH): entity_id=['update.home_assistant_core_update'], version=2022.12.5, backup=False>
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/hassio/update.py", line 303, in async_install
    await async_update_core(self.hass, version=version, backup=backup)
  File "/usr/src/homeassistant/homeassistant/components/hassio/handler.py", line 48, in _wrapper
    data = await funct(*argv, **kwargs)
  File "/usr/src/homeassistant/homeassistant/components/hassio/handler.py", line 245, in async_update_core
    return await hassio.send_command(
  File "/usr/src/homeassistant/homeassistant/components/hassio/handler.py", line 478, in send_command
    raise HassioAPIError()
homeassistant.components.hassio.handler.HassioAPIError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/core.py", line 1763, in catch_exceptions
    await coro_or_task
  File "/usr/src/homeassistant/homeassistant/core.py", line 1782, in _execute_service
    await cast(Callable[[ServiceCall], Awaitable[None]], handler.job.target)(
  File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 213, in handle_service
    await service.entity_service_call(
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 678, in entity_service_call
    future.result()  # pop exception if have
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 943, in async_request_call
    await coro
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 715, in _handle_entity_call
    await result
  File "/usr/src/homeassistant/homeassistant/components/update/__init__.py", line 154, in async_install
    await entity.async_install_with_progress(version, backup)
  File "/usr/src/homeassistant/homeassistant/components/update/__init__.py", line 413, in async_install_with_progress
    await self.async_install(version, backup)
  File "/usr/src/homeassistant/homeassistant/components/hassio/update.py", line 305, in async_install
    raise HomeAssistantError(
homeassistant.exceptions.HomeAssistantError: Error updating Home Assistant Core

but then:
image

:man_shrugging:

What hardware are you running HAOS on Dave?

I am not sure why this has been flagged?

3 Likes

Those are the Core logs. When updating Core itself, it is handled by the Supervisor. Is there anything visible in the Supervisor logs maybe?

…/Frenck

Running on an i7 NUC

Is there a way to see these after a reboot? I had to do a hard reboot to get going again.