Closed wormuths closed 4 years ago
makuser
commented
4 years ago Same as #40278.
Are you running this on 64bit Raspberry OS? I am running it on 64bit and no piwheel has been prebuilt for this and you did not install the required packages to build it yourself, which is absolutely why it fails.
makuser
commented
4 years ago The solution is to install this package: libjpeg-dev, which will also install libjpeg62-turbo-dev as a dep.
You should then be able to build Pillow.
wormuths
commented
4 years ago I’m not running on a Pi. I’m running core in a FreeBSD jail. If those packages are dependencies of Home Assistant they should be pulled in as such.
So I should just use “pip3 install libjpeg-dev“? Then upgrade?
makuser
commented
4 years ago I’m not running on a Pi. I’m running core in a FreeBSD jail.
Good to know. Have a look if you can find a wheel for your architecture and python version: https://pypi.org/project/Pillow/#files
If those packages are dependencies of Home Assistant they should be pulled in as such.
They can not be "pulled in as such", as they are system library dependencies, not python library dependencies. I do agree however, that the installer notes should definitely be updated, as to include the new dependencies and it should also be noted in the upgrade notes.
As of four days ago, this has been updated: https://github.com/home-assistant/home-assistant.io/commit/4d68365e863a5e35396fd2a15e7f7727d9550a40
So I should just use “pip3 install libjpeg-dev“? Then upgrade?
No, https://www.home-assistant.io/docs/installation/raspberry-pi/
wormuths
commented
4 years ago This is a bug. I have had Home Assistant Core running for well over a year, and I’ve been using the same command to upgrade Home Assistant the whole time. This time it fails because of a dependency? If it’s a dependency, then the home assistant upgrade should either install it, or abort because of a dependency problem.
I’m not sure why you’re sending me to the install method for the Pi, I’m not running that. I need to know what commands I should run from the jail shell to make sure the upgrade doesn’t break my whole setup?
What should I go to the shell of my virtual environment and run?
wormuths
commented
4 years ago I appreciate the effort by the way... I just don’t think this can be classified as a “user error”. The process of upgrading HA should pull in what it needs, or not upgrade. HA says the upgrade completed successfully, but it no longer boots after a “success”.
makuser
commented
4 years ago I’m not sure why you’re sending me to the install method for the Pi, I’m not running that. I need to know what commands I should run from the jail shell to make sure the upgrade doesn’t break my whole setup?
Duuude. Did you even look at the link I sent you? It is still called 'raspberry pi', you are right. But it is about 'Home Assistant Core'. Look for yourself: https://www.home-assistant.io/docs/installation/#alternative-installs
I need to know what commands I should run from the jail shell to make sure the upgrade doesn’t break my whole setup?
What should I go to the shell of my virtual environment and run?
You need to install all the library dependencies in order to be able to build the Pillow python library. Doing anything inside your venv will absolutely not help at all. Like not even remotely. It can't. It would always fail. Because you first need to install the dependencies for Pillow.
On a Debian-based Linux system, the required packages are called libjpeg-dev, which you install via apt install libjpeg-dev, or actually as I found out the correct dependency is rather to libopenjp2-7, so apt install libopenjp2-7. I am the Linux guy, you seem to be a FreeBSD fan, so use whatever makes your life easier to install the required dependencies, I assume that is also called "package manager" on FreeBSD? No?
I guess installing the 'Pillow' on FreeBSD will clear up all the required dependencies (pkg install py36-pillow), but it might not install the dev packages as well, so rather install the individual dependencies: pkg install jpeg-turbo tiff webp lcms2 freetype2 openjpeg harfbuzz fribidi libxcb
I ran into the same issue, but I already ran into a similar system dependency issue two times before, so I know where to look. This time, at least the documentation seems to be updated... I did not look until now, because the last two times not even that had been updated. Instead they were relying on the pywheel being prepared and ready for downloading.... Well, I was faster with my upgrade than the pywheel was finished with building, so my system tried to build the python package on its own and failed due to unmet dev library dependencies.
So I agree with you that this is actually 'a bug', but maintainers think differently, because in their opinion it is not a bug. There have been many issues in this bugtracker just about this. They also don't think it is necessary to point this out with a big red font on the release page. But I assume they just want you to run their HassOS or whatever it's called nowadays and not worry about it, because that thing will do anything on its own by pulling the appropriate and prepared docker image...
But being as stubborn like you are here:
I appreciate the effort by the way... I just don’t think this can be classified as a “user error”. The process of upgrading HA should pull in what it needs, or not upgrade. HA says the upgrade completed successfully, but it no longer boots after a “success”.
will not lead you anywhere. Because let me explain to you one simple fact:
Once you are inside a venv, it just can not magically pull in a system package. I mean why would you run it in a venv at all then? Apart from that you seem to isolate it even further from the main system by running it in some kind of jail.
No. pip can not install system packages. Not on Linux, Not on MacOS and surely not on FreeBSD. At least not without explicit commands.
You are welcome.
frenck
commented
4 years ago This is a system dependency, which Home Assistant cannot install or provide you automatically.
There is nothing for us to improve or fix on this and we do not control your system.
Closing this issue, as it is not a bug. The required packages have been listed in this issue.
makuser
commented
4 years ago There is nothing for us to improve or fix on this and we do not control your system.
See, that is the part on which I absolutely disagree.
You could improve communication with the users.
You could mention CLEARLY, that a new system dependency had been introduced by this release.
The issue as described here is a user error and I tried to explain it to the author, because it is a user error by the definition of not preparing the system to be able to run this application. But the actual underlaying problem is rather, that it is not being made easy to maintain a compatible system, due to lack of information.
The release posts on the forum are soo detailed, every single module change is summarized there. The upgrade to Pillow 7.2.0 was also mentioned. The result of it however was omitted. And THAT is the actual bug.
There needs to be a policy IMO, that such crucial information are mentioned in the release in a way that it can be found.
Of course, you might argue that I knew about the Pillow upgrade and that I could look up the dependencies for said package, but that is anything but user friendly.
So I am asking you @frenck, since you at least seem to have the permissions to close bugs on behalf of others, do you agree on the fact that it is user unfriendly and could easily be improved/rectified and could you help me bringing this issue forward to the appropriate team, or not?
I would definitely appreciate it A LOT.
frenck
commented
4 years ago See, that is the part on which I absolutely disagree.
We don't have to agree.
You could improve communication with the user
Feel free to update any of our communications in a PR, everything is open source.
Sure, it could be mentioned as a breaking change. I am sure that is more an honest oversight and not on purpose. Nevertheless, it isn't a bug in the core (where this issue is reported).
wormuths
commented
4 years ago Guys,
I'm not trying to start a war here. LOL
The issue is that as users, us "novice" tinkerers and the like, do not do things we don't understand. We read, we get it working, and we keep updated to correct issues and keep secure. I read all the breaking changes, did a backup, and updated like any good user should do. I rebooted, and the software I've come to rely on TO CONTROL MY HOME just gives me a "404: Not Found" error.
I've said it before and I will repeat it again. Any project that alienates it's users with endless breakage has a limited lifespan, and I really like Home Assistant. I contribute bugs because I'm not an expert on any of this, and that's all I can do to help. I started with Home Assistant when running in a virtual environment was the primary agreement on getting it on a system with horsepower for the future, and flexibility. It has separated a bit from that to a project that seems to want to pair with Raspberry Pi's almost exclusively. As someone with an always on, reliable NAS server, I chose to go the FreeBSD jail route. It is, in fact, what saved me from disaster. In this scenario, I simply clicked "restore snapshot" and the whole thing was back. I'm in this situation for a reason, but am by no means an expert on BSD, Python, etc...
Users like us appreciate the fact that the project has promised to continue to support Core, but a callous answer that "it's up to me to manage my system", while true, isn't good for the life of the project. Because as has been pointed out, it is open source and can be branched off when enough people get frustrated. And I think it's better to keep everyone working on one project, than fracturing things apart.
My suggestion is that if the "official" installation document gets an update, it be included in the release notes so people like myself don't find themselves broken.
Thanks for all the hard work you guys do, and the help. Now I have to get to installing some dependencies...
frenck
commented
4 years ago I'm not trying to start a war here. LOL
Me neither 👍
The issue is that as users, us "novice" tinkerers and the like, do not do things we don't understand.
I contribute bugs because I'm not an expert on any of this,
Really don't want to be *** right now, but running a virtual environment is considered and aimed towards developers/expert users. This also assumes some part of capability from the user of such a setup to be able to handle these things on their own more.
If that is not your cup of tea, I would not recommend running it in such a way and maybe consider a different installation method.
It has separated a bit from that to a project that seems to want to pair with Raspberry Pi's almost exclusively.
Maybe you want to review the options again, as that is a wrong assumption.
Nevertheless, these are more things to discuss on our support channels, like Discord or our community forums.
My suggestion is that if the "official" installation document gets an update
It had.
https://www.home-assistant.io/docs/installation/virtualenv/
Feel free to open up a PR on the release notes to include it (like I told @wormuths above as well, who decided to give a 👎 somehow?)
wormuths
commented
4 years ago Sorry, I meant if a Home Assistant update requires a different underlying OS dependency, then put it under breaking changes. I can manage the rest. I'm not an expert, but I'm not totally lost either. My confusion relies on where the updates and dependencies need to be applied. Keep in mind, I have to keep the FreeNAS system up to date, then update the OS in the jail running on FreeNAS, then keep Python up to date, and finally Home Assistant.
It can get a little nuts. LOL. A heads up is all I ask so I know when to look elsewhere.
Have a great weekend!
frenck
commented
4 years ago Sorry, I meant if a Home Assistant update requires a different underlying OS dependency, then put it under breaking changes.
Yes, I said to times now in this issue, feel free to open up a PR to do so. 👍
The problem
Upgrading from 114.3 to 115.2 caused a loss of all lovelace interfaces. The only thing presented once HA Core started was an error of "404: Not Found".
Environment
Problem-relevant
configuration.yamlIssue is not specific to an integration as far as I can tell.
Additional information
Was working fine until the update. Performed usual update steps, and this happened. I've rolled back to a snapshot to recover.