New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incompatible PiWheels built wheels when on Debian Stretch or lower #25248
Comments
Did you install/update libssl-dev? |
update libssl-dev on rpi will not change anything
for me this issue broke also Xiaomi IR Remote component based on miio |
yeah, exactly. If you are on < 'buster' its broke. |
FWIW, I upgraded my test box running Python 3.7.3, and Debian 9.8, to 0.96. That has OpenSSL 1.1.0 and 1.0.2. I've signed it up for a trial Cloud account, and it has no issues.
I'll need to upgrade my test Pi to Python 3.7 before I can test that. |
Ok, my Pi sees the same error.
|
Seems to affect a number of components, all related to this OPENSSL issue. asuswrt xiaomi_miio broadlink |
I have seen that error before when a virtualenv was created and then python3 was updated underneath it. Are you using virtualenv? |
I am using virtualenv with python 3.7.3 |
I am not sure what you mean by this, yes. I created a new venv when I found out python3.5 was getting deprecated. what python3 do you refer to? The system one or python inside the venv? |
I'm using virtualenv with python 3.7.3. too. Upgraded python a few (HA) versions earlier, by the upgrade script (hassbian tools), but has worked fine till now. I thought this script also creates a new venv. |
When you create a virtualenv it copies the system one into the virtualenv, but it still depends on the system one. So if the system one changes but the one in the virtualenv doesn't you can get weird errors like this. I have actually seen it complain about OPENSSL_1_1_1 because of this on Ubuntu, but not on rasbpian/debian before. Can someone confirm they created a fresh virtualenv after upgrading to python 3.7 and then haven't done an apt upgrade that updated python recently and yet still have this problem? Can they also confirm the steps to create a fresh virtualenv they are using. |
If you are on amd64 and Debian/Ubuntu i'd expect it to use a wheel package which is precompiled with a suitable statically compiled version of OpenSSL actually in the wheel package. I'm not sure why that isnt happening - try 'pip install wheel; pip uninstall cryptography; pip install --no-cache cryptography' On raspbian the same is normally true because of piwheels. It looks like there is a piwheels version of cryptography here -> https://www.piwheels.org/project/cryptography/. The last time i installed raspbian there was a /etc/pip.conf which contained:
With that in place my pi stuff used the cryptography wheels and used the right openssl without having to install any openssl packages via apt. |
I used
to upgrade my venv. but yeah, the point is python is very different: In the venv:
The system:
|
@jurgenweber what happens if you try this in your venv:
And then start HA? |
yeah, same thing.
|
Did it definitely uninstall and reinstall? Might need to do a |
yeah, it did
|
And you are on buster? |
no. :) I did say that in my original message....
|
Nice edit ;) I guess i haven't memorised them... If you are on < buster and have your pip pointing at piwheels then pip will merrily install buster wheels that depend on buster versions of things, so you either have to upgrade to buster or turn off piwheels.org and reinstall cryptography. I guess If your pip is old enough it might not understand |
yeah, I figured the best way forward would be just to upgrade to the latest hassbian which is buster. a problem for tomorrow. THanks, tis late here. |
I built a fresh 3.7 venv for this test.
I followed https://www.home-assistant.io/docs/installation/raspberry-pi/, which says to install wheel. |
@DubhAd What version of Debian/Raspbian do you have on the pi? AIUI if its not buster then it wont work because the wheels for python 3.7 from piwheels.org assume you are on buster. You need to upgrade to buster or install with wheels switched off. |
9.8, so not Buster |
The reason why this broke, PiWheels builds wheels against Debian Buster, which has a newer glibc, which now causes issues if you are still on Debian Stretch. There are 2 possible option to get this fixed: Option 1: IMHO the best / future proof /preferred optionUpgrade your distribution to Debian Buster. After upgrade, everything works as intended. Pros: more future proof, Piwheels work. Steps:
Option 2:Disable Piwheels prebuild packages. Pros: Quick and easy. Steps:
|
Closing up this issue, since there is nothing left to do. See the answer above for a solution. |
yeah, I upgraded to Debian Buster and life is good again. :) Thanks team! |
Home Assistant release with the issue:
0.96.0
Last working Home Assistant release (if known):
0.95.4, but rollback does not work
Operating environment (Hass.io/Docker/Windows/etc.):
hassbian, python 3.7
Component/platform:
cloud
Description of problem:
Problem-relevant
configuration.yaml
entries and (fill out even if it seems unimportant):Traceback (if applicable):
Additional information:
I upgraded to 0.96.0, and there is no cloud.
I down graded
hassbian-config upgrade homeassistant=0.95.4
same problem.not sure what is going on here. nothing with ssl works now.
also
# cat /etc/debian_version 9.9
The text was updated successfully, but these errors were encountered: