Downgrade Docker to Python 3.5 to solve Segmentation Faults

[philhawthorne]

Description:

Downgrades the Dockerfiles used by Home Assistant to Python 3.5, after
Python 3.6 base image was causing segmentation faults.

See #7752

Checklist:

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated in home-assistant.github.io

If the code communicates with devices, web services, or third-party tools:

• Local tests with tox run successfully. Your PR cannot be merged unless tests pass
• New dependencies have been added to the REQUIREMENTS variable (example).
• New dependencies are only imported inside functions that use them (example).
• New dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
• New files were added to .coveragerc.

If the code does not interact with devices:

• Local tests with tox run successfully. Your PR cannot be merged unless tests pass
• Tests have been added to verify that the new code works.

[balloob]

So I'm not a big fan of this. By doing this, we're blocking our upgrade path in the future. Also, some people do not run into any segmentation errors so it is a dependency that is doing something wrong.

We should find the dependency that causes this instead and seeing what behavior causes it.

[philhawthorne]

Yeah totally understand.

Unfortunately though, it seems Home Assistant is unstable on Python 3.6 with the report by @AlexMekkering who isn't using Docker.

With Home Assistant shipping with 3.6, Docker users have no choice but to put up with segmentation faults until the dependency (or dependencies) are resolved. If someone wants to downgrade to a 3.5 image, they'll need to compile their own Dockerfiles.

I understand this is a blocker for future upgrades, but I feel we should have the 3.6 segmentation issues resolved before forcing 3.6 down on people. Of course, that leads to the question how do we test that the issue has been resolved unless we can replicate the problem. For that I'm unsure.

Unless there's a component that needs 3.6 today, I don't see why we shouldn't stick with 3.5 in this image, and then upgrade it once 3.6 is more widely tested and ironed out in other release channels.

[pvizeli]

I think the problem is that we can not use a linux distribution and pack a python 3.6 into this system and think it will work correct. Maby for a small software is that okay but we are to big.

A lot of People don't know it but the python from debian or alpine linux are not the mainstream release. He patch the code to work on his system: http://metadata.ftp-master.debian.org/changelogs/main/p/python3.5/python3.5_3.5.3-1_changelog

I think we need wait until Debian run stable on python 3.6 or we go to alpine Linux like hass.io. They run on python 3.5 but the next release will be python 3.6 (https://pkgs.alpinelinux.org/packages?name=python3&branch=edge&repo=&arch=&maintainer=). We can test it with alpine:edge I think that should be stable to work with homeassistant and is with python3.6 native.

[balloob]

We had this problem when we first introduced asyncio. It got fixed in https://bugs.python.org/issue26617 but it looks like that wasn't the only problem.

I'm going to merge this PR and would love for people that are experiencing the segfaults to help find the issue by running Python in debug mode with Gdb with Python extensions. https://wiki.python.org/moin/DebuggingWithGdb

[nunofgs]

FWIW, this PR also fixed #7733 for me.