Closed codemavn closed 8 months ago
From a touch of research, I think I could run:
apt-get install libffi libffi-dev
in the container, but not sure if that's going to get toasted the next time I pull a home bridge version.
I think your research is correct. Try installing the two packages and restart the plugin. Then let me know if it worked out for you. If that solves the problem, we should open an issue in the repo of the docker image and add these two packages by default.
Okay. Thanks heaps for that. The apt-get did resolve the issue (slightly diff to line above, see below), but there were a few more missing. Namely rust and open ssl. To resolve:
apt-get update
apt-get install libffi8 libffi-dev
pip install --upgrade pip
apt-get install cargo
apt-get install libssl-dev
note using rustc and rustup didn't do the trick, you have to use the cargo installe.
I think we should get this added to the docker container.
Now pardon me because it's been a minute since I was a techie so my docker memory eludes me, but I'm thinking an alternative could be to drop a shell script in the container config directory and getting compose to execute it. Don't know for sure if that's doable, though.
In any case, thanks for the great plugin. once I've overcome the above it's an outstanding implementation.
Thanks for the steps to fix. I will try to reproduce the scenario and will open an issue once I could successfully reproduce it on an ARM based system.
Just ran into this issue with my Hoobs box. Installing the aforementioned system packages with aptitude helped- except for cargo. I could not install cargo with a recent enough version via apt.
Rustup installation instructions (as instructed by cryptography python package) did not work.
I had to . /var/lib/hoobs/appletvenhancedbridge/appletv-enhanced/.venv/bin/activate
and then run
curl https://sh.rustup.rs -sSf | sh
export PATH=$PATH:~/.cargo/bin
Afterward, I ran pip install -r /usr/local/share/.cache/yarn/v6/npm-homebridge-appletv-enhanced-1.2.1-a803532ba99cf7090d2d7ff60c54e5895a7b879d-integrity/node_modules/homebridge-appletv-enhanced/requirements.txt
It stuck on cryptography for a while (30-60 minutes) but it worked this way. Not sure how to adjust to make this work programmatically.
@maxileith great. Let me know how you come along with that. Do you want me to close the issue or will you keep it open until you validate and find a universal solution?
@CardenB wow, >half an hour? interested to know the hardware in hoobs. I thought it took awhile on mine, but even then it was only about 5-7mins for the whole kit and kaboodle. in any case, glad you got it sorted.
@maxileith great. Let me know how you come along with that. Do you want me to close the issue or will you keep it open until you validate and find a universal solution?
Keep it open for now.
@codemavn Do you use a 32-bit installation?
FWIW I was installing on a 32 bit machine with 32 bit user space.
I saw many issues indicating that a 64 bit rust install was searched and that caused some confusion in the build process, but I wasn’t able to confirm this issue for myself.
What fixed was making sure the PATH referenced my recent rust install. For some reason I couldn’t get pip to read this path via the Apple TV plugin install, even when I had it added to the venv activate. I had to do it from the same shell session.
Okay, I have installed the plugin without any issues on a 64-bit arm system (with and without docker). Without any issues. Maybe I will try to do that with a 32-bit installation as well just to verify everything.
However, since even Raspberry's are 64-bit these days, I don't think we should bother the homebridge team with adding unwanted dependencies to homebridge.
What do you guys think about just adding 64-bit as a requirement to the plugins README?
Personally I think making platforms not supported more clear with a reason for each is ideal. For example, somewhere near the top of the readme:
CAUTION, a few exceptional platforms are UNSUPPORTED:
- 32 bit systems
- Issues indicate that python packages required for this plugin have difficulties with 32 bit systems and cannot be installed automatically. This includes 32 bit systems in a 64 bit userspace.
- HOOBS
- HOOBS is a 32 bit architecture and suffers from the above limitations.
- HOOBS has a different plugin system that prevents managing Apple TVs.
I think people are more likely to see this than the current "HOOBS not supported" towards the end of the README.
I wouldn't worry about validating on a 32 bit system. Very few platforms have this restriction and you're not really in control of how things are packaged anyway. It could easily be changed in the future, and clearly is not protected against 32 bit architectures.
You could also add a link to another section for the platforms you have tested against, since the homebridge verification doesn't currently protect against this.
@maxileith, apologies for the late reply. both my pi and the docker container are 32-bit:
$ uname -m
armv7l
I agree that we shouldn't worry about bothering the home bridge team. I think a message as per @CardenB posted above works fine, and perhaps with a link to this issue for workaround options.
Personally I think making platforms not supported more clear with a reason for each is ideal. For example, somewhere near the top of the readme:
CAUTION, a few exceptional platforms are UNSUPPORTED:
32 bit systems
- Issues indicate that python packages required for this plugin have difficulties with 32 bit systems and cannot be installed automatically. This includes 32 bit systems in a 64 bit userspace.
HOOBS
- HOOBS is a 32 bit architecture and suffers from the above limitations.
- HOOBS has a different plugin system that prevents managing Apple TVs.
I think people are more likely to see this than the current "HOOBS not supported" towards the end of the README.
I wouldn't worry about validating on a 32 bit system. Very few platforms have this restriction and you're not really in control of how things are packaged anyway. It could easily be changed in the future, and clearly is not protected against 32 bit architectures.
I have added a disclaimer similar to your suggestion to the README :)
Analysis
Thanks for the great plugin. I'm having an issue on first run in home bridge. Steps I took:
During startup, the plugin is throwing a fatal error, ffi.h: No such file or directory (on one of the pip installs, I think).
my setup:
From a touch of research, I think I could run:
apt-get install libffi libffi-dev
in the container, but not sure if that's going to get toasted the next time I pull a home bridge version.
Alternatively, I may just be doing something wrong or missing something somewhere
Expected Behavior
the plugin completes install and then discovers Apple TVs
Steps To Reproduce
Logs
Configuration
Environment
Additional Context
No response