as well the used components could be an issue. I see docker_compose used in quite some version from cache. Looks like all available version used. But it should be docker_compose-1.29.1-py2.py3-none-any.whl only.
Like it’s building all cached Docker Compose versions against all cached Docker wheels. Still the question why all of those have been cached in the first place.
Probably we should actively purge or skip the cache when calling pip, to avoid issues related to it. pip cache purge is actually for Python 2, so pip3 cache purge should have the intended effect.
libffi-dev is btw required for many other Python software, so it would not be that surprising. Strange however that it probably is the case for PINE A64 while not being the case for RPi 64-bit. Probably it also was for a specific Docker Compose (or Docker) version that is not used on successful installs.
and I was able to run docker-compose although the following warning appears
/usr/local/lib/python3.5/dist-packages/paramiko/transport.py:33: CryptographyDeprecationWarning: Python 3.5 support will be dropped in the next release of cryptography. Please upgrade your Python.
from cryptography.hazmat.backends import default_backend
Not sure what you’d have to do so that the docker-compose install works straight out of the box from the dietpi-software UI and this warning about Python 3.5 no longer appears.
If you make any changes and need me to re-run this I’m more than happy to do so
Yup Stretch. This is the old Debian version. Actual version is Buster. On Stretch, Python 3.5 is the latest available version and will not be updated anymore. Btw next Debian version, Bullseye, will be released this summer and Stretch becomes very old
Not sure if possible but you should consider updating to Buster
building '_cffi_backend' extension
creating build/temp.linux-aarch64-3.5
creating build/temp.linux-aarch64-3.5/c
aarch64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -g -fdebug-prefix-map=/build/python3.5-XIOK8o/python3.5-3.5.3=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -DUSE__THREAD -DHAVE_SYNC_SYNCHRONIZE -I/usr/include/ffi -I/usr/include/libffi -I/usr/include/python3.5m -c c/_cffi_backend.c -o build/temp.linux-aarch64-3.5/c/_cffi_backend.o
c/_cffi_backend.c:15:17: fatal error: ffi.h: No such file or directory
#include <ffi.h>
^
compilation terminated.
error: command 'aarch64-linux-gnu-gcc' failed with exit status 1
----------------------------------------
ERROR: Failed building wheel for cffi
ERROR: Failed to build one or more wheels
Traceback (most recent call last):
File "/usr/local/lib/python3.5/dist-packages/setuptools/installer.py", line 126, in fetch_build_egg
subprocess.check_call(cmd)
File "/usr/lib/python3.5/subprocess.py", line 271, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/usr/bin/python3', '-m', 'pip', '--disable-pip-version-check', 'wheel', '--no-deps', '-w', '/tmp/tmp492vv5zo', '--quiet', 'cffi>=1.4.1']' returned non-zero exit status 1
CFFI backend is compiled, requiring the FFI development headers.
Checked again on Stretch VM and ARMv7 to be sure, but I only on ARMv8 it needs to be compiled, else its available as pre-compiled wheel. I’ll add a fix to dietpi-software: https://github.com/MichaIng/DietPi/pull/4342
perform an in-place upgrade following this guide https://dietpi.com/forum/t/qbittorrent-version-shipping-with-dietpi/2326/9
originally the guide was intended for Raspberry Pi devices but with smaller adjustments on the apt source list’S, it should work on a Pine A64 as well. If all is working fine, Python should be updated to version 3.7 and I would recommend to reinstall Docker Compose after your system has been reboot.
dietpi-software reinstall 134
Disclaimer: Whatever you do, you will do it on your own risk. It’s highly recommended to do a full backup of your SD card before. Best would be to clone it, because the upgrade will touch nearly every installed packaged.
