docker-compose fails to install on Pine A64 on DietPi 7.1.2

Yep. I figured that out in the meantime. Applied the sed command and re-ran the install.

Unfortunately it doesn’t finish. Hangs halfway through the install. The attached shows the CPU at 100% although the RAM is only at about 30% (2GB RAM).

Tried to re-run without success. Stops at the same spot. Is there a way for me to delete the local cache and download the packages again or is there anything else I could try?

this could take time while compiling. Let it run for 1 hour pls.

It ran for more than 2 hrs before I killed it. Looking at the resource monitor I still see CPU% and time incrementing. Does this mean the process still runs? How long can I expect this to run?

Also what about the cache? The log says Using cached ..... Could this be corrupt or do the packages automatically refresh every time I restart the process?

Restarted the installation (still running after 1hr 45) but found this error earlier on the console

      running build_ext
      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: Command errored out with exit status 1: /usr/bin/python3 -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-66i57p6p/cffi_6d177a9a6c0742e0b6d476b839622794/setup.py'"'"'; __file__='"'"'/tmp/pip-install-66i57p6p/cffi_6d177a9a6c0742e0b6d476b839622794/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' install --record /tmp/pip-record-759asbzg/install-record.txt --single-version-externally-managed --prefix /tmp/pip-build-env-0ekuz2br/overlay --compile --install-headers /tmp/pip-build-env-0ekuz2br/overlay/include/python3.5m/cffi Check the logs for full command output.
  ----------------------------------------

to clean the cache you could try running pip cache purge

Will do a test on my 64bit RPi4 as well now.

Ok. Let me know how you go.

As for my install it’s now running for a good 11 hrs :slight_smile: but still runs. My Internet connection is top (100Mbps) but it has been on the last step for at least 1 hr. Anyway I continue to let it run in hope it’ll finish in the next few days :rofl:

sorry for late response but got hijacked by my family :sunglasses:

11 hours is definitely way to long. Even on my old RPi1 it was finishing in less than 1 hour. Will run a test on my RPi4 64bit now.

That long time does not sound normal anymore. And the PINE A64 is not an RPi Zero, but quite capable.

The compilation error above indicates missing library headers:

apt install libffi-dev

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.

Collecting docker-compose
  Downloading docker_compose-1.29.1-py2.py3-none-any.whl (114 kB)

Same for docker

Collecting docker[ssh]>=5
  Downloading docker-5.0.0-py2.py3-none-any.whl (146 kB)

Better to reset the cached versions I would say.


MichaIng
On my RPi4 64bit, libffi-dev is/was not required.

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.

Will do a test now as well.

MichaIng
would it be an option to use --no-cache-dir while calling pip?


tfmeier
pls can you cancel your installation and try running following

pip3 install docker-compose --no-cache-dir

Thanks guys for the support. Doing the following the install went through

clear APT cache
sed -Ei 's@https://bootstrap\.pypa\.io/(3\.5/|)get-pip\.py@https://bootstrap.pypa.io/pip/\1get-pip.py@' /boot/dietpi/dietpi-software
apt install libffi-dev
install docker-compose

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

Are you running Debian Buster or Stretch? Because on Buster you should have a higher Python version.

The warning on Python 3.5 is actually correct as this is an old version

This is the output

root@DietPi:~# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
VERSION_CODENAME=stretch
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
root@DietPi:~#

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 :wink:

Not sure if possible but you should consider updating to Buster :thinking:

On my ARMv8 container it as well worked without libffi-dev
But was on Buster as well, will try on Stretch.

Issue verified on Stretch:

      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

Hmm, happy to do that as per my first post this Pine64 didn’t do anything other than collecting dust :slight_smile:

How would I upgrade to Buster? There was only 1 image for the Pine64

Hi,

basically you would have 2 options.

  1. download a new fresh Buster image and start a clean install from scratch https://dietpi.com/downloads/images/DietPi_PINEA64-ARMv8-Buster.7z

  2. 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. :wink:

I have rebuilt the Pine64 with the referenced Buster image. All went well (docker, docker-compose) without any errors. Thanks for the help again!

my pleasure