Hi Daniel,
Between this and the audio CD business, you are not having much luck.
Happes to me most days.
There may be a solution.
It is possible to build docker images for multiple architectures… see here
So if you put ddgr in docker image, you could build the docker image for arm64 for example.
You have to be able to install docker to run it, so not sure about your phone, but rpi and Termux should be ok.
Have you built a Dockerfile? It is not all that difficult.
Regards
Neville
Given that ddgr is hardware / CPU agnostic, is this relevant - sorry - I guess I should read this whole topic - but - I’m very much a TL;DR guy!
Hi Rosika,
Just one late thought.
This sort of problem comes from using an executable that is installed outside the package system. I am not saying dont do it,. Just making the point that it is the purpose of the packsge system to look after such issues. It cant help you if you operate outside it.
Sometimes we have to do an install manually, rather than as a package.
I have a printer with .deb file drivers. To put those drivers into Void I have to unpack the.deb file and copy various things into /usr/lib and /usr/bin. It works , but when Void does its upgrade, sometimes it removes some of my printer driver files, because the package manager sees they are not under its control, and deletes them.
I am going to have to try and install them in /usr/local instead.
So, you get the point? Only do it if you have to
Cheers
Neville
Well I thought you just proved it was not as agnostic as it seemed to be.
I agree, if it is a python script, it should be like a C program, you should be able to shift source code anywhere. There may still be porting issues, if it calls libraries.
So is it really agnostic? If so, you are right, it should not need a container to give it a protected environment
Cheers
Neville
You have a succint point there - its an alleged, platform agnostic, Python script, that
“seems to fail” (i.e. does it fail? Is “no result” a failure?) on ARM (armhf and arm64 / aarch64) but works perfectly adequatlely on x86_64… point taken…
So , only 2 options
If you want to fiddle with docker, I can make you a startup Dockerfile.
ddgr does not use the GUI so it would be quite simple.
I believe there is also a snap image of ddgr. Can you use snap in arm?
That would be easier than starting out with docker
Hi all, 
sorry I couldn´t reply earlier as I wasn´t online yesterday. 
That´s quite a detailed account of what you were doing and trying to achieve. Thanks a lot.
But I have to admit it seems so specific to me that I surely cannot be of much (or any) help. 
But @nevj to the rescue 
.
He is very knowledgeable indeed.
Still: I´ll keep trying to follow your path.
Thanks a lot Neville.
I see.Well, I´ve never tried that as I´m very satisfied with qemu/kvm, but I have surely heard of Gnome Boxes.
You´re welcome, Neville. I´ll be glad to help if I can … modest as my capabilities are in this respect.
I see. That´s certainly a good explanation.
I understand what you are saying and it makes perfect sense.
The problem as it presented istself just took me by surprise as I´ve been using ddgr for years now - always as a standalone executable - and there were never problems using it.
Therefore my guess: something fundemental must have chamged with the latest system update…
Yes, I think so. .
Thanks a lot.
Many greeting to you all 
Rosika 
From the ddgr Github site
Running standalone
ddgr is a standalone executable (and can run even on environments like Termux). From the containing directory:
$ ./ddgr
I expect it did not run because the python version in Termux is too old
I strongly suspect that’s not the case…
I just installed it via yum on a positvely ancient CentOS 7 machine which has an uptime of 2147 days - I’d suggest it’s versions of python would be yonks older than those in TermUX (which I’ve now managed to fix)…
╭─REDACTO@redacted ~
╰─➤ python --version
Python 2.7.5
╭─REDACTO@redacted ~
╰─➤ uptime 1 ↵
17:15:07 up 2147 days, 22:27, 3 users, load average: 0.02, 0.03, 0.05
╭─REDACTO@redacted ~
╰─➤ uname -a
Linux redacted 3.10.0-327.36.3.el7.x86_64 #1 SMP Mon Oct 24 16:09:20 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
╭─REDACTO@redacted ~
╰─➤ echo $((2147/365))
5
╭─REDACTO@redacted ~
╰─➤ ddgr monteverdi orfeo
1. Monteverdi's Orfeo: 'a brilliant and compelling fable to the ... [www.theguardian.com]
Monteverdi might be surprised to find himself hailed as the inventor of the opera, and he disclaimed
the role of revolutionary, but his Orfeo is a radical, innovative and extraordinary work that ...
...
10. Monteverdi — Orfeo ToolBox 8.1.0 documentation [www.orfeo-toolbox.org]
Monteverdi. Monteverdi is a satellite image viewer. Its main features are: Performance: Navigate
instantly in full size satellite images thanks to its hardware accelerated rendering engine. Compose
tiles or compare multiple images in a stack with rapid cycling and shader effects. Sensor geometry
support: View raw images directly in sensor geometry!
ddgr (? for help)
My own casual diagnostics have determined only one thing, one common thread, with my own kit, it only seems to be dodgy on arm (armhf - AND - arm64/aarch64)…
In Termux :
╭─u0_a206@localhost ~
╰─➤ uname -a
Linux localhost 4.9.118-23733710 #1 SMP PREEMPT Thu Jul 21 17:52:31 KST 2022 aarch64 Android
╭─u0_a206@localhost ~
╰─➤ uptime
17:27:58 up 5 days, 2:29, load average: 13.39, 13.51, 13.43
╭─u0_a206@localhost ~
╰─➤ python --version
Python 3.9.2
╭─u0_a206@localhost ~
╰─➤ ./ddgr monteverdi orfeo
No results.
ddgr (? for help)
I don’t know why the original authors bother to mention TermUX - as they don’t to list a method for installing it on TermUX…
Maybe it’s this (clutching at straws) :
python version in Termux is too old
I strongly suspect that’s not the case…
OK, here is what ddgr drags in when you install the package in Void… along with bash
expat-2.4.9_1: collecting files...
gdbm-1.23_1: collecting files...
libffi-3.3_2: collecting files...
ncurses-libs-6.3_3: collecting files...
libreadline8-8.1.000_1: collecting files...
libedit-20210910.3.1_1: collecting files...
sqlite-3.39.4_1: collecting files...
python3-3.10.7_1: collecting files...
ddgr-2.0_1: collecting files...
Are any of those missing in Termux?
I strongly suspect ddgr may assume the shell is bash.
Does Termux have bash?