erplibre/script/install/install_debian_dependency.sh

481 lines
21 KiB
Bash
Raw Normal View History

#!/usr/bin/env bash
. ./env_var.sh
[FIX] install: the EL9, EL10 and Fedora build chain "dnf install: error: unrecognized arguments" on AlmaLinux 10 and Rocky 10, on every call: PostgreSQL, build dependencies, pyenv. The tools group got away with its fallback, which made the trace misleading -- gcc installed, nothing after it did. "--skip-unavailable" is a dnf5 option, which the script's own comment already said while assuming it everywhere. Fedora 41+ ships dnf5, but EL9 and EL10 stay on dnf4, whose equivalent is "--setopt=strict=0". We now ask dnf what it understands instead of inferring it from the distribution. Three neighbouring fixes: the "c-development" group does not exist on EL, where it is called "development"; CRB is enabled through /usr/bin/crb; and g++ plus the missing headers are installed explicitly. Rust is added only where wheels are absent, and qpdf is built when the distribution ships one older than pikepdf demands. --- FR --- « dnf install: error: unrecognized arguments » sur AlmaLinux 10 et Rocky 10, à chaque appel : PostgreSQL, dépendances de compilation, pyenv. Le groupe d'outils s'en tirait par son repli, ce qui rendait la trace trompeuse — gcc installé, rien après lui. « --skip-unavailable » est une option de dnf5, ce que le commentaire du script disait déjà tout en la supposant partout. Fedora 41+ livre dnf5, mais EL9 et EL10 restent sur dnf4, dont l'équivalent est « --setopt=strict=0 ». On demande maintenant à dnf ce qu'il comprend plutôt que de le déduire de la distribution. Trois correctifs voisins : le groupe « c-development » n'existe pas sur EL, où il s'appelle « development » ; CRB s'active par /usr/bin/crb ; et g++ ainsi que les en-têtes manquants sont posés explicitement. Rust n'est ajouté que là où les roues manquent, et qpdf est compilé quand la distribution en livre un plus ancien que ce qu'exige pikepdf. Assisted-by: Claude Opus 5
2026-08-11 20:46:07 -04:00
. ./script/install/lib_qpdf.sh
[ADD] install s390x : batir PROJ quand la distribution est en retard Debian 13 installe ERPLibre de bout en bout ; Debian 12 s'arrete sur pyproj : ERROR: Minimum supported PROJ version is 9.4.0, installed version is 9.1.1 bookworm livre 9.1.1, trixie 9.6 — d'ou l'ecart entre les deux. La portee est etroite : sur amd64 et arm64, pyproj pose une roue manylinux qui EMBARQUE sa propre PROJ, et la version du systeme n'entre pas en jeu. s390x n'a pas de roue et compile contre celle du systeme. lib_proj.sh est le calque de lib_qpdf.sh, meme motif et memes garde-fous : seuil, comparaison qui complete les composantes manquantes — « sort -V » classe 9.4 avant 9.4.0 — installation dans /usr/local, declaration a ld.so, et jamais de code non nul pour ne pas masquer ce que pyproj dira lui-meme. L'appel reste sous la garde s390x, verifie. --- EN --- Debian 13 installs ERPLibre end to end; Debian 12 stops on pyproj: ERROR: Minimum supported PROJ version is 9.4.0, installed version is 9.1.1 bookworm ships 9.1.1, trixie 9.6 — hence the gap between the two. The scope is narrow: on amd64 and arm64 pyproj lays down a manylinux wheel that BUNDLES its own PROJ, and the system version never comes into play. s390x has no wheel and builds against the system one. lib_proj.sh mirrors lib_qpdf.sh, same pattern and same guards: a threshold, a comparison that pads missing components — "sort -V" ranks 9.4 before 9.4.0 — installation into /usr/local, an ld.so declaration, and never a non-zero exit so as not to mask what pyproj itself will say. The call stays under the s390x guard, verified. Assisted-by: Claude Opus 5 (cherry picked from commit f779702b61ff6405bdd7efabaa1f5bac09e1166b)
2026-08-14 02:19:41 -04:00
. ./script/install/lib_proj.sh
[FIX] install s390x: the compiler was killed for lack of memory matplotlib dies on "c++: fatal error: Killed signal terminated program cc1plus". "Killed" is a SIGKILL: the kernel's OOM killer, and nothing in the message names memory. A single matplotlib source file asks cc1plus for up to 2.5 GiB. Two causes compound. The VM is small -- the catalogue starts at 1 or 2 GiB -- and every build backend launches nproc compilations in parallel, each with its own cc1plus. Six cores exhaust 8 GiB. Hence two answers. A swap file tops memory up to 8 GiB, never taking more than half the free disk nor touching fstab -- a declared and missing swap degrades boot. And parallelism is bounded by actual memory, 2 GiB per task. ninja has no parallelism environment variable, but meson-python reads "NINJA", the executable PATH -- verified in mesonpy 0.20. We point it at a wrapper that adds the -j. That is what saves matplotlib; MAKEFLAGS and CMAKE_BUILD_PARALLEL_LEVEL cover the rest. --- FR --- matplotlib s'arrête sur « c++: fatal error: Killed signal terminated program cc1plus ». « Killed » est un SIGKILL : c'est le tueur du noyau, et rien dans le message ne nomme la mémoire. Un seul fichier de matplotlib demande jusqu'à 2,5 Gio à cc1plus. Deux causes se cumulent. La VM est petite — le catalogue démarre à 1 ou 2 Gio — et chaque moteur de build lance nproc compilations en parallèle, chacune avec son cc1plus. Six cœurs épuisent 8 Gio. D'où deux réponses. Un fichier d'échange complète la mémoire jusqu'à 8 Gio, sans jamais prendre plus de la moitié du disque libre ni toucher à fstab — un swap déclaré et disparu dégrade le démarrage. Et le parallélisme est borné d'après la mémoire réelle, 2 Gio par tâche. ninja n'a aucune variable de parallélisme, mais meson-python lit « NINJA », le CHEMIN de l'exécutable — vérifié dans mesonpy 0.20. On y met une enveloppe qui ajoute le -j. C'est ce qui sauve matplotlib ; MAKEFLAGS et CMAKE_BUILD_PARALLEL_LEVEL couvrent les autres. Assisted-by: Claude Opus 5
2026-08-12 02:56:18 -04:00
. ./script/install/lib_lowmem.sh
EL_USER=${USER}
#EL_INSTALL_WKHTMLTOPDF="True"
# apt-get qui ATTEND le verrou (jusqu'à 10 min) : sur une image cloud fraîche,
# cloud-init / unattended-upgrades tiennent souvent le verrou apt au 1er boot
# (« Could not get lock » -> échec de l'install). DPkg::Lock::Timeout patiente.
APT_GET="sudo apt-get -o DPkg::Lock::Timeout=600"
##
### WKHTMLTOPDF download links
## === Ubuntu Focal x64 === (for other distributions please replace these two links,
## in order to have correct version of wkhtmltopdf installed, for a danger note refer to
## https://github.com/odoo/odoo/wiki/Wkhtmltopdf ):
# Ubuntu 20.04
[FIX] install : os-release au lieu de lsb_release, collision d'IP mieux vue Deux echecs distincts sur les VM Debian s390x posees par l'installateur. lsb_release vient du paquet lsb-release, livre avec la tache « standard ». Les images cloud l'ont ; une Debian posee par debian-installer, non. Les trois variables devenaient VIDES et le script concluait « Your version of Ubuntu is not supported » sur une Debian. /etc/os-release appartient a systemd, il est toujours la, et donne ID, VERSION_ID et VERSION_CODENAME sans rien installer. L'autre echec etait pire : l'adresse fixe choisie appartenait deja a une machine du parc, et l'installation ERPLibre s'est deroulee SUR CETTE DERNIERE. Le journal ne le disait qu'a demi-mot — « git is already the newest version », impossible sur un systeme que d-i vient de poser. Un essai sur le port 22 avec 0,4 s laissait passer toute machine eteinte ou filtree. On interroge desormais le voisinage ARP, puis ICMP, puis SSH. --- EN --- Two distinct failures on Debian s390x VMs laid down by the installer. lsb_release comes from the lsb-release package, shipped with the "standard" task. Cloud images have it; a Debian installed by debian-installer does not. All three variables came out EMPTY and the script concluded "Your version of Ubuntu is not supported" on a Debian. /etc/os-release belongs to systemd, is always there, and gives ID, VERSION_ID and VERSION_CODENAME without installing anything. The other failure was worse: the chosen static address already belonged to a machine in the fleet, and the ERPLibre install ran ON THAT ONE. The log only hinted at it — "git is already the newest version", impossible on a system d-i just laid down. A port-22 probe with 0.4 s let through any machine that was off or filtered. We now check the ARP neighbourhood, then ICMP, then SSH. Assisted-by: Claude Opus 5 (cherry picked from commit c73db1642a676ece1a06cdbdac3e9cfa5b526f3c)
2026-08-14 00:46:22 -04:00
# /etc/os-release D'ABORD, lsb_release seulement en repli.
#
# « lsb_release » vient du paquet lsb-release, qui arrive avec la tâche
# « standard ». Les images cloud l'ont ; une Debian posée par
# debian-installer, non. Les trois variables devenaient alors VIDES, et le
# script concluait « Your version of Ubuntu is not supported » sur une Debian
# — vécu sur s390x, la seule architecture qui passe par l'installateur.
#
# /etc/os-release, lui, appartient à systemd et est toujours là. Il donne
# ID=debian, VERSION_ID=13 et VERSION_CODENAME=trixie sans rien installer.
if [[ -r /etc/os-release ]]; then
# Sous-shell : « source » importerait NAME, PRETTY_NAME et le reste dans
# un script qui n'en veut pas.
UBUNTU_VERSION=$(. /etc/os-release && echo "${VERSION_ID}")
OS=$(. /etc/os-release && echo "${ID}")
# lsb_release rend « Ubuntu » et « Debian » ; os-release rend « ubuntu » et
# « debian ». Les comparaisons plus bas attendent la première forme.
OS="${OS^}"
else
UBUNTU_VERSION=$(lsb_release -rs)
OS=$(lsb_release -si)
fi
[UPD] support: drop Ubuntu 20.04/22.04, add AlmaLinux and Rocky Ubuntu 20.04 and 22.04 leave EVERY architecture, not just s390x. pikepdf needs qpdf 12.2, whose build requires C++20, while focal ships GCC 9 and publishes no g++-10 for s390x at all. Python 3.8, node 10, cargo 0.67 and OpenSSL 1.1.1 each had a workaround; the pile of them did not. 18.04 follows, already off the lists. The refusal lands before any apt, this script also serving existing machines. AlmaLinux 9 and 10, Rocky 9 and 10 join the catalog on all four architectures: the twelve "latest" URLs were opened, with no index to parse unlike Fedora. They would have booted unreachable though -- the cloud-config forced "groups: users, sudo", but the RHEL family has no sudo group, only wheel, and an unknown group makes useradd fail, hence no password and no key. The very trap already known for Debian, repeated elsewhere. Host side, EPEL and CRB are enabled: without them most -devel packages are missing, silently. The server / graphical choice gains Cinnamon, the Linux Mint desktop, from the distribution's own repositories. Mint's repository is set aside: plain HTTP, and i386/amd64 only, which would rule out arm64 and s390x. Along the way, dnf now installs an ENVIRONMENT rather than a group -- "gnome-desktop" brings gdm and gnome-shell but not base-x, hence no X server. --- FR --- Ubuntu 20.04 et 22.04 partent de TOUTES les architectures, pas seulement de s390x. pikepdf réclame qpdf 12.2, dont la compilation exige C++20, quand focal livre GCC 9 et ne publie même pas de g++-10 pour s390x. Python 3.8, node 10, cargo 0.67 et OpenSSL 1.1.1 avaient chacun leur contournement ; leur accumulation, non. 18.04 suit, déjà hors des listes. Le refus tombe avant tout apt, ce script servant aussi les machines existantes. AlmaLinux 9 et 10, Rocky 9 et 10 entrent au catalogue, sur les quatre architectures : les douze URL « latest » ont été ouvertes, aucun index à analyser contrairement à Fedora. Elles auraient pourtant démarré inaccessibles — le cloud-config imposait « groups: users, sudo », or la famille RHEL n'a pas de groupe sudo mais wheel, et un groupe inconnu fait échouer useradd, donc ni mot de passe ni clé. C'est le piège déjà connu pour Debian, reproduit ailleurs. Côté hôte, EPEL et CRB sont activés : sans eux la plupart des -devel manquent, en silence. Le choix serveur / graphique gagne Cinnamon, le bureau de Linux Mint, depuis les dépôts de la distribution. Le dépôt de Mint lui-même est écarté : il est en HTTP nu et ne publie que i386 et amd64, ce qui exclurait arm64 et s390x. Au passage, dnf installe désormais un ENVIRONNEMENT et non un groupe — « gnome-desktop » apporte gdm et gnome-shell mais pas base-x, donc pas de serveur X. Assisted-by: Claude Opus 5
2026-08-11 18:46:11 -04:00
# Ubuntu 18.04, 20.04 et 22.04 ne sont plus supportées, sur AUCUNE
# architecture. Le mur le plus net est pikepdf, qui réclame qpdf >= 12.2,
# lui-même en C++20 : focal livre GCC 9 et ne publie même pas de g++-10 pour
# s390x. S'y ajoutaient Python 3.8 à l'amorçage, node 10, cargo 0.67 et
# OpenSSL 1.1.1 — chacun avait son contournement, l'accumulation non.
#
# Le refus est ICI, avant tout le reste : ce script tourne aussi sur une
# machine existante, pas seulement sur une VM fraîchement déployée.
if [[ "${OS}" == "Ubuntu" ]]; then
[UPD] support: drop Ubuntu 20.04/22.04, add AlmaLinux and Rocky Ubuntu 20.04 and 22.04 leave EVERY architecture, not just s390x. pikepdf needs qpdf 12.2, whose build requires C++20, while focal ships GCC 9 and publishes no g++-10 for s390x at all. Python 3.8, node 10, cargo 0.67 and OpenSSL 1.1.1 each had a workaround; the pile of them did not. 18.04 follows, already off the lists. The refusal lands before any apt, this script also serving existing machines. AlmaLinux 9 and 10, Rocky 9 and 10 join the catalog on all four architectures: the twelve "latest" URLs were opened, with no index to parse unlike Fedora. They would have booted unreachable though -- the cloud-config forced "groups: users, sudo", but the RHEL family has no sudo group, only wheel, and an unknown group makes useradd fail, hence no password and no key. The very trap already known for Debian, repeated elsewhere. Host side, EPEL and CRB are enabled: without them most -devel packages are missing, silently. The server / graphical choice gains Cinnamon, the Linux Mint desktop, from the distribution's own repositories. Mint's repository is set aside: plain HTTP, and i386/amd64 only, which would rule out arm64 and s390x. Along the way, dnf now installs an ENVIRONMENT rather than a group -- "gnome-desktop" brings gdm and gnome-shell but not base-x, hence no X server. --- FR --- Ubuntu 20.04 et 22.04 partent de TOUTES les architectures, pas seulement de s390x. pikepdf réclame qpdf 12.2, dont la compilation exige C++20, quand focal livre GCC 9 et ne publie même pas de g++-10 pour s390x. Python 3.8, node 10, cargo 0.67 et OpenSSL 1.1.1 avaient chacun leur contournement ; leur accumulation, non. 18.04 suit, déjà hors des listes. Le refus tombe avant tout apt, ce script servant aussi les machines existantes. AlmaLinux 9 et 10, Rocky 9 et 10 entrent au catalogue, sur les quatre architectures : les douze URL « latest » ont été ouvertes, aucun index à analyser contrairement à Fedora. Elles auraient pourtant démarré inaccessibles — le cloud-config imposait « groups: users, sudo », or la famille RHEL n'a pas de groupe sudo mais wheel, et un groupe inconnu fait échouer useradd, donc ni mot de passe ni clé. C'est le piège déjà connu pour Debian, reproduit ailleurs. Côté hôte, EPEL et CRB sont activés : sans eux la plupart des -devel manquent, en silence. Le choix serveur / graphique gagne Cinnamon, le bureau de Linux Mint, depuis les dépôts de la distribution. Le dépôt de Mint lui-même est écarté : il est en HTTP nu et ne publie que i386 et amd64, ce qui exclurait arm64 et s390x. Au passage, dnf installe désormais un ENVIRONNEMENT et non un groupe — « gnome-desktop » apporte gdm et gnome-shell mais pas base-x, donc pas de serveur X. Assisted-by: Claude Opus 5
2026-08-11 18:46:11 -04:00
case "${UBUNTU_VERSION}" in
18.04 | 20.04 | 22.04)
echo "Ubuntu ${UBUNTU_VERSION} n'est plus supporte par ERPLibre :"
echo " sa chaine d'outils est trop ancienne (pikepdf exige qpdf 12.2,"
echo " compile en C++20, quand cette version livre GCC 9)."
echo " Utilisez Ubuntu 24.04, 25.10 ou 26.04."
exit 1
;;
esac
fi
if [[ "${OS}" == "Ubuntu" ]]; then
# wkhtmltopdf ne publie pas de build par version d'Ubuntu ; le .deb
# « jammy » est le plus récent et fonctionne de 24.04 à 26.04 et au-delà.
WKHTMLTOX_X64=https://github.com/wkhtmltopdf/packaging/releases/download/0.12.6.1-3/wkhtmltox_0.12.6.1-3.jammy_amd64.deb
elif [[ "${OS}" == "Linuxmint" ]]; then
[UPD] support: drop Ubuntu 20.04/22.04, add AlmaLinux and Rocky Ubuntu 20.04 and 22.04 leave EVERY architecture, not just s390x. pikepdf needs qpdf 12.2, whose build requires C++20, while focal ships GCC 9 and publishes no g++-10 for s390x at all. Python 3.8, node 10, cargo 0.67 and OpenSSL 1.1.1 each had a workaround; the pile of them did not. 18.04 follows, already off the lists. The refusal lands before any apt, this script also serving existing machines. AlmaLinux 9 and 10, Rocky 9 and 10 join the catalog on all four architectures: the twelve "latest" URLs were opened, with no index to parse unlike Fedora. They would have booted unreachable though -- the cloud-config forced "groups: users, sudo", but the RHEL family has no sudo group, only wheel, and an unknown group makes useradd fail, hence no password and no key. The very trap already known for Debian, repeated elsewhere. Host side, EPEL and CRB are enabled: without them most -devel packages are missing, silently. The server / graphical choice gains Cinnamon, the Linux Mint desktop, from the distribution's own repositories. Mint's repository is set aside: plain HTTP, and i386/amd64 only, which would rule out arm64 and s390x. Along the way, dnf now installs an ENVIRONMENT rather than a group -- "gnome-desktop" brings gdm and gnome-shell but not base-x, hence no X server. --- FR --- Ubuntu 20.04 et 22.04 partent de TOUTES les architectures, pas seulement de s390x. pikepdf réclame qpdf 12.2, dont la compilation exige C++20, quand focal livre GCC 9 et ne publie même pas de g++-10 pour s390x. Python 3.8, node 10, cargo 0.67 et OpenSSL 1.1.1 avaient chacun leur contournement ; leur accumulation, non. 18.04 suit, déjà hors des listes. Le refus tombe avant tout apt, ce script servant aussi les machines existantes. AlmaLinux 9 et 10, Rocky 9 et 10 entrent au catalogue, sur les quatre architectures : les douze URL « latest » ont été ouvertes, aucun index à analyser contrairement à Fedora. Elles auraient pourtant démarré inaccessibles — le cloud-config imposait « groups: users, sudo », or la famille RHEL n'a pas de groupe sudo mais wheel, et un groupe inconnu fait échouer useradd, donc ni mot de passe ni clé. C'est le piège déjà connu pour Debian, reproduit ailleurs. Côté hôte, EPEL et CRB sont activés : sans eux la plupart des -devel manquent, en silence. Le choix serveur / graphique gagne Cinnamon, le bureau de Linux Mint, depuis les dépôts de la distribution. Le dépôt de Mint lui-même est écarté : il est en HTTP nu et ne publie que i386 et amd64, ce qui exclurait arm64 et s390x. Au passage, dnf installe désormais un ENVIRONNEMENT et non un groupe — « gnome-desktop » apporte gdm et gnome-shell mais pas base-x, donc pas de serveur X. Assisted-by: Claude Opus 5
2026-08-11 18:46:11 -04:00
# Sans « else », toute Mint autre que 22.3 laissait WKHTMLTOX_X64 VIDE, et
# gdebi etait appele sans fichier. Mint 22.x repose sur noble : meme .deb.
WKHTMLTOX_X64=https://github.com/wkhtmltopdf/packaging/releases/download/0.12.6.1-3/wkhtmltox_0.12.6.1-3.jammy_amd64.deb
2022-12-21 02:22:39 -05:00
elif [[ "${OS}" == "Debian" ]]; then
# bookworm (12), trixie (13) et au-delà : wkhtmltopdf ne publie pas de build
# au-delà de « bookworm » -> on prend bookworm, le plus récent.
WKHTMLTOX_X64=https://github.com/wkhtmltopdf/packaging/releases/download/0.12.6.1-3/wkhtmltox_0.12.6.1-3.bookworm_amd64.deb
2024-02-06 21:26:49 -05:00
elif [[ "${OS}" == *"Ubuntu"* ]]; then
[UPD] support: drop Ubuntu 20.04/22.04, add AlmaLinux and Rocky Ubuntu 20.04 and 22.04 leave EVERY architecture, not just s390x. pikepdf needs qpdf 12.2, whose build requires C++20, while focal ships GCC 9 and publishes no g++-10 for s390x at all. Python 3.8, node 10, cargo 0.67 and OpenSSL 1.1.1 each had a workaround; the pile of them did not. 18.04 follows, already off the lists. The refusal lands before any apt, this script also serving existing machines. AlmaLinux 9 and 10, Rocky 9 and 10 join the catalog on all four architectures: the twelve "latest" URLs were opened, with no index to parse unlike Fedora. They would have booted unreachable though -- the cloud-config forced "groups: users, sudo", but the RHEL family has no sudo group, only wheel, and an unknown group makes useradd fail, hence no password and no key. The very trap already known for Debian, repeated elsewhere. Host side, EPEL and CRB are enabled: without them most -devel packages are missing, silently. The server / graphical choice gains Cinnamon, the Linux Mint desktop, from the distribution's own repositories. Mint's repository is set aside: plain HTTP, and i386/amd64 only, which would rule out arm64 and s390x. Along the way, dnf now installs an ENVIRONMENT rather than a group -- "gnome-desktop" brings gdm and gnome-shell but not base-x, hence no X server. --- FR --- Ubuntu 20.04 et 22.04 partent de TOUTES les architectures, pas seulement de s390x. pikepdf réclame qpdf 12.2, dont la compilation exige C++20, quand focal livre GCC 9 et ne publie même pas de g++-10 pour s390x. Python 3.8, node 10, cargo 0.67 et OpenSSL 1.1.1 avaient chacun leur contournement ; leur accumulation, non. 18.04 suit, déjà hors des listes. Le refus tombe avant tout apt, ce script servant aussi les machines existantes. AlmaLinux 9 et 10, Rocky 9 et 10 entrent au catalogue, sur les quatre architectures : les douze URL « latest » ont été ouvertes, aucun index à analyser contrairement à Fedora. Elles auraient pourtant démarré inaccessibles — le cloud-config imposait « groups: users, sudo », or la famille RHEL n'a pas de groupe sudo mais wheel, et un groupe inconnu fait échouer useradd, donc ni mot de passe ni clé. C'est le piège déjà connu pour Debian, reproduit ailleurs. Côté hôte, EPEL et CRB sont activés : sans eux la plupart des -devel manquent, en silence. Le choix serveur / graphique gagne Cinnamon, le bureau de Linux Mint, depuis les dépôts de la distribution. Le dépôt de Mint lui-même est écarté : il est en HTTP nu et ne publie que i386 et amd64, ce qui exclurait arm64 et s390x. Au passage, dnf installe désormais un ENVIRONNEMENT et non un groupe — « gnome-desktop » apporte gdm et gnome-shell mais pas base-x, donc pas de serveur X. Assisted-by: Claude Opus 5
2026-08-11 18:46:11 -04:00
echo "Your version of Ubuntu is not supported, only support 24.04, 25.10 and 26.04"
WKHTMLTOX_X64=https://github.com/wkhtmltopdf/packaging/releases/download/0.12.6.1-3/wkhtmltox_0.12.6.1-3.jammy_amd64.deb
else
[UPD] support: drop Ubuntu 20.04/22.04, add AlmaLinux and Rocky Ubuntu 20.04 and 22.04 leave EVERY architecture, not just s390x. pikepdf needs qpdf 12.2, whose build requires C++20, while focal ships GCC 9 and publishes no g++-10 for s390x at all. Python 3.8, node 10, cargo 0.67 and OpenSSL 1.1.1 each had a workaround; the pile of them did not. 18.04 follows, already off the lists. The refusal lands before any apt, this script also serving existing machines. AlmaLinux 9 and 10, Rocky 9 and 10 join the catalog on all four architectures: the twelve "latest" URLs were opened, with no index to parse unlike Fedora. They would have booted unreachable though -- the cloud-config forced "groups: users, sudo", but the RHEL family has no sudo group, only wheel, and an unknown group makes useradd fail, hence no password and no key. The very trap already known for Debian, repeated elsewhere. Host side, EPEL and CRB are enabled: without them most -devel packages are missing, silently. The server / graphical choice gains Cinnamon, the Linux Mint desktop, from the distribution's own repositories. Mint's repository is set aside: plain HTTP, and i386/amd64 only, which would rule out arm64 and s390x. Along the way, dnf now installs an ENVIRONMENT rather than a group -- "gnome-desktop" brings gdm and gnome-shell but not base-x, hence no X server. --- FR --- Ubuntu 20.04 et 22.04 partent de TOUTES les architectures, pas seulement de s390x. pikepdf réclame qpdf 12.2, dont la compilation exige C++20, quand focal livre GCC 9 et ne publie même pas de g++-10 pour s390x. Python 3.8, node 10, cargo 0.67 et OpenSSL 1.1.1 avaient chacun leur contournement ; leur accumulation, non. 18.04 suit, déjà hors des listes. Le refus tombe avant tout apt, ce script servant aussi les machines existantes. AlmaLinux 9 et 10, Rocky 9 et 10 entrent au catalogue, sur les quatre architectures : les douze URL « latest » ont été ouvertes, aucun index à analyser contrairement à Fedora. Elles auraient pourtant démarré inaccessibles — le cloud-config imposait « groups: users, sudo », or la famille RHEL n'a pas de groupe sudo mais wheel, et un groupe inconnu fait échouer useradd, donc ni mot de passe ni clé. C'est le piège déjà connu pour Debian, reproduit ailleurs. Côté hôte, EPEL et CRB sont activés : sans eux la plupart des -devel manquent, en silence. Le choix serveur / graphique gagne Cinnamon, le bureau de Linux Mint, depuis les dépôts de la distribution. Le dépôt de Mint lui-même est écarté : il est en HTTP nu et ne publie que i386 et amd64, ce qui exclurait arm64 et s390x. Au passage, dnf installe désormais un ENVIRONNEMENT et non un groupe — « gnome-desktop » apporte gdm et gnome-shell mais pas base-x, donc pas de serveur X. Assisted-by: Claude Opus 5
2026-08-11 18:46:11 -04:00
echo "Your version of Ubuntu is not supported, only support 24.04, 25.10 and 26.04"
2022-12-21 00:25:29 -05:00
exit 1
fi
#--------------------------------------------------
# Mainframe 390x
#--------------------------------------------------
if [ "$(uname -m)" = "s390x" ]; then
echo "Arch s390x detected"
[FIX] install s390x: the compiler was killed for lack of memory matplotlib dies on "c++: fatal error: Killed signal terminated program cc1plus". "Killed" is a SIGKILL: the kernel's OOM killer, and nothing in the message names memory. A single matplotlib source file asks cc1plus for up to 2.5 GiB. Two causes compound. The VM is small -- the catalogue starts at 1 or 2 GiB -- and every build backend launches nproc compilations in parallel, each with its own cc1plus. Six cores exhaust 8 GiB. Hence two answers. A swap file tops memory up to 8 GiB, never taking more than half the free disk nor touching fstab -- a declared and missing swap degrades boot. And parallelism is bounded by actual memory, 2 GiB per task. ninja has no parallelism environment variable, but meson-python reads "NINJA", the executable PATH -- verified in mesonpy 0.20. We point it at a wrapper that adds the -j. That is what saves matplotlib; MAKEFLAGS and CMAKE_BUILD_PARALLEL_LEVEL cover the rest. --- FR --- matplotlib s'arrête sur « c++: fatal error: Killed signal terminated program cc1plus ». « Killed » est un SIGKILL : c'est le tueur du noyau, et rien dans le message ne nomme la mémoire. Un seul fichier de matplotlib demande jusqu'à 2,5 Gio à cc1plus. Deux causes se cumulent. La VM est petite — le catalogue démarre à 1 ou 2 Gio — et chaque moteur de build lance nproc compilations en parallèle, chacune avec son cc1plus. Six cœurs épuisent 8 Gio. D'où deux réponses. Un fichier d'échange complète la mémoire jusqu'à 8 Gio, sans jamais prendre plus de la moitié du disque libre ni toucher à fstab — un swap déclaré et disparu dégrade le démarrage. Et le parallélisme est borné d'après la mémoire réelle, 2 Gio par tâche. ninja n'a aucune variable de parallélisme, mais meson-python lit « NINJA », le CHEMIN de l'exécutable — vérifié dans mesonpy 0.20. On y met une enveloppe qui ajoute le -j. C'est ce qui sauve matplotlib ; MAKEFLAGS et CMAKE_BUILD_PARALLEL_LEVEL couvrent les autres. Assisted-by: Claude Opus 5
2026-08-12 02:56:18 -04:00
# La mémoire est la ressource qui manque en premier ici : cc1plus demande
# jusqu'à 2,5 Gio pour un seul fichier de matplotlib, et le tueur du noyau
# abrège sans jamais nommer la mémoire (« Killed signal terminated program
# cc1plus »). On complète par du swap avant d'en arriver là.
el_swap_ensure
[FIX] install s390x: the Debian build chain, package by package Bringing s390x up on Debian and Ubuntu turned up one blocker at a time, each found on a real machine: no wheel is published there, so everything compiles against distribution headers. manifold3d needs tbb, cmake and ninja; pymupdf loads libclang.so by its bare name through ctypes and only a versioned one is packaged; cryptography and bcrypt need Rust; pikepdf needs qpdf, whose -dev package is named differently across releases. Two traps cost the most time. One unknown name made apt refuse the whole batch of fifteen without ever saying which, so apt itself is now asked what is installable, and a failed batch retries package by package. And a failed unpack leaves dpkg half-configured, after which every apt call blames packages that are in fact installed -- hence the repair step. npm is the other half: npm@latest outran the packaged node and aborted install_os, NodeSource publishes nothing for s390x, and Ubuntu's nodejs package carries no npm on any release. --- FR --- Porter s390x sur Debian et Ubuntu a révélé un blocage à la fois, chacun sur une machine réelle : aucune roue n'y est publiée, donc tout se compile contre les en-têtes de la distribution. manifold3d exige tbb, cmake et ninja ; pymupdf charge libclang.so par son nom nu via ctypes et seul un nom versionné est empaqueté ; cryptography et bcrypt réclament Rust ; pikepdf veut qpdf, dont le paquet -dev change de nom selon la version. Deux pièges ont coûté le plus. Un seul nom inconnu faisait refuser à apt le lot entier de quinze, sans jamais dire lequel : on demande désormais à apt ce qui est installable, et un lot en échec reprend paquet par paquet. Et un dépaquetage raté laisse dpkg à moitié configuré, après quoi tout apt accuse des paquets pourtant installés — d'où l'étape de réparation. npm est l'autre moitié : npm@latest dépassait le node empaqueté et arrêtait install_os, NodeSource ne publie rien pour s390x, et le paquet nodejs d'Ubuntu ne porte npm sur aucune version. Assisted-by: Claude Opus 5
2026-08-11 03:13:39 -04:00
# Sur une VM fraîche, l'index apt peut être vide : « apt install » échouerait
# alors sur TOUT le lot, et l'absence d'un seul paquet ne se voit que bien
# plus loin, sous la forme d'une commande introuvable.
${APT_GET} update
# « ${APT_GET} » et non « sudo apt » : au 1er boot d'une image cloud,
# cloud-init tient le verrou apt, et un « apt install » nu échoue AUSSITÔT.
# Ces trois lots étaient les seuls du script à contourner le wrapper, et
# aucun ne vérifiait son résultat : libqpdf-dev manquait sans un mot, et
# l'échec ne se voyait qu'une heure plus tard, à la compilation de pikepdf.
# Un nom de paquet CHANGE d'une version d'Ubuntu à l'autre : GeographicLib
# s'appelle « libgeographic-dev » sur 20.04 et 22.04, « libgeographiclib-dev »
# depuis 24.04. Le nom récent existe pourtant dans la base apt des anciennes,
# SANS version installable — apt refuse alors le lot ENTIER, emportant les
# quatorze autres paquets. On demande donc à apt lui-même quel nom est
# réellement installable, seule autorité sur la question.
apt_pick() {
for candidate in "$@"; do
if apt-get install -s -qq "${candidate}" > /dev/null 2>&1; then
echo "${candidate}"
return 0
fi
done
echo "$1"
}
# Vrai si dpkg considère le paquet installé et configuré.
apt_is_installed() {
[ "$(dpkg-query -W -f='${db:Status-Status}' "$1" 2>/dev/null)" = "installed" ]
}
# Le lot d'abord, pour la vitesse. S'il échoue, on reprend paquet par paquet
# afin de NOMMER le fautif : sinon un seul nom obsolète masque les autres et
# le message ne dit pas lequel corriger.
apt_install_batch() {
if ${APT_GET} install "$@" -y; then
return 0
fi
# Un dépaquetage raté laisse dpkg à moitié configuré, et TOUT apt suivant
# rend « Unmet dependencies » — y compris pour des paquets déjà installés.
# Sans cette réparation, la boucle ci-dessous accusait les quinze paquets
# à cause d'un seul, et l'installation s'arrêtait sur un paquet présent.
echo "Lot apt en echec : tentative de reparation dpkg..."
sudo dpkg --configure -a || true
${APT_GET} --fix-broken install -y || true
if ${APT_GET} install "$@" -y; then
echo "Reparation reussie."
return 0
fi
echo "Reprise paquet par paquet pour identifier le fautif..."
df -h / | sed 's/^/ disque: /'
APT_FAILED=""
for one in "$@"; do
${APT_GET} install "${one}" -y && continue
# L'échec peut n'être qu'un contrecoup de l'état global : on ne l'impute
# au paquet que si dpkg confirme qu'il n'est PAS installé.
apt_is_installed "${one}" || APT_FAILED="${APT_FAILED} ${one}"
done
[ -z "${APT_FAILED}" ]
}
APT_FAILED=""
GEO_DEV="$(apt_pick libgeographiclib-dev libgeographic-dev)"
# manifold3d (via to-3mf) et pymupdf n'ont pas de roue s390x : ils se
# compilent, d'où tbb, cmake et ninja. Un seul lot, une seule reprise.
apt_install_batch rust-all libqpdf-dev libgeos-dev libproj-dev proj-bin \
proj-data "${GEO_DEV}" freetds-dev freetds-bin libkrb5-dev libssl-dev \
pkg-config build-essential zlib1g-dev libjpeg-dev libtbb-dev cmake \
[ADD] install s390x : batir PROJ quand la distribution est en retard Debian 13 installe ERPLibre de bout en bout ; Debian 12 s'arrete sur pyproj : ERROR: Minimum supported PROJ version is 9.4.0, installed version is 9.1.1 bookworm livre 9.1.1, trixie 9.6 — d'ou l'ecart entre les deux. La portee est etroite : sur amd64 et arm64, pyproj pose une roue manylinux qui EMBARQUE sa propre PROJ, et la version du systeme n'entre pas en jeu. s390x n'a pas de roue et compile contre celle du systeme. lib_proj.sh est le calque de lib_qpdf.sh, meme motif et memes garde-fous : seuil, comparaison qui complete les composantes manquantes — « sort -V » classe 9.4 avant 9.4.0 — installation dans /usr/local, declaration a ld.so, et jamais de code non nul pour ne pas masquer ce que pyproj dira lui-meme. L'appel reste sous la garde s390x, verifie. --- EN --- Debian 13 installs ERPLibre end to end; Debian 12 stops on pyproj: ERROR: Minimum supported PROJ version is 9.4.0, installed version is 9.1.1 bookworm ships 9.1.1, trixie 9.6 — hence the gap between the two. The scope is narrow: on amd64 and arm64 pyproj lays down a manylinux wheel that BUNDLES its own PROJ, and the system version never comes into play. s390x has no wheel and builds against the system one. lib_proj.sh mirrors lib_qpdf.sh, same pattern and same guards: a threshold, a comparison that pads missing components — "sort -V" ranks 9.4 before 9.4.0 — installation into /usr/local, an ld.so declaration, and never a non-zero exit so as not to mask what pyproj itself will say. The call stays under the s390x guard, verified. Assisted-by: Claude Opus 5 (cherry picked from commit f779702b61ff6405bdd7efabaa1f5bac09e1166b)
2026-08-14 02:19:41 -04:00
ninja-build libsqlite3-dev sqlite3 libtiff-dev libcurl4-openssl-dev
[FIX] install s390x: the Debian build chain, package by package Bringing s390x up on Debian and Ubuntu turned up one blocker at a time, each found on a real machine: no wheel is published there, so everything compiles against distribution headers. manifold3d needs tbb, cmake and ninja; pymupdf loads libclang.so by its bare name through ctypes and only a versioned one is packaged; cryptography and bcrypt need Rust; pikepdf needs qpdf, whose -dev package is named differently across releases. Two traps cost the most time. One unknown name made apt refuse the whole batch of fifteen without ever saying which, so apt itself is now asked what is installable, and a failed batch retries package by package. And a failed unpack leaves dpkg half-configured, after which every apt call blames packages that are in fact installed -- hence the repair step. npm is the other half: npm@latest outran the packaged node and aborted install_os, NodeSource publishes nothing for s390x, and Ubuntu's nodejs package carries no npm on any release. --- FR --- Porter s390x sur Debian et Ubuntu a révélé un blocage à la fois, chacun sur une machine réelle : aucune roue n'y est publiée, donc tout se compile contre les en-têtes de la distribution. manifold3d exige tbb, cmake et ninja ; pymupdf charge libclang.so par son nom nu via ctypes et seul un nom versionné est empaqueté ; cryptography et bcrypt réclament Rust ; pikepdf veut qpdf, dont le paquet -dev change de nom selon la version. Deux pièges ont coûté le plus. Un seul nom inconnu faisait refuser à apt le lot entier de quinze, sans jamais dire lequel : on demande désormais à apt ce qui est installable, et un lot en échec reprend paquet par paquet. Et un dépaquetage raté laisse dpkg à moitié configuré, après quoi tout apt accuse des paquets pourtant installés — d'où l'étape de réparation. npm est l'autre moitié : npm@latest dépassait le node empaqueté et arrêtait install_os, NodeSource ne publie rien pour s390x, et le paquet nodejs d'Ubuntu ne porte npm sur aucune version. Assisted-by: Claude Opus 5
2026-08-11 03:13:39 -04:00
if [[ -n "${APT_FAILED}" ]]; then
# Seul un paquet dont dépend la SUITE immédiate est bloquant. Les autres
# servent des modules Odoo optionnels : les rendre fatals immobiliserait
# toute l'installation pour un module que personne n'utilise ici.
echo "Paquets s390x non installables :${APT_FAILED}"
for essential in build-essential pkg-config libssl-dev zlib1g-dev \
libjpeg-dev cmake; do
case " ${APT_FAILED} " in
*" ${essential} "*)
echo "apt-get s390x : '${essential}' est indispensable, arret."
exit 1
;;
esac
done
echo "Aucun n'est indispensable a la compilation : on continue."
fi
# pymupdf non plus n'a pas de roue s390x : il compile MuPDF, dont le
# générateur de liaisons charge « libclang.so » par son nom nu, via ctypes.
# La roue PyPI libclang, qui embarque cette bibliothèque, n'existe pas ici.
# Le paquet de la distribution la fournit bien dans le chemin de l'éditeur de
# liens, mais sous un nom versionné : il ne manque que le lien non versionné.
${APT_GET} install libclang-dev -y
CLANG_LIB_DIR="/usr/lib/s390x-linux-gnu"
if [ ! -e "${CLANG_LIB_DIR}/libclang.so" ]; then
CLANG_SO="$(ls -1 ${CLANG_LIB_DIR}/libclang-[0-9]*.so 2>/dev/null | sort -V | tail -1)"
if [ -n "${CLANG_SO}" ]; then
sudo ln -s "${CLANG_SO}" "${CLANG_LIB_DIR}/libclang.so"
sudo ldconfig
echo "libclang.so -> ${CLANG_SO}"
else
echo "Attention : libclang introuvable, la compilation de pymupdf va echouer."
fi
fi
[FIX] install: the EL9, EL10 and Fedora build chain "dnf install: error: unrecognized arguments" on AlmaLinux 10 and Rocky 10, on every call: PostgreSQL, build dependencies, pyenv. The tools group got away with its fallback, which made the trace misleading -- gcc installed, nothing after it did. "--skip-unavailable" is a dnf5 option, which the script's own comment already said while assuming it everywhere. Fedora 41+ ships dnf5, but EL9 and EL10 stay on dnf4, whose equivalent is "--setopt=strict=0". We now ask dnf what it understands instead of inferring it from the distribution. Three neighbouring fixes: the "c-development" group does not exist on EL, where it is called "development"; CRB is enabled through /usr/bin/crb; and g++ plus the missing headers are installed explicitly. Rust is added only where wheels are absent, and qpdf is built when the distribution ships one older than pikepdf demands. --- FR --- « dnf install: error: unrecognized arguments » sur AlmaLinux 10 et Rocky 10, à chaque appel : PostgreSQL, dépendances de compilation, pyenv. Le groupe d'outils s'en tirait par son repli, ce qui rendait la trace trompeuse — gcc installé, rien après lui. « --skip-unavailable » est une option de dnf5, ce que le commentaire du script disait déjà tout en la supposant partout. Fedora 41+ livre dnf5, mais EL9 et EL10 restent sur dnf4, dont l'équivalent est « --setopt=strict=0 ». On demande maintenant à dnf ce qu'il comprend plutôt que de le déduire de la distribution. Trois correctifs voisins : le groupe « c-development » n'existe pas sur EL, où il s'appelle « development » ; CRB s'active par /usr/bin/crb ; et g++ ainsi que les en-têtes manquants sont posés explicitement. Rust n'est ajouté que là où les roues manquent, et qpdf est compilé quand la distribution en livre un plus ancien que ce qu'exige pikepdf. Assisted-by: Claude Opus 5
2026-08-11 20:46:07 -04:00
# pikepdf se lie a qpdf, dont il exige 12.2.0 au minimum. Ubuntu 24.04 en
# livre 11.9.0 ; 25.10 et 26.04 passent, d'ou le partage observe. Le detail
# -- seuil, version batie, chemin d'installation -- est dans lib_qpdf.sh,
# partage avec les scripts dnf et zypper qui butaient sur le meme mur.
el_qpdf_ensure
[ADD] install s390x : batir PROJ quand la distribution est en retard Debian 13 installe ERPLibre de bout en bout ; Debian 12 s'arrete sur pyproj : ERROR: Minimum supported PROJ version is 9.4.0, installed version is 9.1.1 bookworm livre 9.1.1, trixie 9.6 — d'ou l'ecart entre les deux. La portee est etroite : sur amd64 et arm64, pyproj pose une roue manylinux qui EMBARQUE sa propre PROJ, et la version du systeme n'entre pas en jeu. s390x n'a pas de roue et compile contre celle du systeme. lib_proj.sh est le calque de lib_qpdf.sh, meme motif et memes garde-fous : seuil, comparaison qui complete les composantes manquantes — « sort -V » classe 9.4 avant 9.4.0 — installation dans /usr/local, declaration a ld.so, et jamais de code non nul pour ne pas masquer ce que pyproj dira lui-meme. L'appel reste sous la garde s390x, verifie. --- EN --- Debian 13 installs ERPLibre end to end; Debian 12 stops on pyproj: ERROR: Minimum supported PROJ version is 9.4.0, installed version is 9.1.1 bookworm ships 9.1.1, trixie 9.6 — hence the gap between the two. The scope is narrow: on amd64 and arm64 pyproj lays down a manylinux wheel that BUNDLES its own PROJ, and the system version never comes into play. s390x has no wheel and builds against the system one. lib_proj.sh mirrors lib_qpdf.sh, same pattern and same guards: a threshold, a comparison that pads missing components — "sort -V" ranks 9.4 before 9.4.0 — installation into /usr/local, an ld.so declaration, and never a non-zero exit so as not to mask what pyproj itself will say. The call stays under the s390x guard, verified. Assisted-by: Claude Opus 5 (cherry picked from commit f779702b61ff6405bdd7efabaa1f5bac09e1166b)
2026-08-14 02:19:41 -04:00
# pyproj exige PROJ 9.4 ; bookworm en livre 9.1.1. Meme mecanique que
# qpdf, et meme portee etroite : ailleurs pyproj pose une roue qui
# embarque sa propre PROJ, ici il compile contre celle du systeme.
el_proj_ensure
[FIX] install s390x: the Debian build chain, package by package Bringing s390x up on Debian and Ubuntu turned up one blocker at a time, each found on a real machine: no wheel is published there, so everything compiles against distribution headers. manifold3d needs tbb, cmake and ninja; pymupdf loads libclang.so by its bare name through ctypes and only a versioned one is packaged; cryptography and bcrypt need Rust; pikepdf needs qpdf, whose -dev package is named differently across releases. Two traps cost the most time. One unknown name made apt refuse the whole batch of fifteen without ever saying which, so apt itself is now asked what is installable, and a failed batch retries package by package. And a failed unpack leaves dpkg half-configured, after which every apt call blames packages that are in fact installed -- hence the repair step. npm is the other half: npm@latest outran the packaged node and aborted install_os, NodeSource publishes nothing for s390x, and Ubuntu's nodejs package carries no npm on any release. --- FR --- Porter s390x sur Debian et Ubuntu a révélé un blocage à la fois, chacun sur une machine réelle : aucune roue n'y est publiée, donc tout se compile contre les en-têtes de la distribution. manifold3d exige tbb, cmake et ninja ; pymupdf charge libclang.so par son nom nu via ctypes et seul un nom versionné est empaqueté ; cryptography et bcrypt réclament Rust ; pikepdf veut qpdf, dont le paquet -dev change de nom selon la version. Deux pièges ont coûté le plus. Un seul nom inconnu faisait refuser à apt le lot entier de quinze, sans jamais dire lequel : on demande désormais à apt ce qui est installable, et un lot en échec reprend paquet par paquet. Et un dépaquetage raté laisse dpkg à moitié configuré, après quoi tout apt accuse des paquets pourtant installés — d'où l'étape de réparation. npm est l'autre moitié : npm@latest dépassait le node empaqueté et arrêtait install_os, NodeSource ne publie rien pour s390x, et le paquet nodejs d'Ubuntu ne porte npm sur aucune version. Assisted-by: Claude Opus 5
2026-08-11 03:13:39 -04:00
# cryptography ne publie aucune roue s390x : elle se compile, et son
# Cargo.lock est en version 4, que seul cargo >= 1.78 sait lire. Ubuntu 24.04
# livre 1.75 et s'arrête sur « lock file version 4 requires
# -Znext-lockfile-bump » ; 25.10 et au-delà passent. On complète alors par
# rustup, en exposant la chaîne hors du shell de connexion : les étapes
# suivantes sont des processus distincts, qui ne liront ni ~/.bashrc ni
# ~/.cargo/env.
CARGO_MIN_MINOR=78
cargo_ver="$(cargo --version 2>/dev/null | awk '{print $2}')"
cargo_major="${cargo_ver%%.*}"
cargo_rest="${cargo_ver#*.}"
cargo_minor="${cargo_rest%%.*}"
cargo_ok=0
if [[ "${cargo_major}" =~ ^[0-9]+$ && "${cargo_minor}" =~ ^[0-9]+$ ]]; then
if [[ ${cargo_major} -gt 1 ]] ||
[[ ${cargo_major} -eq 1 && ${cargo_minor} -ge ${CARGO_MIN_MINOR} ]]; then
cargo_ok=1
fi
fi
if [ "${cargo_ok}" -ne 1 ]; then
echo "cargo trop ancien ($(cargo --version 2>/dev/null || echo absent)) pour cryptography : installation via rustup."
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs \
| sh -s -- -y --profile minimal --default-toolchain stable
for bin in cargo rustc; do
if [ -x "${HOME}/.cargo/bin/${bin}" ]; then
sudo ln -sf "${HOME}/.cargo/bin/${bin}" "/usr/local/bin/${bin}"
fi
done
echo "cargo retenu : $(PATH=/usr/local/bin:$PATH cargo --version 2>/dev/null || echo absent)"
fi
fi
#--------------------------------------------------
# Update Server
#--------------------------------------------------
echo -e "\n---- Update Server ----"
#--------------------------------------------------
# Install PostgreSQL Server
#--------------------------------------------------
echo -e "\n---- Install PostgreSQL Server ----"
${APT_GET} install postgresql postgresql-contrib libpq-dev -y
2022-12-21 00:25:29 -05:00
retVal=$?
if [[ $retVal -ne 0 ]]; then
echo "apt-get install postgresql installation error."
exit 1
fi
# PostGIS : optionnel (géospatial). Le nom du paquet « postgis » n'existe pas
# sur toutes les versions (Ubuntu 24.04) -> best-effort, ne bloque pas.
${APT_GET} install postgis -y \
|| ${APT_GET} install postgresql-postgis -y \
|| echo "PostGIS non installé (optionnel)."
echo -e "\n---- Creating the ERPLibre PostgreSQL User ----"
2022-12-21 00:25:29 -05:00
sudo su - postgres -c "createuser -s ${EL_USER}" 2>/dev/null || true
#--------------------------------------------------
# Install Dependencies
#--------------------------------------------------
echo -e "\n--- Installing debian dependency --"
${APT_GET} install git build-essential wget libxslt-dev libzip-dev libldap2-dev libsasl2-dev gdebi-core libffi-dev libbz2-dev parallel pysassc swig cmake portaudio19-dev libcups2-dev xmlsec1 -y
2022-12-21 00:25:29 -05:00
retVal=$?
if [[ $retVal -ne 0 ]]; then
echo "apt-get debian tool installation error."
exit 1
fi
# shfmt : ABSENT des dépôts Ubuntu < 22.04. Il était dans le lot critique
# ci-dessus -> un seul paquet introuvable faisait échouer TOUT l'apt-get
# (donc pas de build-essential/gcc -> pyenv ne pouvait plus compiler Python).
# C'est un simple formateur shell (dev), non requis pour exécuter ERPLibre :
# on l'installe SÉPARÉMENT et en best-effort (jamais fatal).
${APT_GET} install shfmt -y \
|| echo "shfmt indisponible dans les dépôts (Ubuntu < 22.04 ?) — ignoré."
${APT_GET} install libmariadbd-dev freetds-dev -y
2022-12-21 00:25:29 -05:00
retVal=$?
if [[ $retVal -ne 0 ]]; then
echo "apt-get libmariadb installation error."
exit 1
fi
# Dependencies for pyenv
${APT_GET} install make libssl-dev zlib1g-dev libreadline-dev libsqlite3-dev curl llvm libncurses5-dev libncursesw5-dev xz-utils tk-dev liblzma-dev -y
2022-12-21 00:25:29 -05:00
retVal=$?
if [[ $retVal -ne 0 ]]; then
echo "apt-get pyenv dependencies installation error."
exit 1
fi
[ADD] todo qemu: add an Android emulator, and fix what the real run exposed Running it on a VM was the only way to find these. install_os never installed python3-venv, so .venv.erplibre was born crippled — bin/python but no pip, no activate — and everything downstream failed on "No module named git"; one line of dependency fixes it. Capacitor 8 needs a JDK 21 where the mobile repository's installer puts 17, and Gradle must RUN on it. That installer is not idempotent either, so it is replayed only when something is missing. The new emulator option creates an AVD from the SDK's own device list — the newest plain Pixel, smallest screen — with software rendering written into its config so ssh -X does not open a black screen, and adds the user to the kvm group, without which it refuses to start. Checked on a VM: boot completed in 10 s, adb sees emulator-5554, Android 16 x86_64, no KVM refusal. Vitest: 1938 tests pass. The APK still fails, upstream: sentencepiece builds protoc for the target then runs it on the host. --- FR --- Seule l'exécution sur une VM pouvait trouver ceci. install_os n'installait pas python3-venv, si bien que .venv.erplibre naissait infirme — bin/python mais ni pip ni activate — et tout ce qui en dépend tombait sur « No module named git » ; une ligne de dépendance suffit. Capacitor 8 réclame un JDK 21 là où l'installateur du dépôt mobile pose un 17, et Gradle doit TOURNER dessus. Cet installateur n'est pas idempotent non plus : il n'est rejoué que s'il manque quelque chose. La nouvelle option crée un AVD depuis la liste de profils du SDK — le Pixel simple le plus récent, plus petit écran —, écrit le rendu logiciel dans sa configuration pour qu'ssh -X n'ouvre pas un écran noir, et ajoute l'utilisateur au groupe kvm, sans quoi il refuse de démarrer. Vérifié sur une VM : boot en 10 s, adb voit emulator-5554, Android 16 x86_64, aucun refus de KVM. Vitest : 1938 tests passent. L'APK échoue encore, en amont : sentencepiece bâtit protoc pour la cible puis l'exécute sur l'hôte. Assisted-by: Claude Opus 5
2026-08-18 02:17:08 -04:00
# python3-venv : le venv d'OUTILS (.venv.erplibre) est bâti avec le python du
# SYSTÈME, et sur Debian et Ubuntu « python3 -m venv » n'embarque pas ensurepip
# sans ce paquet. Sans lui le venv naît infirme — bin/python existe, ni pip ni
# activate — et tout ce qui en dépend tombe : « repo », la fusion du manifeste
# (ModuleNotFoundError: No module named 'git'), la configuration PyCharm, la
# compilation mobile. Mesuré sur une VM Ubuntu 24.04 fraîche.
${APT_GET} install python3-venv -y
retVal=$?
if [[ $retVal -ne 0 ]]; then
echo "apt-get python3-venv installation error."
exit 1
fi
# Dependencies for selenium
${APT_GET} install libcairo2-dev python3-dev pkg-config libxt-dev libgirepository1.0-dev -y
retVal=$?
if [[ $retVal -ne 0 ]]; then
echo "apt-get selenium dependencies installation error."
exit 1
fi
echo -e "\n---- Installing nodeJS NPM and rtlcss for LTR support ----"
${APT_GET} update
${APT_GET} install -y ca-certificates curl gnupg
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://deb.nodesource.com/gpgkey/nodesource-repo.gpg.key | sudo gpg --dearmor -o /etc/apt/keyrings/nodesource.gpg
[UPD] support: drop Ubuntu 20.04/22.04, add AlmaLinux and Rocky Ubuntu 20.04 and 22.04 leave EVERY architecture, not just s390x. pikepdf needs qpdf 12.2, whose build requires C++20, while focal ships GCC 9 and publishes no g++-10 for s390x at all. Python 3.8, node 10, cargo 0.67 and OpenSSL 1.1.1 each had a workaround; the pile of them did not. 18.04 follows, already off the lists. The refusal lands before any apt, this script also serving existing machines. AlmaLinux 9 and 10, Rocky 9 and 10 join the catalog on all four architectures: the twelve "latest" URLs were opened, with no index to parse unlike Fedora. They would have booted unreachable though -- the cloud-config forced "groups: users, sudo", but the RHEL family has no sudo group, only wheel, and an unknown group makes useradd fail, hence no password and no key. The very trap already known for Debian, repeated elsewhere. Host side, EPEL and CRB are enabled: without them most -devel packages are missing, silently. The server / graphical choice gains Cinnamon, the Linux Mint desktop, from the distribution's own repositories. Mint's repository is set aside: plain HTTP, and i386/amd64 only, which would rule out arm64 and s390x. Along the way, dnf now installs an ENVIRONMENT rather than a group -- "gnome-desktop" brings gdm and gnome-shell but not base-x, hence no X server. --- FR --- Ubuntu 20.04 et 22.04 partent de TOUTES les architectures, pas seulement de s390x. pikepdf réclame qpdf 12.2, dont la compilation exige C++20, quand focal livre GCC 9 et ne publie même pas de g++-10 pour s390x. Python 3.8, node 10, cargo 0.67 et OpenSSL 1.1.1 avaient chacun leur contournement ; leur accumulation, non. 18.04 suit, déjà hors des listes. Le refus tombe avant tout apt, ce script servant aussi les machines existantes. AlmaLinux 9 et 10, Rocky 9 et 10 entrent au catalogue, sur les quatre architectures : les douze URL « latest » ont été ouvertes, aucun index à analyser contrairement à Fedora. Elles auraient pourtant démarré inaccessibles — le cloud-config imposait « groups: users, sudo », or la famille RHEL n'a pas de groupe sudo mais wheel, et un groupe inconnu fait échouer useradd, donc ni mot de passe ni clé. C'est le piège déjà connu pour Debian, reproduit ailleurs. Côté hôte, EPEL et CRB sont activés : sans eux la plupart des -devel manquent, en silence. Le choix serveur / graphique gagne Cinnamon, le bureau de Linux Mint, depuis les dépôts de la distribution. Le dépôt de Mint lui-même est écarté : il est en HTTP nu et ne publie que i386 et amd64, ce qui exclurait arm64 et s390x. Au passage, dnf installe désormais un ENVIRONNEMENT et non un groupe — « gnome-desktop » apporte gdm et gnome-shell mais pas base-x, donc pas de serveur X. Assisted-by: Claude Opus 5
2026-08-11 18:46:11 -04:00
# Node 22+ required by @capacitor/cli v8.x (mobile app dependency)
NODE_MAJOR=22
[FIX] install s390x: the Debian build chain, package by package Bringing s390x up on Debian and Ubuntu turned up one blocker at a time, each found on a real machine: no wheel is published there, so everything compiles against distribution headers. manifold3d needs tbb, cmake and ninja; pymupdf loads libclang.so by its bare name through ctypes and only a versioned one is packaged; cryptography and bcrypt need Rust; pikepdf needs qpdf, whose -dev package is named differently across releases. Two traps cost the most time. One unknown name made apt refuse the whole batch of fifteen without ever saying which, so apt itself is now asked what is installable, and a failed batch retries package by package. And a failed unpack leaves dpkg half-configured, after which every apt call blames packages that are in fact installed -- hence the repair step. npm is the other half: npm@latest outran the packaged node and aborted install_os, NodeSource publishes nothing for s390x, and Ubuntu's nodejs package carries no npm on any release. --- FR --- Porter s390x sur Debian et Ubuntu a révélé un blocage à la fois, chacun sur une machine réelle : aucune roue n'y est publiée, donc tout se compile contre les en-têtes de la distribution. manifold3d exige tbb, cmake et ninja ; pymupdf charge libclang.so par son nom nu via ctypes et seul un nom versionné est empaqueté ; cryptography et bcrypt réclament Rust ; pikepdf veut qpdf, dont le paquet -dev change de nom selon la version. Deux pièges ont coûté le plus. Un seul nom inconnu faisait refuser à apt le lot entier de quinze, sans jamais dire lequel : on demande désormais à apt ce qui est installable, et un lot en échec reprend paquet par paquet. Et un dépaquetage raté laisse dpkg à moitié configuré, après quoi tout apt accuse des paquets pourtant installés — d'où l'étape de réparation. npm est l'autre moitié : npm@latest dépassait le node empaqueté et arrêtait install_os, NodeSource ne publie rien pour s390x, et le paquet nodejs d'Ubuntu ne porte npm sur aucune version. Assisted-by: Claude Opus 5
2026-08-11 03:13:39 -04:00
# NodeSource ne publie que amd64, arm64 et armhf : vérifié, binary-s390x
# répond 404. Ajouter le dépôt sur une autre architecture n'apporte rien et
# fait échouer « apt update » sur un index introuvable. La distribution
# fournit alors nodejs elle-même — Ubuntu 26.04 s390x livre la 22.22.1, ce qui
# convient.
NODE_ARCH="$(dpkg --print-architecture)"
case "${NODE_ARCH}" in
amd64 | arm64 | armhf)
echo "deb [signed-by=/etc/apt/keyrings/nodesource.gpg] https://deb.nodesource.com/node_$NODE_MAJOR.x nodistro main" | sudo tee /etc/apt/sources.list.d/nodesource.list
${APT_GET} update
;;
*)
echo "NodeSource ne publie pas pour ${NODE_ARCH} : nodejs vient de la distribution."
sudo rm -f /etc/apt/sources.list.d/nodesource.list
${APT_GET} update
# Le paquet « nodejs » de NodeSource embarque npm ; celui d'Ubuntu NON —
# vérifié : /usr/bin/npm est absent du paquet sur jammy, noble et questing.
# Sans cette ligne, tout ce qui suit tombe sur « npm: command not found ».
NODE_PKG="nodejs npm"
;;
esac
${APT_GET} install ${NODE_PKG:-nodejs} -y
[FIX] install s390x: the Debian build chain, package by package Bringing s390x up on Debian and Ubuntu turned up one blocker at a time, each found on a real machine: no wheel is published there, so everything compiles against distribution headers. manifold3d needs tbb, cmake and ninja; pymupdf loads libclang.so by its bare name through ctypes and only a versioned one is packaged; cryptography and bcrypt need Rust; pikepdf needs qpdf, whose -dev package is named differently across releases. Two traps cost the most time. One unknown name made apt refuse the whole batch of fifteen without ever saying which, so apt itself is now asked what is installable, and a failed batch retries package by package. And a failed unpack leaves dpkg half-configured, after which every apt call blames packages that are in fact installed -- hence the repair step. npm is the other half: npm@latest outran the packaged node and aborted install_os, NodeSource publishes nothing for s390x, and Ubuntu's nodejs package carries no npm on any release. --- FR --- Porter s390x sur Debian et Ubuntu a révélé un blocage à la fois, chacun sur une machine réelle : aucune roue n'y est publiée, donc tout se compile contre les en-têtes de la distribution. manifold3d exige tbb, cmake et ninja ; pymupdf charge libclang.so par son nom nu via ctypes et seul un nom versionné est empaqueté ; cryptography et bcrypt réclament Rust ; pikepdf veut qpdf, dont le paquet -dev change de nom selon la version. Deux pièges ont coûté le plus. Un seul nom inconnu faisait refuser à apt le lot entier de quinze, sans jamais dire lequel : on demande désormais à apt ce qui est installable, et un lot en échec reprend paquet par paquet. Et un dépaquetage raté laisse dpkg à moitié configuré, après quoi tout apt accuse des paquets pourtant installés — d'où l'étape de réparation. npm est l'autre moitié : npm@latest dépassait le node empaqueté et arrêtait install_os, NodeSource ne publie rien pour s390x, et le paquet nodejs d'Ubuntu ne porte npm sur aucune version. Assisted-by: Claude Opus 5
2026-08-11 03:13:39 -04:00
node_major() {
node --version 2>/dev/null | sed -n 's/^v\([0-9]*\).*/\1/p'
}
# Le node de la distribution suffit sur les versions récentes, pas sur les
# anciennes : focal livre la 10, jammy la 12, alors que « less » exige node 18
# et « rtlcss » node 12. Là où NodeSource n'a rien à offrir, l'archive
# officielle de nodejs.org prend le relais — elle publie bien linux-s390x,
# vérifié dans son index. Rien n'est téléchargé si la distribution suffit.
NODE_MIN=18
node_have="$(node_major)"
if [[ -n "${NODE_PKG}" && ! (${node_have:-0} -ge ${NODE_MIN}) ]]; then
echo "node $(node --version 2>/dev/null || echo absent) trop ancien (< ${NODE_MIN}) : archive officielle Node ${NODE_MAJOR}."
case "${NODE_ARCH}" in
# Node 22 publie linux-{x64,arm64,armv7l,ppc64le,s390x} — vérifié dans son
# index. Pas de riscv64 : cette architecture garde le node de sa
# distribution, et le message plus bas le dit.
s390x) NODE_DIST_ARCH=s390x ;;
ppc64el) NODE_DIST_ARCH=ppc64le ;;
*) NODE_DIST_ARCH="" ;;
esac
NODE_VER="$(curl -fsSL --max-time 60 https://nodejs.org/dist/index.json |
grep -o "\"version\":\"v${NODE_MAJOR}\.[0-9.]*\"" | head -1 | cut -d'"' -f4)"
if [[ -z "${NODE_DIST_ARCH}" || -z "${NODE_VER}" ]]; then
echo "Pas d'archive Node officielle pour ${NODE_ARCH} : on garde celle de la distribution."
else
NODE_TGZ="node-${NODE_VER}-linux-${NODE_DIST_ARCH}.tar.xz"
NODE_TMP="$(mktemp -d)"
if curl -fsSL --max-time 600 -o "${NODE_TMP}/${NODE_TGZ}" \
"https://nodejs.org/dist/${NODE_VER}/${NODE_TGZ}" &&
curl -fsSL --max-time 120 -o "${NODE_TMP}/SHASUMS256.txt" \
"https://nodejs.org/dist/${NODE_VER}/SHASUMS256.txt" &&
(cd "${NODE_TMP}" && grep " ${NODE_TGZ}\$" SHASUMS256.txt | sha256sum -c -); then
# Un « npm install npm@latest -g » antérieur a pu déposer un npm
# incompatible ici : l'archive écrase les fichiers mais ne supprime pas
# ceux qu'elle n'a pas, ce qui laisserait un mélange des deux versions.
sudo rm -rf /usr/local/lib/node_modules/npm
sudo tar -xJf "${NODE_TMP}/${NODE_TGZ}" -C /usr/local --strip-components=1
hash -r
echo "node $(node --version) / npm $(npm --version) installés dans /usr/local."
else
echo "Telechargement de Node ${NODE_VER} impossible : on garde celle de la distribution."
fi
rm -rf "${NODE_TMP}"
fi
fi
if ! command -v npm >/dev/null 2>&1; then
echo "npm est introuvable apres l'installation de nodejs (${NODE_ARCH})."
exit 1
fi
[FIX] install s390x: the Debian build chain, package by package Bringing s390x up on Debian and Ubuntu turned up one blocker at a time, each found on a real machine: no wheel is published there, so everything compiles against distribution headers. manifold3d needs tbb, cmake and ninja; pymupdf loads libclang.so by its bare name through ctypes and only a versioned one is packaged; cryptography and bcrypt need Rust; pikepdf needs qpdf, whose -dev package is named differently across releases. Two traps cost the most time. One unknown name made apt refuse the whole batch of fifteen without ever saying which, so apt itself is now asked what is installable, and a failed batch retries package by package. And a failed unpack leaves dpkg half-configured, after which every apt call blames packages that are in fact installed -- hence the repair step. npm is the other half: npm@latest outran the packaged node and aborted install_os, NodeSource publishes nothing for s390x, and Ubuntu's nodejs package carries no npm on any release. --- FR --- Porter s390x sur Debian et Ubuntu a révélé un blocage à la fois, chacun sur une machine réelle : aucune roue n'y est publiée, donc tout se compile contre les en-têtes de la distribution. manifold3d exige tbb, cmake et ninja ; pymupdf charge libclang.so par son nom nu via ctypes et seul un nom versionné est empaqueté ; cryptography et bcrypt réclament Rust ; pikepdf veut qpdf, dont le paquet -dev change de nom selon la version. Deux pièges ont coûté le plus. Un seul nom inconnu faisait refuser à apt le lot entier de quinze, sans jamais dire lequel : on demande désormais à apt ce qui est installable, et un lot en échec reprend paquet par paquet. Et un dépaquetage raté laisse dpkg à moitié configuré, après quoi tout apt accuse des paquets pourtant installés — d'où l'étape de réparation. npm est l'autre moitié : npm@latest dépassait le node empaqueté et arrêtait install_os, NodeSource ne publie rien pour s390x, et le paquet nodejs d'Ubuntu ne porte npm sur aucune version. Assisted-by: Claude Opus 5
2026-08-11 03:13:39 -04:00
# « npm@latest » dépasse régulièrement le node en place : sur Ubuntu 26.04
# s390x, npm 12 exige node ^22.22.2 alors que l'archive livre la 22.22.1 — un
# correctif d'écart, et EBADENGINE. Pire sur un node ancien : npm 6 n'applique
# PAS « engines », il se contente d'avertir, installe npm 12 par-dessus et le
# rend inutilisable (« Cannot find module 'node:path' », absent avant node
# 14.18). Le npm livré AVEC node est compatible par construction ; cette mise à
# niveau n'est qu'un confort, on ne la tente que si node est assez récent.
if [[ "$(node_major)" =~ ^[0-9]+$ && $(node_major) -ge ${NODE_MAJOR} ]]; then
sudo npm install npm@latest -g
retVal=$?
if [[ $retVal -ne 0 ]]; then
echo "Avertissement : npm n'a pas pu être mis à niveau, on garde $(npm --version)."
fi
else
echo "npm $(npm --version) conservé : node $(node --version) est en deçà de ${NODE_MAJOR}."
fi
sudo npm install -g rtlcss
2022-12-21 00:25:29 -05:00
retVal=$?
if [[ $retVal -ne 0 ]]; then
echo "npm install rtlcss installation error."
2022-12-21 00:25:29 -05:00
exit 1
fi
sudo npm install -g less
retVal=$?
if [[ $retVal -ne 0 ]]; then
echo "npm install less installation error."
exit 1
fi
echo -e "\n---- Test tool ----"
npm install
2022-12-21 00:25:29 -05:00
retVal=$?
if [[ $retVal -ne 0 ]]; then
echo "npm install prettier + plugin-xml installation error."
2022-12-21 00:25:29 -05:00
exit 1
fi
sudo ln -fs /usr/local/bin/lessc /usr/bin/lessc
if [ ${EL_INSTALL_NGINX} = "True" ]; then
echo -e "\n---- Installing nginx ----"
sudo apt install nginx -y
2022-12-21 00:25:29 -05:00
retVal=$?
if [[ $retVal -ne 0 ]]; then
echo "apt install nginx installation error."
exit 1
fi
fi
#--------------------------------------------------
# Install Wkhtmltopdf if needed
#--------------------------------------------------
if [ "$(uname -m)" != "x86_64" ]; then
# WKHTMLTOX_X64 pointe vers un .deb amd64 : sur toute autre architecture
# (s390x, arm64/aarch64…) gdebi échouerait. On saute proprement plutôt que
# d'avorter tout l'install (wkhtmltopdf est optionnel).
echo "wkhtmltopdf : pas de build pour $(uname -m), ignoré (optionnel)."
elif [ ${EL_INSTALL_WKHTMLTOPDF} = "True" ]; then
echo -e "\n---- Installing wkhtml ----"
2022-12-21 00:25:29 -05:00
INSTALLED=$(dpkg -s wkhtmltox | grep installed)
if [ "" == "${INSTALLED}" ]; then
2022-12-21 00:25:29 -05:00
echo -e "\n---- Install wkhtml and place shortcuts on correct place ----"
_url=${WKHTMLTOX_X64}
if [ -z "${_url}" ]; then
# Aucune URL (version non mappée) : wkhtmltopdf est OPTIONNEL, on saute
# proprement plutôt que d'appeler gdebi sans fichier (« Usage: gdebi »).
echo "wkhtmltopdf : aucune URL pour cette version, ignoré (optionnel)."
else
sudo wget ${_url}
sudo gdebi --n $(basename ${_url})
retVal=$?
if [[ $retVal -ne 0 ]]; then
# wkhtmltopdf est OPTIONNEL (rapports PDF). NON bloquant : sur Debian
# 13 (trixie) le .deb dépendait de libssl1.1 (absent) et « exit 1 »
# faisait échouer TOUT install_os -> Odoo jamais installé. On avertit
# et on continue (comme Arch qui poursuit sans wkhtmltopdf).
echo "wkhtmltopdf : installation échouée, ignoré (optionnel — pas de PDF)."
else
sudo ln -fs /usr/local/bin/wkhtmltopdf /usr/bin
sudo ln -fs /usr/local/bin/wkhtmltoimage /usr/bin
fi
2022-12-21 00:25:29 -05:00
fi
else
echo -e "\n---- Already installed wkhtml ----"
fi
else
echo "Wkhtmltopdf isn't installed due to the choice of the user!"
fi