Upgrade on an RPi4 with PostgreSQL and 1.4GB database size on an SSD connected over USB3 took roughly 10 seconds.

2020-07-01 19:42:57 WARNING (Recorder) [homeassistant.components.recorder.migration] Database is about to upgrade. Schema version: 7
2020-07-01 19:42:57 WARNING (Recorder) [homeassistant.components.recorder.migration] Adding columns context_parent_id to table events. Note: this can take several minutes on large databases and slow computers. Please be patient!
2020-07-01 19:42:57 WARNING (Recorder) [homeassistant.components.recorder.migration] Adding columns old_state_id to table states. Note: this can take several minutes on large databases and slow computers. Please be patient!
2020-07-01 19:42:57 WARNING (Recorder) [homeassistant.components.recorder.migration] Adding index `ix_events_context_parent_id` to database. Note: this can take several minutes on large databases and slow computers. Please be patient!
2020-07-01 19:43:02 WARNING (Recorder) [homeassistant.components.recorder.migration] Adding index `ix_events_event_type_time_fired` to database. Note: this can take several minutes on large databases and slow computers. Please be patient!
2020-07-01 19:43:06 WARNING (MainThread) [homeassistant.setup] Setup of recorder is taking over 10 seconds.
2020-07-01 19:43:07 WARNING (Recorder) [homeassistant.components.recorder] Ended unfinished session (id=201 from 2020-06-30 05:30:37.667604+00:00)

The load times of logbook/history are down from ~20s to under less than 3s.

This broke denonavr integration for me. The log has this, which is surprising since defusedxml is already in nixpkgs, so I assumed update.sh would've pulled it in. I only just started looking though (and I don't necessarily expect my issue to block this PR, just wanted to give initial feedback.)

error: https://gist.github.com/colemickens/e814a6e78d29dc487336c242c9b59418

Well, as far as I can tell, denonavr->ssdp->defusedxml, so it looks like a possible bug in the update script and it's dependency resolution.

I'm not sure it matters to me anymore though. This release removes denonavr's ability to be configured via YAML. I am looking for a more static home-assistant replacement moving forward. (Something nix-powered would be neat, and could pair nicely with esphome's declarative nature.)

Well, as far as I can tell, denonavr->ssdp->defusedxml, so it looks like a possible bug in the update script and it's dependency resolution.

I'm not sure it matters to me anymore though. This release removes denonavr's ability to be configured via YAML. I am looking for a more static home-assistant replacement moving forward. (Something nix-powered would be neat, and could pair nicely with esphome's declarative nature.)

mach-nix could provide more precise pinning.

Well, as far as I can tell, denonavr->ssdp->defusedxml, so it looks like a possible bug in the update script and it's dependency resolution.

I'm not sure it matters to me anymore though. This release removes denonavr's ability to be configured via YAML. I am looking for a more static home-assistant replacement moving forward. (Something nix-powered would be neat, and could pair nicely with esphome's declarative nature.)

Our latest script does resolve transitive dependencies. It was not used here for updating though.

This broke denonavr integration for me. The log has this, which is surprising since defusedxml is already in nixpkgs, so I assumed update.sh would've pulled it in. I only just started looking though (and I don't necessarily expect my issue to block this PR, just wanted to give initial feedback.)

error: https://gist.github.com/colemickens/e814a6e78d29dc487336c242c9b59418

• denonavr
  • requires "denonavr==0.9.3" "getmac==0.8.2"

Does not depend on any other component, so the update script won't find defusedxml, which is a requirement in the ssdp, ohmconnect, namecheapdns and ihc components.

The denonavr manifest declares some ssdp values, but does not depend on ssdp. This could in fact be an upstream bug.

https://github.com/home-assistant/core/blob/dev/homeassistant/components/denonavr/manifest.json

I guess they expect ssdp to be loaded through default_config, which depends on it. Did you configure default_config? @colemickens

There were two patch versions released in the meantime.

The bump has been pushed.

Please don't consider me blocking. I was able to get 0.112.1 working after activating ssdp, so everything's good on my end. I'll pull 0.112.2 and test later, but I don't anticipate problems.

Thanks for the PR and the help!

Result of nixpkgs-review pr 91958 1