Je voudrai utiliser Tikka sur Raspberry Pi4 (Debian 11/bullseye avec 8Go de RAM) mais l’installation échoue.
Il semble en effet que Tikka 0.7.4 nécessite PyQt5 5.15.9 et mon installation Python 3.9 possède en standard la version 5.15.2.
Or la compilation n’aboutie pas lors de l’installation de PyQt5-5.15.9 que ce soit séparément ou pendant l’installation de Tikka (manque de RAM malgré une tentative avec l’ajout de 8Go de Swap en plus).
J’ai aussi essayé de revenir quelques versions en arrière mais cela ne change rien à cette dépendance.
Est-ce que je suis le premier à tenter cela ou est-ce que cela a été discuté dans une discussion ?
Y’a-t’il moyen d’y arriver ou c’est “mort” ?
Je sais qu’il reste une possibilité de cross compilation mais bon je préfère demander avant d’envisager cela car je fais partie de ceux qui voudraient bien que l’on puisse utiliser et développer la monnaie libre sur du matériel léger et abordable à tout point de vue. De plus pas sûr non plus que mon petit serveur AMD Ryzen 3 / 16Go puisse compiler PyQt5 pour armv8 !
Ce cas de figure est nouveau. Tu es le premier a faire une installation sur arm.
Les grosses bibliothèques compilées en C ou C++ fournissent des packages precompilés pour les palteformes courantes. Mais si la plateforme n’est pas supportée, alors elle se compile. Et là ça passe ou ça casse. Il faut alors trouver des astuces.
Je te propose de faire mon enquête sur ce problème et de revenir vers toi avec des pistes de solutions. Même si je ne possède pas de plateformes arm.
Merci pour ton aide.
Question bête: est-ce qu’il y a des fonctionnalités de PyQt5-5.15.9 qui sont obligatoires pour Tikka ou est-ce qu’on pourrait la faire tourner en 5.15.2.
Autrement-dit est-ce qu’on pourrai tenter de faire une branche git “armv8” avec une dépendance PyQt5-5.15.2 pour comment ça se passe sans rien toucher au reste ou c’est carrément hors de question ?
C’est pas impossible, c’est juste que j’ai passé une journée entière à mettre a jour l’image docker pour la CI dans cette version.
Donc faire un rollback est possible, mais demande du travail.
Par contre, Avoir deux branches a maintenir avec deux images docker et deux CI n’est pas souhaitable.
Essayons d’abord de trouver le package pour arm 8.
Je ne suis pas sûr que ce soit une si grosse duplication mais sur le principe je suis d’accord, ok.
Qui plus est j’ai testé avec tikka-builder en modifiant la version de PyQt5 et maintenant c’est le module yoyo-migrations-7.3.2 qui explose la RAM à la compilation…
La double CI mènera à deux packages à maintenir sur PyPI ! Alors que ce n’est pas un problème d’ARM, mais de distribution utilisée sur ton ARM.
Effectivement, compiler de grosses dépendances sur ARM pose des problèmes de mémoire.
Mais comme je le pensais, on peut trouver des packages pré-compilés. Pour Raspbian, par exemple :
Voici un site où on peut voir les versions existantes par distribution, PyQt 5.15.9 existe sur Raspbian testing:
A toi de trouver la bonne distribution pour faire tourner Tikka sur ton arm.
Si tu utilises Raspbian testing, tu ne devrais pas avoir de compilation pour Qt.
Il restera la version de Yoyo. Si tu as encore le problème on regardera quelle version il te faut.
Mais pour Yoyo, je dois mettre à jour avec la 8.2.0 semble-t-il
Ok mais je ne pensais pas vraiment à 2 CI à long terme mais à tester l’appli sur une branche git dans le but de voir si son comportement était ok dans un premier temps avec cette version.
Et si ça marche, on peut imaginer que le builder puisse prendre en entrée la version de base de python et de pyqt5 (FROM … ) pour travailler en s’adaptant aux binaires installés avec une seule CI.
C’était une idée que j’ai eu en voyant le tikka-builder, je laisse tomber c’est sans doute plus compliqué que ce que je pense et c’est toi l’expert sur Python et Tikka.
Je vais effectuer le passage en version testing ça résoudra le problème pour moi et ceux qui sont dans le même cas.
Je vous fait un retour sur cette solution dès que je peux.
Merci bien et bon dimanche
De mémoire, j’ai mis le builder à jour en 5.15.9 car mon dépôt avait fait l’upgrade (via poetry, car c’est une upgrade mineur sans conséquences) et donc le builder était trèèèèès long car il installait l’upgrade à chaque lancement…
Mais Tikka fonctionne très bien avec la version Qt 5.15.2. Si vraiment, vraiment, c’est impossible de faire tourner Tikka sur ARM en 5.15.9, je veux bien rollback. Mais tu connais les développeurs. On aime bien être à jour .
Non non laisse, je vais appliquer la solution pour moi dans un premier temps et ensuite je verrai s’il est possible de rendre tout ça plus fluide pour tous avec le minimum d’effort général (car le passage en testing n’est pas non plus anodin).
Retour sur l’installation de Tikka sur armhf/armv8 mais pas que.
Version courte:
Ca fonctionne après upgrade de ma distribution en Debian 12 (bookworm).
En effet la librairie système PyQt5 passe en 5.15.9.
Du moins jusqu’à tikka==0.7.4, car la 0.8.0 plante pour une autre raison de dépendance semble-t’il mais après lancement de l’application. Péripétie sur laquelle j’ai trouvé ce post: Error: No module named 'PyQt5.QtMultimedia' - Stack Overflow
Traceback (most recent call last):
File “/home/fabrice/Applications/tikka/venv/bin/tikka”, line 5, in
from tikka.main import main
File “/home/fabrice/Applications/tikka/venv/lib/python3.11/site-packages/tikka/main.py”, line 22, in
from tikka.slots.pyqt.main import PyQtMainApplication
File “/home/fabrice/Applications/tikka/venv/lib/python3.11/site-packages/tikka/slots/pyqt/main.py”, line 25, in
from tikka.slots.pyqt.windows.main import MainWindow
File “/home/fabrice/Applications/tikka/venv/lib/python3.11/site-packages/tikka/slots/pyqt/windows/main.py”, line 60, in
from tikka.slots.pyqt.windows.scan_qr_code import ScanQRCodeWindow
File “/home/fabrice/Applications/tikka/venv/lib/python3.11/site-packages/tikka/slots/pyqt/windows/scan_qr_code.py”, line 20, in
from PyQt5 import QtMultimedia
ImportError: cannot import name ‘QtMultimedia’ from ‘PyQt5’ (/usr/lib/python3/dist-packages/PyQt5/init.py
Version longue:
Ce n’était pas une mince affaire étant donné que l’upgrade de système génère son propre lot de problèmes (le repo “testing” revient en gros en fait à basculer sur la prochaine version “stable”).
Donc le nouveau système installe Python 3.11.
Le plus troublant c’est que maintenant pip refuse au premier abord d’installer quoi que ce soit sans obliger à travailler dans un environnement virtuel sous peine de casser l’installation système; ce qui est bien et recommandé partout mais ajoute une étape d’installation (cf. externally-managed-environments).
Ok.
Ce faisant il ne faut pas oublier l’option “--system-site-packages” qui permet de créer l’environnement virtuel à partir de l’environnement système, sinon pip va re-compiler PyQt5-5.15.9: retour au problème du début…à savoir l’impossibilité d’aboutir à cette compilation sur ARM !
Au final je pense malgré tout qu’il serait bien de faire 2 choses:
décrire les étapes de création d’un environnement virtuel pour installer l’application puisque c’est (très) fortement recommandé
modifier la dépendance de PyQt5 pour permettre l’utilisation d’une version >=5.15.2 et < 6.0 au lieu de ==5.15.9, donc la 5.15.2 pour ceux qui sont limités à celle-ci tant qu’il n’y a pas de problème bloquant sur cette version, et sinon la 5.15.9 et + pour les plus à jour.
A vous de voir, c’est un retour avant tout pour celles et ceux qui sont dans le même cas.
A+
D’une manière générale, Tikka est un client “riche” ou client “lourd”. Il profite donc au maximum du système de bureau sur lequel il est installé. il n’a pas vocation à tourner sur la plus petite machine possible, mais, au contraire, à s’enrichir de pleins de fonctionnalités avancées. La version 8 commence à exploiter cette philosophie avec des dépendances multimédias. A l’avenir, des fonctions de calculs utiliseront peut-être intensément le CPU ou GPU, des calculs de matrices, de chiffrement, de Toile de Confiance si besoin.
Bref, je considère qu’installer Tikka sur un RaspberryPI ou équivalent peut être intéressant, pour test, mais n’est pas l’objectif de Tikka. Ca fonctionne tant mieux. Sinon, tant pis…
N’hésite pas à utiliser la loupe pour chercher des infos sur ce forum (en haut à droite) Car c’est déjà le cas dans l’installation pour Linux décrite dans ce forum et aussi pour les devs dans le README du dépôt de Tikka. Mais comme c’est pénible à faire et à expliquer au alphatesteurs novices, j’ai trouvé pipx qui permet de s’en affranchir et rédigé un nouveau sujet sur ce forum à ce propos. Peux-tu essayer une installation avec pipx ?
Ok je vais voir ça.
Pour ton problème de dépendance, une piste :
I am seeing the same issue with pypi’s pyqt5 … libdeclarative_multimedia.so is linked against libQt5MultimediaQuick.so which isn’t bundled …
On a debian system this library is provided by the libqt5multimediaquick5 package
Merci pour la modification de version de PyQt5 un peu plus souple, c’est finalement le principal point de tout ça.
Sur pipx: j’avais essayé aussi il me semble et j’avais eu le même message sur le externally-managed-environments. En fait la doc existe bien pour créer un environnement virtuel, il faut juste le lier dans le paragraphe “install” comme préalable à mon avis.
Pour le reste je suis d’accord avec tout ce que tu défend, à la nuance prêt que je ne suis pas minimaliste au point de chercher à tout faire fonctionner sur le plus petit matériel possible car je ne considère pas que le dernier Raspberry Pi en version Pi4 avec 4 CPUs et 8 Go soit une si petite machine. Et ce n’est pas obligatoirement si obsolète au niveau système système, on l’a vu.
Autrement il est vrai on pourra se tourner vers un client plus léger, mais pour l’instant sur la v2 c’est limité justement !
Je ne sais pas s’il restera des spécificités après le soucis de libqt5multimediaquick5, mais s’il en reste je pense faire une mini doc spécifique d’installation arm que je te soumettrai pour Tikka et tikka-builder.
C’est étonnant, car même si pipx utilise pip, il se charge de l’environnement virtuel automatiquement. Il faudrait “debug” pipx et leur remonter le problème avec un ticket si pipx ne fonctionne pas sur Raspbian…
Où veux-tu que je mettes la doc précisément ? Le README du dépôt ?
[EDIT]
J’ai ajouté de la doc pour pipx et le virtualenv dans le README.md : https://git.duniter.org/clients/python/tikka/-/tree/fixes
Je continuerai à t’aider pour que Tikka fonctionne sur ARM. Et tes retours sont précieux ! Je précisais juste les limites de l’exercice et l’objectif de Tikka.
Merci pour ton aide sur ARM ! Je pense que les prochaines dépendances seront pour afficher des graphiques (mathplotlib ou autre). Mais elles seront moins pénibles à gérer que le multimédia. Donc on est tranquille pour un petit moment là.
Oui s’il faut une ligne ou deux dans le README directement.
Mais ce n’est pas urgent si ça fonctionne actuellement pour la majorité.
Je vais re-tester sur toutes les plateformes/versions pour voir si je peux minimiser au maximum les consignes d’installation pour tous et valider les pré-requis systèmes communs et ceux qui sont spécifiques.
Car pour l’instant je me retrouve avec ce message qui rebute un peu et qu’on ne peut éviter qu’avec l’inquiétante option --break-system-packages pipx:
× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
python3-xyz, where xyz is the package you are trying to
install.
If you wish to install a non-Debian-packaged Python package,
create a virtual environment using python3 -m venv path/to/venv.
Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
sure you have python3-full installed.
If you wish to install a non-Debian packaged Python application,
it may be easiest to use pipx install xyz, which will manage a
virtual environment for you. Make sure you have pipx installed.
See /usr/share/doc/python3.11/README.venv for more information.
note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.
fabrice@raspberrypi:~ $ python3 -m pip install --user --break-system-packages pipx
Looking in indexes: Simple index, piwheels - Simple index
Collecting pipx
Using cached https://www.piwheels.org/simple/pipx/pipx-1.2.0-py3-none-any.whl (57 kB)
Requirement already satisfied: argcomplete>=1.9.4 in ./.local/lib/python3.11/site-packages (from pipx) (2.1.1)
Requirement already satisfied: packaging>=20.0 in /usr/lib/python3/dist-packages (from pipx) (23.0)
Requirement already satisfied: userpath>=1.6.0 in ./.local/lib/python3.11/site-packages (from pipx) (1.8.0)
Requirement already satisfied: click in /usr/lib/python3/dist-packages (from userpath>=1.6.0->pipx) (8.1.3)
Installing collected packages: pipx
Successfully installed pipx-1.2.0
]
Je veux enquêter pour voir si c’est parce-que Arm et/ou parce-que Debian 12/bookworm dans le but de ne plus bloquer d’installation à l’avenir pour le plus grand nombre si c’est possible tout de même …!
Mais ce week-end pas le temps désolé, j’ai Ecotrail Paris (je suis coureur aussi).
A+
J’ai avancé un peu en particulier sur libqt5multimediaquick5.
En fait il y a plusieurs librairies qui manquent selon le système comme tu l’as dit dans le README sur la 0.8.2: libqt5multimedia5, libqt5multimediawidgets5…, mais j’ai trouvé un package qui fonctionne directement pour moi et qui semble installer le tout: python3-pyqt5.qtmultimedia.
Tikka 0.8.2 fonctionne bien ensuite pour la dernière version de Qt5 ET la dernière version de raspbian sur aarch64/armv8 sous debian 12. C’est top déjà.
En revanche l’ajout de QtMultimedia à partir de 0.8.0 a ajouté en même temps une dépendance sur une autre librairie (opencv-contrib-python-headless<5.0.0.0,>=4.7.0.72) qui demande à être compilée et qui bloque l’installation sur les petits systèmes non complètement à jour, donc retour au départ mais je n’ai pas terminé les essais sur celle-ci, disons que c’est en cours.
A suivre.
La lib multimedia de Qt se charge d’afficher l’image de la webcam et de dessiner un cadre autour du qrcode détecté. Open-cv se charge de détecter le qrcode et son contenu.
Pour info, j’expérimente des crashs avec la fonctionnalité webcam de Qt5 et @Pini aussi. Si je n’arrive pas à les résoudre, je verrais si je peux faire l’équivalent uniquement avec opencv. Car open-cv aussi peut ouvrir une fenêtre avec l’image de la webcam, en plus de détecter le qrcode.
.