Bonjour,
C’est assez rare mais je vais avoir besoin de votre pour faire des tests. J’ai récemment commencer a faire des tests sur debian 12 (donc php8). Globalement le core en alpha/beta ne pose pas de soucis tout marche, j’ai pas vu non plus de soucis sur les plugins que j’utilise au niveau php. Il est plus strict (une méthode appelé en static doit être en static par exemple). Mais bon php8 ne pose pas de gros soucis (d’ailleurs le market et tous les autres site jeedom y sont passé sans probleme).
Les soucis viennent (comme souvent j’ai envie de dire) de python. En debian 12 pip ne marche plus par défaut a moins d’etre en venv. Il faut donc passer par les packages python3-xyz (ex python3-requests), ya du boulot la mais c’est faisable sauf que souvent les packages existe pas avec cette méthode. J’arrive a contourner en intégrant directement le packages dans le plugin (c’est pas bien sur le papier mais en vrai vous allez voir que c’est utile). Par contre il y a un point assez genant c’est la crypto. Pycrypto n’existe plus depuis longtemps et est remplacé par pycryptodome, sous debian 12 il faut donc python3-pycryptodome. Jusque la pas de soucis sauf qu’ils ont changé le nom de module python ensuite de Crypto en Cryptodome. Il faut donc dans tous les plugins utilisant Crypto remplacé par Cryptodome, d’ou l’avantage de mettre les packages directement dans le plugin.
Tous ça pour dire que jusque la j’ai réussi a m’en sortir, va avoir du boulot mais c’est faisable et c’est pas la dessus que j’ai besoin d’aide. Mon soucis est plus ensuite. N’ayant que un Synology (et pas un foudre de guerre) je test tout en docker et je me suis dit que j’allais (enfin) faire ça propre en passant par docker compose donc avec un service db et un service http. Pas de soucis j’ai fait un docker spécial pour ça marche :
services:
db:
image: mariadb:latest
command:
- "--default-authentication-plugin=mysql_native_password"
- "--skip-name-resolve"
- "--key_buffer_size=16M"
- "--thread_cache_size=16"
- "--tmp_table_size=48M"
- "--max_heap_table_size=48M"
- "--query_cache_type=1"
- "--query_cache_size=32M"
- "--query_cache_limit=2M"
- "--query_cache_min_res_unit=3K"
- "--innodb_flush_method=O_DIRECT"
- "--innodb_flush_log_at_trx_commit=2"
- "--innodb_log_file_size=32M"
- "--innodb_large_prefix=on"
volumes:
- db:/var/lib/mysql
restart: always
environment:
- MYSQL_ROOT_PASSWORD=TODO
- MYSQL_DATABASE=jeedom
- MYSQL_USER=jeedom
- MYSQL_PASSWORD=TODO
expose:
- 3306
http:
image: jeedom/jeedom:4.4-http-bookworm
volumes:
- http:/var/www/html
tmpfs:
- /tmp/jeedom
ports:
- 52080:80
restart: always
environment:
- DB_HOST=db
- DB_USERNAME=jeedom
- DB_PASSWORD=TODO
- DB_NAME=jeedom
volumes:
db:
http:
Jeedom démarre bien, j’ai pu remettre mon backup et dans l’ensemble ça tourne (au passage aucun gain de perf du a php8). Par contre ensuite ça se complique :
- j’ai des messages qui indique la classe ajax introuvable, mais pas tout le temps… J’arrive pas a comprendre pourquoi dans le même code des fois il l’a trouve et desfois non. Surement un truc php8
- plus gênant j’ai des erreurs de timeout d’accès a la db
Pour c’est 2 soucis j’aimerais savoir si certain d’entre vous pouvez tester (en dev bien sur) et me dire si ils reproduisent car je soupçonne fortement un soucis plutôt coté synology (en particulier pour le timeout sur la db).
En vous remerciant d’avance
mais je regarderais en aout, et aussi pour générer une image jeedom sur debian 12 via le workflow github.