[ADD] reverse proxy: dev front for Odoo 18, HTTPS, started from TODO
6 commits. Opened on its web port, an Odoo running with workers fails to
bind its websocket, which only the bus port serves. The proxy routes both
from one address, sets X-Forwarded-* for proxy_mode and relays bytes
unchanged, so an upgraded WebSocket stays open; it serves HTTPS with a
local authority, logs each request, bounds waits except the relay, and
names the Odoo port that does not answer. TODO Network starts it from
config.conf and issues the certificates. Checked: 48 tests; against a
live Odoo 18 over HTTPS, a wss ping returns its pong.
--- FR ---
[ADD] reverse proxy : façade de dev pour Odoo 18, HTTPS, lancée de TODO
6 commits. Ouvert sur son port web, un Odoo à workers n'arrive pas à lier
sa websocket, que seul le port du bus sert. Le mandataire route les deux
depuis une adresse, pose les X-Forwarded-* de proxy_mode et relaie les
octets tels quels : une WebSocket montée reste ouverte ; il sert en HTTPS
avec une autorité locale, journalise chaque requête, borne les attentes
sauf le relais et nomme le port d'Odoo muet. TODO Network le lance depuis
config.conf et émet les certificats. Vérifié : 48 tests ; face à un Odoo
18 réel en HTTPS, un ping wss rend son pong.
Assisted-by: Claude Opus 5.5
Records the branch for the next release under Added: the development
reverse proxy that serves pages and /websocket from one address without
nginx, with HTTPS, one log line per request, the startup probe and the
502 that name the silent Odoo port, and bounds that never apply to an
open WebSocket; the local authority and certificate for HTTPS tests;
the TODO Network entries that start it and issue the certificates.
Checked: make doc_markdown regenerates both files, each language only
in its own; a simulated merge with master has no conflict.
--- FR ---
[UPD] changelog : mandataire de dev Odoo 18, HTTPS, entrées TODO Network
Consigne la branche pour la prochaine version sous Ajouté : le mandataire
inverse de développement qui sert les pages et /websocket depuis une
adresse sans nginx, avec le HTTPS, une ligne de journal par requête, la
sonde au démarrage et le 502 qui nomment le port d'Odoo muet, et des
bornes jamais appliquées à une WebSocket ouverte ; l'autorité et le
certificat locaux des tests HTTPS ; les entrées TODO Network qui le
lancent et émettent les certificats.
Vérifié : make doc_markdown régénère les deux fichiers, chaque langue
dans le sien seulement ; un merge simulé avec master est sans conflit.
Assisted-by: Claude Opus 5.5
The reverse proxy entry now asks HTTP or HTTPS; in HTTPS it issues the
local certificate on first use, passes it to the proxy and names the
authority to import in the browser. A fifth Network entry issues it
again with extra names or addresses typed by the user, keeping the
authority already imported.
Checked: 10 menu tests, among them a real openssl issue whose SAN holds
the typed names; test_todo_i18n passes.
--- FR ---
[IMP] todo network : HTTPS pour le mandataire, certificats locaux
L'entrée du mandataire demande désormais HTTP ou HTTPS ; en HTTPS, elle
émet le certificat local au premier usage, le passe au mandataire et
nomme l'autorité à importer dans le navigateur. Une cinquième entrée de
Network le réémet avec des noms ou adresses saisis, en gardant l'autorité
déjà importée.
Vérifié : 10 tests du menu, dont une vraie émission openssl dont le SAN
porte les noms saisis ; test_todo_i18n passe.
Assisted-by: Claude Opus 5.5
A client that opened a connection and sent nothing held its task forever,
and the proxy stayed silent until a 502 that named no port. The request
head now waits 30 s (408) and the connection to Odoo 10 s (504), never
the relay, so a WebSocket stays open; a line per request gives route,
status and duration; the start probes both ports and a 502 names the one
missing, with workers for the bus. --tls-cert/--tls-key serve HTTPS and
default X-Forwarded-Proto to https; --trust-forwarded extends a chain.
Checked: 32 tests; live Odoo 18 over HTTPS, wss ping returns its pong.
--- FR ---
[IMP] reverse proxy : délais, journal, sonde au démarrage, TLS, chaîne
Un client qui ouvrait une connexion sans rien envoyer gardait sa tâche
pour toujours, et le mandataire restait muet jusqu'à un 502 sans port. La
tête attend désormais 30 s (408) et la connexion à Odoo 10 s (504), jamais
le relais : une WebSocket reste ouverte ; une ligne par requête donne
route, statut et durée ; le démarrage sonde les deux ports et un 502 nomme
celui qui manque, workers pour le bus. --tls-cert/--tls-key servent en
HTTPS, X-Forwarded-Proto à https ; --trust-forwarded prolonge une chaîne.
Vérifié : 32 tests ; Odoo 18 réel en HTTPS, un ping wss rend son pong.
Assisted-by: Claude Opus 5.5
Testing Odoo behind HTTPS needs a certificate the browser accepts,
WebSocket over wss included. local_cert.py issues, through the openssl
command, a local authority to import once and a server certificate it
signs for localhost, the loopbacks, the host name and its addresses.
The authority is kept across issues, so a new name needs no new import;
the directory is 0700 and the keys 0600, the authority being able to
sign for any name. Server certificates last 397 days, under the 398
that browsers accept.
Checked: 6 tests, openssl verify passes, SAN and key modes asserted.
--- FR ---
[ADD] reverse proxy : autorité locale et certificat pour tests HTTPS
Tester Odoo derrière HTTPS exige un certificat que le navigateur accepte,
WebSocket en wss comprise. local_cert.py émet, par la commande openssl,
une autorité locale à importer une fois et un certificat serveur qu'elle
signe pour localhost, les boucles locales, le nom d'hôte et ses adresses.
L'autorité est gardée d'une émission à l'autre : un nouveau nom n'exige
aucun nouvel import. Répertoire en 0700 et clés en 0600, l'autorité
pouvant signer pour tout nom. Certificats serveur de 397 jours, sous les
398 qu'acceptent les navigateurs.
Vérifié : 6 tests, openssl verify passe, SAN et droits des clés vérifiés.
Assisted-by: Claude Opus 5.5
Network gains a fourth entry that starts script/reverse_proxy/main.py
with the web and bus ports read from config.conf, falling back to the
older xmlrpc_port and longpolling_port names. It asks for this machine
only or the whole network, local by default, and warns when proxy_mode
is off or workers is 0: the first makes Odoo ignore X-Forwarded-*, the
second leaves no bus port, so /websocket fails behind the proxy too.
Checked: 48 tests pass (proxy, config reading, menu wiring, i18n); the
French screen renders with the real config.conf.
--- FR ---
[ADD] todo network : lancer le mandataire inverse Odoo, local ou réseau
Network gagne une quatrième entrée qui lance script/reverse_proxy/main.py
avec les ports web et bus lus dans config.conf, repli sur les anciens noms
xmlrpc_port et longpolling_port. Elle demande cette machine seule ou tout
le réseau, local par défaut, et prévient quand proxy_mode est éteint ou
workers vaut 0 : le premier fait ignorer X-Forwarded-* à Odoo, le second
ne laisse aucun port de bus, et /websocket échoue aussi derrière le proxy.
Vérifié : 48 tests passent (mandataire, lecture du config, câblage du
menu, i18n) ; l'écran français s'affiche avec le vrai config.conf.
Assisted-by: Claude Opus 5.5
A single local address routes pages to the Odoo web port and /websocket
to the bus port, with X-Forwarded-* set for proxy_mode; a client value
for these headers is replaced. Only the request head is read: bytes then
pass through unchanged in both directions, so an upgraded WebSocket stays
open and a gzip or chunked response reaches the browser intact. Each
connection carries one request; production keeps nginx (script/nginx).
Checked: 15 tests on real sockets (routing, headers, 5 MB body, gzip,
WebSocket echo, 502, 400, 431); byte-identical to direct against Odoo 18.
--- FR ---
[ADD] reverse proxy : façade de dev pour Odoo 18, websocket dans 2 sens
Une seule adresse locale envoie les pages au port web d'Odoo et
/websocket au port du bus, avec les X-Forwarded-* de proxy_mode ; la
valeur qu'un client donne à ces en-têtes est remplacée. Seule la tête est
lue : les octets passent ensuite tels quels dans les deux sens, une
WebSocket montée reste ouverte et une réponse gzip ou en morceaux arrive
intacte. Une requête par connexion ; la production garde nginx.
Vérifié : 15 tests sur vrais sockets (routage, en-têtes, corps de 5 Mo,
gzip, écho WebSocket, 502, 400, 431) ; identique octet pour octet au
direct face à Odoo 18.
Assisted-by: Claude Opus 5.5
[FIX] qemu cache: git mirror limited to http(s), icons on UI chooser
3 commits. The git mirror of the QEMU cache took the scheme of a git
negotiation from the request line the client writes, so an ssh:// or
git:// repository made the cache connect, with its service account keys,
to a host the client chose. It now clones only over http and https, and
the binary reports 0.2.17. The interface chooser of the TODO CLI gains
icons on its two choices.
Checked: full qemu_cache Go suite passes, a real clone through the
mirror still works; test_todo_i18n passes.
--- FR ---
[FIX] qemu cache : miroir git limité à http(s), icônes du choix d'IU
3 commits. Le miroir git du cache QEMU prenait le schéma d'une
négociation git dans la ligne de requête écrite par le client : un dépôt
ssh:// ou git:// faisait se connecter le cache, avec les clés de son
compte de service, à un hôte choisi par le client. Il ne clone plus qu'en
http et https, et le binaire annonce 0.2.17. Le choix d'interface du CLI
TODO gagne des icônes sur ses deux options.
Vérifié : suite Go de qemu_cache au vert, un vrai clone à travers le
miroir fonctionne toujours ; test_todo_i18n passe.
Assisted-by: Claude Opus 5.5
Records the branch for the next release: under Security, the git mirror
of the QEMU cache that no longer follows an ssh:// or git:// repository
named by a client, with the binary version 0.2.17 that tells a fixed
cache apart; under Changed, the icons on the interface chooser.
Checked: make doc_markdown regenerates both files, each language only
in its own.
--- FR ---
[UPD] changelog : miroir git du cache qemu limité à http(s), icônes
Consigne la branche pour la prochaine version : sous Sécurité, le miroir
git du cache QEMU qui ne suit plus un dépôt ssh:// ou git:// nommé par un
client, avec la version 0.2.17 du binaire qui distingue un cache corrigé ;
sous Modifié, les icônes du choix d'interface.
Vérifié : make doc_markdown régénère les deux fichiers, chaque langue
dans le sien seulement.
Assisted-by: Claude Opus 5.5
The interface chooser of the QEMU deployment and of the Odoo migration,
and the matching preferences in Configuration, read as two plain lines.
The TUI form now carries a clipboard icon and the line by line questions
a speech balloon, in both languages. Both are single code point emoji,
without the variation selector that shifts alignment on some terminals.
Checked: both labels render with their icon in French and English, and
test_todo_i18n passes.
--- FR ---
[IMP] todo : icônes sur les choix formulaire TUI et questions classiques
Le choix d'interface du déploiement QEMU et de la migration Odoo, et les
préférences correspondantes de Configuration, se lisaient comme deux
lignes nues. Le formulaire TUI porte désormais un presse-papiers et les
questions ligne par ligne une bulle, dans les deux langues. Ce sont des
emoji d'un seul point de code, sans le sélecteur de variante qui décale
l'alignement sur certains terminaux.
Vérifié : les deux libellés s'affichent avec leur icône en français et
en anglais, et test_todo_i18n passe.
Assisted-by: Claude Opus 5.5
The scheme of a git negotiation came from the request line the client
writes, so "ssh://any-host/x.git/info/refs" made the cache run git clone
over ssh, with its service account keys, toward a host the client chose.
A git client reaches an HTTP proxy only over HTTP(S), so nothing cached
is lost. DepotDeURL now refuses other schemes, the clone ends its options
with "--", and GIT_ALLOW_PROTOCOL=http:https bounds git itself.
Checked: ssh, git, file and ext refused, a real clone through the mirror
still passes, full qemu_cache Go suite green.
--- FR ---
[FIX] qemu cache : le miroir git ne clone qu'en http et https
Le schéma d'une négociation git venait de la ligne de requête écrite par
le client : « ssh://hôte-quelconque/x.git/info/refs » faisait lancer au
cache un git clone en ssh, avec les clés de son compte de service, vers
un hôte choisi par le client. Un client git ne joint un mandataire HTTP
qu'en HTTP(S) : rien de ce qui se met en cache n'est perdu. DepotDeURL
refuse les autres schémas, le clone clôt ses options par « -- », et
GIT_ALLOW_PROTOCOL=http:https borne git lui-même.
Vérifié : ssh, git, file et ext refusés, un vrai clone à travers le
miroir passe toujours, suite Go de qemu_cache au vert.
Assisted-by: Claude Opus 5.5
[UPD] requirement: Odoo 18 aws 1.43.75, requests 2.32.4, no examples
6 commits. aiobotocore 3.9.1 accepts botocore only below 1.43.76, so the
AWS trio moves together to 1.43.75. requests is pinned to 2.32.4 against
the 2.31.0 of Odoo 18 and its two CVEs; its version had followed an
example requirements file, which poetry_update.py now skips along with
anything under doc and examples directories. factur-x gets the floor
already locked, openpyxl and xlsxwriter move for Transform data.
Checked: poetry lock resolves at each commit, the Transform data leak
test passes, 511 tests.
--- FR ---
[UPD] requirement : Odoo 18 aws 1.43.75, requests 2.32.4, sans exemples
6 commits. aiobotocore 3.9.1 n'accepte botocore que sous 1.43.76 : le trio
AWS passe ensemble à 1.43.75. requests est épinglé à 2.32.4 contre le
2.31.0 d'Odoo 18 et ses deux CVE ; sa version suivait un requirements
d'exemple, que poetry_update.py écarte désormais avec tout ce qui est
sous un répertoire doc ou examples. factur-x reçoit le plancher déjà
verrouillé, openpyxl et xlsxwriter montent pour Transform data.
Vérifié : poetry lock résout à chaque commit, le test de fuite de
Transform data passe, 511 tests.
Assisted-by: Claude Opus 5.5
The Unreleased entry named botocore 1.43.49 with aiobotocore 3.9.0,
which the branch replaces by 1.43.75 with 3.9.1; the entry now matches
what installs. Added: openpyxl and xlsxwriter for Transform data and the
factur-x floor under Changed, the doc and examples filter of
poetry_update.py under Fixed, requests 2.32.4 under Security.
Checked: make doc_markdown regenerates both files, each language only
in its own.
--- FR ---
[UPD] changelog : aws 1.43.75, requests 2.32.4, exemples doc écartés
L'entrée Unreleased nommait botocore 1.43.49 avec aiobotocore 3.9.0,
que la branche remplace par 1.43.75 avec 3.9.1 ; l'entrée colle désormais
à ce qui s'installe. Ajoutés : openpyxl et xlsxwriter pour Transform data
et le plancher de factur-x sous Modifié, le filtre doc et examples de
poetry_update.py sous Corrigé, requests 2.32.4 sous Sécurité.
Vérifié : make doc_markdown régénère les deux fichiers, chaque langue
dans le sien seulement.
Assisted-by: Claude Opus 5.5
poetry_update.py read every requirements.txt of the addon repositories,
illustrations included: an example file declaring a loose ">=" moved a
dependency for the whole environment, past the pin Odoo sets. A path
with a directory named doc, docs, example or examples, compared by exact
name, is now skipped for requirements and manifests alike; the ERPLibre
requirements file is still added without filtering.
Checked on a tree with the extra repositories: 70 requirements and 4016
manifests found, the one example file skipped, no manifest lost.
--- FR ---
[FIX] poetry update : ignorer les requirements sous doc et examples
poetry_update.py lisait tout requirements.txt des dépôts d'addons,
illustrations comprises : un fichier d'exemple déclarant un « >= » lâche
déplaçait une dépendance pour tout l'environnement, par-delà l'épingle
d'Odoo. Un chemin dont un répertoire s'appelle doc, docs, example ou
examples, comparé au nom exact, est désormais écarté, requirements comme
manifestes ; le requirements d'ERPLibre reste ajouté sans filtre.
Vérifié sur une arborescence avec les dépôts extra : 70 requirements et
4016 manifestes trouvés, le seul fichier d'exemple écarté, aucun manifeste
perdu.
Assisted-by: Claude Opus 5.5
Odoo 18 pins requests 2.31.0, affected by CVE-2024-35195 and
CVE-2024-47081, both fixed in 2.32.4. Left to the generated resolution,
the version followed whatever an addon repository declared, down to an
example requirements file under a doc/ directory. The ERPLibre pin now
wins the conflict and states its reason.
Checked: poetry lock resolves, requests is the only package that moves.
--- FR ---
[UPD] requirement : requests 2.32.4 plutôt que le 2.31.0 d'Odoo 18
Odoo 18 épingle requests 2.31.0, touchée par CVE-2024-35195 et
CVE-2024-47081, toutes deux corrigées en 2.32.4. Livrée à la résolution
générée, la version suivait ce qu'un dépôt d'addons déclarait, jusqu'à un
requirements d'exemple sous un répertoire doc/. L'épingle d'ERPLibre
l'emporte désormais et dit sa raison.
Vérifié : poetry lock résout, requests est le seul paquet qui bouge.
Assisted-by: Claude Opus 5.5
aiobotocore 3.9.1 accepts botocore only in >=1.43.66,<1.43.76, so
botocore 1.43.49 failed the resolution against it. botocore and boto3
move to 1.43.75, the highest release in that range; boto3 1.43.75 needs
botocore>=1.43.75 and s3transfer <0.20, which the lock already holds.
Checked: poetry lock resolves, only the three AWS packages change
version.
--- FR ---
[UPD] requirement : aiobotocore 3.9.1 avec botocore et boto3 1.43.75
aiobotocore 3.9.1 n'accepte botocore que dans >=1.43.66,<1.43.76 :
botocore 1.43.49 faisait échouer la résolution. botocore et boto3
passent à 1.43.75, la plus haute version de cette plage ; boto3 1.43.75
exige botocore>=1.43.75 et s3transfer <0.20, que le lock porte déjà.
Vérifié : poetry lock résout, seuls les trois paquets AWS changent de
version.
Assisted-by: Claude Opus 5.5
The lock already resolves factur-x 6.8 on every architecture but s390x,
which keeps its <4 branch; >=4.2 let a regeneration fall back to a 4.x
or 5.x that no install has run. The floor now matches what is locked,
so no installed version changes.
Checked: the lock changes only its content-hash; the calls OCA_edi makes
(generate_from_file, xml_check_xsd, get_flavor, get_level,
get_xml_namespaces, get_facturx_level) match the 6.8 signatures.
--- FR ---
[UPD] requirement : plancher de factur-x à 6.8 hors s390x
Le lock résout déjà factur-x 6.8 sur toute architecture sauf s390x, qui
garde sa branche <4 ; >=4.2 laissait une régénération retomber sur une
4.x ou 5.x qu'aucune installation n'a fait tourner. Le plancher suit
désormais le lock : aucune version installée ne change.
Vérifié : le lock ne change que son content-hash ; les appels d'OCA_edi
(generate_from_file, xml_check_xsd, get_flavor, get_level,
get_xml_namespaces, get_facturx_level) collent aux signatures de 6.8.
Assisted-by: Claude Opus 5.5
The xlsx cleaning of Transform data reaches openpyxl private attributes
(_external_links, _charts, _pivots, _images, _cf_rules), which is why
openpyxl is pinned exactly and each bump has to pass the leak test.
Checked: test_transform_external passes, 511 tests, none skipped,
TestFuiteXlsx included, in a .venv.todo.external_data built from this
file.
--- FR ---
[UPD] todo external data : openpyxl 3.1.5, xlsxwriter 3.2.9
Le nettoyage xlsx de Transform data touche des attributs privés
d'openpyxl (_external_links, _charts, _pivots, _images, _cf_rules) :
d'où une épingle exacte, et chaque montée doit passer le test de fuite.
Vérifié : test_transform_external passe, 511 tests, aucun ignoré,
TestFuiteXlsx compris, dans un .venv.todo.external_data bâti de ce
fichier.
Assisted-by: Claude Opus 5.5
[UPD] requirement: Odoo 18 on pandas 3, cryptography 50, aws 1.43
3 commits. botocore 1.43.49 failed the resolution against aiobotocore
3.1.3, which caps it below 1.42.50; aiobotocore 3.9.0 is the only release
whose range holds it, and Dependabot now proposes the three AWS packages
in one pull request so they stay aligned. pandas moves to 3.0.6: the
seven modules importing it run their pandas calls unchanged, and no
installed package caps it below 3 outside test extras. Checked: the lock
keeps its 362 packages and an installation with the extras succeeds.
--- FR ---
[UPD] requirement : Odoo 18 sur pandas 3, cryptography 50, aws 1.43
3 commits. botocore 1.43.49 faisait échouer la résolution face à
aiobotocore 3.1.3, qui le plafonne sous 1.42.50 ; aiobotocore 3.9.0 est la
seule version dont la plage le contient, et Dependabot propose désormais
les trois paquets AWS dans une seule demande de fusion pour qu'ils restent
alignés. pandas passe en 3.0.6 : les sept modules qui l'importent
exécutent leurs appels pandas sans changement, et aucun paquet installé ne
le borne sous 3 hors extras de test. Vérifié : le lock garde ses 362
paquets et une installation avec les extras réussit.
Assisted-by: Claude Opus 5.5
Records the branch for the next release under Changed: the Odoo 18 move
to pandas 3.0.6, cryptography 50, Pillow 12.3 and the AWS trio aligned on
aiobotocore 3.9.0, with the pandas 4 warning left in a third-party
attendance dashboard, and the Dependabot group that keeps the three AWS
packages in one pull request.
Checked: make doc_markdown regenerates both files, each language only
in its own.
--- FR ---
[UPD] changelog : Odoo 18 sur pandas 3, aws 1.43, groupe aws Dependabot
Consigne la branche pour la prochaine version sous Modifié : le passage
d'Odoo 18 à pandas 3.0.6, cryptography 50, Pillow 12.3 et le trio AWS
aligné sur aiobotocore 3.9.0, avec l'avertissement pandas 4 laissé dans
un tableau de bord de présence tiers, et le groupe Dependabot qui garde
les trois paquets AWS dans une seule demande de fusion.
Vérifié : make doc_markdown régénère les deux fichiers, chaque langue
dans le sien seulement.
Assisted-by: Claude Opus 5.5
botocore 1.43.49 needs aiobotocore 3.9.0, the only release whose range
(>=1.43.3,<1.43.57) holds it; 3.1.3 capped botocore below 1.42.50 and
failed the resolution. pandas 3.0.6: the seven modules importing it run
their pandas calls unchanged, and no installed package caps it below 3
outside test extras. pyopenssl 26.4.0 accepts cryptography 50.
Pillow 12.3.0 is aligned in todo_external_data.txt.
Checked: the lock keeps its 362 packages, PyMuPDF keeps its s390x
marker, and an installation with the extras succeeds.
--- FR ---
[UPD] requirement : Odoo 18 sur pandas 3, cryptography 50, aws 1.43
botocore 1.43.49 exige aiobotocore 3.9.0, la seule version dont la plage
(>=1.43.3,<1.43.57) le contient ; la 3.1.3 plafonnait botocore sous
1.42.50 et faisait échouer la résolution. pandas 3.0.6 : les sept modules
qui l'importent exécutent leurs appels pandas sans changement, et aucun
paquet installé ne le borne sous 3 hors extras de test. pyopenssl 26.4.0
accepte cryptography 50. Pillow 12.3.0 est aligné dans todo_external_data.
Vérifié : le lock garde ses 362 paquets, PyMuPDF son marqueur s390x, et
une installation avec les extras réussit.
Assisted-by: Claude Opus 5.5
Each aiobotocore release accepts only a narrow botocore range, and boto3
pins botocore. Proposed one by one, a botocore bump against an unchanged
aiobotocore fails the resolution. The aws group brings the three version
updates in one pull request; security fixes still arrive on their own.
Dependabot does not solve constraints in a requirements file, so the
grouped versions may still need aligning by hand.
Checked: the YAML parses.
--- FR ---
[UPD] dependabot : grouper aiobotocore, botocore et boto3
Chaque version d'aiobotocore n'accepte qu'une plage étroite de botocore,
et boto3 épingle botocore. Proposées une à une, une montée de botocore
face à un aiobotocore inchangé fait échouer la résolution. Le groupe aws
réunit les trois mises à jour de version dans une seule demande de
fusion ; les correctifs de sécurité arrivent toujours seuls. Dependabot
ne résout pas les contraintes d'un requirements : les versions groupées
peuvent encore demander un alignement à la main.
Vérifié : le YAML se lit.
Assisted-by: Claude Opus 5.5
[UPD] requirement: Odoo 18 lock, poetry update venv, dependabot scope
6 commits. Dependabot opened pull requests against the frozen requirements
of Odoo 12 to 17; its security updates now fall under the exclusions, and
meteostat 2.x, which caps pytz below 2024, is ignored. poetry_update.py
names make switch_odoo_XX when pyproject.toml is missing and runs Poetry in
the Odoo venv, not in an active .venv.erplibre. The Odoo 18 lock resolves
again with openai, fsspec and idna pinned. Checked: no dependency leaves the
pyproject or the lock. Not tested: majors ujson 6, plotly 7, sqlalchemy 2.1.
--- FR ---
[UPD] requirement : lock Odoo 18, venv poetry update, portée dependabot
6 commits. Dependabot ouvrait des demandes de fusion sur les requirements
figés d'Odoo 12 à 17 ; ses mises à jour de sécurité tombent désormais sous
les exclusions, et meteostat 2.x, qui plafonne pytz sous 2024, est ignoré.
poetry_update.py nomme make switch_odoo_XX quand pyproject.toml manque et
fait tourner Poetry dans le venv Odoo, pas dans un .venv.erplibre actif. Le
lock d'Odoo 18 se résout de nouveau, openai, fsspec et idna épinglés.
Vérifié : aucune dépendance ne quitte le pyproject ni le lock. Non testé :
majeures ujson 6, plotly 7, sqlalchemy 2.1.
Assisted-by: Claude Opus 5.5
Records the dev/github_bot branch for the next release: Dependabot out
of the frozen Odoo 12 to 17 requirements, poetry_update.py on a missing
pyproject.toml and in the Odoo venv, the refreshed Odoo 18 lock with its
untested majors, and idna 3.20 under Security.
Checked: make doc_markdown regenerates both files, each language only
in its own.
--- FR ---
[UPD] changelog : portée dependabot, venv poetry update, lock Odoo 18
Consigne la branche dev/github_bot pour la prochaine version : Dependabot
hors des requirements figés d'Odoo 12 à 17, poetry_update.py sur un
pyproject.toml absent et dans le venv Odoo, le lock d'Odoo 18 rafraîchi
avec ses majeures non testées, et idna 3.20 sous Sécurité.
Vérifié : make doc_markdown régénère les deux fichiers, chaque langue
dans le sien seulement.
Assisted-by: Claude Opus 5.5
Unpinned, openai and fsspec float to releases that break resolution:
openai 3.x needs idna>=3.18 against the idna==3.6 of Odoo, and s3fs
wants fsspec at its own exact version. openai stays on 2.x, fsspec moves
with s3fs, idna 3.20 overrides Odoo (3.6 carries CVE-2024-3651).
meteostat returns to 1.x, every 2.x caps pytz below 2024. The s390x
exclusion of PyMuPDF now lives in the requirements, so it survives.
Checked: no dependency leaves the pyproject (194 to 196) or the lock.
Not tested: majors ujson 6, plotly 7, python-slugify 9, sqlalchemy 2.1.
--- FR ---
[UPD] requirement : lock Odoo 18 à jour, épingles openai, idna et fsspec
Sans borne, openai et fsspec dérivent vers des versions qui cassent la
résolution : openai 3.x exige idna>=3.18 contre l'idna==3.6 d'Odoo, et
s3fs veut fsspec à sa propre version exacte. openai reste en 2.x, fsspec
suit s3fs, idna 3.20 supplante Odoo (la 3.6 porte CVE-2024-3651).
meteostat revient en 1.x, toute 2.x plafonne pytz sous 2024. L'exclusion
s390x de PyMuPDF vit désormais dans les requirements : elle survit.
Vérifié : aucune dépendance ne quitte le pyproject (194 à 196) ni le lock.
Non testé : majeures ujson 6, plotly 7, python-slugify 9, sqlalchemy 2.1.
Assisted-by: Claude Opus 5.5
Every meteostat 2.x release, 2.0.0 to 2.1.5, requires pytz <2024.0.
Odoo leaves pytz unpinned, so the resolution takes the current release
and meteostat 2.x makes it fail; forcing pytz down instead would freeze
the timezone data of every Odoo instance. meteostat 1.x leaves pytz
free, so only its minor and patch updates are proposed.
Checked: requires_dist of each 2.x release on PyPI; the YAML parses.
--- FR ---
[UPD] dependabot : ignorer les versions majeures de meteostat
Chaque version 2.x de meteostat, de 2.0.0 à 2.1.5, exige pytz <2024.0.
Odoo laisse pytz libre, la résolution prend donc la version courante et
meteostat 2.x la fait échouer ; forcer pytz vers le bas figerait les
données de fuseaux horaires de toute instance Odoo. meteostat 1.x laisse
pytz libre : seules ses versions mineures et correctives sont proposées.
Vérifié : requires_dist de chaque version 2.x sur PyPI ; le YAML se lit.
Assisted-by: Claude Opus 5.5
Poetry works in the active virtualenv when VIRTUAL_ENV is set. Launched
from a shell under .venv.erplibre, poetry add and poetry lock inherited
its Python, outside the pyproject bounds, and failed with
InvalidCurrentPythonVersionError. Both calls now activate the Odoo venv
of the ERPLibre version, as install_locally.sh already does.
Checked: poetry env info -p reports .venv.erplibre before, the Odoo
venv after, for the shell script and for the Python call alike.
--- FR ---
[FIX] poetry update : poetry dans le venv Odoo, pas dans le venv actif
Poetry travaille dans le virtualenv actif quand VIRTUAL_ENV est posé.
Lancés d'un shell sous .venv.erplibre, poetry add et poetry lock en
héritaient le Python, hors des bornes du pyproject, et échouaient sur
InvalidCurrentPythonVersionError. Les deux appels activent désormais le
venv Odoo de la version ERPLibre, comme le fait déjà install_locally.sh.
Vérifié : poetry env info -p donne .venv.erplibre avant, le venv Odoo
après, pour le script shell comme pour l'appel Python.
Assisted-by: Claude Opus 5.5
The root pyproject.toml and poetry.lock are unversioned symlinks to the
active version's files in requirement/, created by the version switch.
Without them the script died on a FileNotFoundError traceback. It now
names the fix, make switch_odoo_XX for the active Odoo version; on a
terminal it offers to run it and restarts with the same arguments.
Checked: an existing file passes, a missing one exits 1 off a terminal
and on a declined prompt. The accepted path, which runs the switch, is
not tested.
--- FR ---
[FIX] poetry update : arrêt sur pyproject.toml absent, switch proposé
pyproject.toml et poetry.lock à la racine sont des liens non versionnés
vers les fichiers de la version active dans requirement/, créés par le
switch de version. Sans eux, le script mourait sur un FileNotFoundError.
Il nomme désormais le remède, make switch_odoo_XX pour la version Odoo
active ; dans un terminal, il propose de le lancer et se relance avec
les mêmes arguments. Vérifié : un fichier présent passe, un absent sort
en 1 hors terminal et sur un refus. L'acceptation, qui lance le switch,
n'est pas testée.
Assisted-by: Claude Opus 5.5
Security updates reuse a dependabot.yml entry only when its directory
matches the manifest's; they scan requirement/ as "/requirement", which
no entry declared, so their pull requests bumped the frozen pins of
Odoo 12 to 17. Only Odoo 18 now receives updates. Globs replace the
exact names and also cover ignore_requirements, pyproject and poetry.lock.
Checked: the YAML parses and the globs match 27 files in requirement/,
none for odoo18. Not yet checked on GitHub: takes effect once on master.
--- FR ---
[FIX] dependabot : exclure aussi Odoo 12-17 des mises à jour de sécurité
Les mises à jour de sécurité ne reprennent une entrée de dependabot.yml
que si son répertoire correspond à celui du manifeste ; elles lisent
requirement/ comme « /requirement », qu'aucune entrée ne déclarait, d'où
des PR qui modifiaient les versions figées d'Odoo 12 à 17. Seul Odoo 18
reçoit désormais les mises à jour. Des globs remplacent les noms exacts
et couvrent aussi ignore_requirements, pyproject et poetry.lock.
Vérifié : le YAML se lit et les globs ciblent 27 fichiers de requirement/,
aucun pour odoo18. Non vérifié sur GitHub : effectif une fois sur master.
Assisted-by: Claude Opus 5.5
[IMP] todo: safe startup, Claude command sync, English-first commits
8 commits. make runs todo.sh, whose name says a menu opens; install.sh keeps
choosing the interpreter, now probed by running code, since python -V
vouched for a venv built on another machine that could not start. The
install, which deletes an existing .venv.erplibre, runs only on a yes. The
Claude command list shows missing and outdated copies, their diff, and
redeploys them; commit messages open in English with a French title under
--- FR ---, enforced by the hook; language and Fork move to Configuration.
Checked: unit suites of each piece pass, 108 in test_todo and i18n.
--- FR ---
[IMP] todo : démarrage sûr, commandes Claude à jour, commits en anglais
8 commits. make lance todo.sh, dont le nom annonce un menu ; install.sh garde
le choix de l'interpréteur, sondé désormais en exécutant du code, puisque
python -V cautionnait un venv bâti sur une autre machine incapable de
démarrer. L'installation, qui supprime un .venv.erplibre existant, ne part
que sur un oui. La liste des commandes Claude montre les copies absentes et
périmées, leur diff, et les redéploie ; les messages de commit s'ouvrent en
anglais avec un titre français sous --- FR ---, que le hook exige ; la
langue et Fork passent dans Configuration.
Vérifié : suites unitaires de chaque partie au vert, 108 pour test_todo et i18n.
Assisted-by: Claude Opus 5.5
Four entries record what the branch changes for a user: a .venv.erplibre
built elsewhere is reported instead of launched, the Claude command list
shows missing and outdated copies and redeploys them, commit messages open
in English, and the language and Fork entries move to Configuration.
Checked: make doc_markdown regenerates both files, bullets aligned.
--- FR ---
[UPD] changelog : sonde du venv, liste des commandes, règle, menus TODO
Quatre entrées disent ce que la branche change pour l'utilisateur : un
.venv.erplibre bâti ailleurs est signalé plutôt que lancé, la liste des
commandes Claude montre les copies absentes et périmées et les redéploie, les
messages de commit s'ouvrent en anglais, et la langue et Fork passent dans
Configuration.
Vérifié : make doc_markdown régénère les deux fichiers, puces alignées.
Assisted-by: Claude Opus 5.5
Execute carried a Preferences section whose one entry, the language, is
already Configuration's first item: two places for one setting. It is
removed, with its two unused translations. Fork, which opens a second TODO,
leaves the main menu for Configuration; the main menu now numbers Telemetry
4 and Configuration 5, and Reset all preferences becomes 6.
Checked: Configuration displayed with Fork at 5; 108 tests pass.
--- FR ---
[IMP] menus todo : langue dans Configuration seule, Fork y déménage
Execute portait une section Préférences dont la seule entrée, la langue, est
déjà la première de Configuration : deux endroits pour un réglage. Elle part,
avec ses deux traductions devenues inutiles. Fork, qui ouvre un second TODO,
quitte le menu principal pour Configuration ; le menu principal numérote
désormais Télémétrie 4 et Configuration 5, et la réinitialisation devient 6.
Vérifié : Configuration affichée avec Fork en 5 ; 108 tests passent.
Assisted-by: Claude Opus 5.5
The language chooser was the only TODO screen without icons, and it spelled
Francais without its accent. The first-launch prompt and the one reached
from Configuration now open on a globe and mark each language with its flag;
the label reads Français in both.
Checked: both prompts displayed; test_todo and i18n tests, 108, pass.
--- FR ---
[IMP] todo : icônes au choix de la langue, accent sur Français
Le choix de la langue était le seul écran de TODO sans icône, et il écrivait
Francais sans accent. L'invite du premier lancement et celle de Configuration
s'ouvrent désormais sur un globe et marquent chaque langue de son drapeau ;
le libellé se lit Français dans les deux.
Vérifié : les deux invites affichées ; test_todo et tests i18n, 108, passent.
Assisted-by: Claude Opus 5.5
The command list showed only what sat in ~/.claude/commands, with a date:
a command never installed stayed invisible, and a copy older than its
template in conf/ looked the same as a current one. Each ERPLibre template is
now compared with its copy, ignoring the git identity line: not installed,
up to date, or to redeploy with its +/- line count; other commands are
marked not from ERPLibre. On y/N it shows the diff, then redeploys the
outdated copies, keeping the name and e-mail /commit carried.
Checked: 7 new tests on a temporary directory; test_todo, 81 tests, passes.
--- FR ---
[IMP] todo configs claude : commandes absentes, périmées, redéploiement
La liste des commandes ne montrait que le contenu de ~/.claude/commands,
avec une date : une commande jamais installée restait invisible, et une copie
plus vieille que son gabarit de conf/ ressemblait à une copie à jour. Chaque
gabarit d'ERPLibre est désormais comparé à sa copie, hors ligne d'identité
git : non installée, à jour, ou à redéployer avec son compte +/- ; les autres
commandes sont marquées hors ERPLibre. Sur o/N elle montre le diff, puis
redéploie les copies périmées en gardant le nom et le courriel de /commit.
Vérifié : 7 nouveaux tests sur un dossier temporaire ; test_todo, 81 tests.
Assisted-by: Claude Opus 5.5
git log --oneline shows only the subject, and it read in whichever language
the author was thinking in. The subject and the body under it are now in
English, then --- FR --- opens the French section, which starts with the
subject translated under the same tag. The hook refuses a --- EN --- marker
and a French section without that title, and checks the title like a
subject; it does not count against the body budget. Whether the subject is
really English is not checked. /commit and /git_prepare_merge follow.
Checked: 55 hook tests, 7 of them new; i18n tests pass.
--- FR ---
[UPD] règle de commit : sujet anglais d'abord, titre FR sous --- FR ---
git log --oneline ne montre que le sujet, et il se lisait dans la langue où
l'auteur pensait. Le sujet et le corps qui le suit sont désormais en anglais,
puis --- FR --- ouvre la section française, qui commence par le sujet traduit
sous le même tag. Le hook refuse un marqueur --- EN --- et une section
française sans ce titre, et juge ce titre comme un sujet ; il ne compte pas
dans le budget du corps. Que le sujet soit vraiment en anglais ne se vérifie
pas. /commit et /git_prepare_merge suivent.
Vérifié : 55 tests du hook, dont 7 nouveaux ; tests i18n au vert.
Assisted-by: Claude Opus 5.5
On a system too old to read TODO, install.sh ran the install without asking,
and the install DELETES an existing .venv.erplibre. It now runs only on a yes
typed in a terminal: o, oui, y or yes, any case. Enter alone means no, and
with no terminal no question is asked and nothing is installed. « aucun
python3 » finally shows when the probe is silent: the || fallback never fired
behind a pipe.
Checked: 16 tests, each answer on a pseudo-terminal; install.sh run in an
isolated copy exits 1 on « n » and installs on « o ».
--- FR ---
[IMP] install.sh : demander o/N avant d'installer le venv d'outillage
Sur un système trop ancien pour lire TODO, install.sh lançait l'installation
sans rien demander, et celle-ci SUPPRIME un .venv.erplibre existant. Elle ne
part plus que sur un oui tapé au terminal : o, oui, y ou yes, toute casse.
Entrée seule vaut non, et sans terminal aucune question n'est posée ni
installation lancée. « aucun python3 » s'affiche enfin quand la sonde est
muette : le repli par || ne se déclenchait jamais derrière un tube.
Vérifié : 16 tests, dont chaque réponse sur un pseudo-terminal ; install.sh
lancé dans une copie isolée sort en 1 sur « n » et installe sur « o ».
Assisted-by: Claude Opus 5.5
make prints the recipe it runs, and « ./install.sh » offered an installation
to read where one opens a menu. The launcher adds nothing but a name and
passes every argument to install.sh, which alone keeps picking an interpreter
able to READ the code and stays the entry point of a fresh machine.
A test caps todo.sh at six lines of code and refuses it python3, bin/python
and sort -V: two copies of that choice would drift. The changelog names the
launcher.
Checked: chain run through to the menu, exit 0; 9 tests.
--- FR ---
[ADD] todo : lanceur todo.sh, que make affiche à la place d'install.sh
make affiche la recette qu'il exécute, et « ./install.sh » y donnait à lire
une installation là où l'on ouvre un menu. Le lanceur n'ajoute qu'un nom et
passe chaque argument à install.sh, qui garde seul le choix d'un interpréteur
capable de LIRE le code et reste le point d'entrée d'une machine neuve.
Un test plafonne todo.sh à six lignes de code et lui refuse python3,
bin/python et sort -V : deux copies de ce choix dériveraient. Le changelog
nomme le lanceur.
Vérifié : chaîne lancée jusqu'au menu, sortie 0 ; 9 tests.
Assisted-by: Claude Opus 5
Assisted-by: Claude Opus 5.5
"python -V" answers before loading the standard library. A venv whose
interpreter cannot find it, such as a checkout mounted from another machine,
still reported its version and passed as healthy. install.sh then handed TODO
to it, which died on "No module named 'encodings'", and the "venv built
elsewhere" guard never printed. The probe now runs "import sys": an
interpreter that cannot start returns nothing.
Checked: a fake python that answers -V but fails otherwise makes the test
fail on the old code and pass with the fix.
--- FR ---
[FIX] install.sh : sonder la version en exécutant du code, non par -V
« python -V » répond avant de charger la bibliothèque standard. Un venv dont
l'interpréteur ne la trouve pas, comme un checkout monté depuis une autre
machine, rendait donc sa version et passait pour sain. install.sh lui passait
alors TODO, qui mourait sur « No module named 'encodings' », et le garde
« venv bâti ailleurs » ne s'affichait jamais. La sonde exécute maintenant
« import sys » : un interpréteur qui ne démarre pas ne rend rien.
Vérifié : un faux python sain à -V mais mort ailleurs fait échouer le test
sur l'ancien code et le réussit avec la correction.
Assisted-by: Claude Opus 5.5
« python -V » répond avant de charger la bibliothèque standard. Un venv dont
l'interpréteur ne la trouve pas, comme un checkout monté depuis une autre
machine, rendait donc sa version et passait pour sain. install.sh lui passait
alors TODO, qui mourait sur « No module named 'encodings' », et le garde
« venv bâti ailleurs » ne s'affichait jamais. La sonde exécute maintenant
« import sys » : un interpréteur qui ne démarre pas ne rend rien.
Vérifié : un faux python sain à -V mais mort ailleurs fait échouer le test
sur l'ancien code et le réussit avec la correction.
--- EN ---
"python -V" answers before loading the standard library. A venv whose
interpreter cannot find it, such as a checkout mounted from another machine,
still reported its version and passed as healthy. install.sh then handed TODO
to it, which died on "No module named 'encodings'", and the "venv built
elsewhere" guard never printed. The probe now runs "import sys": an
interpreter that cannot start returns nothing.
Checked: a fake python that answers -V but fails otherwise makes the test
fail on the old code and pass with the fix.
Assisted-by: Claude Opus 5.5
Le formateur de ce dépôt est ruff depuis qu'il remplace black, qui ne connaît
aucune cible au-delà de py313 ; ce passage applique sa norme à l'arbre entier,
d'un coup, pour qu'aucun commit de fond n'ait à porter du style. L'écart tient
presque entièrement aux chaînes coupées à la main que ruff recolle quand elles
tiennent sur une ligne, et aux « with » multiples qu'il regroupe : aucune
valeur ne change, et les clés de traduction non plus.
Vérifié : la suite unitaire reste verte après le passage, et le contrôle de
syntaxe ne signale rien.
--- EN ---
This repository's formatter is ruff since it replaced black, which knows no
target beyond py313; this pass applies its standard to the whole tree at once,
so that no substantive commit has to carry style. The difference is almost
entirely the hand-split strings ruff joins back when they fit on one line, and
the multiple "with" it merges: no value changes, nor do the translation keys.
Checked: the unit suite stays green after the pass, and the syntax check
reports nothing.
Assisted-by: Claude Opus 5
[UPD] outillage : un Python à lui, un formateur par contexte, des gardes
17 commits. Le venv d'outillage prenait le python3 du système, quel qu'il
soit : sur une machine en 3.10, TODO mourait sur une SyntaxError avant tout
message, et rien ne permettait plus de lancer l'installation qui en serait
sorti. Il a désormais sa version, distincte de celle d'Odoo, et le patch ne
borne que cette dernière — l'exiger partout écartait un Python de
distribution d'un cran en retard et faisait compiler CPython pour rien. Le
formatage suit le contexte : ruff ici, la norme OCA pour les modules Odoo.
Debian 11 part, sa suite de sécurité n'étant ni servie ni archivée.
Vérifié : 6764 tests verts, et l'arbre Python parse de 3.10 à 3.14.
--- EN ---
17 commits. The tooling venv took the system python3, whatever it was: on a
3.10 machine TODO died on a SyntaxError before any message, and nothing could
start the install that would have rescued it. It now has its own version,
distinct from Odoo's, and the patch bounds only the latter — requiring it
everywhere turned away a distribution Python one step behind and compiled
CPython for nothing. Formatting follows context: ruff here, the OCA standard
for Odoo modules. Debian 11 goes, its security suite being neither served nor
archived.
Checked: 6764 tests green, and the Python tree parses from 3.10 to 3.14.
Assisted-by: Claude Opus 5
Cinq livraisons de cette branche manquaient à la liste du non-publié : le proxy
SOCKS du menu de déploiement et la cible qui formate les tests, côté ajouts ;
la reprise d'un téléchargement coupé, le faisceau de certificats désigné
seulement s'il existe, et « make version » qui nomme les deux Python, côté
corrections. Un lecteur qui choisit de mettre à jour n'y voyait donc ni la
commande neuve ni les trois pannes levées.
Vérifié : les quatre sections du non-publié comptent autant de puces en
français qu'en anglais, et les deux fichiers générés suivent leur source.
--- EN ---
Five of this branch's deliveries were missing from the unreleased list: the
SOCKS proxy of the deployment menu and the target formatting the tests, on the
added side; the resume of an interrupted download, the certificate bundle named
only when it exists, and "make version" naming both Pythons, on the fixed side.
A reader choosing whether to upgrade saw neither the new command nor the three
failures lifted.
Checked: the four unreleased sections carry as many bullets in French as in
English, and both generated files follow their source.
Assisted-by: Claude Opus 5
tasks/ porte les notes de travail que la convention garde hors du dépôt, et
.erplibre-state.json l'état de ce qu'un checkout a installé, écrit par
erplibre_state.py. Non ignorés, un « git add -A » les emportait.
--- EN ---
tasks/ holds the working notes the convention keeps out of the repository,
and .erplibre-state.json the state of what a checkout has installed, written
by erplibre_state.py. Left unignored, a "git add -A" swept them in.
Assisted-by: Claude Opus 5
« make version » lit .python-odoo-version et l'affichait sous le libellé nu
« Python version ». Tant que les deux venvs partageaient leur interpréteur, le
libellé suffisait ; depuis qu'ils divergent, il laisse croire que le dépôt n'a
qu'une version de Python, et le chiffre affiché n'est pas celui du venv dans
lequel l'utilisateur travaille. Les deux sont désormais nommées, celle d'Odoo
comme celle de l'outillage. Seule la sortie change : cette valeur ne participe
à aucun identifiant, et l'absence du fichier reste sans conséquence.
Vérifié : les deux versions s'affichent, puis la conclusion reste la même.
--- EN ---
"make version" reads .python-odoo-version and printed it under the bare label
"Python version". While both venvs shared their interpreter the label was
enough; now that they diverge, it suggests the repository has a single Python
version, and the figure shown is not that of the venv the user works in. Both
are now named, Odoo's and the tooling's. Only the output changes: this value
takes part in no identifier, and a missing file stays without consequence.
Checked: both versions print, then the conclusion stays the same.
Assisted-by: Claude Opus 5
Elle faisait ajouter bullseye-security pour y prendre libssl1.1 sur Debian 13.
Ce dépôt n'existe plus : son index est encore publié mais son pool ne porte
plus les fichiers, et rien n'en a été archivé. La recette ne pouvait donc que
donner une source morte, puis une erreur qui n'en désigne pas la cause.
Elle était en outre inutile : le build de wkhtmltopdf qu'on installe là-bas
est celui de bookworm, qui réclame libssl3 — que trixie fournit sous le nom
libssl3t64, en déclarant « Provides: libssl3 ». L'installation se résout donc
seule. La section qui suit garde l'issue de secours, un service en conteneur.
Vérifié : plus aucune mention de bullseye ni de libssl1.1 dans la FAQ.
--- EN ---
It had the reader add bullseye-security to take libssl1.1 from it on Debian
13. That repository is gone: its index is still published but its pool no
longer holds the files, and nothing was archived. The recipe could therefore
only yield a dead source, then an error naming none of its cause. It was
useless besides: the wkhtmltopdf build installed there is bookworm's, which
requires libssl3 — which trixie supplies as libssl3t64, declaring "Provides:
libssl3". The install resolves on its own. The next section keeps the fallback,
a containerised service.
Checked: no mention of bullseye or libssl1.1 left in the FAQ.
Assisted-by: Claude Opus 5
Odoo 13, 14 et 15 bâtissaient encore sur bullseye, dont le dépôt de sécurité
est démantelé. Rien ne les y obligeait : la base est
« python:<version>-slim-<version Debian> », donc l'interpréteur vient de
l'image officielle et non de Debian — les variantes bookworm existent jusqu'à
3.7.17. L'aiguillage portait en outre une branche « buster » INATTEIGNABLE,
sa condition étant la négation de celle qui la précédait ; elle part avec le
reste. Le build de wkhtmltopdf suit la version : celui de bullseye réclame
libssl1.1, absente de bookworm.
Vérifié : les images 3.7.17 et 3.8.20 slim-bookworm existent, le .deb bookworm
rend l'empreinte déclarée, et ses quinze dépendances sont dans bookworm.
--- EN ---
Odoo 13, 14 and 15 still built on bullseye, whose security repository is
dismantled. Nothing required it: the base is
"python:<version>-slim-<suite>", so the interpreter comes from the official
image and not from Debian — the bookworm variants exist down to 3.7.17. The
switch also carried an UNREACHABLE "buster" branch, its condition being the
negation of the one before it; it goes with the rest. The wkhtmltopdf build
follows the suite: bullseye's requires libssl1.1, absent from bookworm.
Checked: the 3.7.17 and 3.8.20 slim-bookworm images exist, the bookworm .deb
matches the declared checksum, and its fifteen dependencies are in bookworm.
Assisted-by: Claude Opus 5
Son LTS est terminé, et sa suite de sécurité n'est ni servie ni archivée :
security.debian.org publie encore un index qui nomme des paquets dont le pool
ne porte plus le fichier, et archive.debian.org ne connaît pas bullseye. apt
s'arrête donc avant d'installer git, sur une version qui ne recevra plus rien.
Elle quitte le catalogue de déploiement et le script de dépendances, où la
variable qui la distinguait n'a plus d'usage. Debian 12 et 13 restent, et
l'image de la 13 est toujours le dernier point de version — sans rien à
changer ici quand le suivant paraît.
Vérifié : plus aucune trace de bullseye dans script/, hors la base des
conteneurs, traitée à part.
--- EN ---
Its LTS has ended, and its security suite is neither served nor archived:
security.debian.org still publishes an index naming packages whose pool no
longer holds the file, and archive.debian.org does not know bullseye. apt
therefore stops before installing git, on a version that will receive nothing
more. It leaves the deployment catalogue and the dependency script, where the
variable telling it apart has no use left. Debian 12 and 13 stay, and 13's
image is always the latest point release — with nothing to change here when
the next one appears.
Checked: no trace of bullseye left in script/, beyond the container base,
handled separately.
Assisted-by: Claude Opus 5
Les variables du cache — PIP_CERT et ses voisines — recevaient le chemin
canonique de la famille de paquets, sans que rien ne vérifie qu'il soit là. Une
image peut ne pas le porter : sur une Fedora récente,
« /etc/pki/tls/certs/ca-bundle.crt » manque alors que le faisceau extrait
existe. pip refuse alors TOUT téléchargement, y compris ce qui n'a rien à voir
avec le cache, et l'installation s'arrête sur des paquets publics. Le faisceau
de la famille est essayé d'abord, les autres connus ensuite ; aucun trouvé
n'écrit aucune variable, et pip garde son propre jeu de certificats.
Vérifié : la commande produite parcourt les quatre chemins avant de renoncer.
--- EN ---
The cache variables — PIP_CERT and its neighbours — received the canonical path
of the package family, with nothing checking it was there. An image may not
carry it: on a recent Fedora, "/etc/pki/tls/certs/ca-bundle.crt" is missing
while the extracted bundle exists. pip then refuses EVERY download, including
what has nothing to do with the cache, and the install stops on public
packages. The family bundle is tried first, the other known ones next; none
found writes no variable, and pip keeps its own certificate set.
Checked: the produced command walks the four paths before giving up.
Assisted-by: Claude Opus 5
Une image de VM pèse un demi-gigaoctet : une coupure y est bien plus probable
que sur une page. Le contrôle de complétude existait — sans lui un .part
tronqué passait pour une image, donnant un qcow2 valide mais VIDE — mais il
jetait les octets reçus et renvoyait l'utilisateur à un « curl -C - » tapé à
la main. Le transfert se reprend désormais sur le même miroir, trois essais,
par un « Range » qui demande la suite ; on ne change de miroir qu'ensuite. Un
serveur qui ignore le Range rend le fichier entier, et l'on repart alors de
zéro plutôt que de doubler les octets déjà là.
Vérifié : 5 tests contre un serveur qui coupe au tiers, image reconstituée à
l'octet près, et le .part tronqué part quand les reprises s'épuisent.
--- EN ---
A VM image weighs half a gigabyte: an interruption is far likelier there than
on a page. The completeness check existed — without it a truncated .part
passed for an image, giving a valid but EMPTY qcow2 — but it threw away the
bytes received and sent the user back to a hand-typed "curl -C -". The
transfer now resumes on the same mirror, three attempts, through a "Range"
asking for the rest; only then does it change mirror. A server ignoring the
Range returns the whole file, and we restart from zero rather than doubling
the bytes already there.
Checked: 5 tests against a server cutting at one third, image reassembled byte
for byte, and the truncated .part goes when the retries run out.
Assisted-by: Claude Opus 5
Les six cibles d'addons visaient « ./addons/<dépôt>/ », une disposition que
seul un manifeste produit : la production les range sous
« odoo<version>/addons/ ». isort s'arrêtait donc sur une trace pour un chemin
inexistant, et « make format_all » échouait sans avoir formaté un module. Les
dépôts sont maintenant NOMMÉS, cherchés sous les deux dispositions, et celui
qu'un manifeste ne rapatrie pas s'annonce puis est ignoré. Le formateur est
celui de la communauté, qui a quitté black : ruff en 88 colonnes, avec les
sections d'imports « odoo » et « odoo.addons » qu'isort ne sait pas produire.
Vérifié : trois des six dépôts sont présents ici, les autres s'annoncent
absents sans faire échouer la cible.
--- EN ---
The six addons targets aimed at "./addons/<repo>/", a layout only one manifest
produces: production files them under "odoo<version>/addons/". isort therefore
stopped on a traceback for a non-existent path, and "make format_all" failed
without formatting a module. Repositories are now NAMED, looked up under both
layouts, and one a manifest does not check out announces itself then is
skipped. The formatter is the community's, which left black: ruff at 88
columns, with the "odoo" and "odoo.addons" import sections isort cannot
produce.
Checked: three of the six repositories are present here, the others announce
themselves absent without failing the target.
Assisted-by: Claude Opus 5
Un échec de « repo forall » arrêtait tout : la liste des fichiers locaux, déjà
obtenue, était jetée, et « make format » rendait 0 sans avoir formaté une
ligne. Sa sortie d'erreur, capturée puis jetée, emportait la seule explication,
et seule l'exception Python restait à l'écran. Google Repo n'ajoute pourtant
que les dépôts rapatriés : il est joué sans check, ce qu'il a écrit est relayé,
et les fichiers locaux sont formatés quand même. « Rien à formater » se dit au
lieu d'une sortie muette, et un échec du dépôt lui-même rend non nul.
Vérifié : avec un repo bouchonné qui échoue, son message s'affiche et le
fichier local est formaté.
--- EN ---
A failing "repo forall" stopped everything: the local file list, already
gathered, was dropped, and "make format" returned 0 without formatting a line.
Its error output, captured then thrown away, carried the only explanation, and
only the Python exception stayed on screen. Google Repo only adds the checked
out repositories: it runs without check, whatever it wrote is relayed, and
local files are formatted anyway. "Nothing to format" is said instead of a
silent exit, and a failure of the repository itself returns non-zero.
Checked: with a stub repo that fails, its message shows and the local file is
formatted.
Assisted-by: Claude Opus 5
« -L » relaie UN service ; « -D » ouvre un relais SOCKS, par lequel le
navigateur atteint n'importe quelle destination depuis la machine distante —
une interface qui n'écoute que sur sa boucle locale, un hôte de son réseau sans
route depuis ici. Le port par défaut est 1080, modifiable, et contrôlé libre
avant d'ouvrir. La saisie de l'adresse est celle de sshfs, désormais partagée :
l'alias de ~/.ssh/config part tel quel à ssh, faute de quoi son ProxyJump se
perdrait et une VM imbriquée deviendrait injoignable. Le réglage de Firefox
s'affiche AVANT le lancement, la commande ne rendant la main qu'au Ctrl+C.
Vérifié : 9 tests neufs, et la numérotation du menu que deux autres gardent.
--- EN ---
"-L" relays ONE service; "-D" opens a SOCKS relay, through which the browser
reaches any destination from the remote machine — an interface listening only
on its loopback, a host of its network with no route from here. The default
port is 1080, changeable, and checked free before opening. The address prompt
is sshfs's, now shared: the ~/.ssh/config alias goes to ssh as is, failing
which its ProxyJump would be lost and a nested VM become unreachable. The
Firefox settings print BEFORE the launch, the command only returning on
Ctrl+C.
Checked: 9 new tests, and the menu numbering two others guard.
Assisted-by: Claude Opus 5
install.sh et make lançaient todo.py par son hashbang, donc par le python3 du
PATH, sans rien garantir de sa version : une syntaxe plus récente l'arrête en
SyntaxError au chargement, et le poste hors d'âge perd tout moyen de lancer
l'installation qui l'en sortirait. L'ordre est désormais le venv d'outillage,
sinon le python3 du PATH s'il suffit, sinon l'installation. TODO lui-même se
relance dans le venv, vérifie version et modules avant ses imports, et propose
l'installation en terminal — ce que « make » sur un clone neuf promet depuis
toujours sans le tenir.
Vérifié : venv à jour, venv périmé, systèmes en 3.10, 3.14 et 3.15 vont chacun
où il faut ; un import du module ne relance rien et lève comme avant.
--- EN ---
install.sh and make ran todo.py through its hashbang, so through the python3 of
the PATH, with no guarantee about its version: a newer syntax stops it with a
SyntaxError at load, and the ageing machine loses every way to start the
install that would rescue it. The order is now the tools venv, else the python3
of the PATH when it suffices, else the install. TODO itself relaunches in the
venv, checks version and modules before its imports, and offers the install in
a terminal — what "make" on a fresh clone has always promised without
keeping.
Checked: fresh venv, stale venv, systems on 3.10, 3.14 and 3.15 each go where
they should; importing the module relaunches nothing and raises as before.
Assisted-by: Claude Opus 5
install_erplibre.sh bâtissait .venv.erplibre avec le python3 du système, quelle
que soit sa version : un 3.10 y donnait un venv que l'outillage ne sait pas
charger. Il délègue à install_venv.sh, qui obtient la version par mise, pyenv
ou la distribution, et rebâtit un venv hors service. Le PATCH ne borne que le
venv d'Odoo, dont le pyproject exige « >=3.12.10,<3.13 » : l'exiger ailleurs
écartait un Python de distribution d'un cran en retard — NixOS 25.11 livre
3.14.2 — et faisait compiler CPython pour rien. Le module NixOS déclare
désormais les DEUX Python, substitués depuis les fichiers de version.
Vérifié : 15 tests sur des venvs factices, conservés, rebâtis ou refusés selon
leur état, et un chemin sans pyvenv.cfg garde son contenu.
--- EN ---
install_erplibre.sh built .venv.erplibre with the system python3, whatever its
version: a 3.10 gave a venv the tooling cannot load. It delegates to
install_venv.sh, which obtains the version through mise, pyenv or the
distribution, and rebuilds a venv out of service. The PATCH bounds only Odoo's
venv, whose pyproject requires ">=3.12.10,<3.13": requiring it elsewhere turned
away a distribution Python one step behind — NixOS 25.11 ships 3.14.2 — and
compiled CPython for nothing. The NixOS module now declares BOTH Pythons,
substituted from the version files.
Checked: 15 tests on stub venvs, kept, rebuilt or refused by their state, and a
path without pyvenv.cfg keeps its content.
Assisted-by: Claude Opus 5
Une syntaxe plus récente que le Python du dépôt ne casse qu'au chargement, et
aucun outil en place ne la voyait : la cible de black borne ce qu'il ÉCRIT,
jamais ce qu'il accepte, et flake8 analyse avec l'interpréteur courant. Le
contrôle compile les fichiers indexés avec un vrai interpréteur de la version
déclarée, trouvé sans réseau par mise, pyenv ou le PATH, et se prend lui-même
quand il y tourne déjà. Sans interpréteur, il DIT qu'il n'a pas vérifié plutôt
que de laisser croire le contraire. Le hook relaie, sans bloquer le commit, et
écarte les dépôts rapatriés dont ce dépôt ne répond pas.
Vérifié : les f-strings PEP 701 de la révision précédente sont signalées, rien
ne l'est sur l'arbre courant, et l'absence du fichier de version se dit.
--- EN ---
A syntax newer than the repository's Python only breaks at load, and no tool in
place saw it: black's target bounds what it WRITES, never what it accepts, and
flake8 parses with the running interpreter. The check compiles staged files
with a real interpreter of the declared version, found without network through
mise, pyenv or the PATH, and takes itself when it already runs under it.
Without one, it SAYS it did not check rather than implying it did. The hook
relays, without blocking the commit, and skips the checked-out repositories
this one does not answer for.
Checked: the PEP 701 f-strings of the previous revision are reported, nothing
is on the current tree, and a missing version file is announced.
Assisted-by: Claude Opus 5
Cinq fichiers employaient des f-strings PEP 701 — guillemets imbriqués du même
type, backslash dans l'expression, expression sur plusieurs lignes — que
Python refuse avant 3.12. Or les hooks de script/git/hooks portent
« #!/usr/bin/env python3 » et tournent donc sur l'interpréteur du système,
qu'une distribution livre encore en 3.10 : la SyntaxError tombe au chargement,
sans qu'aucun garde puisse nommer la commande à taper. Les chaînes traduites
gardent leur texte à l'octet près, sans quoi leur clé se perdrait. Les
commentaires de ces fichiers passent du récit au présent, comme la règle le
demande de ce qu'on touche.
Vérifié : tout l'arbre Python parse sous 3.10, 3.11, 3.12 et 3.14.
--- EN ---
Five files used PEP 701 f-strings — quotes of the same kind nested, a backslash
in the expression, an expression spanning lines — which Python refuses before
3.12. The hooks in script/git/hooks carry "#!/usr/bin/env python3" and so run
on the system interpreter, which a distribution still ships as 3.10: the
SyntaxError lands at load, before any guard can name the command to type.
Translated strings keep their text byte for byte, else their key would be lost.
The comments of those files move from tale to present tense, as the rule asks
of what one touches.
Checked: the whole Python tree parses under 3.10, 3.11, 3.12 and 3.14.
Assisted-by: Claude Opus 5
Aucune cible ne formatait les tests : « make format_all » couvre script/ et les
six dépôts d'addons, et rien d'autre. Seul « make format » les atteignait, et
seulement ceux qu'un diff signalait, si bien que 75 fichiers sur 210 ne
suivaient aucune norme — de la dérive silencieuse dans un arbre qui sert de
référence au reste. Les tests tournent dans le venv d'outillage : ils suivent
donc ruff, comme script/, et la cible entre dans format_all.
Vérifié : « make -n format_test » nomme bien ruff, et format_all l'inclut.
--- EN ---
No target formatted the tests: "make format_all" covers script/ and the six
addons repositories, nothing else. Only "make format" reached them, and only
those a diff reported, so that 75 files out of 210 followed no standard —
silent drift in a tree the rest takes as reference. The tests run in the
tooling venv: they therefore follow ruff, like script/, and the target joins
format_all.
Checked: "make -n format_test" names ruff, and format_all includes it.
Assisted-by: Claude Opus 5
« make format » donnait isort et black à tout fichier Python : la cible py37,
plus petit dénominateur commun de six dépôts d'addons, imposait son style au
code de ce dépôt. Le contexte décide désormais — les modules Odoo gardent isort
et black, le reste passe par ruff, réglé dans .ruff.toml, comme la norme OCA
depuis qu'elle a quitté black. Les dépôts rapatriés sous script/ en sont
écartés, chemin nommé compris. La cible y reste py310 : dès 3.14 ruff écrit
« except A, B: » sans parenthèses, que le python3 des hooks ne sait pas lire.
Vérifié : un fichier reçoit deux normes selon son chemin, et aucun dépôt
rapatrié n'est touché.
--- EN ---
"make format" gave isort and black to every Python file: the py37 target,
lowest common denominator of six addons repositories, imposed its style on this
repository's code. Context now decides — Odoo modules keep isort and black,
everything else goes through ruff, set in .ruff.toml, as the OCA standard does
since it left black. The repositories checked out under script/ are excluded, a
named path included. The target stays py310 there: from 3.14 on, ruff writes
"except A, B:" unparenthesised, which the python3 of the hooks cannot read.
Checked: one file gets two standards by its path, and no checked-out
repository is touched.
Assisted-by: Claude Opus 5
[FIX] qemu : clé portable du cache, re-clé du magasin, image reprise
10 commits. Le magasin rangeait un objet sous le chemin ENTIER de son URL : un
miroir qui préfixe ce chemin donnait deux clés pour les mêmes octets, et le
cache retéléchargeait ce qu'il détenait — sur un journal de 7099 noms livrés,
1124 vivaient sous plusieurs chemins, 3,18 Gio repris à l'amont pour rien.
Seuls les six derniers segments comptent désormais, quatre pour la famille
pacman dont les chemins sont plus courts. « --recle » rattrape un magasin
déjà rempli sans rien retélécharger, et une image gardée devenue périmée est
reprise une fois au lieu de perdre la campagne entière.
Vérifié : suites Go et Python vertes, et une campagne hors ligne où la seconde
VM n'a repris aucun octet de paquet à l'amont.
--- EN ---
10 commits. The store filed an object under the WHOLE path of its URL: a mirror
prefixing that path gave two keys for the same bytes, and the cache
re-downloaded what it held — over a log of 7099 delivered names, 1124 lived
under several paths, 3.18 GiB taken upstream for nothing. Only the last six
segments count now, four for the pacman family whose paths are shorter.
« --recle » brings over a store already filled, downloading nothing, and a
kept image gone stale is fetched once more instead of losing a whole campaign.
Checked: Go and Python suites green, and an offline campaign where the second
VM took no package byte from upstream.
Assisted-by: Claude Opus 5
La section du non-publié taisait trois correctifs déjà fusionnés : l'attente
de l'étape finale de cloud-init avant de rendre la main, sans quoi une session
vit sans les variables du cache et une installation lancée par sudo rejette
son certificat ; les métadonnées de dépôt RPM nommées par l'empreinte de leur
contenu, désormais servies du disque, une plage faisant prendre le fichier
entier ; et l'attente NTP levée sur une VM hors ligne, qui sans cela n'ouvre
jamais son serveur ssh. Régénéré par mmg : 54 puces de chaque côté.
--- EN ---
The Unreleased section was silent on three fixes already merged: the wait for
cloud-init's final stage before handing over, without which a session lives
without the cache variables and an install run by sudo rejects its
certificate; RPM repository metadata named after the hash of its content, now
served from disk, a range fetching the whole file; and the NTP wait lifted on
an offline VM, which otherwise never opens its ssh server. Regenerated with
mmg: 54 bullets on each side.
Assisted-by: Claude Opus 5
Un miroir d'Arch sert « archlinux/core/os/x86_64/<paquet> » là où un autre
sert « core/os/x86_64/<paquet> » : quatre et cinq segments, plus courts que la
borne commune de six, qui les garde entiers et en fait deux clés pour un même
octet. La famille pacman passe donc à quatre, ce qui retire le segment du
miroir et garde le nom du dépôt. La borne haute reste partout ailleurs : deux
distributions peuvent publier un « .deb » de même nom pour d'autres octets, et
les confondre servirait le paquet de l'une à l'autre. Vérifié : quatre
mutations attrapées, aucune collision sur les chemins relevés.
--- EN ---
An Arch mirror serves « archlinux/core/os/x86_64/<package> » where another
serves « core/os/x86_64/<package> »: four and five segments, shorter than the
common bound of six, which keeps them whole and makes two keys for one byte.
The pacman family therefore moves to four, which drops the mirror's segment
and keeps the repository name. The high bound stays everywhere else: two
distributions may publish a « .deb » of the same name for other bytes, and
merging them would serve one's package as the other's. Checked: four mutations
caught, no collision over the paths surveyed.
Assisted-by: Claude Opus 5
Additionner déplacés, fondus et inchangés dépasse le nombre d'objets lus, et
la passe paraît alors se contredire. Elle ne se trompe pas : une copie déjà
rangée sous la clé courante est comptée inchangée quand le parcours la visite,
puis fondue si une copie plus récente vient prendre sa place. Le commentaire
le dit désormais, pour que personne ne prenne cette somme pour un inventaire.
--- EN ---
Adding moved, merged and unchanged exceeds the number of objects read, and the
pass then seems to contradict itself. It does not: a copy already stored under
the current key is counted unchanged when the walk visits it, then merged if a
more recent copy takes its place. The comment now says so, lest anyone take
that sum for an inventory.
Assisted-by: Claude Opus 5
La règle de clé d'un fichier portable a changé : seule la fin du chemin compte
désormais. Les objets écrits sous l'ancienne règle restent sur le disque mais
deviennent introuvables — le service les redemande à l'amont, et la place
qu'ils tiennent ne sert plus personne. Sur un magasin de 12 764 objets, 5 419
étaient dans ce cas, soit 9,11 Gio. La passe les range sous la clé courante
sans rien retélécharger, et fond au passage les copies qu'un miroir portait
sous plusieurs chemins — 1 422 groupes, environ 3,37 Gio rendus. Un statut
seul n'est pas touché : sa clé porte l'hôte. Vérifié : cinq tests, trois
mutations attrapées.
--- EN ---
The key rule for a portable file changed: only the end of the path now counts.
Objects written under the old rule stay on disk but become unreachable — the
service asks upstream again, and the space they hold serves no one. On a store
of 12 764 objects, 5 419 were in that case, that is 9.11 GiB. The pass stores
them again under the current key without downloading anything, and merges on
the way the copies a mirror carried under several paths — 1 422 groups, about
3.37 GiB returned. A status-only entry is left alone: its key carries the
host. Checked: five tests, three mutations caught.
Assisted-by: Claude Opus 5
Un miroir préfixe le chemin à sa guise — « /rocky/10.2/… »,
« /mirror/rocky-linux/10.2/… », « /pub/archive/fedora/… » — et le chemin
entier donnait deux clés pour un même octet : le cache retéléchargeait ce
qu'il détenait. Relevé sur un journal de 7099 noms livrés : 1124 vivaient sous
plusieurs chemins, et 3,18 Gio repartaient à l'amont pour rien. Seuls les six
derniers segments comptent désormais, les segments vides tombant avec eux. Six
est le plus petit nombre sans collision : un chemin Debian en porte six, si
bien que cinq confondraient son paquet avec celui d'Ubuntu, qui porte le même
nom pour d'autres octets — 38 cas mesurés. Vérifié : deux mutations attrapées.
--- EN ---
A mirror prefixes the path as it pleases, and the whole path gave two keys for
one byte: the cache re-downloaded what it held. Measured over a log of 7099
delivered names: 1124 lived under several paths, and 3.18 GiB went back
upstream for nothing. Only the last six segments now count, empty ones falling
with them. Six is the smallest number without collision: a Debian path carries
six, so five would confuse its package with Ubuntu's, which bears the same
name for other bytes — 38 measured cases. Checked: two mutations caught.
Assisted-by: Claude Opus 5
Le relevé des fichiers que la seconde VM découvre seule attribuait leur
existence à la publication continue d'Arch, quelle que soit la distribution
mesurée. Sur une famille RHEL, ces fichiers viennent surtout d'un miroir qui
range les mêmes paquets sous un autre chemin : la clé du magasin portant le
chemin, le cache les retélécharge alors qu'il les détient. Le message nomme
désormais les deux causes sans en imputer une à un système qui n'est pas
celui de la campagne.
--- EN ---
The report of files the second VM discovers alone blamed their existence on
Arch's rolling release, whatever the distribution measured. On a RHEL family
system they mostly come from a mirror storing the same packages under another
path: the store key carrying the path, the cache re-downloads what it already
holds. The message now names both causes without pinning one on a system that
is not the campaign's.
Assisted-by: Claude Opus 5
Un même paquet vit sous deux chemins selon le miroir, et la clé du magasin
porte le chemin : la première VM peut recevoir « 504 » sur l'un — amont jugé
muet — puis être servie du disque par l'autre. Rien n'entre alors au magasin
sous le premier chemin, et le téléchargement honnête de la seconde y était
compté en faute, faisant échouer une mesure où le cache avait tout servi. Une
URL n'est « déjà vue » que si la première VM en a obtenu les octets ; un
statut absent vaut livré, les journaux d'avant ne l'écrivant pas toujours.
Vérifié : trois tests, deux mutations attrapées.
--- EN ---
One package lives under two paths depending on the mirror, and the store key
carries the path: the first VM can get « 504 » on one — upstream judged mute —
then be served from disk by the other. Nothing enters the store under the
first path, and the second VM's honest download was counted a fault there,
failing a measurement where the cache had served everything. A URL is « already
seen » only if the first VM obtained its bytes; a missing status counts as
delivered, older logs not always writing it. Checked: three tests, two
mutations caught.
Assisted-by: Claude Opus 5
Une image gardée vieillit : le répertoire « latest » d'une distribution avance
à chaque version mineure, et la somme publiée cesse de décrire celle du
disque. La vérification la supprimait puis sortait en erreur — une campagne
entière, trois VM, perdue pour une péremption qu'un seul téléchargement
répare. Un écart sur une image DÉJÀ présente la fait désormais reprendre une
fois ; un second écart porte sur des octets fraîchement téléchargés, et arrête
tout. Sans liste de miroirs, et pour des sommes injoignables, rien ne change.
Vérifié : quatre tests de comportement, deux mutations attrapées.
--- EN ---
A kept image ages: a distribution's « latest » directory moves with each point
release, and the published sum stops describing the one on disk. The check
deleted it and exited — a whole campaign, three VMs, lost to a staleness one
download repairs. A mismatch on an image ALREADY present now makes it fetched
once more; a second mismatch is on freshly downloaded bytes, and stops
everything. With no mirror list, and for unreachable sums, nothing changes.
Checked: four behaviour tests, two mutations caught.
Assisted-by: Claude Opus 5
Le binaire a gagné le retrait d'une entrée du magasin par URL et le classement
des objets nix comme immuables sans que la version bouge : « --version » ne
distinguait plus un cache qui porte ces règles d'un cache qui ne les porte
pas, et une réinstallation ne se constatait donc pas. Un hôte pouvait servir
un binaire ignorant l'option « --oublie » tout en annonçant le même numéro.
--- EN ---
The binary gained the removal of a single store entry by URL and the
classification of nix objects as immutable without the version moving:
« --version » could no longer tell a cache holding those rules from one that
does not, so a reinstall could not be observed. A host could serve a binary
ignoring the « --oublie » option while announcing the same number.
Assisted-by: Claude Opus 5
[ADD] garde-fous : refuser une clé i18n double, borner le guide à 80
3 commits. Deux défauts qui ne se signalent pas d'eux-mêmes, et que rien
n'empêchait de revenir.
Une clé de traduction écrite deux fois fait afficher à un menu la traduction
d'un autre : Python bâtit un dictionnaire littéral de haut en bas et garde la
dernière, sans un mot. Le contrôle lit le fichier par son ARBRE, la collision
pouvant s'écrire sur une seule ligne où une expression régulière ne la voit
pas. Vert sur l'état actuel : aucune clé n'est en double aujourd'hui.
Le guide de connexion tenait dans 80 colonnes nu et en rendait 103 une fois
la VM équipée, là où l'épreuve de largeur ne regardait que le guide nu. C'est
la mise en page qui porte la règle désormais. 6706 tests.
--- EN ---
3 commits. Two defects that do not report themselves, and that nothing
prevented from coming back.
A translation key written twice makes one menu show another's translation:
Python builds a literal dictionary top to bottom and keeps the last one,
without a word. The check reads the file by its TREE, the collision being
writable on a single line where a regular expression does not see it. Green
on the current state: no key is duplicated today.
The connection guide fitted in 80 columns bare and rendered 103 once the VM
was equipped, where the width check looked only at the bare guide. The layout
now carries the rule. 6706 tests.
Assisted-by: Claude Opus 5
Ce que le guide fait désormais se voit à chaque ouverture de session sur une
VM équipée : un lecteur qui choisit de mettre à jour doit le lire.
Le garde-fou i18n n'a pas d'entrée : aucune clé n'est en double aujourd'hui,
donc rien ne change pour qui utilise le produit. Il empêche un retour, il ne
corrige pas un symptôme.
--- EN ---
What the guide now does shows at every login on an equipped VM: a reader
choosing whether to upgrade has to read it.
The i18n guard gets no entry: no key is duplicated today, so nothing changes
for whoever uses the product. It prevents a return, it does not fix a
symptom.
Assisted-by: Claude Opus 5
Le guide tenait dans 80 colonnes nu, et rendait 103 dès qu'une VM portait
ses outils et un bureau. Le cadre débordait alors, le terminal repliait où
il voulait, et l'alignement en deux colonnes — seule chose qui rend un
guide lisible d'un coup d'œil — disparaissait.
La mise en page porte désormais la règle, plutôt que la longueur des textes
qui n'aurait tenu que jusqu'au prochain outil : la glose se replie sous sa
colonne, et passe sous sa commande quand celle-ci ne laisse plus de quoi
écrire. L'épreuve de largeur ne couvrait que le guide nu ; elle couvre le
guide équipé, qui est celui où le débordement vivait.
--- EN ---
The guide fitted in 80 columns bare, and rendered 103 as soon as a VM
carried its tools and a desktop. The frame then overflowed, the terminal
wrapped wherever it liked, and the two-column alignment — the only thing
making a guide readable at a glance — was gone.
The layout now carries the rule, rather than the length of texts which would
have held only until the next tool: a gloss wraps under its column, and
moves below its command when that command leaves no room. The width check
covered only the bare guide; it now covers the equipped one, which is where
the overflow lived.
Assisted-by: Claude Opus 5
Python bâtit un dictionnaire littéral de haut en bas : la dernière
occurrence gagne. Une clé posée deux fois fait donc qu'un menu affiche la
traduction d'un autre, et rien ne le signale — ni au chargement, ni à
l'exécution, ni au test qui exerce le premier menu.
Le contrôle lit le fichier par son ARBRE et non par une expression
régulière, laquelle n'attrapait que la forme multiligne quand la collision
peut s'écrire sur une seule. Vert sur l'état actuel, donc aucune clé en
double aujourd'hui ; éprouvé sur les deux formes, qu'il refuse.
--- EN ---
Python builds a literal dictionary top to bottom: the last occurrence wins.
A key written twice therefore makes one menu show another's translation, and
nothing reports it — not at load, not at run, not in the test exercising the
first menu.
The check reads the file by its TREE rather than by a regular expression,
which only caught the multi-line form when the collision can be written on
one. Green on the current state, so no duplicate key today; exercised on
both forms, which it refuses.
Assisted-by: Claude Opus 5
[ADD] qemu, proxmox et cache : NixOS devient déployable
23 commits. NixOS est le neuvième système déployable, et le seul dont aucune
distribution ne publie d'image cloud : celle d'un tiers est épinglée, sa somme
vérifiée, l'UEFI imposé là où elle n'a pas de secteur BIOS. Les dépendances
d'ERPLibre y sont DÉCLARÉES au lieu d'être posées commande par commande.
Presque rien ne s'y devine — /etc est en lecture seule, /bin un montage FUSE
que systemd ne voit pas, le pare-feu est actif et sshd ne montre aucun motd.
Le cache de téléchargement a dû apprendre à lui servir l'autorité, perdue à
trois frontières, sans quoi NixOS en restait soustrait et le hors ligne lui
était fermé. Vérifié sur machines réelles : installation complète, 0 refus de
certificat, Odoo en 303. 6697 tests.
--- EN ---
23 commits. NixOS is the ninth deployable system, and the only one no
distribution publishes a cloud image for: a third party's is pinned, its sum
verified, UEFI forced where it has no BIOS sector. ERPLibre's dependencies are
DECLARED there instead of installed one command at a time.
Almost nothing there is guessable — /etc is read-only, /bin a FUSE mount
systemd does not see, the firewall is on and sshd shows no motd. The download
cache had to learn to serve it the authority, lost at three boundaries,
without which NixOS stayed exempt from it and offline deployment was closed
to it. Checked on real machines: a complete install, 0 certificate refusals,
Odoo in 303. 6697 tests.
Assisted-by: Claude Opus 5
Le dernier écran avant de créer portait « ERPLibre ne s'installe pas encore
sur NixOS : la VM est créée, l'installation échoue ». Il s'y installe, de
bout en bout : clone, make install_os, make install_odoo_18, Odoo enregistré
en service et servant 8069.
Un avertissement périmé à cet endroit ne fait pas qu'induire en erreur, il
décourage d'essayer ce qui marche — et c'est la seule ligne de l'écran qui
parle d'un échec. Sa traduction part avec lui, une entrée que personne
n'appelle vieillissant sans qu'on le sache.
--- EN ---
The last screen before creating carried « ERPLibre does not install on NixOS
yet: the VM is created, the install fails ». It does install, end to end:
clone, make install_os, make install_odoo_18, Odoo registered as a service
and serving 8069.
A stale warning there does not merely mislead, it discourages trying what
works — and it is the screen's only line that speaks of a failure. Its
translation goes with it, an entry nobody calls ageing unnoticed.
Assisted-by: Claude Opus 5
Le point annonçait qu'un fragment de service suffit à donner l'autorité du
cache à NixOS. C'était vrai de ce qu'on savait en l'écrivant, et le lecteur
qui s'y fie repart avec un mécanisme qui échoue.
Mesuré depuis : « sudo nix store info » rend « Store URL: local » et un
NIX_REMOTE vide — le nix de root ne passe pas par le démon, il télécharge
lui-même, avec l'environnement que sudo lui laisse, et sudo n'en laisse
aucun. Le point nomme désormais les trois frontières où l'environnement se
perd, et ce qui traverse chacune.
--- EN ---
The entry announced that a service drop-in is enough to give NixOS the
cache's authority. That was true of what was known when it was written, and
a reader who relies on it leaves with a mechanism that fails.
Measured since: « sudo nix store info » reports « Store URL: local » and an
empty NIX_REMOTE — root's nix does not go through the daemon, it downloads
on its own, with whatever environment sudo leaves it, and sudo leaves none.
The entry now names the three boundaries where the environment is lost, and
what crosses each.
Assisted-by: Claude Opus 5
Les décisions que l'hôte prend avant de lancer sont gardées pour le journal
de la VM, celui qu'on rouvre le lendemain quand l'installation a échoué.
Celle du miroir apt restait sur la console, qui a défilé depuis.
C'est pourtant là qu'on la cherche : le magasin range ses index sous l'HÔTE
demandé, et une VM qui en réclame un autre ne retrouve rien de ce qui est
gardé — hors ligne, l'installation échoue plus bas sur des dépendances
introuvables, un message qui accuse le dépôt et jamais le miroir. Le nom du
miroir posé, ou le code de l'échec, rejoignent donc les autres notes.
--- EN ---
The decisions the host takes before launching are kept for the VM's log, the
one reopened the next day when the install has failed. The apt mirror's
stayed on the console, which has scrolled away since.
Yet that is where it is looked for: the store files its indexes under the
HOST asked for, and a VM asking for another finds nothing of what is kept —
offline, the install fails further down on unresolvable dependencies, a
message that blames the repository and never the mirror. The pinned mirror's
name, or the failure's code, therefore join the other notes.
Assisted-by: Claude Opus 5
Quand la somme d'une image ne correspond pas, le message nomme le geste à
faire EN PREMIER, cet hôte pouvant être lui-même derrière le cache. Il
rendait « printf %s | … --oublie » : une f-string dont le marqueur était
tombé, et un printf sans opérande. Recopiée, la commande lit un flux vide,
n'efface rien et sort à 0 — on croit avoir purgé, on efface l'image, on
relance, et le magasin ressert les mêmes octets indéfiniment. Un remède qui
réussit sans rien faire est pire que pas de remède.
La voie libvirt donnait déjà l'URL ; celle-ci la donne aussi. Le test la
joue dans un vrai shell, la ligne traversant deux quotages.
--- EN ---
When an image's checksum does not match, the message names the step to take
FIRST, this host possibly being behind the cache itself. It printed
« printf %s | … --oublie »: an f-string whose placeholder had been lost, and
a printf with no operand. Copied, the command reads an empty stream, erases
nothing and exits 0 — you believe you purged, you erase the image, you
retry, and the store serves the same bytes for ever. A remedy that succeeds
without doing anything is worse than none.
The libvirt path already gave the URL; this one now does too. The test plays
it in a real shell, the line crossing two levels of quoting.
Assisted-by: Claude Opus 5
Le classeur ne connaissait pas nix. Un « <empreinte>.narinfo » et les
« nar/<empreinte>.nar.zst » tombaient dans le volatil par défaut, donc
revalidés un par un contre l'amont — relevé sur un déploiement réel :
346 narinfo, 249 nar.zst, 54 nar.xz, tous volatils, pour des fichiers dont
le NOM est l'empreinte du chemin de store et qui ne changeront jamais.
Une dérivation modifiée porte une autre empreinte, donc un autre nom. La
clé écarte l'hôte du même coup : le nom identifie le fichier sur tout
miroir. « nix-cache-info » reste volatile, il décrit le magasin amont.
--- EN ---
The classifier did not know nix. A "<hash>.narinfo" and the
"nar/<hash>.nar.zst" fell into the volatile default, so were revalidated
one by one against upstream — read off a real deployment: 346 narinfo,
249 nar.zst, 54 nar.xz, all volatile, for files whose NAME is the store
path hash and which will never change.
A modified derivation carries another hash, hence another name. The key
drops the host at the same time: the name identifies the file on any
mirror. "nix-cache-info" stays volatile, it describes the upstream store.
Assisted-by: Claude Opus 5
NixOS était SOUSTRAIT du cache faute d'ancre de confiance par fichier, ce
qui lui fermait le hors ligne : le magasin est alors la seule source, et
l'exception ne laisse rien. Une déclaration arriverait trop tard, la
première reconstruction étant le premier téléchargement.
L'autorité est donc POINTÉE, consommateur par consommateur, et
l'environnement se perd à trois frontières : nix-daemon, activé par
socket, qu'un fragment sous /run/systemd/system atteint ; sudo, que
« env_keep » traverse — le nix de root parle droit au magasin local et
télécharge lui-même ; et la session ssh, ouverte une seconde avant que
cloud-init n'écrive le faisceau. Vérifié : installation complète, 0 refus.
--- EN ---
NixOS was EXEMPTED from the cache for want of a per-file trust anchor,
which closed offline deployment to it: the store is then the only source,
and an exemption leaves nothing. A declaration would come too late, the
first rebuild being the first download.
The authority is therefore POINTED AT, consumer by consumer, and the
environment is lost at three boundaries: nix-daemon, socket-activated,
reached by a drop-in under /run/systemd/system; sudo, crossed by
« env_keep » — root's nix talks straight to the local store and downloads
itself; and the ssh session, opened one second before cloud-init writes
the bundle. Checked: a complete install, 0 refusals.
Assisted-by: Claude Opus 5
Le rebase apporte trois choses auxquelles ce travail devait s'accorder.
Les messages du binaire se traduisent désormais : ceux du refus de place
et de l'aide de --oublie passent par T(), avec leur entrée au catalogue —
deux garde-fous refusent sinon un message sans traduction ou l'inverse.
Soustraire l'hôte au cache est REFUSÉ hors ligne : le magasin est alors la
seule source, et l'excepter ne le ferait pas télécharger en direct, cela
le priverait de tout, ses propres paquets compris.
Et le guide de connexion annonce les outils sur la voie Proxmox aussi ; il
n'y était plus écrit du tout, l'argument manquant étant avalé.
--- EN ---
The rebase brings three things this work had to align with. The binary's
messages are now translatable: the out-of-space refusal and the --oublie
help go through T(), with their catalogue entry — two guard rails
otherwise refuse a message without a translation, or the reverse.
Exempting the host from the cache is REFUSED offline: the store is then
the only source, and exempting it would not make it download directly, it
would leave it with nothing, its own packages included.
And the connection guide announces the tools on the Proxmox path too; it
was no longer written there at all, the missing argument being swallowed.
Assisted-by: Claude Opus 5
On entrait en ssh sans savoir que nix, PyCharm ou la forge étaient là, ni
par quelle commande s'en servir : le guide ne connaissait que la
distribution, ERPLibre et la présence d'un bureau. La liste vient du menu
FILTRÉE par la machine — Android Studio n'existe qu'en x86_64, PyCharm
veut un bureau — et chaque ligne est confrontée au code qui l'installe.
Le bloc NixOS porte la racine du dépôt, seule ligne qui n'était ni absolue
ni commande, et trois lignes qu'on ne devine pas : « --rollback », qui
défait une déclaration fautive ; « nixos-version » ; et « ls /bin », vide
alors que /bin/bash s'exécute. Une recherche de paquet a été essayée puis
écartée, muette sur cette image.
--- EN ---
One logged in over ssh with no way to know nix, PyCharm or the forge were
there, nor which command to use: the guide knew only the distribution,
ERPLibre and whether a desktop was installed. The list comes from the menu
FILTERED by the machine — Android Studio is x86_64 only, PyCharm wants a
desktop — and every line is checked against the code that installs it.
The NixOS block carries the checkout root, its only line neither absolute
nor a command, and three lines nobody guesses: « --rollback », which
undoes a faulty declaration; « nixos-version »; and « ls /bin », empty
while /bin/bash runs. A package search was tried then dropped, silent on
this image.
Assisted-by: Claude Opus 5
Deux changements de comportement manquaient au non-publié, et ce sont
justement ceux qu'un lecteur doit connaître avant de mettre à jour. La
vérification d'une image ne se demande plus, donc une commande qui
passait « --verify » ne change rien et une qui ne le passait pas vérifie
désormais : « --no-verify » est l'échappatoire, à réserver au hors ligne.
Et « --bios » est refusé sur une image sans secteur d'amorçage, là où il
était obéi et donnait une VM « running » à console muette.
--- EN ---
Two behaviour changes were missing from Unreleased, and they are exactly
the ones a reader needs before upgrading. Verifying an image is no longer
asked for, so a command passing "--verify" changes nothing while one that
did not now verifies: "--no-verify" is the way out, to be kept for offline
runs.
And "--bios" is refused on an image with no boot sector, where it used to
be obeyed and gave a VM reported "running" with a silent console.
Assisted-by: Claude Opus 5
La vérification existait sous un drapeau, et pour Ubuntu SEULEMENT : les
autres images arrivaient sans que rien ne les regarde, alors que leurs
éditeurs publient tous une somme. Six y entrent, relevées sur les dépôts
plutôt que devinées — Debian est en sha512, les familles RHEL nomment
« CHECKSUM », Rocky l'écrit en forme BSD, Arch et openSUSE posent une
somme par image. Fedora en reste dehors, son fichier portant un numéro de
construction que l'URL de l'image ne donne pas.
Injoignable n'arrête plus rien, un écart si. Le menu du cache sait aussi
oublier une URL, « --detient » faisant l'aperçu.
--- EN ---
Verification existed behind a flag, and for Ubuntu ONLY: the other images
arrived with nothing looking at them, though every publisher ships a sum.
Six now enter, read off the repositories rather than guessed — Debian is
sha512, the RHEL families name it "CHECKSUM", Rocky writes the BSD form,
Arch and openSUSE ship a sum per image. Fedora stays out, its file
carrying a build number the image URL does not give.
Unreachable no longer stops anything, a mismatch does. The cache menu can
also forget one URL, "--detient" serving as the preview.
Assisted-by: Claude Opus 5
Le déploiement écrit /etc/motd partout et compte sur pam_motd pour le
montrer — vrai des quatre images cloud, faux ici : sshd rend « printmotd
no » et le PAM n'en contient aucun. Le guide était écrit, complet, et
personne ne le lisait. Il gagne un bloc propre à NixOS, dont le piège
qu'il existe pour dire — /etc/nixos/erplibre.nix est réécrit par
« make install_os », et ce qu'on y ajoute disparaît sans un mot.
La locale demandée ne s'appliquait pas : cloud-init passe par locale-gen
et update-locale, absents ici. Mesuré — fr_CA demandé, en_US obtenu. Rien
n'est imposé à une NixOS qu'on avait déjà.
--- EN ---
Deployment writes /etc/motd everywhere and relies on pam_motd to show it —
true of the four cloud images, false here: sshd returns "printmotd no" and
the PAM stack holds none. The guide was written, complete, and nobody read
it. It gains a NixOS block, including the trap it exists to name —
/etc/nixos/erplibre.nix is rewritten by "make install_os", and what you
add there vanishes without a word.
The requested locale did not apply: cloud-init goes through locale-gen and
update-locale, absent here. Measured — fr_CA asked, en_US obtained.
Nothing is imposed on a NixOS one already had.
Assisted-by: Claude Opus 5
Un invité sans magasin de confiance ne peut RIEN recevoir, et sur un hôte
Proxmox c'est l'HÔTE qu'il faut excepter : imbriqué, l'invité sort masqué
derrière lui et le pont ne voit jamais sa propre adresse. Mesuré depuis
l'invité : code 000 et vérification SSL 19, puis 200 et 0. Sans cela le
gestionnaire de paquets se rabattait sur 564 dérivations à construire.
Le journal par VM ne portait AUCUN message du menu : la cause vivait sur
une console qui défile, et le fichier qu'on rouvre après l'échec n'avait
que le symptôme. Et « db_drop_all » annonçait détruites des bases qui ne
l'étaient pas, son code de retour jeté.
--- EN ---
A guest with no trust store can receive NOTHING, and on a Proxmox host it
is the HOST that must be exempted: nested, the guest leaves masqueraded
behind it and the bridge never sees its own address. Measured from the
guest: code 000 and SSL verification 19, then 200 and 0. Without it the
package manager fell back to building 564 derivations.
The per-VM log carried NO message from the menu: the cause lived on a
console that scrolls away, and the file reopened after failure held only
the symptom. And "db_drop_all" announced databases as dropped that were
not, its exit status discarded.
Assisted-by: Claude Opus 5
NixOS active un pare-feu par défaut ; aucune des quatre autres images
cloud n'en active. Le service écoutait bien et répondait en local, mais
l'hôte ne recevait RIEN — pas un refus, un silence jusqu'au délai — et le
suivi déclarait Odoo absent sur une machine où il tournait. Mesuré : 000
après 12 s, puis 303 en 9 ms.
Un système déclaratif n'a que ce qui est écrit : xmlsec1, sans lequel
Odoo refuse d'installer auth_saml ; parallel et shfmt, appelés par leur
nom nu ; growpart, dont l'absence faisait rendre 0 à un agrandissement qui
n'agrandissait rien ; et l'agent invité, qui venait de l'image.
--- EN ---
NixOS enables a firewall by default; none of the four other cloud images
does. The service did listen and answered locally, but the host received
NOTHING — not a refusal, silence until the timeout — and the monitor
declared Odoo absent on a machine where it was running. Measured: 000
after 12 s, then 303 in 9 ms.
A declarative system has only what is written: xmlsec1, without which Odoo
refuses to install auth_saml; parallel and shfmt, called by bare name;
growpart, whose absence made a disk grow return 0 while growing nothing;
and the guest agent, which came from the image.
Assisted-by: Claude Opus 5
Rien n'invalidait une entrée dont la somme ne correspond pas : le magasin
continuait de la servir, et retélécharger ne changeait rien puisque c'est
lui qui répond. Les deux purges existantes ne l'atteignent pas — l'une
efface tout, l'autre saute ce qui est récent alors que chaque service
remet cette date, si bien qu'un objet empoisonné qui sert ne vieillit
jamais.
Symétrique de « --detient » : mêmes lignes, mêmes fonctions de clé, mêmes
refus, et un objet présent qui résiste est dit refusé plutôt qu'oublié.
Mesuré : garde, puis oublié 53080, puis absent.
--- EN ---
Nothing invalidated an entry whose checksum does not match: the store kept
serving it, and re-downloading changed nothing since the store is what
answers. Neither existing purge reaches it — one erases everything, the
other skips what is recent while every service resets that date, so a
poisoned object that serves never ages.
Symmetric to "--detient": same lines, same key functions, same refusals,
and a present object that resists is reported refused rather than
forgotten. Measured: held, then forgotten 53080, then absent.
Assisted-by: Claude Opus 5
Trois obstacles enchaînés, aucun visible sans une vraie machine. /etc est
généré depuis le store : le « tee » d'une unité y rend « Read-only file
system », et l'installation échouait à sa DERNIÈRE étape, après que le
clone, le venv et un démarrage d'Odoo avaient réussi. ExecStart=/bin/bash
rendait 203/EXEC, /bin étant un montage FUSE que systemd ne voit pas ; et
le PATH d'une unité n'a pas bash, que réclament les shebangs de run.sh.
Déclarée, l'unité est démarrée par la reconstruction — qui a lieu pendant
« make install_os », quand la source d'Odoo n'arrive qu'après : une
condition la fait sauter plutôt qu'échouer 21 fois de suite. Mesuré :
service actif, 8069 servi par lui, login en 303.
--- EN ---
Three chained obstacles, none visible without a real machine. /etc is
generated from the store: « tee » of a unit there returns « Read-only file
system », and the install failed at its LAST step, after the clone, the
venv and an Odoo start had all succeeded. ExecStart=/bin/bash returned
203/EXEC, /bin being a FUSE mount systemd does not see; and a unit's PATH
carries no bash, which run.sh's shebangs ask for.
Declared, the unit is started by the rebuild — which happens during
« make install_os », while Odoo's source lands later: a condition makes it
skip rather than fail 21 times over. Measured: service active, 8069 served
by it, login in 303.
Assisted-by: Claude Opus 5
Les tests longs lançaient la CLI sans privilège, alors que le dossier des
images appartient à root en 755 : arrêt à l'étape 1 sur « Permission
refusée », avant d'avoir rien créé. Ils ne pouvaient donc pas tourner du
tout — pas même échouer utilement. Le menu passe sudo depuis toujours ;
c'est cette forme qui est reprise, et jamais à blanc.
Le refus de place d'un miroir reprenait un champ que tout appelant laisse
à zéro : « moins de 0 o libres » n'annonce aucun seuil et ne dit pas ce
qui a été mesuré. Treize tests héritaient du plancher de production,
10 Gio, et rougissaient sur un /tmp en tmpfs.
--- EN ---
The long tests ran the CLI unprivileged, while the image directory is
owned by root, mode 755: they stopped at step 1 on "permission denied",
before creating anything. They therefore could not run at all — not even
fail usefully. The menu has always passed sudo; that is the form taken
here, and never on a dry run.
A mirror's refusal for lack of space echoed a field every caller leaves at
zero: "less than 0 B free" announces no threshold and does not say what
was measured. Thirteen tests inherited the production floor, 10 GiB, and
went red on a tmpfs /tmp.
Assisted-by: Claude Opus 5
Deux tables opposées vivaient dans le même fichier : l'une forçait le
BIOS, l'autre l'UEFI, chacune lue d'un seul côté. Elles pouvaient se
contredire sans que rien ne le dise. FIRMWARE_IMPOSE les remplace, et les
deux suites passent inchangées. « --bios » l'emportait sur un fait
physique : forcé sur une image sans secteur d'amorçage, il donnait une VM
« running » à console muette. Il est ignoré, et l'appelant l'apprend.
Le fuseau était lu en UTF-8 strict sous un « except OSError » : un octet
qui n'en est pas faisait échouer tout le déploiement pour une traduction
de confort.
--- EN ---
Two opposing tables lived in one file: one forced BIOS, the other UEFI,
each read by one side only. They could contradict each other silently.
FIRMWARE_IMPOSE replaces both, and both suites pass unchanged. "--bios"
overrode a physical fact: forced on an image with no boot sector it gave a
"running" VM with a mute console. It is ignored now, and the caller is
told.
The timezone was read as strict UTF-8 under an "except OSError": a byte
that is not one failed the whole deployment for a convenience
translation.
Assisted-by: Claude Opus 5
Le détournement est TRANSPARENT et vaut pour tout le pont : ne pas donner
l'autorité à une VM ne la dispense pas d'être interceptée, elle échoue sur
« self-signed certificate in certificate chain ». NixOS n'a pas d'ancre de
confiance par fichier, et la poser par déclaration arriverait trop tard —
la première reconstruction EST le premier téléchargement. La VM est donc
exceptée par son adresse MAC, avant sa création, et cela se dit.
L'image Proxmox n'est mise en place qu'une fois complète : « wget -O »
écrivait dans la cible, et une coupure y figeait un fichier tronqué que
le test de présence acceptait à chaque déploiement suivant.
--- EN ---
Interception is TRANSPARENT and covers the whole bridge: withholding the
authority from a VM does not spare it, it fails on "self-signed
certificate in certificate chain". NixOS has no per-file trust anchor, and
declaring one would come too late — the first rebuild IS the first
download. The VM is therefore exempted by MAC, before creation, and it is
said.
The Proxmox image is put in place only once complete: "wget -O" wrote into
the target, and an interruption froze a truncated file there that the
presence test accepted on every later deployment.
Assisted-by: Claude Opus 5
Aucune lecture de code ne les aurait trouvés. Son image n'a pas de secteur
d'amorçage BIOS : une VM créée en SeaBIOS se déclare « running » avec une
console MUETTE, d'où un marqueur par distribution — Debian 13 démarre en
SeaBIOS sur le même hôte, et renverser le défaut coûterait un disque EFI
à chaque VM du parc.
« --ciuser » s'en remet au compte par DÉFAUT de l'image, que NixOS nomme
autrement : le cloud-config du dépôt part en extrait pour toutes les
distributions. Et le lecteur cloud-init passe sur le bus SCSI, une image
bâtie pour virtio seul ne voyant jamais un lecteur IDE.
--- EN ---
No code reading would have found them. Its image has no BIOS boot sector:
a VM created in SeaBIOS reports "running" with a SILENT console, hence a
per-distribution marker — Debian 13 boots in SeaBIOS on the same host, and
flipping the default would cost an EFI disk on every VM.
"--ciuser" defers to the image's DEFAULT account, which NixOS names
otherwise: the repository's cloud-config now travels as a snippet for
every distribution. And the cloud-init drive moves to the SCSI bus, an
image built for virtio alone never seeing an IDE drive.
Assisted-by: Claude Opus 5
Une machine, une question binaire : le chemin que le MENU emprunte
aboutit-il sur un système déclaratif. La commande d'installation est celle
du menu, prise telle quelle — un test qui installerait par ses propres
soins prouverait SON chemin, pas celui du produit, et c'est là que les
pannes se cachaient.
Le verdict est l'ÉTAT de la machine, non un code de retour :
« nixos-rebuild » rend 4 quand une unité n'a pas redémarré alors que le
système est activé. Il vit dans long_test/ parce qu'il crée une VM et
prend des heures ; le lanceur unitaire doit rester lançable en secondes.
--- EN ---
One machine, one binary question: does the path the MENU takes succeed on
a declarative system. The install command is the menu's, taken as is — a
test installing by its own means would prove ITS path, not the product's,
and that is where the failures hid.
The verdict is the machine's STATE, not an exit code: "nixos-rebuild"
returns 4 when a unit failed to restart while the system is active. It
lives in long_test/ because it creates a VM and takes hours; the unit
runner must stay runnable in seconds.
Assisted-by: Claude Opus 5
L'amorçage d'ERPLibre n'atteignait pas NixOS : le Makefile force
« SHELL := /bin/bash », que l'image ne porte pas, et le fournisseur de
Python ne cherche l'interpréteur du système qu'en /usr/bin/pythonX.Y.
Les deux répondent une fois envfs déclaré.
Ce qui n'a pas de roue amont se compile et réclame ses en-têtes : ils sont
liés au profil du système, leurs bibliothèques vont au chargeur, et
pg_config — dérivation à part dans nixpkgs — est nommé. La sortie « doc »
de CPython est écartée : sa construction est un Sphinx de 3 000 pages qui
domine le temps d'installation d'une VM de 4 Go.
--- EN ---
ERPLibre's bootstrap did not reach NixOS: the Makefile forces "SHELL :=
/bin/bash", which the image lacks, and the Python provider only looks for
the system interpreter at /usr/bin/pythonX.Y. Both answer once envfs is
declared.
What has no upstream wheel compiles and demands its headers: they are
linked into the system profile, their libraries reach the loader, and
pg_config — a separate derivation in nixpkgs — is named. CPython's "doc"
output is left out: building it is a 3000-page Sphinx run that dominates
install time on a 4 GB VM.
Assisted-by: Claude Opus 5
Deux réglages régionaux échouaient sur toute VM Debian, et le seul signe
en était le mot « error » dans un compte-rendu qui le porte à chaque fois.
« update-locale » refuse un locale qui n'est pas généré, et le module du
clavier finit par redémarrer console-setup, absent de l'image
genericcloud : le réglage est écrit avant cet échec, donc le poser
nous-mêmes ne perd que la console texte.
Et l'installateur nix n'écrit plus dans ~/.bashrc : un fichier que
l'utilisateur possède ne se modifie pas pour la durée d'un amorçage.
--- EN ---
Two regional settings failed on every Debian VM, and the only sign was the
word "error" in a report that carries it every time. "update-locale"
refuses a locale that is not generated, and the keyboard module ends by
restarting console-setup, absent from the genericcloud image: the setting
is written before that failure, so placing it ourselves loses only the
text console.
And the nix installer no longer writes into ~/.bashrc: a file the user
owns is not edited for the duration of a bootstrap.
Assisted-by: Claude Opus 5
Neuvième système du catalogue, et le seul dont aucune distribution ne
publie d'image cloud : celle d'un tiers est épinglée et sa somme vérifiée
à chaque téléchargement. Son seed diffère aussi — networkd prend la clé
d'un bloc pour un NOM d'interface là où netplan honore un « match: », et
sshd refuse un compte dont le shell n'existe pas, d'où /bin/sh.
Ses dépendances se DÉCLARENT dans conf/nixos/erplibre.nix : envfs répond
à /usr/bin/env, nix-ld donne aux roues manylinux leur chargeur. Vérifié
sur une VM : le verrou de 362 paquets s'installe et Odoo répond.
--- EN ---
Ninth system of the catalogue, and the only one no distribution publishes
a cloud image for: a third party's is pinned and its sum verified at every
download. Its seed differs too — networkd reads a block's key as an
interface NAME where netplan honours a "match:", and sshd refuses an
account whose shell does not exist, hence /bin/sh.
Its dependencies are DECLARED in conf/nixos/erplibre.nix: envfs answers
/usr/bin/env, nix-ld gives manylinux wheels their loader. Checked on a VM:
the 362-package lock installs and Odoo answers.
Assisted-by: Claude Opus 5
[ADD] qemu : cache des téléchargements des VM, hors ligne, 3D Proxmox
14 commits. Les VM d'un hôte retéléchargeaient les mêmes paquets et dépôts à
chaque installation, et rien ne prouvait qu'une installation tienne sans
réseau. Un cache transparent sert du disque ce qui ne change pas, garde git en
miroir et peut couper le réseau de toute une installation. Sur une vraie
installation d'ERPLibre et d'Odoo 18, la seconde VM n'a tiré de l'amont aucun
paquet ni requête git. Viennent avec : la 3D sous Proxmox VE, le verrou apt et
l'agent invité attendus, les outils optionnels posés ou dits absents. Vérifié :
tests Go, et 6318 tests unitaires dont 9 échecs déjà présents sur master ; la
campagne hors ligne complète n'a pas été rejouée après ses deux derniers
correctifs.
--- EN ---
14 commits. A host's VMs downloaded the same packages and repositories again
on every install, and nothing proved an install could hold without the
network. A transparent cache serves from disk what never changes, mirrors git
and can cut the network for a whole install. On a real ERPLibre and Odoo 18
install, the second VM pulled no package and no git request upstream. With it:
3D on Proxmox VE, the apt lock and the guest agent waited for, optional tools
installed or reported missing. Verified: Go tests, and 6318 unit tests with 9
failures already present on master; the full offline run was not replayed
after its last two fixes.
Assisted-by: Claude Opus 5
« cloud-init status --wait » rend la main dès que cloud-init se déclare en
erreur — un module accessoire y suffit — alors que son étape finale écrit
encore l'autorité du cache, les variables et le fichier sudoers. Une session
ouverte dans cette seconde-là vit sans ces variables, PAM ne relisant plus le
fichier, et sudo n'a alors rien à conserver : l'installation lancée par sudo
rejette le certificat du cache. L'attente guette désormais l'unité
cloud-final, et son seul état « activating » : ce oneshot reste ACTIF une fois
fini, si bien qu'« is-active » y ferait attendre la borne entière pour rien.
--- EN ---
« cloud-init status --wait » returns as soon as cloud-init declares itself in
error — an accessory module is enough — while its final stage still writes the
cache authority, the variables and the sudoers file. A session opened in that
second lives without those variables, PAM never rereading the file, and sudo
then has nothing to keep: an install run by sudo rejects the cache
certificate. The wait now watches the cloud-final unit, and only its
« activating » state: this oneshot stays ACTIVE once finished, so « is-active »
would wait the whole bound for nothing.
Assisted-by: Claude Opus 5
A package manager opens several connections to one repository at once and
closes those it does not use. The cache saw three cut handshakes in the same
second, counted three refusals, and moved the host to an opaque tunnel, which
never consults the store. A client then waited four hours on that tunnel,
holding a socket the far end had closed, until its own deadline killed it.
Cuts closer than two seconds now count as one incident; a client that really
rejects the authority retries seconds later and is banned as before. A closing
tunnel is logged with its duration and bytes each way.
--- FR ---
Un gestionnaire de paquets ouvre plusieurs connexions de front vers un dépôt
et ferme celles dont il ne se sert pas. Le cache voyait trois poignées de main
coupées dans la même seconde, comptait trois refus, et passait l'hôte en
tunnel opaque, qui ne consulte jamais le magasin. Un client attendait alors
quatre heures sur ce tunnel, sur un socket que l'autre bout avait refermé,
jusqu'à son propre délai. Deux coupures à moins de deux secondes comptent
désormais pour un incident ; un client qui rejette vraiment l'autorité
réessaie et reste condamné. La fin d'un tunnel est journalisée.
Assisted-by: Claude Opus 5
The verdict counted every upstream line of an already seen package as a file
the cache failed to serve. A mirror that publishes the distribution under
another path answers 404 to each package; the client moves to the next
mirror, which the cache serves from disk. The 404 goes upstream on both VMs
without anything missing, and an openSUSE campaign failed on six such lines.
An upstream answer of 400 or more is now reported apart and not counted.
Checked: a test for the refusal, and one where a delivered 200 still fails.
--- FR ---
Le verdict comptait toute ligne d'amont d'un paquet déjà vu comme un fichier
que le cache n'a pas servi. Un miroir qui publie la distribution sous un
autre chemin répond 404 à chaque paquet ; le client passe au miroir suivant,
que le cache sert du disque. Le 404 repart à l'amont aux deux VM sans que
rien ne manque, et une campagne openSUSE échouait sur six de ces lignes. Une
réponse d'amont de 400 ou plus est désormais signalée à part, sans compter.
Vérifié : un test du refus, et un où un 200 livré échoue toujours.
Assisted-by: Claude Opus 5
Trois défauts qui empêchaient une VM hors ligne d'aboutir. zypper vérifie
chaque dépôt par un HEAD, jamais gardé sous une clé portable : le dépôt était
déclaré invalide alors que le magasin tenait son index, et un HEAD reçoit
désormais les en-têtes du corps du GET gardé. Une image qui attend la
synchronisation NTP avant son étape finale ne démarrait jamais son serveur
ssh, faute de serveur de temps joignable ; l'attente est levée sur une VM
déployée hors ligne. Enfin, une troisième VM en échec nomme l'étape qui l'a
arrêtée, là où le résumé d'une série n'affichait qu'un verdict nu.
--- EN ---
Three faults that kept an offline VM from finishing. zypper checks each
repository with a HEAD, never stored under a portable key: the repository was
declared invalid while the store held its index, and a HEAD now gets the
headers of the stored GET body. An image waiting for NTP synchronisation
before its final stage never started its ssh server, no time server being
reachable; that wait is lifted on a VM deployed offline. Last, a failing third
VM names the step that stopped it, where a series summary showed a bare
verdict.
Assisted-by: Claude Opus 5
An RPM repository names each metadata file after the hash of its content;
only repomd.xml is current. Classified volatile, a primary.xml.gz of tens of
megabytes was taken whole on every install, about 110 MB per VM on a RHEL
family system. dnf fetches .zck metadata by ranges, and a range is never
stored: upstream cut, the next VM got 504 and dnf stopped. Such files are now
immutable, and a range on a missing immutable file makes the cache fetch the
whole file in the background, once per key. Checked: a range served offline
from disk, each rule mutation-tested, race detector clean.
--- FR ---
Un dépôt RPM nomme chaque métadonnée d'après l'empreinte de son contenu ;
seul repomd.xml est courant. Classé volatile, un primary.xml.gz de dizaines de
mégaoctets était repris en entier à chaque installation, environ 110 Mo par VM
sur un système de la famille RHEL. dnf prend les métadonnées .zck par plages,
et une plage ne se garde pas : amont coupé, la VM suivante recevait 504 et dnf
s'arrêtait. Ces fichiers sont désormais figés, et une plage sur un fichier figé
absent fait prendre au cache le fichier entier en arrière-plan, une fois par
clé. Vérifié : plage servie hors ligne du disque, chaque règle éprouvée par
mutation, détecteur de courses muet.
Assisted-by: Claude Opus 5
Quatre défauts qu'une campagne complète sur les sept systèmes du catalogue a
mis au jour. La famille zypper visait un faisceau de certificats qu'openSUSE
n'écrit pas, et pip s'arrêtait là, en ligne comme hors ligne. sudo remet
l'environnement à zéro : sans env_keep, une installation lancée par sudo
rejette l'autorité du cache là où PAM ne relit pas /etc/environment. Le
journal de console n'était gardé que pour la voie installateur, si bien
qu'une image cloud bloquée avant ssh ne laissait rien à lire. Et une VM de
8 Gio restait allumée après sa mesure, épuisant la mémoire de l'hôte.
--- EN ---
Four faults a full campaign over the catalogue's seven systems brought out.
The zypper family pointed at a certificate bundle openSUSE does not write,
and pip stopped there, online as well as offline. sudo resets the
environment: without env_keep, an install run by sudo rejects the cache
authority where PAM does not reread /etc/environment. The console log was
kept for the installer path only, so a cloud image stuck before ssh left
nothing to read. And an 8 GiB VM stayed up after its measurement, exhausting
the host's memory.
Assisted-by: Claude Opus 5
Le cache ne diminuait jamais de lui-même et vit sur le disque de
l'orchestrateur : un parc qui déploie chaque jour finissait par le remplir,
sans que rien ne le signale. Deux règles existent désormais, éteintes par
défaut et réglées depuis le menu : l'âge du dernier usage, et un plafond de
taille qui efface le moins récemment servi jusqu'à tenir dessous, objets et
dépôts git confondus. Un minuteur systemd quotidien les applique, et une
réinstallation garde les valeurs choisies. Le menu montre d'abord ce qui
partirait.
--- EN ---
The cache never shrank by itself and lives on the orchestrator's disk: a site
deploying every day filled it up with nothing to say so. Two rules now exist,
off by default and set from the menu: the age of last use, and a size ceiling
that erases the least recently served until the cache fits under it, objects
and git mirrors alike. A daily systemd timer applies them, and a reinstall
keeps the chosen values. The menu first shows what would go.
Assisted-by: Claude Opus 5
Each campaign covered one system, so proving the cache beyond Ubuntu meant
relaunching by hand and comparing reports one by one. --distro now accepts
« tous » or a comma list: each system runs its full campaign with the
catalogue version, its VMs are destroyed before the next one — three VMs per
system would not fit together on the host disk — and a table compares verdict,
durations and upstream bytes. A failure does not stop the series; an unknown
name is refused before any VM is created. Checked: tests and mutations.
--- FR ---
Chaque campagne couvrait un système : prouver le cache au-delà d'Ubuntu
voulait dire relancer à la main et comparer les rapports un à un. --distro
accepte désormais « tous » ou une liste : chaque système fait sa campagne
complète avec la version du catalogue, ses VM sont défaites avant le suivant —
trois VM par système ne tiendraient pas ensemble sur le disque de l'hôte — et
un tableau compare verdict, durées et octets d'amont. Un échec n'arrête pas la
série ; un nom inconnu est refusé avant qu'aucune VM ne soit créée. Vérifié :
tests et mutations.
Assisted-by: Claude Opus 5
L'audit de npm interroge un service qu'aucun cache ne rejoue : amont coupé,
il échoue à chaque installation sans rien vérifier. Une VM déployée hors
ligne reçoit donc NPM_CONFIG_AUDIT=false, écrit dans /etc/environment et
relu après cloud-init ; une VM en ligne garde son audit. Le retrait d'une
exception du détournement parle désormais la langue du menu, son message
allant à l'erreur standard tandis que la sortie standard garde les règles
que nft lit, qui ne se traduisent jamais.
--- EN ---
The npm audit queries a service no cache can replay: upstream cut, it fails
every install without checking anything. A VM deployed offline therefore gets
NPM_CONFIG_AUDIT=false, written in /etc/environment and read back after
cloud-init; an online VM keeps its audit. Removing a redirection exception
now speaks the menu's language, its message going to standard error while
standard output keeps the rules nft reads, which are never translated.
Assisted-by: Claude Opus 5
Sur une installation complète, les index pip, les métadonnées npm et le
bundle de repo pesaient environ 110 Mo par VM, repris en entier à chaque
fois. Un index déjà gardé part désormais avec son ETag : l'amont juge chaque
requête, et un « 304 » sert le corps depuis le disque. Sous « Vary: Accept »,
chaque représentation est rangée à part, faute de quoi deux clients qui
alternent les retéléchargent tour à tour. Les métadonnées PEP 658 de pip,
nommées « .whl.metadata », sont figées comme l'archive qu'elles décrivent.
--- EN ---
On a full install the pip indexes, npm metadata and repo bundle weighed about
110 MB per VM, taken whole every time. An index already kept now leaves with
its ETag: upstream judges every request, and a « 304 » serves the body from
disk. Under « Vary: Accept » each representation is stored apart, without
which two clients alternating between them re-download each in turn. The
PEP 658 metadata of pip, named « .whl.metadata », are as immutable as the
archive they describe.
Assisted-by: Claude Opus 5
Six tests asserted that an assistant module does not import script.todo.todo
by looking at sys.modules of the running process. Under the full suite another
test had already imported todo, so all six failed whatever the module did. Each
now imports its module in a fresh interpreter and reads the answer there.
Checked: the six pass after test_todo_menu, the order that broke them, and a
module made to import todo fails its test.
--- FR ---
Six tests affirmaient qu'un module de l'assistant n'importe pas
script.todo.todo en regardant le sys.modules du processus en cours. Dans la
suite complète, un autre test avait déjà importé todo : les six échouaient
quoi que fasse le module. Chacun importe désormais son module dans un
interpréteur neuf et y lit la réponse. Vérifié : les six passent après
test_todo_menu, l'ordre qui les faisait tomber, et un module qu'on fait
importer todo fait échouer son test.
Assisted-by: Claude Opus 5
Three Transform data tests wrote an Excel workbook with openpyxl, which the
.venv.erplibre requirements never declared, so the unit suite reported three
errors on every install. openpyxl is now declared there. The tests skip when it
cannot be imported in their own interpreter, since a venv built before this
line still lacks it; the dedicated engine venv is not the right probe, as the
tests write their workbook in-process. Checked: 707 Transform tests pass, and
with openpyxl made unimportable the three are skipped, not errors.
--- FR ---
Trois tests de Transform data écrivaient un classeur Excel avec openpyxl, que
les dépendances de .venv.erplibre ne déclaraient pas : la suite unitaire
rendait trois erreurs sur toute installation. openpyxl y est désormais
déclaré. Les tests se sautent quand il ne s'importe pas dans leur interpréteur,
un venv bâti avant cette ligne ne l'ayant toujours pas ; le venv dédié du
moteur n'est pas la bonne sonde, les tests écrivant leur classeur sur place.
Vérifié : 707 tests de Transform passent, et openpyxl rendu inimportable, les
trois sont sautés et non en erreur.
Assisted-by: Claude Opus 5
Le binaire ne parlait que français alors que le menu suit EL_LANG : un
opérateur anglophone lisait un statut qu'il ne comprenait pas. Chaque message
humain passe par T(), dont la clé EST le texte français, et un catalogue
anglais le traduit ; la langue vient de --lang, puis d'EL_LANG, le français
restant le défaut. Le menu demande le français pour ce qu'il RELIT, ses
motifs ne connaissant que cette langue. Un test refuse un message sans
traduction, une traduction orpheline et un verbe de format qui diverge.
--- EN ---
The binary spoke French only while the menu follows EL_LANG: an English
reader got a status he could not read. Every human message goes through T(),
whose key IS the French text, and an English catalogue translates it; the
language comes from --lang, then EL_LANG, French remaining the default. The
menu asks for French for what it READS BACK, its patterns knowing that
language alone. A test refuses a message without translation, an orphan
translation, and a format verb that drifts.
Assisted-by: Claude Opus 5
[ADD] qemu : cache des téléchargements des VM, hors ligne, 3D Proxmox
14 commits. Les VM d'un hôte retéléchargeaient les mêmes paquets et dépôts à
chaque installation, et rien ne prouvait qu'une installation tienne sans
réseau. Un cache transparent sert du disque ce qui ne change pas, garde git en
miroir et peut couper le réseau de toute une installation. Sur une vraie
installation d'ERPLibre et d'Odoo 18, la seconde VM n'a tiré de l'amont aucun
paquet ni requête git. Viennent avec : la 3D sous Proxmox VE, le verrou apt et
l'agent invité attendus, les outils optionnels posés ou dits absents. Vérifié :
tests Go, et 6318 tests unitaires dont 9 échecs déjà présents sur master ; la
campagne hors ligne complète n'a pas été rejouée après ses deux derniers
correctifs.
--- EN ---
14 commits. A host's VMs downloaded the same packages and repositories again
on every install, and nothing proved an install could hold without the
network. A transparent cache serves from disk what never changes, mirrors git
and can cut the network for a whole install. On a real ERPLibre and Odoo 18
install, the second VM pulled no package and no git request upstream. With it:
3D on Proxmox VE, the apt lock and the guest agent waited for, optional tools
installed or reported missing. Verified: Go tests, and 6318 unit tests with 9
failures already present on master; the full offline run was not replayed
after its last two fixes.
Assisted-by: Claude Opus 5
The Unreleased section describes what the preceding commits deliver: the QEMU
download cache and its git mirrors, offline deployment for QEMU and Proxmox VE,
Proxmox 3D acceleration, and the install fixes that go with them. Each entry
says what the software now does or refuses, for a reader choosing whether to
upgrade. CHANGELOG.md and CHANGELOG.fr.md are the files mmg generates from
CHANGELOG.base.md.
--- FR ---
La section du non-publié décrit ce que livrent les commits qui précèdent : le
cache de téléchargement QEMU et ses miroirs git, le déploiement hors ligne
pour QEMU et Proxmox VE, l'accélération 3D sous Proxmox, et les corrections
d'installation qui les accompagnent. Chaque entrée dit ce que le logiciel fait
ou refuse désormais, pour qui choisit de mettre à jour. CHANGELOG.md et
CHANGELOG.fr.md sont les fichiers que mmg génère depuis CHANGELOG.base.md.
Assisted-by: Claude Opus 5
A Proxmox VM always used the serial console as its display, so nothing inside
it could render. The form offers 3D: the VM gets « --vga virtio-gl » and the
account joins the render and video groups in the guest, which « qm set »
cannot write; without them GL falls back to software while VIRGL reports
success. The box is offered only where the host has a render node, VIRGL, GL
and EGL, Proxmox refusing to start the VM otherwise once its disk is written.
What is missing is named with its package, and a button installs it, then
reads the host again. Covered by test/test_proxmox_form.py.
--- FR ---
Une VM Proxmox prenait toujours la console série pour affichage : rien ne
pouvait y rendre. Le formulaire offre la 3D : la VM reçoit « --vga virtio-gl »
et le compte entre dans les groupes render et video dans l'invité, ce que
« qm set » ne sait pas écrire ; sans eux, GL retombe en logiciel alors que
VIRGL annonce un succès. La case n'est offerte que si l'hôte a un nœud de
rendu, VIRGL, GL et EGL, Proxmox refusant sinon de démarrer la VM une fois son
disque écrit. Ce qui manque est nommé avec son paquet, et un bouton le pose
puis relit l'hôte. Couvert par test/test_proxmox_form.py.
Assisted-by: Claude Opus 5
Without pipefail, « curl … | sh » returns the status of sh, 0 on empty input:
a failed download passed for an install, its fallback never ran, and the
failure surfaced later as « command not found ». mise and pyenv are downloaded
into a mktemp file, then run, and a check refuses any fallback behind a pipe
without pipefail. starship's installer runs as root under a root timeout, never
reaching the « sudo -v » that sudo-rs refuses, and its shell hook is guarded.
Each tool then reports the version found or « not installed », without
tripping « set -e ».
--- FR ---
Sans pipefail, « curl … | sh » rend le statut de sh, 0 sur une entrée vide :
un téléchargement raté passait pour une pose, son repli ne tournait jamais, et
l'échec se lisait plus loin sous « command not found ». mise et pyenv sont
téléchargés dans un fichier tiré par mktemp, puis exécutés, et un contrôle
refuse tout repli derrière un tube sans pipefail. L'installateur de starship
tourne en root sous un délai root, sans atteindre le « sudo -v » que sudo-rs
refuse, et son crochet de shell est gardé. Chaque outil dit ensuite la version
trouvée ou « non installé », sans faire tomber « set -e ».
Assisted-by: Claude Opus 5
The Proxmox install script calls Debian's own tools — dpkg, apt-get,
hostname, debconf-set-selections. A host without them cannot PLAY it: the
shell returns 127 at the first call, and the truncated output that follows
made nine tests fail on an Arch host. A report carrying nine failures nobody
can act on makes its reader stop looking for what matters. They skip now,
naming the missing tool, judged on what happened rather than on an inventory
— a host may have dpkg without debconf-set-selections.
--- FR ---
Le script d'installation Proxmox appelle les outils de Debian — dpkg,
apt-get, hostname, debconf-set-selections. Une machine qui ne les a pas ne
peut pas le JOUER : le shell rend 127 au premier appel, et la sortie
tronquée faisait échouer neuf tests sur un hôte Arch. Un rapport qui porte
neuf échecs sur lesquels personne ne peut agir fait cesser d'y chercher ce
qui compte. Ils sautent désormais en nommant l'outil absent, jugés sur ce
qui s'est passé et non sur un inventaire — une machine peut porter dpkg
sans debconf-set-selections.
Assisted-by: Claude Opus 5
Ten of the eighteen entries carried no pictogram, and the eye picks one out
of such a list before it reads. Each takes the icon its siblings already use
elsewhere in the tool — 📋 lists, 🧹 cleans, 📊 measures, 🔍 previews, 📥
downloads, 🗂 catalogues, 🖥 tunnels a desktop — so the same picture keeps
meaning the same thing from one menu to the next. A table in the tests holds
the pairing, in both languages, and checks the menu still shows the entries
it freezes.
--- FR ---
Dix des dix-huit entrées ne portaient aucun pictogramme, et l'œil s'y repère
avant de lire. Chacune reçoit l'icône que ses semblables portent déjà
ailleurs dans l'outil — 📋 liste, 🧹 nettoie, 📊 mesure, 🔍 prévisualise, 📥
télécharge, 🗂 catalogue, 🖥 ouvre un bureau —, si bien qu'une même image
garde le même sens d'un menu à l'autre. Un tableau dans les tests fige le
couple, dans les deux langues, et vérifie que le menu affiche encore les
entrées qu'il fige.
Assisted-by: Claude Opus 5
Two tests of test/test_todo_longtest.py measured their surroundings rather
than the code. The descent plan shrinks with free resources by design, so
demanding four levels failed on a host whose disk had filled; the test checks
the invariant at the depth the host allows — each level narrower than its
parent, two vCPUs at least — and skips below two levels, saying so. The
dry-run test counted reports, whose names carry the second they were written
in; it now requires that no report of a real descent was written.
--- FR ---
Deux tests de test/test_todo_longtest.py mesuraient leur environnement plutôt
que le code. Le plan de descente rétrécit avec les ressources libres, c'est
voulu : exiger quatre étages échouait sur un hôte au disque rempli. Le test
vérifie l'invariant à la profondeur que l'hôte permet — chaque étage plus
étroit que son parent, deux vCPU au moins — et se saute sous deux étages en le
disant. Le test à blanc comptait des rapports dont le nom porte la seconde de
leur écriture ; il exige désormais qu'aucun rapport de vraie descente ne soit
écrit.
Assisted-by: Claude Opus 5
The long-test menu printed the command and ran it at once: a mistyped digit
created real VMs, and « --detruire » removes machines with their disks. The
command stays printed, since it is what makes the question answerable, and the
prompt follows it. Warning and question are chosen from the arguments, so a
destruction is never confirmed with the words of a launch. A dry run or a
report creates nothing and asks nothing. Covered by
test/test_longtest_confirm.py.
--- FR ---
Le menu des tests longs affichait la commande et l'exécutait aussitôt : un
chiffre tapé de travers créait de vraies VM, et « --detruire » efface des
machines avec leurs disques. La commande reste affichée, c'est elle qui rend
la question répondable, et l'invite la suit. L'avertissement et la question se
choisissent sur les arguments : une destruction n'est jamais confirmée avec
les mots d'un lancement. Un plan à blanc ou un rapport ne crée rien et ne
demande rien. Couvert par test/test_longtest_confirm.py.
Assisted-by: Claude Opus 5
Aucune VM Fedora ne démarrait : pas de console, pas de bail DHCP, une machine
« en cours d'exécution » qui ne fait rien. Le micrologiciel charge et DÉMARRE
le chargeur — il l'annonce — puis se fige sans écrire un octet sur le disque.
La même image en BIOS démarre son noyau : ce n'est donc ni l'image, saine, ni
sa partition EFI, dont le chemin de repli est bien là. Ni l'entropie ni la
machine q35 n'y changent rien. Une table nomme les distributions concernées et
« --bios » l'emporte toujours, pour l'hôte qui n'a pas OVMF.
--- EN ---
No Fedora VM would start: no console, no DHCP lease, a machine "running" that
does nothing. The firmware loads and STARTS the loader — it says so — then
freezes without writing a byte to disk. The same image under BIOS boots its
kernel: so it is neither the image, which is sound, nor its EFI partition,
whose fallback path is present. Neither entropy nor the q35 machine changes
anything. A table names the distributions concerned, and "--bios" always
wins, for the host that has no OVMF.
Assisted-by: Claude Opus 5
Deux réglages que cloud-init applique au premier démarrage, et qui échouaient
tous les deux SANS arrêter le déploiement. Un nom d'hôte n'accepte ni souligné
ni point, là où un nom de domaine libvirt les tolère : la VM gardait le nom
générique de son image. Un alias de fuseau hérité — la forme que plusieurs
distributions récentes ont reléguée à un paquet séparé — faisait marquer
l'exécution de cloud-init en erreur et laissait la machine en UTC, ce qui ne
se voit qu'après coup sur des horodatages à +0000. Le nom est nettoyé, le
fuseau rendu canonique par la table d'alias de tzdata.
--- EN ---
Two settings cloud-init applies at first boot, both of which failed WITHOUT
stopping the deployment. A hostname accepts neither underscore nor dot, where
a libvirt domain name tolerates them: the VM kept its image's generic name. A
legacy timezone alias — the form several recent distributions moved to a
separate package — marked the cloud-init run as failed and left the machine in
UTC, which only shows up later on +0000 timestamps. The name is cleaned, the
timezone made canonical through tzdata's alias table.
Assisted-by: Claude Opus 5
VMs of one host pulled the same packages again and again, and an install
could not be proven to work without the network. A Go service intercepts the
bridge transparently: a package file is served from disk, an index is always
revalidated upstream and replayed only when upstream is mute, git is mirrored.
Deployment poses the cache authority in QEMU and Proxmox VE guests, and can cut
the network for a whole install. The TODO menu installs, diagnoses, fills,
cleans and copies the store; long_test/qemu_cache.py measures that a second VM
pulls no package upstream. Covered by Go tests and test/test_qemu_cache_*.py.
--- FR ---
Les VM d'un hôte tiraient sans cesse les mêmes paquets, et rien ne prouvait
qu'une installation marche sans réseau. Un service Go intercepte le pont de
façon transparente : un fichier de paquet est servi du disque, un index est
toujours revalidé à l'amont et rejoué seulement quand l'amont est muet, git
est mis en miroir. Le déploiement pose l'autorité du cache dans les invités
QEMU et Proxmox VE, et peut couper le réseau pour toute une installation. Le
menu TODO installe, diagnostique, remplit, nettoie et emporte le magasin ;
long_test/qemu_cache.py mesure qu'une seconde VM ne tire aucun paquet de
l'amont. Couvert par les tests Go et test/test_qemu_cache_*.py.
Assisted-by: Claude Opus 5
Dans le script du service qui pose qemu-guest-agent, « && » et « || » se
lisent à égalité de gauche à droite : une pose apt réussie enchaînait sur
« dnf install », puis sur le « command -v » d'un gestionnaire absent, qui
rend 127 sous dash. Le service finissait en échec après avoir posé
l'agent. Chaque branche est désormais entre accolades. Vérifié : le script
extrait de la vraie configuration cloud-init rend 0 avec apt-get, dnf ou
pacman factice.
--- EN ---
In the script of the service installing qemu-guest-agent, "&&" and "||"
have equal precedence, left to right: a successful apt install went on to
"dnf install", then to the "command -v" of a missing manager, which
returns 127 under dash. The service ended in failure after installing the
agent. Each branch is now braced. Checked: the script extracted from the
real cloud-init configuration returns 0 with a fake apt-get, dnf or
pacman.
Assisted-by: Claude Opus 5
A desktop install repeated « Could not get lock » for minutes, then could run
on an index never refreshed. Disabling the apt-daily timer does not interrupt
the apt-get it already started, so its service is stopped too. The guest agent
is laid by a detached unit that runs its own apt-get update: « cloud-init
status --wait » says done while that lock is still held, so the wait covers
that unit. Retries come back every two seconds, DPkg::Lock::Timeout not
covering the list lock, and an update that never succeeds says so at once.
--- FR ---
Une installation de bureau répétait « Impossible d'obtenir le verrou » pendant
des minutes, puis pouvait tourner sur un index jamais rafraîchi. Désactiver le
minuteur apt-daily n'interrompt pas l'apt-get qu'il a lancé : son service est
donc arrêté aussi. L'agent invité est posé par une unité détachée qui fait son
propre apt-get update : « cloud-init status --wait » dit « done » pendant que
ce verrou est tenu, et l'attente couvre donc cette unité. La reprise repasse
toutes les deux secondes, DPkg::Lock::Timeout ne couvrant pas le verrou des
listes, et un update qui n'aboutit pas le dit sur-le-champ.
Assisted-by: Claude Opus 5
L'étiquette « - Default » ne paraissait jamais, ni au choix de version ni au
choix d'environnement : les deux lectures interrogeaient « Default » avec une
majuscule, quand conf/supported_version_erplibre.json écrit « default ».
dict.get rend None sur une clé absente, sans rien dire — la version par
défaut passait donc pour une version ordinaire, et rien ne le signalait.
Le garde-fou ne vérifie pas ce seul cas : il apparie les deux côtés, et toute
clé que le menu interroge doit exister dans le fichier. Vérifié : 4 tests,
dont deux tombent si la majuscule revient.
--- EN ---
The « - Default » label never appeared, neither on the version choice nor on
the environment one: both reads asked for « Default » with a capital, while
conf/supported_version_erplibre.json writes « default ». dict.get returns None
on a missing key without a word — the default version therefore looked like an
ordinary one, and nothing said otherwise.
The guard does not check that single case: it pairs both sides, and every key
the menu asks for must exist in the file. Checked: 4 tests, two of which fail
if the capital comes back.
Assisted-by: Claude Opus 5
L'outil n'inspectait que « # » : sondé avec des motifs interdits, il restait
muet sur un « .go » et sortait 0. Du Go étant entré dans le dépôt, ses
commentaires n'étaient relus par personne d'autre que leur auteur, alors que
la convention vaut pour tout commentaire.
Trois pièges, et le premier est celui qui compte : « // » ouvre un
commentaire SAUF dans une chaîne, et « https:// » en porte deux. La chaîne
brute entre accents graves n'échappe rien, et « /* … */ » couvre plusieurs
lignes. Vérifié : 8 cas neufs, dont l'URL qui ne doit rien ouvrir.
--- EN ---
The tool only inspected « # »: probed with forbidden patterns, it stayed
silent on a « .go » and exited 0. Now that Go has entered the repository, its
comments were read by nobody but their author, while the convention covers
every comment.
Three traps, and the first is the one that matters: « // » opens a comment
EXCEPT inside a string, and « https:// » carries two of them. The raw string
between backticks escapes nothing, and « /* … */ » spans several lines.
Checked: 8 new cases, including the URL that must open nothing.
Assisted-by: Claude Opus 5
[FIX] selenium, requirement : import et privé réparés, dépendance dite
Trois commits. Le pilotage Firefox ne démarrait plus : tkinter, importé en
tête alors qu'il ne sert qu'au sélecteur de fichier du coffre, rendait tout
le module inimportable sur un Python bâti sans lui. Cet arrêt levé, un second
apparaissait : about:addons n'est plus navigable depuis le contexte contenu
et le contexte chrome exige un drapeau que geckodriver refuse, donc la
permission « fenêtres privées » s'accorde à l'installation de l'extension.
markdown-it-py cesse d'arriver en transitif par un outil de lint. Vérifié :
sombre en fenêtre privée, blanc sans extension, repli geckodriver servi.
--- EN ---
Three commits. Firefox automation no longer started: tkinter, imported at
module level though it only serves the vault's file picker, made the whole
module unimportable on a Python built without it. With that stop lifted, a
second one surfaced: about:addons is no longer reachable from the content
context and the chrome context demands a flag geckodriver rejects, so the
« private windows » permission is now granted when the addon is installed.
markdown-it-py stops arriving transitively through a lint tool. Checked:
dark in a private window, white with no addon, geckodriver fallback hit.
Assisted-by: Claude Opus 5
.claude/settings.json est la configuration partagée du dépôt : la clé
enabledPlugins active superpowers pour tout contributeur qui ouvre Claude Code
ici, sans manipulation de sa part. Le plugin apporte des skills de méthode —
idéation, débogage systématique, TDD, revue de code — et un hook SessionStart
qui s'exécute au démarrage de chaque session.
Aucune version n'est épinglée : chaque poste prend celle que son marketplace a
installée. Vérifié sur la 6.3.0, qui porte quatorze skills et ce seul hook.
--- EN ---
.claude/settings.json is the repository's shared configuration: the
enabledPlugins key turns superpowers on for every contributor who opens Claude
Code here, with nothing to do on their side. The plugin carries method skills
— brainstorming, systematic debugging, TDD, code review — and a SessionStart
hook that runs at the start of every session.
No version is pinned: each workstation gets whatever its marketplace
installed. Checked on 6.3.0, which carries fourteen skills and that one hook.
Assisted-by: Claude Opus 5
Trois entrées sous [Unreleased] : une sous Ajouté pour la dépendance de rendu
markdown, deux sous Corrigé pour le démarrage des scripts Selenium sur un
Python sans tkinter et pour le mode sombre en fenêtre privée.
La source est CHANGELOG.base.md ; la paire générée par make doc_markdown suit
dans le même commit, étant ce que la plupart des lecteurs ouvrent. Vérifié :
les listes anglaise et française portent le même nombre de puces dans chaque
section, Ajouté 16 et Corrigé 8.
--- EN ---
Three entries under [Unreleased]: one under Added for the markdown rendering
dependency, two under Fixed for the Selenium scripts starting on a Python
without tkinter and for dark mode in a private window.
The source is CHANGELOG.base.md; the pair generated by make doc_markdown
follows in the same commit, being what most readers actually open. Checked:
the English and French lists carry the same number of bullets in every
section, Added 16 and Fixed 8.
Assisted-by: Claude Opus 5
Firefox refuse la navigation vers about:addons depuis le contexte contenu, et
le contexte chrome exige -remote-allow-system-access, que geckodriver refuse
via les capabilities : les deux voies vers la case « Exécuter dans les
fenêtres privées » sont fermées.
La permission s'accorde à l'installation, par le champ allowPrivateBrowsing de
/moz/addon/install ; 46 lignes de clics XPath disparaissent. Un geckodriver qui
ignore le champ installe sans la permission au lieu d'interrompre la session.
Vérifié : sombre en fenêtre privée, blanc sans extension, repli servi.
--- EN ---
Firefox refuses navigation to about:addons from the content context, and the
chrome context demands -remote-allow-system-access, which geckodriver rejects
through capabilities: both routes to the « Run in Private Windows » checkbox
are closed.
The permission is now granted at install time, through the allowPrivateBrowsing
field of /moz/addon/install; 46 lines of XPath clicking are gone. A geckodriver
that ignores the field installs without the permission instead of killing the
session. Checked: dark in a private window, white with no addon, fallback hit.
Assisted-by: Claude Opus 5
tkinter ne sert qu'au sélecteur de fichier du coffre, et seulement quand aucun
chemin KDBX n'est configuré. Importé en tête, il rendait tout le pilotage de
navigateur inimportable sur un Python bâti sans lui — donc sur tout serveur
sans paquet d'interface graphique.
Sans tkinter ni chemin configuré, get_kdbx journalise et rend None, comme le
fait déjà kdbx_manager. Vérifié : web_login.py --help sort en 0, et le chemin
dégradé appelé directement rend None.
--- EN ---
tkinter is only needed by the vault file picker, and only when no KDBX path is
configured. Imported at module level, it made the whole browser automation
unimportable on a Python built without it — that is, on any server with no
graphical toolkit package.
With no tkinter and no configured path, get_kdbx logs and returns None, as
kdbx_manager already does. Checked: web_login.py --help exits 0, and the
degraded path called directly returns None.
Assisted-by: Claude Opus 5
The researcher assistant renders the model's markdown into HTML before
sanitising it, and markdown-it-py is the engine. It is present in the
environment only through bandit -> rich, so a lint tool holds up the render
path of a portal page: dropping bandit would drop the engine, with no
diagnostic beyond an ImportError at request time. The pin is declared where
functional dependencies live, not among the development ones, and matches the
version already installed.
--- FR ---
L'assistant du chercheur rend le markdown du modèle en HTML avant de
l'assainir, et markdown-it-py est le moteur. Il n'est présent dans
l'environnement que par la chaîne bandit -> rich : un outil de lint porte
donc le chemin de rendu d'une page portail, et retirer bandit retirerait le
moteur, sans autre diagnostic qu'une ImportError au moment de la requête.
L'épingle est déclarée là où vivent les dépendances fonctionnelles, non
celles de développement, et reprend la version déjà installée.
Assisted-by: Claude Opus 5
[ADD] transform data, et un nom d'organisation retiré d'un test
Deux sujets. Partager un fichier ou une base demandait d'anonymiser à la
main, colonne par colonne, ou de ne pas partager : l'entrée ouvre un
fichier externe — Excel, Access, CSV, XML, JSON — ou une base Odoo, dit
ce qu'elle porte, puis en tire une copie. L'original n'est jamais touché.
Deux règles gouvernent ce qui sort. Une colonne n'est laissée intacte que
sur son CONTENU mesuré, hors onze étiquettes structurelles. Et la copie
est relue octet par octet, un classeur portant de la donnée en une
douzaine d'endroits qui ne sont pas des cellules.
Vérifié : 5 748 tests — 13 rouges, déjà rouges sur master.
--- EN ---
Two subjects. Sharing a file or a database meant anonymising by hand,
column by column, or not sharing: the entry opens an external file —
Excel, Access, CSV, XML, JSON — or an Odoo database, says what it holds,
then draws a copy of it. The original is never touched.
Two rules govern what comes out. A column is left alone on its measured
CONTENT, bar eleven structural labels. And the copy is reread byte by
byte, a workbook holding data in a dozen places that are not cells.
Checked: 5,748 tests — 13 red, already red on master.
Assisted-by: Claude Opus 5
Partager un fichier ou une base demandait d'anonymiser à la main,
colonne par colonne, ou de ne pas partager. L'entrée ouvre un fichier
externe — Excel, Access, CSV, XML, JSON — ou une base Odoo, dit ce
qu'elle porte, puis en tire une copie. L'original n'est jamais touché.
Deux règles gouvernent ce qui sort. Une colonne n'est laissée intacte
que sur son CONTENU mesuré, hors onze étiquettes structurelles : décider
sur l'étiquette recopiait les colonnes les plus identifiantes en les
annonçant protégées. Et la copie est relue octet par octet, un classeur
portant de la donnée en une douzaine d'endroits hors des cellules.
Vérifié : 5 748 tests — 13 rouges, déjà rouges sur master.
--- EN ---
Sharing a file or a database meant anonymising by hand, column by
column, or not sharing. The entry opens an external file — Excel,
Access, CSV, XML, JSON — or an Odoo database, says what it holds, then
draws a copy of it. The original is never touched.
Two rules govern what comes out. A column is left alone on its measured
CONTENT, bar eleven structural labels: deciding on the label copied the
most identifying columns verbatim while announcing them as protected.
And the copy is reread byte by byte, a workbook holding data in a dozen
places that are not cells.
Checked: 5,748 tests — 13 red, already red on master.
Assisted-by: Claude Opus 5
La règle des conventions est explicite : l'exemple qui illustre un
interdit s'invente, et un test fige sa valeur pour toujours. Le nom d'une
organisation tierce servait de profil et de passerelle dans quatorze
occurrences, choisi parce qu'il était parlant — exactement le réflexe que
la règle combat.
Le remplaçant est inventé et vérifié absent du reste du dépôt. Ce que le
test éprouve ne change pas : un profil sans route reste accepté et
signalé.
--- EN ---
The conventions are explicit: an example illustrating a prohibition is
invented, and a test freezes its value forever. A third-party
organisation's name served as profile and gateway in fourteen places,
picked because it spoke — exactly the reflex the rule fights.
The replacement is invented and verified absent from the rest of the
repository. What the test proves does not change: a profile without
routes is still accepted and flagged.
Assisted-by: Claude Opus 5
[ADD] assistant LLM, et dix correctifs : secrets, sudo, ssh, i18n
12 commits, deux sujets. L'entrée « Question IA » envoyait toute question à
une seule API distante, sur un modèle figé et sans historique : aucun serveur
local n'était atteignable, et rien ne disait où partait le texte.
Deux règles gouvernent ce qui la remplace. Un port ne dit jamais qui répond —
un seul en héberge jusqu'à trois — donc l'identité se lit dans le corps. Et
une adresse ne devient jamais du texte d'invite, d'où une poignée opaque.
Dix correctifs suivent, hors périmètre et chacun son commit : une clé d'API
caviardée dans les traces, un sudo interactif retiré d'un affichage, trois
lecteurs de configuration SSH accordés, onze menus sans fil d'Ariane.
Vérifié : 5 092 tests, et contre un serveur du réseau.
--- EN ---
12 commits, two subjects. The "AI question" entry sent every question to a
single remote API, on a frozen model and with no history: no local server was
reachable, and nothing said where the text was going.
Two rules govern what replaces it. A port never says who answers — one hosts
up to three products — so identity is read from the body. And an address never
becomes prompt text, hence an opaque handle in its place.
Ten fixes follow, out of scope and one commit each: an API key redacted from
traces, an interactive sudo removed from a display, three readers of the SSH
configuration made to agree, eleven menus with no breadcrumb.
Checked: 5,092 tests, and against a server on the network.
Assisted-by: Claude Opus 5
L'entrée « non publié » ne portait que la fonctionnalité. Un lecteur qui
décide d'une mise à jour n'y voyait ni le mot de passe root qu'on ne lui
demande plus, ni le drapeau qui repart sur Python 3.14, ni la clé d'API
désormais caviardée dans une trace.
Trois sections dans l'ordre du fichier — six correctifs, un retrait de
dépendance, une entrée de sécurité — et une puce de plus sous « Ajouté » pour
le signal neuf de l'outil d'hygiène. Les deux langues portent le même nombre
de puces dans le même ordre, vérifié par comptage : les deux listes se lisent
côte à côte, et une puce d'un seul côté laisse l'autre moitié fausse.
--- EN ---
The "unreleased" entry carried only the feature. A reader deciding on an
upgrade saw neither the root password no longer asked of them, nor the flag
that runs again on Python 3.14, nor the API key now redacted from a trace.
Three sections in the file's own order — six fixes, one dependency removal,
one security entry — and one more bullet under "Added" for the hygiene tool's
new signal. Both languages carry the same number of bullets in the same
order, verified by counting: the two lists are read side by side, and a
bullet on one side only leaves the other half wrong.
Assisted-by: Claude Opus 5
Le paquet était déclaré, donc installé dans chaque environnement, et aucun
fichier ne l'importe. Il est aussi le mauvais outil pour ce dépôt : la
configuration SSH s'y lit soit par `ssh -G`, qui connaît les `Include`, les
`Match` et l'héritage des jokers, soit par le lecteur de lignes du paquet,
et une bibliothèque tierce n'apporte ni l'un ni l'autre.
Un test de la découverte affirme déjà qu'il n'est pas importé là où il
tenterait : cette assertion garde tout son sens, elle n'a plus de paquet
derrière elle.
--- EN ---
The package was declared, so installed into every environment, and no file
imports it. It is also the wrong tool for this repository: SSH configuration
is read here either through `ssh -G`, which knows about `Include`, `Match` and
wildcard inheritance, or through the package's own line reader, and a
third-party library brings neither.
A discovery test already asserts it is not imported where it would be
tempting: that assertion keeps all its meaning, it simply no longer has a
package behind it.
Assisted-by: Claude Opus 5
L'outil voyait les adresses, les courriels et les chemins de compte, mais pas
les NOMS — la classe que la règle interdit au même titre, et celle qu'un
assistant qui parcourt le réseau multiplie. Le rapport annonçait « 0
identifiant » sur un fichier qui en portait un.
Un signal à relire, jamais une trouvaille : un nom d'hôte NU ne se distingue
mécaniquement ni d'un mot ordinaire ni du nom d'un logiciel, donc seule la
forme qualifiée se reconnaît, contre une liste FERMÉE de suffixes. En sortent
l'en-tête de copyright, les domaines de la RFC 2606, et toute adresse portée
par une URL. Vérifié : 54 tests, et 21 signaux sur le dépôt, tous des miroirs.
--- EN ---
The tool saw addresses, e-mails and account paths, but not NAMES — the class
the rule forbids just as much, and the one an assistant sweeping the network
multiplies. The report announced "0 identifying" on a file that carried one.
A signal to re-read, never a finding: a BARE host name is mechanically
indistinguishable from an ordinary word or a piece of software, so only the
qualified form is recognised, against a CLOSED list of suffixes. Out of it go
the copyright header, the RFC 2606 domains, and any address carried by a URL.
Checked: 54 tests, and 21 signals across the repository, all mirrors.
Assisted-by: Claude Opus 5
`click.prompt` ajoute son propre « : » à l'étiquette qu'on lui donne, et
quinze étiquettes le portaient déjà. Le menu le plus vu du logiciel demandait
donc « Commande :: », et sept invites de déploiement à distance affichaient
un deux-points suivi d'un autre.
Le suffixe est désormais explicite partout où l'étiquette ponctue elle-même,
et sa valeur se déduit de l'étiquette : rien quand elle porte déjà l'espace
qui suit, un espace quand le deux-points est nu. Un contrôle lit l'arbre et
résout les DEUX langues, le français mettant une espace avant le deux-points
là où l'anglais n'en met pas — chercher dans le texte du code ne verrait que
la clé anglaise.
--- EN ---
`click.prompt` adds its own ":" to the label it is given, and fifteen labels
already carried one. The most-seen menu of the software therefore asked
"Command:: ", and seven remote-deployment prompts showed a colon followed by
another.
The suffix is now explicit wherever the label punctuates itself, and its value
follows from the label: nothing when it already carries the trailing space, a
space when the colon is bare. A check reads the tree and resolves BOTH
languages, French putting a space before the colon where English does not —
searching the code text would only see the English key.
Assisted-by: Claude Opus 5
Le drapeau `--max_process` de deux scripts passe par ce pool, et il ne
tournait plus du tout. Deux retraits d'API le traversaient : `loop=` a quitté
`asyncio.wait` en 3.10, où le passer lève un TypeError, et
`asyncio.get_event_loop()` lève hors d'une loop en marche depuis 3.14, où il
ne faisait qu'avertir — donc la classe n'était même plus instanciable, alors
que l'aide annonce toujours l'option.
La loop n'est plus créée à l'instanciation mais à l'exécution, et `close` ne
ferme que celle que la classe a ouverte : une loop reçue en argument
appartient à l'appelant, qui compte encore dessus. Vérifié : 7 tests sur de
vraies coroutines, et les deux appels d'origine lèvent toujours à part.
--- EN ---
The `--max_process` flag of two scripts goes through this pool, and it no
longer ran at all. Two API removals crossed it: `loop=` left `asyncio.wait` in
3.10, where passing it raises a TypeError, and `asyncio.get_event_loop()`
raises outside a running loop since 3.14, where it merely warned before — so
the class was not even constructible, while the help still advertises the
option.
The loop is no longer created at construction but at run time, and `close`
only closes the one the class opened: a loop received as an argument belongs to
the caller, who still counts on it. Checked: 7 tests on real coroutines, and
both original calls still raise on their own.
Assisted-by: Claude Opus 5
Trois clés étaient déclarées deux fois dans un littéral de trois mille
entrées. Rien n'avertit et rien ne lève : la seconde gagne, et le prix s'est
déjà payé en étiquette de menu, la traduction lue n'étant pas celle qu'on
venait d'écrire au premier endroit. Les trois portaient la même traduction des
deux côtés, donc aucun écran ne change ; c'est le piège qui part.
Le contrôle passe de « pas plus de trois » à « aucune », et il vit désormais
avec les tests d'internationalisation plutôt qu'avec ceux d'un menu. Il lit
l'ARBRE : une fois le dictionnaire construit, le doublon a déjà disparu et il
n'y a plus rien à demander.
--- EN ---
Three keys were declared twice in a literal of three thousand entries.
Nothing warns and nothing raises: the second wins, and the price was already
paid on a menu label, the translation read not being the one just written at
the first place. All three carried the same translation on both sides, so no
screen changes; what goes is the trap.
The check moves from "no more than three" to "none at all", and it now lives
with the internationalisation tests rather than with a menu's. It reads the
TREE: once the dictionary is built the duplicate is already gone, and there is
nothing left to ask.
Assisted-by: Claude Opus 5
Onze sous-menus n'avaient pas d'étiquette de fil d'Ariane. Leur segment
manquait à l'en-tête, et la télémétrie les traitait comme des COMMANDES : ils
apparaissaient en feuille, sous leur nom de méthode brut.
Le contrôle qui devait l'attraper cherchait dans la table de répartition du
menu Exécution, donc il ne voyait que les sous-menus atteints depuis là — un
menu ouvert depuis ailleurs, ou défini dans un mixin, n'était jamais examiné.
Il cherche maintenant par ce que le code APPELLE, dans tout le paquet, et
trois exemptions périmées ont disparu avec lui. Cinq écrans restent exemptés
et disent pourquoi : ce sont des actions qui posent une question.
--- EN ---
Eleven submenus had no breadcrumb label. Their segment was missing from the
header, and telemetry treated them as COMMANDS: they showed up as leaves,
under their raw method name.
The check meant to catch this looked in the Execute menu's dispatch table, so
it only saw submenus reached from there — a menu opened from elsewhere, or
defined in a mixin, was never examined. It now searches by what the code
CALLS, across the whole package, and three stale exemptions went with it. Five
screens stay exempt and say why: they are actions that ask a question.
Assisted-by: Claude Opus 5
Trois lecteurs de ~/.ssh/config tranchaient la même question autrement : l'un
comparait le mot-clé avec la casse, un autre exigeait un espace là où une
tabulation est légale, un troisième laissait passer le motif nié `!nom`. Un
alias déclaré « host » en minuscules était donc vu par l'un et invisible aux
deux autres, ce qui se lit comme une panne intermittente de la découverte.
La décision passe dans un module qui ne lit aucun fichier. Il rend None sur ce
qui n'est pas une déclaration et une liste — possiblement vide — sur ce qui en
est une : « Host * » ne nomme aucune machine mais reste une déclaration, sinon
ses directives se rattachent au bloc précédent. Vérifié : 19 tests, et le menu
reconnaît toujours le serveur du réseau par sa source SSH.
--- EN ---
Three readers of ~/.ssh/config settled the same question differently: one
compared the keyword case-sensitively, another required a space where a tab is
legal, a third let the negated pattern `!name` through. An alias declared with
a lowercase "host" was therefore seen by one and invisible to the other two,
which reads as intermittent discovery failure.
The decision moves into a module that reads no file. It returns None for what
is not a declaration and a list — possibly empty — for what is: "Host *" names
no machine yet remains a declaration, otherwise its directives attach to the
previous block. Checked: 19 tests, and the menu still recognises the server on
the network through its SSH source.
Assisted-by: Claude Opus 5
Un nom d'organisation servait d'exemple dans une docstring et dans quatre
tests — nom de base, chemin de compte, préfixe de copie. La règle du dépôt
l'interdit partout hors de `private/`, et ces fichiers suivent le dépôt en
amont : sur un fork rendu public, l'exemple le devient aussi.
Un test le fige pour toujours, et trois des cinq sites servaient justement à
démontrer qu'un chemin de compte ou un nom est refusé. Une valeur inventée
démontre aussi bien, et celle-ci ne paraît nulle part ailleurs. La docstring
perd son exemple : il n'illustrait que « long », et la phrase le dit
maintenant. Le détecteur du dépôt ne voit pas cette classe — il n'annonçait
rien ici.
--- EN ---
An organisation's name served as an example in one docstring and in four
tests — a database name, an account path, a copy prefix. The repository's rule
forbids it anywhere outside `private/`, and these files follow the repository
upstream: on a fork made public, the example becomes public too.
A test freezes it forever, and three of the five sites existed precisely to
demonstrate that an account path or a name is refused. An invented value
demonstrates just as well, and this one appears nowhere else. The docstring
loses its example: it only illustrated "long", which the sentence now says.
The repository's detector does not see this class — it reported nothing here.
Assisted-by: Claude Opus 5
La lecture passait par « sudo sh -c cat » sans jamais demander si le privilège
était nécessaire. Elle est appelée une fois par VM pour afficher une liste, et
toutes les trois secondes pendant dix minutes par l'attente d'une VM : l'invite
root tombait donc en boucle au milieu d'un écran, ce qui entraîne à taper un
mot de passe root dans ce qui le demande.
La lecture directe passe d'abord et suffit sur une installation standard, ces
fichiers d'état étant en 0644 là où le « .conf » voisin est en 0600. Le
privilège n'est tenté qu'ensuite, avec « -n », qui échoue au lieu de demander ;
un répertoire interdit rend un glob vide, d'où l'essai même sans chemin trouvé.
Les deux appelants se replient déjà sur une autre source. Vérifié : 12 tests.
--- EN ---
The read went through "sudo sh -c cat" without ever asking whether the
privilege was needed. It is called once per VM to display a list, and every
three seconds for ten minutes while waiting on a VM: the root prompt therefore
landed in a loop in the middle of a screen, which trains someone to type a root
password into whatever asks for it.
The direct read comes first and suffices on a standard install, those status
files being 0644 where the neighbouring ".conf" is 0600. The privilege is only
tried afterwards, with "-n", which fails instead of asking; a forbidden
directory returns an empty glob, hence the attempt even with no path found.
Both callers already fall back to another source. Checked: 12 tests.
Assisted-by: Claude Opus 5
Le filtre ne connaissait que trois noms de variable — mot de passe, secret,
jeton — donc `OPENAI_API_KEY=` partait en clair dans le terminal, dans les
journaux et dans toute sortie CI qui les capture. Un jeton d'en-tête échappait
aux deux règles par construction : il ne porte ni nom d'option ni nom de
variable, il suit le mot « Bearer ».
Le filtre couvre maintenant `API_KEY` côté variables et `Authorization:
Bearer|Basic` côté en-têtes, sans casse, la valeur allant jusqu'au premier
blanc. Il protège au même titre la restauration de base, qui l'appelle sur
six sorties. Reste le dernier rempart et non le premier : argv est lisible par
tout compte de la machine, où aucun caviardage n'atteint.
--- EN ---
The filter knew only three variable names — password, secret, token — so
`OPENAI_API_KEY=` went out in the clear to the terminal, to the logs and to
any CI output capturing them. A header token escaped both rules by
construction: it carries neither an option name nor a variable name, it
follows the word "Bearer".
The filter now covers `API_KEY` on the variable side and `Authorization:
Bearer|Basic` on the header side, case-insensitively, the value running to the
first blank. It protects database restore just as much, which calls it on six
outputs. It stays the last line of defence, not the first: argv is readable by
every account on the machine, where no redaction reaches.
Assisted-by: Claude Opus 5
L'entrée « Question IA » envoyait toute question à une seule API distante, sur
un modèle figé et sans historique : aucun serveur local n'était atteignable,
et rien ne disait où partait le texte.
Deux règles gouvernent ce qui la remplace. Un port ne dit jamais qui répond —
un seul en héberge jusqu'à trois, et une famille réémet l'API d'une autre en
entier — donc l'identité se lit dans le CORPS, par une échelle ordonnée. Et
une adresse ne devient jamais du texte d'invite : le détecteur du dépôt ne
voit pas les noms d'hôte, d'où une poignée opaque à sa place.
Vérifié : 284 tests, et contre un serveur du réseau — reconnaissance,
capacités lues, conversation multi-tours, triage juste.
--- EN ---
The "AI question" entry sent every question to a single remote API, on a
frozen model and with no history: no local server was reachable, and nothing
said where the text was going.
Two rules govern what replaces it. A port never says who answers — one hosts
up to three products, and one family re-serves another's native API in full —
so identity is read from the BODY, by an ordered ladder. And an address never
becomes prompt text: the repository's detector does not see host names, hence
an opaque handle in its place.
Checked: 284 tests, and against a server on the network — recognition,
capabilities read, a multi-turn conversation, a correct triage.
Assisted-by: Claude Opus 5
[FIX] vpn : ne plus demander une route que le pilote ne pose pas
2 commits. Le formulaire demandait « tout le trafic ? » à un pilote dont
le serveur décide du routage, ne faisait rien de la réponse, et l'état la
jugeait quand même : un champ sans effet et un verdict en échec permanent
sur un tunnel sain.
Un drapeau dit désormais quels pilotes posent cette route ; les autres ne
sont ni interrogés ni jugés. L'honorer serait pire qu'inutile — forcer une
route par défaut contre une passerelle en tunnel scindé donne un trou
noir. Les routes déclarées restent honorées, et le formulaire nomme
« 0.0.0.0/0 ». Une recherche de préréglage sans appelant part avec.
Vérifié : 274 tests unitaires du VPN.
--- EN ---
2 commits. The form asked "all traffic?" of a driver whose server decides
the routing, did nothing with the answer, and status judged it anyway: a
field with no effect and a permanently failed verdict on a healthy tunnel.
A flag now says which drivers lay that route; the others are neither
asked nor judged. Honouring it would be worse than useless — forcing a
default route against a split-tunnel gateway gives a black hole. Declared
routes stay honoured, and the form names "0.0.0.0/0". A preset lookup
with no caller goes with it. Checked: 274 VPN unit tests.
Assisted-by: Claude Opus 5
`presets.load(identifiant)` n'avait aucun appelant hors de son propre
test : une interface publique inventée pour un besoin qui ne s'est pas
présenté, et un test qui n'existait que parce qu'elle existait. Le menu
liste par `load_all` et choisit par rang.
Elle reviendra le jour où un CLI prendra un préréglage par son nom, avec
le test que ce besoin justifiera. Vérifié : 48 tests des préréglages
verts, et aucun appel résiduel dans script/ ni test/.
--- EN ---
`presets.load(identifier)` had no caller outside its own test: a public
interface invented for a need that never arose, and a test that existed
only because the interface did. The menu lists through `load_all` and
picks by rank.
It comes back the day a CLI takes a preset by name, with the test that
need will justify. Checked: 48 preset tests green, and no remaining call
in script/ or test/.
Assisted-by: Claude Opus 5
Le formulaire demandait « tout le trafic ? » à un pilote dont le SERVEUR
décide du routage, ne faisait rien de la réponse, et `status` la jugeait
quand même : un ✗ permanent sur un tunnel sain, et un profil annonçant
« tout le trafic » sans l'obtenir.
Un drapeau, sur le modèle de celui du MTU, dit quels pilotes posent cette
route. Les autres ne sont ni interrogés ni jugés, et un drapeau laissé à
vrai n'est plus conservé. L'honorer serait pire qu'inutile : forcer une
route par défaut contre une passerelle en tunnel scindé donne un trou
noir, une passerelle ne routant pas ce qu'elle n'a pas annoncé. Les routes
déclarées, elles, restent honorées — le formulaire le dit.
--- EN ---
The form asked "all traffic?" of a driver whose SERVER decides the
routing, did nothing with the answer, and `status` judged it anyway: a
permanent ✗ on a healthy tunnel, and a profile announcing "all traffic"
without getting it.
A flag, modelled on the MTU one, says which drivers lay that route. The
others are neither asked nor judged, and a flag left true is no longer
kept. Honouring it would be worse than useless: forcing a default route
against a split-tunnel gateway gives a black hole, a gateway not routing
what it never advertised. Declared routes are still honoured — the form
says so.
Assisted-by: Claude Opus 5
[ADD] vpn : joindre un service SAML d'un site, du profil au tunnel
8 commits. L'outil montait cinq technologies mais ne joignait pas un
service qui authentifie par un fournisseur d'identité : openconnect
s'arrête sur « No SSO handler », les distributions le bâtissant sans
webview.
Le profil AnyConnect d'un site devient un préréglage, et les deux
« groupes » qu'expose Cisco sont distingués — les confondre donnait le
formulaire d'un autre service. L'étape web est déléguée à un greffon, le
tunnel monté par le pilote : nom d'interface, état et diagnostic restent
au profil. Les préréglages d'un site vivent dans un répertoire ignoré par
git. Vérifié : 269 tests, un tunnel monté puis démonté pour de vrai.
--- EN ---
8 commits. The tool could bring up five technologies but could not reach
a service authenticating through an identity provider: openconnect stops
on "No SSO handler", distributions building it without a webview.
A site's AnyConnect profile now becomes a preset, and the two "groups"
Cisco exposes are told apart — confusing them handed over another
service's login form. The web step is delegated to a helper, the tunnel
brought up by the driver: interface name, state and diagnosis stay with
the profile. A site's presets live in a git-ignored directory. Checked:
269 unit tests, and one tunnel really mounted then torn down.
Assisted-by: Claude Opus 5
Huit puces sous « Unreleased », pour qui choisit de mettre à jour et non
pour qui relit le diff : ce que l'outil joint désormais, et ce qu'il
refusait avant. Le VPN lui-même est arrivé en 1.8.0 ; ces lignes disent
ce qui s'y ajoute.
La section « Added » n'existait pas encore sous « Unreleased » : elle est
créée dans les deux langues, au format du fichier, et les deux listes se
lisent côte à côte dans le même ordre. Régénéré par mmg. Rien
d'identifiant : ni établissement, ni passerelle réelle, ni adresse.
--- EN ---
Eight bullets under "Unreleased", written for someone choosing whether to
upgrade and not for someone reviewing the diff: what the tool now reaches,
and what it used to refuse. The VPN itself landed in 1.8.0; these lines
say what is being added to it.
The "Added" section did not exist yet under "Unreleased": it is created in
both languages, in the file's own format, and the two lists read side by
side in the same order. Regenerated by mmg. Nothing identifying: no
institution, no real gateway, no address.
Assisted-by: Claude Opus 5
Le verdict se fondait sur le seul fichier d'état, que RIEN n'efface quand
un tunnel meurt sans passer par « down » — machine redémarrée, processus
tué, session expirée. Un état laissé derrière était annoncé monté sur
l'écran même qui déclarait le processus mort et l'interface absente.
L'interface arbitre désormais : son nom vient de l'état s'il y en a un,
sinon du pilote pour ceux qui la nomment d'avance, si bien qu'un tunnel
monté hors de l'outil est vu aussi. Sshuttle n'en crée aucune, là le
processus reste seul juge. La liste des profils le marque, connecter un
profil déjà monté demande confirmation, et déconnecter un profil déjà
tombé le dit sans l'empêcher : « down » nettoie l'état laissé.
--- EN ---
The verdict rested on the state file alone, which NOTHING clears when a
tunnel dies without going through "down" — machine rebooted, process
killed, session expired. A leftover state was reported as mounted on the
very screen declaring the process gone and the interface absent.
The interface now arbitrates: its name comes from the state when there is
one, otherwise from drivers that name it in advance, so a tunnel brought
up outside the tool is seen too. Sshuttle creates none, and there the
process stays the only judge. The profile list marks it, connecting an
already-mounted profile asks first, and disconnecting an already-down one
says so without refusing: "down" clears the leftover state.
Assisted-by: Claude Opus 5
Personne ne retient « /opt/cisco/secureclient/vpn/profile ». Le chemin
tapé oblige à le connaître ; le parcours seul n'aide pas quand le fichier
vient d'ailleurs, d'un courriel ou du portail d'un site. Les deux, dans
cet ordre, et la saisie reprend la main dès qu'on sort du parcours sans
rien choisir ou qu'on en rapporte un répertoire.
Le parcours n'est proposé que si l'un des répertoires connus existe :
l'ouvrir sur un chemin absent afficherait une liste vide, ce qui ressemble
à une panne. Vérifié : 7 tests unitaires, dont chacun des replis.
--- EN ---
Nobody remembers "/opt/cisco/secureclient/vpn/profile". A typed path
requires knowing it; browsing alone does not help when the file comes
from elsewhere, from an e-mail or a site's portal. Both, in that order,
and typing takes over as soon as one leaves the browser without choosing
anything, or brings back a directory from it.
Browsing is offered only if one of the known directories exists: opening
it on an absent path would show an empty list, which looks like a fault.
Checked: 7 unit tests, one for each fallback.
Assisted-by: Claude Opus 5
openconnect refuse les passerelles qui exigent un navigateur intégré, sur
« No SSO handler » : les distributions le bâtissent sans webview. Rien
n'installait le greffon qui fait cette étape, que le pilote attendait
pourtant — une machine paraissait équipée sans l'être.
La question n'est posée que pour le pilote qui peut s'en servir, et
seulement quand le greffon manque. Son amont est arrêté depuis 2023 :
épingles intenables sur un Python récent, Qt et lxml pris de la
distribution, correctif rejoué à chaque installation. Le venv appartient
à l'utilisateur, non à root, qui n'a ni affichage ni trousseau. Vérifié :
installation depuis rien en 6,5 s, paquets éprouvés sur debian et ubuntu.
--- EN ---
openconnect refuses gateways demanding an embedded browser, on "No SSO
handler": distributions build it without a webview. Nothing installed the
helper that performs that step, which the driver expected all the same —
a machine looked equipped without being so.
The question is asked only for the driver that can use it, and only when
the helper is missing. Its upstream has been unmaintained since 2023:
pins unsatisfiable on a recent Python, Qt and lxml taken from the
distribution, a patch replayed on every install. The venv belongs to the
user, not root, which has neither display nor keyring. Checked: install
from nothing in 6.5 s, package names proven on debian and ubuntu only.
Assisted-by: Claude Opus 5
Deux mécanismes désignent un service sur un concentrateur : un chemin
d'URL, une valeur de menu déroulant. Les confondre rend le formulaire d'un
AUTRE service — identifiants justes refusés, rien ne désignant le groupe.
Et certains ne comparent que les N premiers caractères du mot de passe,
que le profil déclare désormais sans jamais rien tronquer.
Une passerelle qui exige un navigateur intégré arrête openconnect sur
« No SSO handler », les distributions le bâtissant sans webview. Un greffon
fait l'étape web et rend un cookie ; le pilote monte lui-même, et le profil
garde son interface, son état et son diagnostic.
Vérifié : 249 tests unitaires, un tunnel monté contre une passerelle SAML.
--- EN ---
Two mechanisms designate a service on one concentrator: a URL path, and a
dropdown value. Confusing them hands over ANOTHER service's login form —
correct credentials refused, with nothing pointing at the group. And some
compare only the first N characters of the password, which the profile now
declares without ever truncating anything.
A gateway demanding an embedded browser stops openconnect on "No SSO
handler", distributions building it without a webview. A helper does the
web step and returns a cookie; the driver mounts the tunnel itself, so the
profile keeps its interface, its state and its diagnosis.
Checked: 249 unit tests, and one tunnel mounted against a SAML gateway.
Assisted-by: Claude Opus 5
Un site publie sa passerelle, son protocole et son groupe de connexion.
Les retaper sur chaque poste, c'est se tromper un jour sur le seul champ
qui décide du service joint. Un préréglage est un profil PARTIEL, sans
identifiant ni secret : c'est ce qui lui permet de circuler.
Les répertoires sont lus dans l'ordre et le plus tardif gagne sur un même
identifiant, pour qu'un site corrige un gabarit livré sans modifier de
fichier suivi, donc sans conflit au prochain pull. Un fichier illisible
est signalé et sauté : sinon la panne se lit « aucun préréglage » alors
qu'il y en a dix. Un profil AnyConnect porte déjà les trois balises
utiles, il est donc lu directement. Vérifié : 19 tests unitaires.
--- EN ---
A site publishes its gateway, protocol and connection group. Retyping
them on every machine means getting the one field that decides which
service you reach wrong some day. A preset is a PARTIAL profile, with no
username and no secret: that is what lets it be handed around.
Directories are read in order and the latest wins on the same identifier,
so a site can fix a shipped template without editing a tracked file, and
without a conflict on the next pull. An unreadable file is reported and
skipped: otherwise the fault reads as "no preset" when ten exist. An
AnyConnect profile already carries the three useful tags, so it is read
directly. Checked: 19 unit tests.
Assisted-by: Claude Opus 5
openconnect appelle vpnc-script pour poser les routes et le DNS. Il vient
d'un paquet distinct, dont le nom change de famille en famille et qui
l'installe à des endroits différents. C'est un FICHIER qu'on cherche, pas
un binaire du PATH : le contrôle des binaires ne peut donc pas le voir.
Sans lui, la session s'ouvre, openconnect démarre, et l'interface tun
n'apparaît jamais. La panne se manifeste trois étages au-dessus du paquet
absent, sur un symptôme qui ne l'accuse pas. L'installateur nomme
désormais le paquet à poser, par famille de distribution.
--- EN ---
openconnect calls vpnc-script to lay down routes and DNS. It ships in a
separate package whose name varies by family and which installs it at
different paths. It is a FILE we look for, not a binary on the PATH, so
the binary check cannot see it.
Without it the session opens, openconnect starts, and the tun interface
never appears. The failure surfaces three stages above the missing
package, on a symptom that does not accuse it. The installer now names
the package to install, per distribution family.
Assisted-by: Claude Opus 5
Un préréglage de site nomme un établissement, sa passerelle et son groupe
de connexion. Rien de tout cela n'a sa place dans un dépôt public : sur un
fork, ce qui est commité devient public comme le reste.
Le répertoire ignoré sert de point de montage à un dépôt privé, qui les
versionne là où le dépôt lui-même est privé.
--- EN ---
A site preset names an institution, its gateway and its connection group.
None of that belongs in a public repository: on a fork, whatever is
committed becomes public like the rest.
The ignored directory is the mount point for a private repository, which
versions those presets where the repository itself is private.
Assisted-by: Claude Opus 5
[ADD] release : 1.8.0 publiée, 1.7.0 rattrapée, non-publié resserré
5 commits. Le tag v1.7.0 existait depuis mars sans section de changelog, et
ses 209 commits restaient au non-publié, gonflé à 152 puces d'un paragraphe
par langue — illisible pour qui décide s'il met à jour. 1.7.0 documente
désormais ce que son tag porte ; le travail d'après tient en 39 puces d'une
ligne et paraît en 1.8.0, note de migration comprise ; la version déclarée
suit à onze endroits, du fichier semver que lit env_var.sh aux huit pyproject.
L'installation Arch pose le paginateur less, sans lequel git ne pagine rien.
Le tag, default.xml et les images docker suivent la procédure, hors d'ici.
Vérifié : parité en/fr par section, ERPLIBRE_VERSION=1.8.0, tests de version.
--- EN ---
5 commits. Tag v1.7.0 had existed since March with no changelog section, and
its 209 commits stayed in the unreleased list, swollen to 152 paragraph-long
entries per language — unreadable for someone deciding whether to upgrade.
1.7.0 now documents what its tag carries; the work that followed fits in 39
one-line entries and ships as 1.8.0, migration note included; the declared
version follows in eleven places, from the semver file env_var.sh reads to the
eight pyproject files. Arch installs the less pager, without which git pages
nothing. The tag, default.xml and the docker images follow the procedure,
outside this. Checked: en/fr parity per section, ERPLIBRE_VERSION=1.8.0,
version tests green.
Assisted-by: Claude Opus 5
Les 39 puces du non-publié décrivent du travail fini qu'aucun numéro ne
permettait de citer. La section 1.8.0 les porte, avec la note de migration que
réclament le choix de l'interpréteur Python et le retrait d'Ubuntu 20.04 et
22.04. La version déclarée suit, comme le veut doc/RELEASE.base.md : le
fichier semver que lit env_var.sh, les huit pyproject, npm, CLAUDE.md et la
note des versions supportées. La ligne de contracts/compatibility.json reste
en 1.7.0, elle atteste un appariement mobile éprouvé et non la version
courante. Le commentaire de todo.py ne nomme plus de version, celle du dépôt
étant marquée « default » dans le fichier des versions supportées.
Vérifié : ERPLIBRE_VERSION=1.8.0, parité 17/8/10/2/2, tests de version verts.
--- EN ---
The unreleased list's 39 entries describe finished work no number could cite.
The 1.8.0 section carries them, with the migration note that choosing the
Python interpreter and dropping Ubuntu 20.04 and 22.04 call for. The declared
version follows, as doc/RELEASE.base.md wants: the semver file env_var.sh
reads, the eight pyproject files, npm, CLAUDE.md and the supported-version
note. The contracts/compatibility.json row stays at 1.7.0, attesting a tested
mobile pairing and not the current version. The todo.py comment names no
version any more, the repository's own being marked « default » in the
supported-version file. Checked: ERPLIBRE_VERSION=1.8.0, 17/8/10/2/2 parity,
version tests green.
Assisted-by: Claude Opus 5
La section portait 152 puces par langue, souvent d'un paragraphe chacune :
illisible pour qui décide s'il met à jour, et un changelog se lit pour
décider, non pour relire un diff. Elle en porte 39, d'une ligne, regroupées
par sujet pour qu'aucun thème ne disparaisse — les 24 puces sur les VM QEMU
tiennent en cinq lignes, les 14 correctifs d'installation en une. Le détail
part volontairement ; il reste dans les commits. Restent la liste des
distributions, qu'un lecteur y cherche la sienne, et les chiffres qui bornent
en trois mots. Vérifié : parité 17/8/10/2/2 dans les deux langues.
--- EN ---
The section carried 152 entries per language, often a paragraph each:
unreadable for someone deciding whether to upgrade, and a changelog is read
to decide, not to review a diff. It now carries 39, one line each, grouped by
subject so no theme disappears — the 24 entries on QEMU VMs fit in five
lines, the 14 installation fixes in one. The detail goes deliberately; it
stays in the commits. What stays is the distribution list, so a reader can
look for their own, and the figures that bound a fix in three words.
Checked: 17/8/10/2/2 parity in both languages.
Assisted-by: Claude Opus 5
Le tag v1.7.0 existe depuis mars et chaque déclaration disait encore 1.6.0.
« .erplibre-semver-version » est la source que env_var.sh lit dans
ERPLIBRE_VERSION. « pyproject.toml » est un lien vers le fichier de la version
d'Odoo active : les huit portent la version d'ERPLibre, en laisser sept à
1.6.0 ferait dépendre la version déclarée de la bascule d'Odoo. Les étiquettes
d'images docker restent à 1.6.0 : elles nomment des images publiées, empreinte
de compilation comprise, que la construction n'a pas encore produites.
Vérifié : env_var.sh rend 1.7.0, les quatre JSON se relisent, et les tests de
version et de configuration passent.
--- EN ---
Tag v1.7.0 has existed since March and every declaration still said 1.6.0.
`.erplibre-semver-version` is the source env_var.sh reads into
ERPLIBRE_VERSION. `pyproject.toml` is a link to the file of the active Odoo
version: all eight carry the ERPLibre version, and leaving seven at 1.6.0
would make the declared version depend on an Odoo switch. The docker image
tags stay at 1.6.0: they name published images, build hash included, that the
build step has not produced yet. Checked: env_var.sh renders 1.7.0, the four
JSON files reload, and the version and configuration tests pass.
Assisted-by: Claude Opus 5
Le tag v1.7.0 existe depuis le 11 mars 2026 sans section : ses 209 commits
restaient au non-publié, où un lecteur qui compare une version à ses notes ne
trouvait rien. Le tri suit l'ascendance du tag et non la date d'écriture d'une
puce : le changelog AU tag en donne 19, et douze autres, écrites depuis,
décrivaient du travail antérieur — script/qemu, analyse, proxmox, vpn et
long_test n'existaient pas encore. Le non-publié portait deux sections Modifié
et deux Corrigé, fusionnées dans l'ordre canonique ; ses puces passent de 181
à 152 par langue. La liste des dépendances Odoo 18 mêlait 2024, 1.7.0 et
l'après-tag : seul flanker y reste. Vérifié : parité en/fr par section.
--- EN ---
Tag v1.7.0 has existed since 11 March 2026 with no section: its 209 commits
stayed in the unreleased list, where a reader comparing a version to its notes
found nothing. The sort follows ancestry of the tag, not the date an entry was
written: the changelog AT the tag gives 19 of them, and twelve more, written
since, described earlier work — script/qemu, analyse, proxmox, vpn and
long_test did not exist yet. The unreleased list carried two Changed and two
Fixed sections, now merged in canonical order; its entries go from 181 to 152
per language. The Odoo 18 dependency list mixed 2024, 1.7.0 and post-tag work:
only flanker stays there. Checked: en/fr parity per section.
Assisted-by: Claude Opus 5
Le script pose git, et sur Arch « less » n'est ni dans le groupe « base » ni
une dépendance ferme de git : pacman le donne pour OPTIONNEL et ne l'installe
donc jamais. Git appelle pourtant son paginateur par défaut, si bien que log,
diff, show et tag s'arrêtent sur « unable to execute pager 'less' » sans rien
afficher — sur une image cloud comme sur toute installation minimale. Debian
et Ubuntu l'obtiennent par les recommandations de leur paquet git, notion que
pacman n'a pas. Constaté par « pacman -Si base » et « pacman -Sii less » ;
bash -n sur le script, dont le « less » npm reste le préprocesseur CSS.
--- EN ---
The script poses git, and on Arch « less » is neither in the « base » group nor
a firm dependency of git: pacman lists it as OPTIONAL and therefore never
installs it. Git calls its default pager all the same, so log, diff, show and
tag stop on « unable to execute pager 'less' » displaying nothing — on a cloud
image as on any minimal install. Debian and Ubuntu get it through their git
package's recommendations, a notion pacman does not have. Checked with
« pacman -Si base » and « pacman -Sii less »; bash -n on the script, whose npm
« less » stays the CSS preprocessor.
Assisted-by: Claude Opus 5
[IMP] qemu, todo, git : sous-réseau recréable, sudo motivé, lots tenus
12 commits. Une VM prend son adresse dans le /24 de son réseau et en sort par
le .1 porté par le pont : déplacer ce /24 sous une VM allumée, ou abattre le
réseau, lui laisse un bail qui ne mène nulle part et un tap hors du pont. Le
réseau se lit et se recrée dans l'ordre, un préfixe qui recouvre ce que l'hôte
route déjà est refusé, et l'autostart ne s'arme plus après un net-start refusé
— d'où un hôte sans réseau au redémarrage. Le déploiement dit sur quel constat
sudo est requis et pose ce qu'il installe ; au menu, un dépôt fautif n'emporte
plus son lot, une invite se voit avant la réponse, script/ ne masque plus
GitPython. Vérifié : 4639 tests, hors les 9 de qemu_proxmox que « hostname »
manque à l'hôte.
--- EN ---
12 commits. A VM takes its address in its network's /24 and leaves by the .1
carried by the bridge: moving that /24 under a live VM, or tearing the network
down, leaves it a lease leading nowhere and a tap off the bridge. The network
is read and recreated in order, a prefix overlapping what the host already
routes is refused, and autostart is no longer armed after a refused net-start
— hence a host with no network at the next boot. A deployment says on what it
checked sudo is required and poses what it installs; at the menu, a faulty
repository no longer takes its batch down, a prompt is seen before the answer,
script/ no longer hides GitPython. Checked: 4639 tests, bar the 9 of
qemu_proxmox that a missing `hostname` fails on the host.
Assisted-by: Claude Opus 5
Cinq correctifs et une icône de menu passaient d'une branche à la production
sans qu'un lecteur qui décide de mettre à jour puisse le savoir : les cinq
commits QEMU du lot étaient décrits, ceux des outils git et du menu non. Le
non-publié les porte désormais, avec le mode de défaillance retiré et le
chiffre qui le borne — une page HTML de 34 ko avalée par « sh », un lot de
plus de cent dépôts abandonné, 49 tests et une erreur d'import devenus 84.
Les six entrées suivent le même ordre dans les deux langues, la source étant
CHANGELOG.base.md, et make doc_markdown a régénéré la paire.
--- EN ---
Five fixes and one menu icon went from a branch to production with no way for
a reader deciding whether to upgrade to know it: the batch's five QEMU commits
were described, those of the git tools and of the menu were not. The unreleased
section now carries them, with the failure mode removed and the figure that
bounds it — a 34 kB HTML page swallowed by `sh`, a batch of more than a hundred
repositories abandoned, 49 tests and an import error turned into 84. The six
entries follow the same order in both languages, the source being
CHANGELOG.base.md, and make doc_markdown regenerated the pair.
Assisted-by: Claude Opus 5
Une VM prend son adresse dans le /24 de son réseau et en sort par le .1,
porté par le pont : déplacer ce /24 sous une VM allumée lui laisse un bail
qui ne mène nulle part, et abattre le réseau détache son tap, que libvirt
n'y remet pas. network_qemu.py tient les trois gestes dans l'ordre — arrêter
les VM attachées, redéfinir le réseau sur le préfixe voulu, rallumer celles
qu'il a arrêtées, elles seules. Une VM sourde au shutdown annule la
redéfinition plutôt que d'y perdre son pont ; --force-off coupe le courant.
Un préfixe qui recouvre ce que l'hôte route déjà est refusé.
Vérifié : 13 tests neufs, la numérotation du menu, une passe à blanc.
--- EN ---
A VM takes its address in its network's /24 and leaves through the .1,
carried by the bridge: moving that /24 under a live VM leaves it a lease
leading nowhere, and tearing the network down detaches its tap, which
libvirt does not put back. network_qemu.py holds the three steps in order —
shut down the attached VMs, redefine the network on the wanted prefix, start
again the ones it stopped, those only. A VM deaf to the shutdown cancels the
redefinition rather than losing its bridge; --force-off cuts the power.
A prefix overlapping what the host already routes is refused.
Checked: 13 new tests, the menu numbering, one dry run.
Assisted-by: Claude Opus 5
Un réseau libvirt démarré porte et route son /24 sur son pont, et ce pont
comptait dans « ce que l'hôte occupe déjà » : le verdict était donc
« collision » sur toute machine où le réseau tournait, quel que soit son
sous-réseau. Tout déploiement passe par cette vérification, qui abattait
alors le réseau et le déplaçait sur un /24 libre là où rien n'entrait en
conflit — les VM attachées y perdaient passerelle et pont. Le pont du réseau
examiné en est écarté, chaque adresse étant rattachée à son interface ; un
nom de pont illisible n'écarte rien. Le XML de net-define passe par un
fichier temporaire imprévisible, retiré même quand virsh échoue.
Vérifié : 31 tests, dont 10 neufs, que le retrait de l'exclusion casse.
--- EN ---
A started libvirt network carries and routes its /24 on its bridge, and that
bridge counted as « what the host already occupies »: the verdict was
therefore « collision » on every machine where the network ran, whatever
subnet it served. Every deployment goes through that check, which then tore
the network down and moved it onto a free /24 where nothing conflicted — the
attached VMs lost gateway and bridge. The bridge of the network being
examined is now excluded, each address being tied to its own interface; an
unreadable bridge name excludes nothing. The XML for net-define goes through
an unpredictable temporary file, removed even when virsh fails.
Checked: 31 tests, 10 of them new, which removing the exclusion breaks.
Assisted-by: Claude Opus 5
sudo ne dit jamais ce qu'il sert à faire : son invite tombe entre deux lignes
de journal, et l'on tape un mot de passe sans savoir s'il porte sur libvirt,
sur un paquet ou sur un fichier — d'autant qu'appartenir au groupe libvirt a
l'air de suffire. Il ne suffit pas, et libvirt n'y est pour rien : le disque
et le seed s'écrivent dans le pool par défaut, répertoire de root où le
groupe ne donne pas l'écriture. Le motif est constaté, non déduit :
l'écriture s'essaie, une ACL pouvant l'accorder là où le mode semble la
refuser. Dit une fois avant la première commande privilégiée, et en dernière
ligne du récapitulatif. Vérifié : 18 tests, root compris, à qui rien n'est dit.
--- EN ---
sudo never states what it is about to do: its prompt lands between two log
lines, and one types a password without knowing whether it covers libvirt, a
package or a file — the more so as being in the libvirt group looks like it
should be enough. It is not, and libvirt is not the reason: the disk and the
seed are written into the default pool, a root-owned directory where the
group grants no write right. The reason is checked, not deduced: writing is
tried, since an ACL can grant it where the mode seems to refuse it. Said once
before the first privileged command, and last on the review page. Checked: 18
tests, root included, which is told nothing.
Assisted-by: Claude Opus 5
Le réseau « default » de libvirt sert 192.168.122.0/24, et toute VM déployée
par ce dépôt y vit : son pont prendrait la première adresse du /24, celle de
sa passerelle. virsh refuse ce démarrage tant que la route est là ; au
démarrage, libvirtd monte ses réseaux avant le bail DHCP, et plus rien ne la
signale. L'autostart était armé même après un net-start refusé, d'où un hôte
sans réseau au redémarrage suivant. Il ne s'arme plus qu'en l'absence de
collision, le réseau est déplacé par redéfinition — ni pont ni module du
noyau — et un actif en collision est abattu. L'état, cherché en anglais quand
virsh traduit, se lisait toujours éteint : LC_ALL=C. Vérifié sur un hôte en
collision, puis 21 tests.
--- EN ---
libvirt's `default` network serves 192.168.122.0/24, and every VM this
repository deploys lives there: its bridge would take the /24's first
address, which is that machine's gateway. virsh refuses such a start while
the route is there; at boot, libvirtd raises its networks before the DHCP
lease, and nothing signals the collision. Autostart was armed even after a
refused net-start, hence a host with no network at the next boot. It is armed
only where no collision remains, the network is moved by redefinition — no
bridge, no kernel module — and an active collision is torn down. State, read
in English where virsh translates, always read as off: LC_ALL=C. Checked on a
colliding host, then 21 tests.
Assisted-by: Claude Opus 5
L'option des outils d'assistance posait trois installateurs amont, puis
laissait tout à retaper : hook global de rtk, zdiff3, hooks git du dépôt,
commandes Claude, activation du venv. Elle les pose, en deux temps parce que
hooks et gabarits VIVENT dans le dépôt ; le complément suit le clone, rend
toujours 0 — un confort ne fait pas échouer une VM — et sans clone la moitié
manquante est nommée. core.editor n'est posé qu'à défaut, l'hôte transmettant
déjà le sien. L'aide « ? » et F1 dit ce que chaque option installe, là où un
libellé de case porte trois des huit poses. Vérifié : 51 tests, les deux
écrans montés sans terminal, « bash -n » sur les fragments distants.
--- EN ---
The AI tools box posed three upstream installers, then left every setting to
retype: rtk's global hook, zdiff3, the checkout's git hooks, the Claude
commands, activating the venv. It poses them, in two phases because hooks and
templates LIVE in the checkout; the complement follows the clone, always
returns 0 — a comfort must not fail a VM — and with no clone the missing half
is named. core.editor is posed only where there is none, the host already
transmitting its own. The `?` and F1 help says what each option installs,
where a checkbox label carries three of this one's eight poses. Checked: 51
tests, both screens mounted headless, `bash -n` on the remote fragments.
Assisted-by: Claude Opus 5
Le menu RTK est le seul dont les entrées n'affichaient rien avant leur
libellé : six lignes que seul leur numéro distinguait. Les six glyphes sont
pris parmi ceux que le fichier emploie déjà plutôt que choisis pour eux-mêmes
— un caractère récent s'affiche en tofu sur un terminal dont la police ne le
connaît pas. L'icône va dans la chaîne traduite, comme partout ailleurs dans
le menu, donc les deux langues la portent.
Vérifié : rendu en français et en anglais ; chacune des six clés ne sert
qu'ici, aucun autre menu n'est touché.
--- EN ---
The RTK menu is the only one whose entries showed nothing before their label:
six lines told apart by their number alone. The six glyphs are taken from
those the file already uses rather than picked for themselves — a recent
character renders as tofu on a terminal whose font does not know it. The icon
goes into the translated string, as everywhere else in the menu, so both
languages carry it.
Checked: rendering in French and English; each of the six keys is used here
only, so no other menu is affected.
Assisted-by: Claude Opus 5
L'URL amont de starship pointait sur un chemin qui n'existe pas : le serveur
rend 404 avec une page HTML de 34 ko, que « curl -sS » écrit tout de même sur
sa sortie en rendant 0. Cette page arrivait donc sur l'entrée de « sh », qui
s'arrêtait sur « Syntax error » à sa deuxième ligne — un diagnostic qui ne dit
ni l'URL fautive ni que rien n'a été posé. « -f » fait taire curl et rendre 22
sur toute réponse d'erreur ; les quatre autres installateurs amont du fichier
l'utilisaient déjà.
Vérifié : le « --help » de l'installateur est atteint, sans rien installer.
--- EN ---
The upstream starship URL pointed at a path that does not exist: the server
answers 404 with a 34 kB HTML page, which `curl -sS` writes to its output
anyway while exiting 0. That page reached the input of `sh`, which stopped on
`Syntax error` at its second line — a diagnosis naming neither the wrong URL
nor the fact that nothing was installed. `-f` makes curl write nothing and
return 22 on any error response; the four other upstream installers in the
file already used it.
Checked: the installer's `--help` is reached, with nothing installed.
Assisted-by: Claude Opus 5
« readline » ne rend la main qu'au saut de ligne : une invite qui n'en
porte pas restait retenue jusqu'à la ligne suivante, écrite après la
réponse. Toute question « [o/N] » d'une commande du menu se voyait donc
après coup, et l'on y répondait à l'aveugle. La lecture se fait par blocs,
le reliquat part à l'écran aussitôt et stdout est vidé ; un décodeur
incrémental protège les accents coupés entre deux lectures.
Vérifié : invite visible avant la frappe, sans double affichage ; 13 cas de
non-régression ; 4546 tests, seuls les 9 échecs préexistants de qemu_proxmox.
--- EN ---
`readline` only returns at a newline: a prompt carrying none stayed held
back until the next line, written after the answer. Every "[o/N]" question
asked by a menu command was therefore seen after the fact, and answered
blind. Reading now happens in chunks, the trailing fragment reaches the
screen at once and stdout is flushed; an incremental decoder protects
accented characters split across two reads.
Checked: prompt visible before typing, with no double display; 13 regression
cases; 4546 tests, only the 9 pre-existing qemu_proxmox failures.
Assisted-by: Claude Opus 5
Un répertoire vidé à la main passe `os.path.isdir` puis fait lever
l'ouverture du dépôt, ce qui emportait tout le reste du lot. Ces états —
clone interrompu, `.git` effacé — sont courants sur un checkout de
développement, et sans rapport avec les dépôts qui attendent leur remote.
Les écarts sont rendus plutôt qu'affichés au fil de l'eau : noyés dans la
trace d'un lot de plus de cent dépôts, ils ne se voient plus. La sortie
reste nulle, comme déjà pour un répertoire absent.
Vérifié dans des dépôts jetables ; 6 tests neufs, dont 2 échouent si le
garde-fou est retiré.
--- EN ---
A directory emptied by hand passes `os.path.isdir` then makes opening the
repository raise, which took down the whole rest of the batch. Such states —
an interrupted clone, a deleted `.git` — are common on a development
checkout, and unrelated to the repositories awaiting their remote.
Deviations are returned rather than printed as they happen: drowned in the
trace of a batch of over a hundred repositories, they can no longer be seen.
The exit code stays zero, as it already was for a missing directory.
Checked in throwaway repositories; 6 new tests, 2 of which fail if the guard
is removed.
Assisted-by: Claude Opus 5
Le répertoire ajouté est `script/`, qui porte un `git/` : en tête de
`sys.path`, il fait résoudre `import git` vers ce paquet plutôt que vers
GitPython, pour tout module importé ENSUITE dans le même processus — une
bibliothèque tierce disparaît parce qu'une des nôtres porte le même nom.
En queue, `lib_identifiant` se trouve toujours et les paquets installés
gardent la priorité ; la racine du dépôt suit la même règle, elle porte un
`test/` homonyme d'un paquet standard.
Mesuré : `unittest discover -p 'test_git*.py'` passe de 49 tests et une
erreur d'import à 84 verts ; le hook commit-msg reste vérifié.
--- EN ---
The directory being added is `script/`, which holds a `git/`: at the head of
`sys.path` it makes `import git` resolve to that package rather than to
GitPython, for every module imported AFTERWARDS in the same process — a
third-party library vanishes because one of ours bears the same name.
At the tail, `lib_identifiant` is still found and installed packages keep
their precedence; the repository root follows the same rule, it holds a
`test/` sharing its name with a standard library package.
Measured: `unittest discover -p 'test_git*.py'` goes from 49 tests and one
import error to 84 green; the commit-msg hook stays verified.
Assisted-by: Claude Opus 5
Le traitement de `add_root` est en FIN de fonction, et deux retours
anticipés lui sautaient par-dessus : sans manifeste, la liste revenait vide
alors que la racine était demandée. Le script qui réécrit les remotes ne
trouvait donc rien à faire sur un checkout sans `.repo`, et l'annonçait
comme un succès.
L'ajout de la racine et le tri passent par un point de sortie unique, ce
qui supprime la copie qui gardait le défaut dans une variante sur deux. Une
origine absente vaut l'URL par défaut plutôt qu'une exception.
Vérifié dans un dépôt jetable, dans les deux sens et sans origine ; 4 tests
neufs, qui échouent si le retour anticipé revient.
--- EN ---
The `add_root` handling sits at the END of the function, and two early
returns jumped over it: with no manifest, the list came back empty although
the root had been asked for. The script that rewrites the remotes therefore
found nothing to do on a checkout without `.repo`, and reported it as a
success.
Adding the root and sorting now go through a single exit point, which drops
the copy that kept the fault in one variant out of two. A missing origin
falls back to the default URL rather than raising.
Checked in a throwaway repository, both ways and with no origin; 4 new
tests, which fail if the early return comes back.
Assisted-by: Claude Opus 5
[ADD] vpn : cinq tunnels au menu, secrets en coffre, diagnostic étagé
7 commits. Rien ne permettait de monter un tunnel VPN, ni de dire pourquoi il
refuse de monter. Cinq technologies libres arrivent au menu ; le profil,
lisible et partageable, est séparé des secrets, qui vivent dans un coffre
KeePassXC et ne touchent jamais un disque persistant. Le diagnostic part du
noyau et remonte, pour que la première ligne fausse soit la cause et non une
conséquence, et propose le remède connu sans l'appliquer seul. Demander tout
le trafic par le tunnel ne coupe plus la session SSH qui en donne l'ordre, et
le coffre s'ouvre sur une machine sans tkinter, donc sur tout serveur.
Vérifié : 175 tests VPN et 8 sur le coffre ; le moteur, sorti seul dans un
worktree, y passe ses 144 tests sans le menu.
--- EN ---
7 commits. Nothing could raise a VPN tunnel, nor say why one refuses to come
up. Five free technologies arrive at the menu; the profile, readable and
shareable, is kept apart from the secrets, which live in a KeePassXC vault
and never touch a persistent disk. Diagnosis starts at the kernel and climbs,
so the first false line is the cause and not a consequence, and offers the
known remedy without applying it alone. Asking for all traffic through the
tunnel no longer cuts the SSH session giving the order, and the vault opens
on a machine without tkinter, which is every server.
Checked: 175 VPN tests and 8 on the vault; the engine, checked out alone in a
worktree, passes its 144 tests there without the menu.
Assisted-by: Claude Opus 5
La branche part de master : elle livre l'outil entier, pas des retouches.
Deux puces sous Ajouté — l'outil et son diagnostic étagé — et une sous
Corrigé pour le coffre KeePassXC, qui ne doit rien au VPN et servait déjà
ailleurs.
Ce qu'une branche corrige de son propre travail n'y figure pas : le lanceur
de tests et ses huit fichiers muets sont revenus à l'état de master, et une
puce les annonçant décrirait un aller-retour invisible du dehors.
--- EN ---
The branch forks from master: it delivers the whole tool, not touch-ups. Two
bullets under Added — the tool and its staged diagnosis — and one under Fixed
for the KeePassXC vault, which owes nothing to the VPN and already served
elsewhere.
What a branch fixes in its own work is absent: the test launcher and its
eight silent files are back to master's state, and a bullet announcing them
would describe a round trip invisible from outside.
Assisted-by: Claude Opus 5
`vpn.py` savait tout faire en ligne de commande, mais il fallait écrire le
profil JSON à la main et déposer les secrets dans KeePassXC soi-même. Le menu
pose les questions que le pilote choisi déclare, et lui seul : ajouter une
technologie n'ajoute pas une ligne ici.
Le coffre est manipulé EN PROCESSUS — le mot de passe maître est déjà en
mémoire, le redemander à un sous-processus serait une saisie de plus à chaque
geste. Montage, démontage et diagnostic passent au contraire par `vpn.py` en
sous-processus : ils durent, ils parlent, et la sortie en direct est ce qui
rend une montée de tunnel suivable.
Vérifié : 37 tests sur le menu, aucune saisie réelle.
--- EN ---
`vpn.py` could already do everything from the command line, but the JSON
profile had to be written by hand and the secrets filed into KeePassXC by
hand. The menu asks the questions the chosen driver declares, and only those:
adding a technology adds no line here.
The vault is handled IN PROCESS — the master password is already in memory,
and asking a subprocess for it again would be one more entry at every step.
Raising, tearing down and diagnosing go through `vpn.py` as a subprocess
instead: they last, they talk, and live output is what makes a tunnel coming
up followable.
Checked: 37 tests on the menu, no real input.
Assisted-by: Claude Opus 5
Le dépôt n'avait aucun moyen de monter un tunnel VPN ni de dire pourquoi il
refuse de monter. Cinq technologies libres, un pilote chacune, derrière un
`vpn.py` qui monte, démonte et diagnostique.
Ce qui n'est pas secret — hôte, utilisateur, routes, MTU — vit dans une
configuration JSON lisible ; clés pré-partagées et mots de passe vivent dans
un coffre KeePassXC. Un profil se montre et se partage sans donner de quoi
monter le tunnel. Les secrets s'écrivent en tmpfs sous 0700, jamais sur un
disque persistant. Le diagnostic part du noyau et remonte, pour que la
première ligne fausse soit la cause et non une conséquence.
Vérifié : 138 tests, dont le rendu de chaque fichier généré.
--- EN ---
The repository had no way to raise a VPN tunnel, nor to say why one refuses
to come up. Five free technologies, one driver each, behind a `vpn.py` that
raises, tears down and diagnoses.
What is not secret — host, user, routes, MTU — lives in readable JSON
configuration; pre-shared keys and passwords live in a KeePassXC vault. A
profile can be shown and shared without handing over the means to raise the
tunnel. Secrets are written to tmpfs at 0700, never to a persistent disk.
Diagnosis starts at the kernel and climbs, so the first false line is the
cause and not a consequence.
Checked: 138 tests, including the rendering of every generated file.
Assisted-by: Claude Opus 5
Trois fichiers de la suite n'étaient pas au format du dépôt : imports non
triés, expressions coupées là où la ligne tient. `make format` les rattrape.
Aucun test n'est ajouté, retiré ni modifié dans ce qu'il vérifie.
--- EN ---
Three files of the suite were not in the repository's format: unsorted
imports, expressions broken where the line fits. `make format` catches them
up. No test is added, removed, or changed in what it checks.
Assisted-by: Claude Opus 5
Le lanceur prend TOUT `test/test_*.py` par glob, et l'en-tête disait
pourquoi : une liste de préfixes oublie ce qu'on ajoute. Il ne disait pas où
mettre ce qui doit rester dehors, si bien qu'une famille de tests nouvelle
semblait avoir quelque chose à déclarer ici.
La frontière est un RÉPERTOIRE : ce qui ne doit pas être lancé vit ailleurs
que dans `test/`. Rien à déclarer, donc rien à oublier de déclarer.
--- EN ---
The launcher takes ALL of `test/test_*.py` by glob, and the header said why:
a list of prefixes forgets whatever gets added. It did not say where to put
what must stay out, so a new family of tests looked as though it had
something to declare here.
The boundary is a DIRECTORY: what must not run lives somewhere other than
`test/`. Nothing to declare, hence nothing to forget to declare.
Assisted-by: Claude Opus 5
L'invite de `getpass` part vers le terminal, la ligne qui nomme le coffre
vers la sortie standard — un TUBE dès qu'un menu nous lance. Sans vidage, les
deux ressortaient dans le désordre : « Mot de passe du coffre : Coffre
KeePass : <chemin> », la question avant ce dont elle parle.
Le bouchon de `print` des tests accepte désormais la signature complète de
`print` : sans `**k`, ajouter un `flush` au code testé faisait échouer six
tests sur une différence étrangère à ce qu'ils vérifient.
--- EN ---
The `getpass` prompt goes to the terminal, the line naming the vault to
standard output — a PIPE as soon as a menu launches us. Without a flush the
two came out in the wrong order: "Vault password: KeePass vault: <path>", the
question before what it is about.
The tests' `print` stub now accepts the full signature of `print`: without
`**k`, adding a `flush` to the code under test failed six tests over a
difference foreign to what they check.
Assisted-by: Claude Opus 5
Sur une machine sans tkinter — tout serveur — `get_kdbx()` rendait None en
journalisant « pykeepass is not installed », alors que pykeepass était là.
Les deux imports partageaient un seul `try` : l'absence de tkinter mettait
aussi `PyKeePass` à None, et le coffre restait inouvrable même avec chemin et
mot de passe configurés.
tkinter ne sert qu'au sélecteur de fichier, quand aucun chemin n'est
configuré ; deux blocs séparés le rendent à ce seul rôle.
--- EN ---
On a machine without tkinter — every server — `get_kdbx()` returned None
while logging "pykeepass is not installed", though pykeepass was present.
Both imports shared one `try`: a missing tkinter set `PyKeePass` to None as
well, and the vault stayed unopenable even with path and password configured.
tkinter serves only the file picker, when no path is configured; two separate
blocks give it back that single role.
Assisted-by: Claude Opus 5
[ADD] qemu et todo : 3D, diagnostic, récupération, outils installés
42 commits. La 3D des VM QEMU devient utilisable de bout en bout : quatre
pannes la rendaient inopérante en silence, dont un attribut de libvirt
12.5.0 qui l'emporte sur « accel3d » et un groupe manquant dans l'invité
qui renvoyait toute application GL au rendu logiciel. Un diagnostic en
lecture seule, écrit dans un fichier à transmettre, dit ce que l'hôte
sait faire ET ce que chaque VM recevra. Viennent avec : récupération de
fichiers dans un disque mort, assistants posés dans l'invité, menu qui
installe, libvirt par le groupe et non par sudo. 1 202 tests lancés.
--- EN ---
42 commits. 3D on QEMU VMs becomes usable end to end: four faults left it
silently inert, among them an attribute from libvirt 12.5.0 that outranks
« accel3d » and a group missing in the guest that sent every GL
application back to software rendering. A read-only diagnostic, written
to one file to hand over, now says what the host can do AND what each VM
will get. Along with it: file recovery from a dead disk, assistants
installed in the guest, a menu that installs, and libvirt reached through
the group rather than sudo. 1,202 tests run.
Assisted-by: Claude Opus 5
Le menu qui déploie les commandes d'assistant était le dernier resté nu,
et cinq lignes qui ouvrent toutes sur le même mot se lisent une par une.
Chaque signe dit ce que la commande fait — message, fusion, plan, code,
inventaire — plutôt que de répéter qu'il s'agit d'une commande.
Les cinq emoji rendent sur deux colonnes, d'où l'espace unique qui les
sépare du libellé. Aucun ne servait ailleurs : un même signe pour deux
concepts distincts se lit comme un lien qui n'existe pas.
--- EN ---
The menu deploying assistant commands was the last one left bare, and
five lines all opening on the same word are read one by one. Each sign
says what the command does — message, merge, plan, code, inventory —
instead of repeating that it is a command.
The five emoji render two columns wide, hence the single space before
the label. None was in use elsewhere: one sign for two distinct concepts
reads as a link that does not exist.
Assisted-by: Claude Opus 5
Une case de plus au catalogue des outils, donc une case dans les deux
écrans sans y toucher. Cochée, elle découvre le choix de l'agent — Claude
Code ou opencode — et l'identité git, pré-remplie avec celle de l'hôte :
c'est ce que la VM reçoit déjà, et un champ vide la ferait croire absente.
Ce qui est saisi prime, champ par champ.
Phase « before », où chaque outil se garde lui-même. Chaque pose est aussi
privée d'entrée standard et bornée dans le temps : « || true » couvre
l'échec, pas l'ATTENTE, et un installateur amont qui pose une question
resterait pendu sur un SSH sans terminal — d'où « -y » pour starship.
--- EN ---
One more entry in the tool catalogue, hence one more box on both screens
for free. Ticked, it reveals the agent choice — Claude Code or opencode —
and the git identity, prefilled from the host: that is what the VM
already gets, and an empty field would suggest none. What is typed wins,
field by field.
Phase « before », where each tool guards itself. Every install is also
denied stdin and time-bounded: « || true » covers failure, not WAITING,
and an upstream installer asking a question would hang on a terminal-less
SSH — hence « -y » for starship.
Assisted-by: Claude Opus 5
Les mêmes outils se posent à DEUX endroits : sur l'hôte par le menu Shell,
et bientôt dans une VM par le déploiement QEMU. Une URL amont recopiée
dérive dès que l'une des deux copies change, et c'est la seconde qu'on
oublie — celle qui n'a pas de menu pour la montrer.
Les noms de classe restent : ils sont l'interface, et les tests les
interrogent. Aucun comportement ne change.
--- EN ---
The same tools are installed in TWO places: on the host from the Shell
menu, and soon inside a VM from the QEMU deployment. A copied upstream
URL drifts as soon as one of the two copies changes, and the forgotten
one is the second — the one with no menu to show it.
The class names stay: they are the interface, and the tests read them.
No behaviour changes.
Assisted-by: Claude Opus 5
Le garde des menus refusait le menu QEMU : deux entrées y étaient arrivées
sans être déclarées dans sa table, donc sans que personne dise où elles
mènent. C'est la panne qu'il existe pour signaler, et elle traînait rouge.
Le garde de la suite refusait test_qemu_start_egl : quatre classes s'y
étaient empilées APRÈS « unittest.main() ». Elles tournaient — unittest
collecte à l'import — mais le fichier n'était plus lançable seul, ce que
le garde vérifie précisément.
--- EN ---
The menu guard rejected the QEMU menu: two entries had landed there
undeclared in its table, so with nobody saying where they lead. That is
the very failure it exists to report, and it sat red.
The suite guard rejected test_qemu_start_egl: four classes had piled up
AFTER « unittest.main() ». They ran — unittest collects at import — but
the file was no longer runnable on its own, which is exactly what the
guard checks.
Assisted-by: Claude Opus 5
Le matériel virtuel accéléré ne suffisait pas. Dans l'invité, le nœud de
rendu appartient à « root:render » en 0660 et le compte créé n'y était
pas : toute application GL retombait sur le rendu logiciel alors que la
négociation VIRGL avait réussi, et rien ne le signalait. En session
graphique locale, logind pose une ACL pour l'utilisateur du siège ; en
SSH ou en tty, le cas d'une VM de ce parc, personne ne la pose.
Les groupes sont DÉCLARÉS avant d'être utilisés : « useradd -G » échoue
sur un nom inconnu, et cloud-init ne crée alors pas le compte du tout —
la VM démarre inaccessible. « render » manque des images anciennes. Même
parité côté preseed, par « groupadd -f ». « --gpu off » n'ajoute rien.
--- EN ---
Accelerated virtual hardware was not enough. In the guest the render
node is « root:render » at 0660 and the created account was not in it:
every GL application fell back to software rendering although VIRGL
negotiation had succeeded, with nothing to say so. On a local graphical
session logind sets an ACL for the seat's user; over SSH or on a tty,
which is what these VMs get, nobody sets one.
Groups are DECLARED before use: « useradd -G » fails on an unknown name
and cloud-init then creates no account at all — the VM boots
unreachable. « render » is missing from older images. The preseed keeps
parity via « groupadd -f ». « --gpu off » adds nothing.
Assisted-by: Claude Opus 5
Le rapport disait ce que l'HÔTE sait faire, jamais ce que chaque VM
recevra au prochain démarrage. Trois valeurs y répondent ensemble et
aucune seule : le type de vidéo, « accel3d », et le device figé par
libvirt, qui l'emporte sur les deux autres. La section les lit dans la
définition persistante et écrit la commande qui défige, sans la lancer.
Les sections Python du rapport sont désormais isolées. Le fichier
s'écrit d'un bloc à la fin : une section qui lève emportait tout ce qui
avait été relevé avant elle, laissant sans rapport au moment d'en avoir
besoin. Le double de test rendait un objet sans « returncode », ce qui
masquait le défaut.
--- EN ---
The report said what the HOST can do, never what each VM will get on its
next boot. Three values answer that together and none alone: video type,
« accel3d », and the device libvirt pinned, which outranks both. The
section reads them from the persistent definition and writes out the
unpinning command without running it.
Python sections of the report are now isolated. The file is written in
one block at the end: a section that raised took down everything
gathered before it, leaving no report exactly when one is needed. The
test double returned an object with no « returncode », hiding the fault.
Assisted-by: Claude Opus 5
Depuis libvirt 12.5.0, le <model> vidéo porte un attribut « device » qui
grave le device QEMU retenu, pour tenir l'ABI de l'invité stable d'un
démarrage à l'autre. Il l'emporte sur « accel3d ». Une VM démarrée une
première fois sans 3D — module GL absent, ou option non cochée — garde
donc le device sans GL, et l'activer ensuite n'écrit qu'une intention :
QEMU reçoit toujours « virtio-vga » nu.
L'état lisait « accel3d » sans lire cet attribut, si bien que le résumé
annonçait « 3D » sur une VM qui tourne sans. Il porte désormais le device
figé quand celui-ci contredit la demande.
--- EN ---
Since libvirt 12.5.0 the video <model> carries a « device » attribute
recording the chosen QEMU device, to keep the guest ABI stable across
restarts. It outranks « accel3d ». A VM first started without 3D — GL
module absent, or the box unticked — therefore keeps the non-GL device,
and enabling it afterwards writes an intent only: QEMU still gets plain
« virtio-vga ».
State read « accel3d » without that attribute, so the summary announced
« 3D » on a VM running without it. It now names the pinned device
whenever it contradicts the request.
Assisted-by: Claude Opus 5
Les deux devices accélérés sont des modules séparés, empaquetés à part
sur les distributions qui découpent QEMU. Le relevé ne cherchait que
« virtio-gpu-gl » ; c'est « virtio-vga-gl » que libvirt exige pour un
écran principal compatible VGA, soit le cas d'une VM graphique. Le
rapport ressortait donc tout en vert à côté de la pièce absente.
Sans ce module, QEMU n'annonce pas le device, libvirt le remplace en
silence par « virtio-vga » nu et la VM démarre sans 3D — l'egl-headless
demandé restant en place, rien dans la définition ne trahit le repli.
--- EN ---
The two accelerated devices are separate modules, packaged apart on
distributions that split QEMU. The survey looked only for
« virtio-gpu-gl »; libvirt needs « virtio-vga-gl » for a VGA-compatible
primary display, which is what a graphical VM gets. The report therefore
came back all green next to the missing piece.
Without that module QEMU does not advertise the device, libvirt quietly
falls back to plain « virtio-vga » and the VM boots with no 3D — the
requested egl-headless still in place, nothing in the definition telling.
Assisted-by: Claude Opus 5
Le relevé disait ce que la définition DEMANDE, jamais ce que la VM a
REÇU ; libvirt peut retirer l'accélération entre les deux sans le
signaler. Or « egl-headless » paraît sur la ligne de commande que la 3D
soit active ou non : le seul témoin est le suffixe « -gl » du device.
Chercher « virgl » n'aide pas — cette forme ne s'écrit plus sur les QEMU
récents, et son absence sur une VM accélérée fait conclure à un réglage
manquant qui n'existe pas.
La sonde lit /proc/<pid>/cmdline, sans privilège, et trie sur argv[0] :
sur la ligne entière elle se compterait elle-même.
--- EN ---
The report told what the definition ASKS for, never what the VM GOT;
libvirt can drop acceleration in between without saying so. And
« egl-headless » shows on the command line whether 3D is live or not:
the only witness is the device's « -gl » suffix. Grepping for « virgl »
does not help — that spelling is gone from recent QEMU, and its absence
on an accelerated VM suggests a missing setting that does not exist.
The probe reads /proc/<pid>/cmdline, unprivileged, and sorts on argv[0]:
on the whole line it would count itself.
Assisted-by: Claude Opus 5
Le menu Git avait posé la convention ; dix autres restaient nus, et une
liste sans icône se lit ligne à ligne. L'espacement suit la largeur
RENDUE, lue dans Unicode et non devinée : deux espaces derrière un emoji
d'une colonne, une derrière un large — d'où le changement de signe de la
Configuration, dont le sien décalait le menu principal. Un même concept
garde son signe d'un menu à l'autre. « Quitter » garde sa traduction nue,
sa clé servant onze fois en raccourci de pied de page : son icône se pose
sur la ligne du menu.
Vérifié : menus rendus dans les deux langues, aucune clé incomplète,
aucune icône divergente entre les langues.
--- EN ---
The Git menu had set the convention; ten others stayed bare, and a list
without icons is read line by line. Spacing follows the RENDERED width,
read from Unicode rather than guessed: two spaces after a one-column
emoji, one after a wide one — hence the new sign for Configuration, whose
own offset the main menu. One concept keeps its sign from menu to menu.
« Quit » keeps its bare translation, its key serving eleven times as a
footer shortcut: its icon sits on the menu's own line.
Checked: menus rendered in both languages, no incomplete key, no icon
diverging between languages.
Assisted-by: Claude Opus 5
Un problème de VM se résout souvent par quelqu'un qui n'a pas accès à la
machine : vingt et une sondes en lecture écrivent un relevé unique —
hôte, hyperviseur, GPU, outils, stockage — chacune bornée dans le temps,
une commande qui pend ne devant pas retenir le rapport. Sur le pilote
NVIDIA propriétaire, trois conditions vivent hors des briques Mesa et
QEMU, dont la liste de périphériques où libvirt n'ajoute jamais les nœuds
de la carte : le relevé les nomme et propose la commande qui installe ce
qui lui manque, affichée avant la question. Gérer se scinde en trois.
--- EN ---
A VM problem is often solved by someone with no access to the machine:
twenty-one read-only probes write one report — host, hypervisor, GPU,
tools, storage — each time-bounded, since a command that hangs must not
hold the report. On the proprietary NVIDIA driver three conditions live
outside the Mesa and QEMU pieces, among them the device list where
libvirt never adds the card's own nodes: the report names them and offers
the command installing what it lacks, shown before the question is put.
The Manage menu splits in three.
Assisted-by: Claude Opus 5
Le nœud de rendu peut exister sans qu'EGL y démarre : QEMU refuse alors
le domaine, et la 3D écrite dans la définition rend la VM inutilisable
jusqu'à ce que quelqu'un défasse le réglage. La création avait déjà son
repli, le réglage d'une VM existante n'en avait pas. Un relevé accompagne
le refus, car deux briques distinctes entrent en jeu : egl-headless ouvre
le nœud par GBM — c'est Mesa qui répond — et virglrenderer ne sert
qu'ensuite, donc l'installer ne répare pas un EGL qui refuse.
Vérifié : 11 tests, rougis par trois mutations — rattraper n'importe quel
échec, ne pas redémarrer après le retrait, éteindre l'autostart au passage.
--- EN ---
The render node can exist without EGL starting on it: QEMU then refuses
the domain, and the 3D written into the definition leaves the VM unusable
until someone undoes the setting. Creation already had its fallback,
adjusting an existing VM had none. A report comes with the refusal, since
two distinct bricks are involved: egl-headless opens the node through GBM
— Mesa answers — and virglrenderer only serves afterwards, so installing
it repairs no EGL that refuses.
Checked: 11 tests, turned red by three mutations — catching any failure,
not restarting after removal, switching autostart off along the way.
Assisted-by: Claude Opus 5
Le module importe la CLASSE datetime, pas le module : « datetime.datetime »
n'existe donc pas, et l'écran des statistiques sortait sur une
AttributeError qui emportait TODO entier. La garde couvre aussi
TypeError : un horodatage absent vaut None dans un résumé sans aucune
installation, et une statistique ne doit pas décider de la survie du menu.
Vérifié : un horodatage valide rend sa date, None et une valeur hors
bornes rendent « ? » sans lever.
--- EN ---
The module imports the datetime CLASS, not the module: « datetime.datetime »
therefore does not exist, and the statistics screen exited on an
AttributeError that took the whole of TODO with it. The guard also covers
TypeError: an absent timestamp is None in a summary with no install at
all, and a statistic must not decide whether the menu survives.
Checked: a valid timestamp renders its date, None and an out-of-range
value render « ? » without raising.
Assisted-by: Claude Opus 5
Le « bin » du venv est en tête du PATH de chaque commande lancée par le
menu, et il contient un python3. Un outil système écrit en Python et
amorcé par « env python3 » s'y amorce donc, dans un interpréteur où les
modules de la distribution n'existent pas : l'import échoue sur un module
que la machine possède pourtant. Sous sudo le piège était invisible, sudo
réinitialisant le PATH ; le retirer là où il ne servait plus l'a mis au
jour.
Vérifié : 6 tests, rougis par trois mutations. La ligne d'amorçage des
outils visés n'a pas été inspectée : le mécanisme est démontré, pas qu'il
soit la cause sur un hôte donné.
--- EN ---
The venv's « bin » leads the PATH of every command the menu launches, and
it holds a python3. A system tool written in Python and started through
« env python3 » therefore boots on that interpreter, where the
distribution's modules do not exist: the import fails on a module the
machine does have. Under sudo the trap was invisible, sudo resetting the
PATH; removing it where it was no longer needed brought it out.
Checked: 6 tests, turned red by three mutations. The shebang of the tools
concerned was not inspected: the mechanism is demonstrated, not that it
is the cause on any given host.
Assisted-by: Claude Opus 5
Une VM qui ne démarre plus garde ses fichiers : libguestfs monte son
qcow2 sans elle. Toute commande porte « --ro », et c'est ce qui change la
manœuvre : ouvrir en écriture le disque d'une machine allumée corrompt
son système de fichiers, la lire ne risque rien. Un arrêt reste proposé
et non imposé — une lecture vivante voit un état peut-être incohérent,
un fichier à moitié écrit, un journal non rejoué. Le nom du paquet suit
la distribution, celui de Debian n'existant nulle part ailleurs.
Vérifié : 16 tests, rougis par quatre mutations — perdre le « --ro »,
donner le nom Debian partout, dupliquer un numéro, retirer l'entrée.
--- EN ---
A VM that no longer boots still holds its files: libguestfs mounts its
qcow2 without it. Every command carries « --ro », and that is what
changes the operation: opening a running machine's disk for writing
corrupts its filesystem, reading it risks nothing. A shutdown stays
offered, not imposed — a live read sees a possibly torn state, a
half-written file, an unreplayed journal. The package name follows the
distribution, Debian's existing nowhere else.
Checked: 16 tests, turned red by four mutations — losing « --ro », using
Debian's name everywhere, duplicating a number, dropping the entry.
Assisted-by: Claude Opus 5
La section du menu des plugins prenait « Install » pour clé, déjà portée
par l'entrée « 📦 Installation » du menu principal. Dans un littéral de
dict Python la dernière définition gagne, sans erreur ni avertissement :
le menu principal affichait donc « Installer ». La clé de la section est
renommée, la première étant en place depuis longtemps.
Vérifié : le menu principal retrouve « 📦 Installation », et un balayage
des clés ne laisse que trois doublons, tous à valeurs identiques donc
sans effet.
--- EN ---
The plugin menu's section used « Install » as its key, already held by
the main menu's « 📦 Installation » entry. In a Python dict literal the
last definition wins, with no error and no warning: the main menu
therefore showed « Installer ». The section's key is renamed, the first
one having been there far longer.
Checked: the main menu gets « 📦 Installation » back, and a sweep of the
keys leaves only three duplicates, all with identical values and so
without effect.
Assisted-by: Claude Opus 5
Sans « --connect », un virsh non root vise qemu:///session : un
hyperviseur SÉPARÉ, où aucune VM du système n'existe. « list --all » y
rend une liste vide, sans erreur ni avertissement. L'URI par défaut de
root masquait l'omission tant que les commandes passaient par sudo ;
appartenir au groupe libvirt donne le droit d'atteindre qemu:///system
mais ne change pas l'URI. Les 40 appels locaux passent donc par un
constructeur unique — dont 19 en liste d'arguments, qui gardaient encore
sudo en dur.
Vérifié : une garde balaie les deux fichiers et échoue si un virsh est
écrit sans URI ; la réintroduire fait rougir.
--- EN ---
Without « --connect », a non-root virsh targets qemu:///session: a
SEPARATE hypervisor, where none of the system's VMs exist. « list --all »
returns an empty list there, with no error and no warning. Root's default
URI masked the omission as long as commands went through sudo; libvirt
group membership grants the right to reach qemu:///system but does not
change the URI. All 40 local calls therefore go through one builder —
19 of them argument lists that still hardcoded sudo.
Checked: a guard sweeps both files and fails if a virsh is written
without the URI; putting one back turns it red.
Assisted-by: Claude Opus 5
Une VM sans console peut vouloir un virtio-gpu accéléré — rendu hors
écran, ou émulateur qui tourne dedans — et « auto » ne l'accorde jamais :
il s'abstient sans écran, pour ne pas poser un périphérique vidéo que
personne n'a demandé. La case envoie donc « --gpu on », qui l'accorde
désormais. « --graphics none » est alors écarté : il dit « aucun
affichage », et egl-headless EST un affichage. Le repli le rend quand la
3D tombe, sinon la VM repartirait sur le défaut de virt-install.
Vérifié : 8 tests neufs et 2 sur le repli, rougis par trois mutations.
Le rendu de la case dans le terminal plein écran n'est pas testé.
--- EN ---
A VM without a console may want an accelerated virtio-gpu — offscreen
rendering, or an emulator running inside — and « auto » never grants it:
it abstains without a screen, so as not to add a video device nobody
asked for. The box therefore sends « --gpu on », which now grants it.
« --graphics none » is then dropped: it means « no display », and
egl-headless IS a display. The fallback gives it back when 3D fails,
otherwise the VM would restart on virt-install's default.
Checked: 8 new tests and 2 on the fallback, turned red by three
mutations. The box's rendering in the full-screen terminal is not tested.
Assisted-by: Claude Opus 5
Une création interrompue laisse son qcow2 sans VM définie, et deploy_qemu
refuse ensuite d'écraser : la création échoue APRÈS avoir fait attendre.
Le disque est donc proposé à l'effacement, taille et chemin affichés.
Proposé et non effacé d'office : le même nom peut désigner le disque
d'une VM retirée à la main, dont on voulait garder les données. Un refus
ne laisse pas filer vers l'échec, il redemande. La proposition vient
après la fermeture du formulaire plein écran, parce qu'effacer là demande
root et qu'une invite de mot de passe n'y a nulle part où s'afficher.
Vérifié : 7 tests, rougis par deux mutations — ne pas redemander après un
refus, et sauter la proposition sur le chemin plein écran.
--- EN ---
An interrupted creation leaves its qcow2 with no defined VM, and
deploy_qemu then refuses to overwrite: creation fails AFTER the wait. The
disk is therefore offered for deletion, size and path shown. Offered, not
deleted outright: the same name may designate the disk of a VM removed by
hand, whose data was meant to be kept. A refusal does not drift into
failure, it asks again. The offer comes after the full-screen form
closes, because deleting there needs root and a password prompt has
nowhere to appear inside it.
Checked: 7 tests, turned red by two mutations — not asking again after a
refusal, and skipping the offer on the full-screen path.
Assisted-by: Claude Opus 5
Le nœud de rendu existe mais EGL ne s'y initialise pas : QEMU s'arrête
sur « eglInitialize failed » pendant la connexion au moniteur. La
détection ne voit qu'un fichier dans /dev/dri, et rien ne distingue un
GPU utilisable d'un nœud sans pile EGL avant que QEMU n'essaie. La
création réessaie donc sans la 3D, après avoir retiré le domaine de
l'essai raté — sans quoi le nom reste pris. « --gpu on » n'est pas
rétrogradé en silence, et un échec qui n'est pas celui d'EGL n'est pas
rattrapé.
Vérifié : 8 tests et trois mutations. Le chemin réel n'a pas été exécuté,
faute de /dev/dri et de virt-install sur la machine de développement.
--- EN ---
The render node exists but EGL will not initialise on it: QEMU stops on
« eglInitialize failed » while connecting to the monitor. Detection only
sees a file under /dev/dri, and nothing separates a usable GPU from a
node without an EGL stack until QEMU tries. Creation therefore retries
without 3D, after undefining the domain of the failed attempt — the name
would otherwise stay taken. « --gpu on » is not silently downgraded, and
a failure that is not EGL's is not caught.
Checked: 8 tests and three mutations. The real path was not exercised,
for lack of /dev/dri and virt-install on the development machine.
Assisted-by: Claude Opus 5
Appartenir au groupe libvirt suffit à joindre qemu:///system : le sudo
écrit en dur n'y ajoutait aucun droit et réclamait un mot de passe à
chaque entrée de menu. La question se tranche en ESSAYANT, jamais en
lisant /etc/group : les groupes d'un processus sont figés à l'ouverture
de session, donc la table dit le déclaré, l'essai le faisable. C'est la
distinction que porte aussi l'avertissement d'avant-installation. Un
hyperviseur distant garde sudo, ses droits ne se sondant pas d'ici.
Vérifié : 10 tests, rougis par deux mutations — lire /etc/group, et
conclure « pas de sudo » sur un sondage mort.
--- EN ---
Membership of the libvirt group is enough to reach qemu:///system: the
hardcoded sudo added no right there and asked for a password at every
menu entry. The question is settled by TRYING, never by reading
/etc/group: a process's groups are frozen at session start, so the table
states what is declared, the attempt what is doable. The pre-install
warning carries that same distinction. A remote hypervisor keeps sudo,
its rights not being probeable from here.
Checked: 10 tests, turned red by two mutations — reading /etc/group, and
concluding « no sudo » from a dead probe.
Assisted-by: Claude Opus 5
Une VM ratée n'affichait que ses quatre dernières lignes, et l'épilogue
« Échec de la commande » avec sa ligne de commande les occupe entièrement :
le message de l'outil tombait juste au-dessus de la fenêtre. La sortie
étant jetée après la boucle, passé l'écran elle n'existait plus nulle
part. Trente lignes en cas d'échec, quatre en cas de réussite, et la
sortie complète va dans un fichier dont le chemin s'affiche. Quand la
commande portait la 3D, le rapport nomme « --gpu off » : le menu ne
l'expose pas, c'est la seule issue depuis là.
Vérifié : 7 tests, dont un nom de VM hostile qui ne doit pas composer un
chemin hors du répertoire de session.
--- EN ---
A failed VM showed only its last four lines, and the « Échec de la
commande » epilogue with its command line fills them entirely: the tool's
own message fell just above the window. The output being discarded after
the loop, past the screen it existed nowhere at all. Thirty lines on
failure, four on success, and the whole output goes to a file whose path
is printed. When the command carried 3D, the report names « --gpu off »:
the menu does not expose it, and it is the only way out from there.
Checked: 7 tests, among them a hostile VM name that must not compose a
path outside the session directory.
Assisted-by: Claude Opus 5
Environ 1 130 tokens étaient chargés à chaque session pour du contenu
dérivable ou écrit deux fois : les deux tableaux d'index décrivaient des
fichiers déjà chargés en entier, et la ligne de format de commit
contredisait 04-code-conventions.md et le hook qui l'applique. Les règles
du générateur et du déploiement ne servent qu'à une tâche : elles se
chargent désormais à la demande, comme les deux skills déjà en place.
L'interdit du générateur, lui, reste dans CLAUDE.md — une interdiction ne
doit pas dépendre de l'ouverture d'une skill.
Vérifié : aucun renvoi vers les fichiers déplacés, et les quatre skills
déclarent un nom qui correspond à leur répertoire.
--- EN ---
About 1,130 tokens loaded every session for content that is derivable or
written twice: the two index tables described files already loaded in
full, and the commit-format line contradicted 04-code-conventions.md and
the hook enforcing it. The code-generator and deployment rules serve one
task each: they now load on demand, like the two skills already in place.
The generator's prohibition stays in CLAUDE.md — a ban must not depend on
a skill being opened.
Checked: no reference points at the moved files, and all four skills
declare a name matching their directory.
Assisted-by: Claude Opus 5
Une image cloud Arch est nue : ni bash-completion, ni accès à l'AUR. Les
deux arrivent avec l'amorçage, sur la seule branche pacman. yay-bin
plutôt que yay, dont le paquet source compile Go pour le même outil ; la
construction reste sous l'utilisateur de la VM, makepkg refusant root. Le
« || true » qui ferme le bloc porte : le groupe est le dernier membre de
sa liste « || », donc set -e s'y applique et un sudo en échec emporterait
l'installation entière. Le guide de connexion n'annonce yay que si une
installation a eu lieu.
Vérifié : 10 tests, dont « bash -n » sur la commande distante entière et
la survie du bloc sous set -e avec un PATH vide.
--- EN ---
An Arch cloud image is bare: no bash-completion, no AUR access. Both come
with the bootstrap, on the pacman branch alone. yay-bin rather than yay,
whose source package compiles Go for the same tool; the build stays under
the VM user, makepkg refusing root. The « || true » closing the block
carries weight: the group is the last member of its « || » list, so set -e
applies inside it and one failing sudo would take the whole install down.
The login guide announces yay only when an install ran.
Checked: 10 tests, among them « bash -n » over the whole remote command
and the block surviving set -e with an empty PATH.
Assisted-by: Claude Opus 5
Accepter d'installer les paquets QEMU redémarrait la machine sans autre
question : --assume-yes couvrait le gestionnaire de paquets, et la
commande y ajoutait --reboot-if-needed, qui ne demandait rien. Une seule
constante servait la VM qu'on vient de créer et le poste qui la crée.
--reboot-if-needed PROPOSE désormais, sur /dev/tty pour rester visible
quand la sortie est un tuyau, et vaut non par défaut ; un refus laisse
les paquets posés et dit quoi faire. --assume-yes-reboot est le seul
consentement muet, que seul le profil invité porte.
Vérifié : 7 tests, rougis par deux mutations — assume_yes rouvrant la
porte, le menu hôte reprenant le drapeau.
--- EN ---
Accepting the QEMU package install rebooted the machine with no further
question: --assume-yes covered the package manager, and the command
added --reboot-if-needed, which asked nothing. One constant served both
the VM just created and the workstation creating it. --reboot-if-needed
now OFFERS, on /dev/tty so it stays visible when output is a pipe, and
defaults to no; a refusal leaves the packages in place and says what to
do. --assume-yes-reboot is the only silent consent, carried by the guest
profile alone.
Checked: 7 tests, turned red by two mutations — assume_yes reopening the
door, the host menu taking the flag back.
Assisted-by: Claude Opus 5
Les règles à appliquer avant de coder sont éparpillées entre les configs,
les hooks et les modules maison, et la documentation en contredit
plusieurs : autopep8 est recommandé alors que le script sort en 1, aucun
script oca-* n'est installé, la racine n'a ni .pre-commit-config.yaml ni
.pylintrc, et flake8 comme pylint-odoo ne vivent que dans le venv Odoo,
que rien ne lance. Le gabarit énonce ce que l'outillage impose, à effort
high, l'épinglage ultracode restant celui de l'utilisateur.
Vérifié : 146 règles relevées, 142 confirmées contre leur citation, 4
retirées. Deux gardes lient chaque entrée du menu à un gabarit présent
qui déclare le bon nom.
--- EN ---
The rules to apply before coding are scattered across the configs, the
hooks and the in-house modules, and the documentation contradicts several
of them: autopep8 is recommended although the script exits 1, no oca-*
script is installed, the root carries neither .pre-commit-config.yaml nor
.pylintrc, and flake8 as well as pylint-odoo live only in the Odoo venv,
which nothing invokes. The template states what the tooling enforces, at
high effort, the ultracode pin remaining the user's own.
Checked: 146 rules surveyed, 142 confirmed against their citation, 4
dropped. Two guards tie each menu entry to a template that exists and
declares the right name.
Assisted-by: Claude Opus 5
Ajouter une entrée commence par des décisions qu'aucun gabarit
n'imposait : quel menu parent, motif A ou B, quoi faire en cas d'échec,
ce qui est détruit, ce qui touche à une donnée client. La commande les
demande avant d'écrire, planifie avec superpowers quand le plugin est
là, et pose sa spécification dans tasks/, non versionné. Son frontmatter
fixe l'effort à max, seule valeur de l'énumération ; ultracode est un
épinglage de session que l'utilisateur tape, non un réglage de gabarit.
Vérifié : les deux gabarits déployés dans un HOME jetable, relus « à
jour » par l'écran de contexte.
--- EN ---
Adding an entry starts with decisions no template forced: which parent
menu, pattern A or B, what to do on failure, what gets destroyed, what
touches customer data. The command asks them before writing, plans with
superpowers when the plugin is there, and lays its specification in
tasks/, which is not versioned. Its frontmatter sets effort to max, the
only value in the enumeration; ultracode is a session pin the user
types, not a template setting.
Checked: both templates deployed into a throwaway HOME, read back as up
to date by the context screen.
Assisted-by: Claude Opus 5
Rien ne posait un plugin depuis TODO ; la CLI seule le faisait, hors du
menu. L'installation passe par « -y » : la sortie de TODO est un tuyau,
pas un terminal, et la CLI refuse sans lui toute installation qui
exécute une commande déclarée par un marketplace. La liste préférée
s'affiche donc AVANT la confirmation, seule occasion de la lire ; ses
quatre plugins travaillent sur le poste, sans service tiers ni compte.
La recherche lit les manifestes sur le disque, donc hors ligne.
Vérifié : 8 tests neufs, dont la frontière de mot qui sépare deux noms
dont l'un contient l'autre — une recherche naïve en rate trois.
--- EN ---
Nothing installed a plugin from TODO; the CLI alone did, outside the
menu. Installing goes through « -y »: TODO's output is a pipe, not a
terminal, and without it the CLI refuses any install that runs a
command declared by a marketplace. The preferred list is therefore
shown BEFORE the confirmation, the only chance to read it; its four
plugins run on the workstation, with no third party and no account.
Search reads the manifests from disk, hence offline.
Checked: 8 new tests, among them the word boundary separating two names
where one contains the other — a naive search misses three of them.
Assisted-by: Claude Opus 5
Une fusion apporte plusieurs commits d'un coup, et rien ne guidait les
deux écrits qu'elle demande : l'entrée de changelog et le message de
merge. La commande déployée impose la source — CHANGELOG.base.md, les
fichiers générés étant perdus au prochain doc_markdown — et le corps
bilingue avec son trailer, que le garde-fou ne verra jamais, commit-msg
ignorant tout message ouvrant sur « Merge ». Elle prépare, elle ne
fusionne pas : le message part dans tasks/, non versionné.
Vérifié : 45 tests du menu, et un déploiement dans un HOME jetable que
l'écran de contexte relit « à jour » face à son gabarit.
--- EN ---
A merge lands several commits at once, and nothing guided the two pieces
of writing it needs: the changelog entry and the merge message. The
deployed command imposes the source — CHANGELOG.base.md, the generated
files being lost at the next doc_markdown — and the bilingual body with
its trailer, which the guard rail never sees, commit-msg skipping any
message opening on « Merge ». It prepares, it does not merge: the
message goes to tasks/, which is not versioned.
Checked: 45 menu tests, and a deployment into a throwaway HOME that the
context screen reads back as up to date against its template.
Assisted-by: Claude Opus 5
Ces installateurs posent leur binaire dans un répertoire du HOME que le PATH
d'un shell ne porte pas toujours : sans la ligne d'export, le binaire est là
et la commande reste introuvable. Le répertoire diffère d'un outil à l'autre,
et l'un des deux écrit déjà sa propre ligne — la présence se teste donc sur
le répertoire, pas sur la graphie, et rien n'est ajouté deux fois.
Le PATH d'un processus est figé depuis son démarrage : un nouveau shell est
nécessaire, ce que la sortie dit. Troisième écrivain dans le fichier de
shell, starship compris, d'où l'écriture mise en commun. Vérifié : 31 tests.
--- EN ---
These installers put their binary in a HOME directory that a shell's PATH
does not always carry: without the export line, the binary is there and the
command stays not found. The directory differs from one tool to the other,
and one of the two already writes its own line — presence is therefore tested
on the directory, not on the spelling, and nothing is added twice.
A process PATH is frozen since its start: a new shell is needed, which the
output says. Third writer into the shell file, starship included, hence the
shared write. Checked: 31 tests.
Assisted-by: Claude Opus 5
Sept entrées sans repère visuel se lisent une par une. L'icône entre dans la
traduction, qui porte déjà le libellé affiché.
Un glyphe à présentation texte occupe une colonne quand les autres en
occupent deux, et décale la colonne des libellés : il prend deux espaces,
comme 🖥 et ⚙ ailleurs dans le fichier. Rendu vérifié dans les deux langues.
--- EN ---
Seven entries with no visual marker are read one by one. The icon goes into
the translation, which already carries the displayed label.
A text-presentation glyph takes one column where the others take two, and
shifts the label column: it gets two spaces, like 🖥 and ⚙ elsewhere in the
file. Rendering checked in both languages.
Assisted-by: Claude Opus 5
Poser le binaire ne change pas le prompt : c'est la ligne d'initialisation
dans le fichier du shell qui le fait, et les deux étapes échouent séparément.
Le paquet vient de la distribution quand elle le connaît, de l'installateur
amont sinon — starship n'est pas empaqueté partout. Le fichier du shell n'est
demandé que devant plusieurs candidats, et la ligne ne s'écrit qu'une fois.
L'entrée porte sa destination dans « method » : son rang suit le nombre
d'entrées de todo.json, qu'un numéro codé en dur ignorerait. Vérifié : 18
tests.
--- EN ---
Laying down the binary does not change the prompt: the init line in the shell
file does, and the two steps fail separately. The package comes from the
distribution when it knows it, from the upstream installer otherwise —
starship is not packaged everywhere. The shell file is only asked for when
several candidates exist, and the line is written only once.
The entry carries its destination in « method »: its rank follows the number
of todo.json entries, which a hard-coded number would ignore. Checked: 18
tests.
Assisted-by: Claude Opus 5
Une distribution en publication continue n'a qu'une version, latest : le
segment ne distingue aucune VM d'une autre et sort du nom. Une version
nommée qui coexiste avec d'autres au catalogue y reste, tumbleweed comme
les numérotées.
Le nom se relit dans l'autre sens pour retrouver (distro, version) et
filtrer les outils par distribution : une VM déjà déployée sous l'ancien
nom n'y est plus résolue, la renommer suffit. Vérifié : catalogue rejoué
sans collision, aller-retour du nom, 6 tests.
--- EN ---
A rolling-release distribution has a single version, latest: the segment
tells no VM apart from another and leaves the name. A named version that
coexists with others in the catalogue stays, tumbleweed as much as the
numbered ones.
The name is read back the other way to recover (distro, version) and filter
tools by distribution: a VM already deployed under the old name no longer
resolves there, renaming it is enough. Checked: catalogue replayed without
collision, name round trip, 6 tests.
Assisted-by: Claude Opus 5
zdiff3 fait figurer la base commune dans les marqueurs de conflit et sort
de la zone contestée les lignes que les deux côtés ont en commun : il reste
moins à arbitrer à la main. Le style demande git 2.35, que toutes les
plateformes supportées dépassent.
La valeur est relue après écriture, « git config » ne rendant rien à
l'écriture. L'entrée est déclarée dans TestGitMenuNumbering : le menu Git
mêle entrées codées en dur et entrées de todo.json, qu'un rang de plus
décale. Vérifié : 117 tests au vert.
--- EN ---
zdiff3 puts the merge base into the conflict markers and lifts out of the
contested area the lines both sides share: less is left to arbitrate by
hand. The style needs git 2.35, which every supported platform exceeds.
The value is read back after writing, as « git config » returns nothing on
write. The entry is declared in TestGitMenuNumbering: the Git menu mixes
hard-coded entries with todo.json ones, which one more rank shifts.
Checked: 117 tests green.
Assisted-by: Claude Opus 5
Un processus garde le PATH qu'il avait au démarrage : rtk installé dans
~/.local/bin pendant que TODO tourne échappe à shutil.which, et « rtk » nu
sort en 127. Le menu le cherche donc aussi à l'emplacement de
l'installateur et l'appelle par son chemin absolu, sans confondre un
binaire hors PATH avec une absence.
L'installation annonce son résultat : version et chemin, ou échec.
Vérifié : 9 tests neufs, 117 au total.
--- EN ---
A process keeps the PATH it had at startup: rtk installed into
~/.local/bin while TODO runs escapes shutil.which, and a bare « rtk »
exits 127. The menu therefore also looks at the installer's location and
calls the binary by its absolute path, without mistaking a binary outside
the PATH for a missing one.
Installation now reports its outcome: version and path, or failure.
Checked: 9 new tests, 117 in total.
Assisted-by: Claude Opus 5
La sauvegarde double la place occupée et le défaut était OUI : sur un
disque presque plein, une entrée vide lançait une copie qui s'arrête à
mi-course et laisse un .bak tronqué. Les deux tailles passent donc avant
la question, et le défaut bascule à NON quand la place manque.
Le besoin annoncé est la taille ALLOUÉE : « cp --sparse=always » ne
recopie pas les trous d'un qcow2. La sortie du gestionnaire de paquets
enchaînait par ailleurs sur une question portant sur autre chose ;
l'étape se referme d'une ligne.
Vérifié : le défaut remis à OUI sans place, comme la taille apparente au
lieu de l'allouée, font tomber les tests. 4144 verts.
--- EN ---
A backup doubles the space used and the default was YES: on a nearly
full disk, an empty answer started a copy that stops midway and leaves a
truncated .bak. Both sizes now come before the question, and the default
flips to NO when the room is short.
The need shown is the ALLOCATED size: "cp --sparse=always" does not copy
the holes of a qcow2. The package manager output also ran straight into a
question about something else; the step now closes with a line of its
own.
Checked: putting the default back to YES without room, like the apparent
size instead of the allocated one, makes the tests fail. 4144 green.
Assisted-by: Claude Opus 5
La réduction sûre listait les outils manquants et s'arrêtait là. Trois
écritures séparées savaient installer, chacune un sous-ensemble
différent : openSUSE posait virt-viewer, mais ni navigateur CLI ni
lm-sensors.
Le binaire n'est presque jamais le paquet : sgdisk vit dans « gdisk »
chez Debian et Fedora, dans « gptfdisk » chez Arch et openSUSE. Deux
règles passent aussi dans la composante : l'ID de la distribution décide
avant le PATH, et la commande s'affiche avant la question.
Vérifié : commandes identiques sur les trois familles déjà couvertes,
4139 tests verts.
--- EN ---
The safe shrink listed the missing tools and stopped there. Three
separate writings knew how to install, each covering a different
subset: openSUSE could put virt-viewer down, but neither a CLI browser
nor lm-sensors.
A binary is almost never the package: sgdisk lives in "gdisk" on Debian
and Fedora, in "gptfdisk" on Arch and openSUSE. Two rules move into the
component as well: the distribution ID decides before the PATH, and the
command is shown before the question.
Checked: commands identical on the three families already covered, and
4139 tests green.
Assisted-by: Claude Opus 5
Les commentaires suivent le dépôt en amont : une adresse ou un nom de
machine qui s'y trouve devient public. Cinq adresses et deux noms de VM
y étaient, plus cinq phrases racontant la séance où le défaut est apparu.
Le mode de défaillance reste, au présent — « une VM renommée se voit
attribuer la passerelle » — et l'incident part. Un relevé d'un seul jour
part avec lui ; la structure durable reste.
check_comment_hygiene.py passe de 5 identifiants et 5 à relire à zéro.
Aucune ligne de code n'est touchée, seulement du texte de commentaire.
--- EN ---
Comments follow the repository upstream: an address or a machine name
sitting in one becomes public. Five addresses and two VM names were
there, plus five sentences telling the session where the fault appeared.
The failure mode stays, in the present — "a renamed VM is given the
gateway" — and the incident goes. A reading taken on one day goes with
it; the durable structure stays.
check_comment_hygiene.py goes from 5 identifiers and 5 to re-read down to
zero. No line of code is touched, only comment prose.
Assisted-by: Claude Opus 5
Un commit-msg non installé, c'est le garde-fou de convention qui ne tourne
jamais, et la pose restait une commande à recopier. git saute sans rien
dire un hook privé du bit d'exécution : l'installation le remet.
exec_command_live ne passe aucun cwd et ce dépôt porte 128 dépôts
imbriqués : sans « git -C racine », un lancement depuis un addon y écrivait
core.hooksPath et laissait la racine sans garde-fou. Et comme cette
fonction retourne le code sans jamais lever, un « fatal: not in a git
directory » annonçait « hooks installés ».
Vérifié : 4114 tests verts ; le nouveau garde tombe sur un dispatch
échangé comme sur une entrée sans branche.
--- EN ---
An uninstalled commit-msg is the convention guard never running, and
installing it stayed a command to copy by hand. git skips a hook without
the execution bit and says nothing: installing restores it.
exec_command_live passes no cwd and this checkout holds 128 nested
repositories: without the "git -C root", a launch from an addon wrote
core.hooksPath there and left the root unguarded. And since that function
returns the exit code without ever raising, a "fatal: not in a git
directory" still announced "hooks installed".
Checked: 4114 tests green; the new guard fails on a swapped dispatch as
well as on an entry with no branch.
Assisted-by: Claude Opus 5
[ADD] commentaires : la convention, ses deux garde-fous, le code nettoyé
Six commits. Le dépôt n'avait aucune règle sur le commentaire de code : le
seul modèle d'écriture disponible était celui du corps de commit, et le
gabarit y renvoyait explicitement le raisonnement qui n'y tenait pas. Le
récit s'est donc écoulé dans les sources, avec les noms qu'il portait.
L'épreuve tient en une phrase : le code est le sujet, au présent de ce qu'il
fait. Une phrase dont le sujet est un incident, une machine, une date ou une
personne part vers tasks/, qui n'est pas versionné ; le mode de défaillance
que le code empêche, lui, reste. Rien d'identifiant hors de private/, et
l'exemple qui illustre cet interdit s'invente plutôt qu'il ne s'emprunte,
un test figeant pour toujours ce qu'il contient.
Deux garde-fous, de sévérité opposée. Le hook commit-msg REFUSE la part
mécanique d'un message : longueur par langue, adresse, courriel, chemin de
compte. Le hook pre-commit INFORME — il liste les commentaires à relire dans
les fichiers indexés et sort toujours en 0, un contrôle bloquant à cette
échelle se faisant désinstaller. L'outil sépare la trouvaille du signal :
l'identifiant se retire, le récit se relit, la même phrase pouvant énoncer
un fait durable.
Un écran du menu TODO relève le contexte fourni à un assistant sur ses six
sources et repère une commande déployée qui a dérivé de son gabarit. Code et
jeux d'essai perdent au passage leurs valeurs réelles — base, adresse,
compte, hôte — au profit de valeurs inventées.
Vérifié : 65 tests neufs, dont 43 pour l'outil seul. Le prédicat qui
distingue une adresse d'une version de manifeste est partagé par les deux
garde-fous, deux prédicats pour une même question finissant par diverger.
--- EN ---
Six commits. The repository had no rule at all about code comments: the only
writing model available was the commit body, and the template explicitly sent
the reasoning that did not fit there into a code comment. The story therefore
flowed into the sources, carrying the names it named.
The test fits in one sentence: the code is the subject, in the present of
what it does. A sentence whose subject is an incident, a machine, a date or a
person goes to tasks/, which is not versioned; the failure mode the code
prevents stays. Nothing identifying outside private/, and the example
illustrating that ban is invented rather than borrowed, a test freezing
forever what it holds.
Two guard rails, of opposite severity. The commit-msg hook REFUSES what is
mechanical in a message: length per language, address, e-mail, account path.
The pre-commit hook INFORMS — it lists the comments worth re-reading in the
staged files and always exits 0, a blocking check at that scale getting
uninstalled. The tool separates the finding from the signal: identifying data
is removed, narrative is re-read, the same sentence being able to state a
durable fact.
A TODO screen reports the context given to an assistant across its six
sources and spots a deployed command that drifted from its template. Code and
fixtures lose their real values along the way — database, address, account,
host — for invented ones.
Checked: 65 new tests, 43 of them for the tool alone. The predicate telling an
address from a manifest version is shared by both guard rails, two predicates
for one question ending up diverging.
Assisted-by: Claude Opus 5
Les messages du garde-fou étaient des littéraux français : l'anglais n'était
pas supporté, quelle que soit la valeur de EL_LANG. Onze clés passent
désormais par t(), pour 6 ms de surcoût mesuré par commit. L'en-tête
annonçait « sujet » alors que le contrôle lit aussi le corps ; il dit
« message ».
Les tests ne passaient que parce que le dépôt est en français : un poste en
anglais en cassait quarante. La langue devient une précondition — épinglée en
mémoire, car set_lang() écrirait un fichier suivi — et les assertions qui
citent du texte français se sautent en nommant leur raison.
Vérifié en basculant EL_LANG : 48 tests OK en français, 2 sautés en anglais.
--- EN ---
The guard rail's messages were French literals: English was not supported at
all, whatever EL_LANG said. Eleven keys now go through t(), for a measured
6 ms of overhead per commit. The header announced "subject" while the check
reads the body too; it says "message".
The tests passed only because the repository is in French: a workstation in
English broke forty of them. The language becomes a precondition — pinned in
memory, since set_lang() would write a tracked file — and the assertions
quoting French text skip while naming their reason.
Checked by switching EL_LANG: 48 tests OK in French, 2 skipped in English.
Assisted-by: Claude Opus 5
Trois contrôles préexistants passaient au rouge sur cette branche.
Un fichier qui porte un shebang doit être exécutable : commité en 644, il
casse deux invariants, le mode stocké par git et le bit sur disque. Ses six
frères de script/analyse/ sont en 755.
Le contrôle d'outillage ne balayait pas script/*.py : un module partagé posé
là passait pour un paquet tiers non déclaré. Trois fichiers de plus entrent
dans le balayage, sans révéler d'autre dépendance. Et une clé de traduction
appelée six fois n'était pas déclarée, l'écran rendant un mot anglais.
Vérifié : 4105 tests, tout vert.
--- EN ---
Three pre-existing checks were turning red on this branch.
A file carrying a shebang must be executable: committed as 644, it breaks two
invariants, the mode git stores and the bit on disk. Its six siblings in
script/analyse/ are 755.
The tooling check never scanned script/*.py: a shared module placed there was
taken for an undeclared third-party package. Three more files enter the scan,
revealing no other dependency. And a translation key called six times was
undeclared, the screen rendering an English word.
Checked: 4105 tests, all green.
Assisted-by: Claude Opus 5
Le journal s'arrêtait à la fusion précédente : trente-deux commits n'y
figuraient pas, l'outillage de migration d'un côté, la convention d'écriture
et ses garde-fous de l'autre.
Dix-sept entrées les couvrent, en Ajouté, Modifié, Corrigé et Retiré. Le
`.base.md` est édité et mmg régénère les deux fichiers dérivés, qui ne se
modifient jamais à la main.
Vérifié : autant de puces en français qu'en anglais dans chaque section, et
aucune donnée identifiante. `[Unreleased]` porte deux sections Modifié et
deux Corrigé, défaut antérieur ; les entrées vont dans les premières.
--- EN ---
The changelog stopped at the previous merge: thirty-two commits were missing
from it, the migration tooling on one side, the writing convention and its
guard rails on the other.
Seventeen entries cover them, across Added, Changed, Fixed and Removed. The
`.base.md` is edited and mmg regenerates the two derived files, which are
never edited by hand.
Checked: as many French bullets as English ones in every section, and no
identifying data. `[Unreleased]` carries two Changed and two Fixed sections,
a pre-existing defect; the entries go into the first of each.
Assisted-by: Claude Opus 5
`git add -A` indexe tout ce qui n'est pas suivi. Or `private/` et `tasks/` ne
le sont pas EXPRÈS : le premier est le seul endroit autorisé à porter une
donnée de client, le second reçoit l'enquête précisément parce qu'il ne part
pas dans git. Un ratissage les commit tous les deux.
Il emporte aussi ce qui est en cours ailleurs dans le checkout, sous un sujet
qui ne le couvre pas. Le gabarit nomme désormais les fichiers et renvoie à
`git add -p` quand un fichier porte deux sujets.
La règle porte la même consigne : le gabarit ne se lit qu'à l'appel de la
commande, la règle est chargée à chaque session.
--- EN ---
`git add -A` stages everything untracked. Yet `private/` and `tasks/` are
untracked ON PURPOSE: the first is the only place allowed to carry customer
data, the second receives the investigation precisely because it does not go
into git. A sweep commits both.
It also swallows whatever else is in flight in the checkout, under a subject
that does not cover it. The template now names the files and points at
`git add -p` when one file carries two subjects.
The rule carries the same instruction: the template is read only when the
command is invoked, the rule is loaded every session.
Assisted-by: Claude Opus 5
Le contexte d'un assistant est éparpillé sur six sources — instructions,
règles, skills, commandes déployées, hooks git, mémoire — et rien ne disait
laquelle manquait ni laquelle avait dérivé.
L'écran les relève. Chaque commande déployée est comparée à son gabarit du
dépôt en ignorant les lignes d'identité git, que le déploiement substitue :
une copie périmée se voit, là où une égalité stricte les déclarerait toutes
périmées. Les termes de la liste privée sont COMPTÉS, jamais affichés.
--- EN ---
An assistant's context is scattered over six sources — instructions, rules,
skills, deployed commands, git hooks, memory — and nothing said which one was
missing nor which one had drifted.
The screen reports them. Each deployed command is compared to its repository
template, ignoring the git identity lines the deployment substitutes: a stale
copy shows up, where a strict equality would declare them all stale. The
private list's terms are COUNTED, never displayed.
Assisted-by: Claude Opus 5
Rien ne relevait les commentaires hors convention. L'outil lit commentaires et
docstrings, jamais le code autour, et rend deux familles inégales :
l'identifiant — adresse, courriel, chemin de compte, nom de la liste privée —
est une trouvaille ; le récit — témoignage, date, personne — un signal à relire.
Le hook pre-commit le lance sur l'index, sort toujours en 0 — un contrôle
bloquant à cette échelle se fait désinstaller — et parle quand l'outil échoue.
La règle du générateur et sa doc portent le nettoyage au fur et à mesure, et
l'exemple d'un interdit s'invente : base, adresse, compte et hôte en prennent un.
L'écran du contexte est posé, sans entrée de menu. Vérifié : 252 tests des six
fichiers d'essai touchés passent.
--- EN ---
Nothing reported the comments that break the convention. The tool reads
comments and docstrings, never the code around them, and returns two unequal
families: identifying data — address, e-mail, account path, private-list name
— is a finding; narrative — witness marker, date, person — a signal to re-read.
The pre-commit hook runs it on the index, always exits 0 — a blocking check at
that scale gets uninstalled — and speaks when the tool fails. The generator
rule and its doc carry the clean-up as you go, and a forbidden thing's example
is invented: a real database, address, account and host each take one.
The context screen is in place, with no menu entry. Checked: 252 tests of the
six touched fixture files pass.
Assisted-by: Claude Opus 5
Le garde-fou ne lisait que le sujet : le corps portait des noms de bases
réelles, des adresses et des chemins de compte, et sa longueur médiane
faisait une fois et demie le plafond de la convention.
Il lit désormais le corps, trailers et diff de --cleanup=scissors exclus :
longueur par langue, adresse IP, courriel, chemin de compte, et les termes
d'une liste qui vit hors du dépôt puisque c'est elle qu'elle protège —
absente, le contrôle se tait. Le prédicat qui sépare une adresse d'une
version de manifeste est partagé ; 40 tests couvrent les deux lectures.
--- EN ---
The guard rail read the subject only, while the body carried real database
names, addresses and account paths, and its median length was one and a
half times the convention's ceiling.
It now reads the body, trailers and the --cleanup=scissors diff excluded:
length per language, IP address, e-mail, account path, and the terms of a
list living outside the repository, since the list is what it protects —
absent, that check stays silent. The predicate telling an address from a
manifest version is shared; 40 tests cover both readings.
Assisted-by: Claude Opus 5
Le dépôt n'avait aucune règle sur le commentaire de code : le seul modèle
d'écriture était le corps de commit, et le gabarit y renvoyait le
raisonnement qui n'y tenait pas. Le récit s'écoulait dans les sources,
avec les noms qu'il portait.
L'épreuve tient en une phrase : le code est le sujet, au présent de ce
qu'il fait. Une phrase dont le sujet est un incident, une machine, une date
ou une personne part vers tasks/, non versionné ; le mode de défaillance
que le code empêche reste. Rien d'identifiant hors de private/, et
seulement sur un dépôt privé.
--- EN ---
The repository had no rule at all about code comments: the only writing
model available was the commit body, and the template sent the reasoning
that did not fit there into a comment. The story flowed into the sources,
carrying the names it named.
The test fits in one sentence: the code is the subject, in the present of
what it does. A sentence whose subject is an incident, a machine, a date or
a person goes to tasks/, unversioned; the failure mode the code prevents
stays. Nothing identifying outside private/, and only on a private
repository.
Assisted-by: Claude Opus 5
[ADD] migration : copie anonymisée, verdicts remontés, dérives dépistées
Vingt-deux commits. Une copie de production s'ouvre désormais sans rien
atteindre au dehors : `exp_duplicate_database` d'Odoo coupe la source,
régénère l'uuid, emporte le filestore et neutralise — depuis la 16 seulement.
En deçà, un script du dépôt prend le relais plutôt que de refuser, et
l'exécution annonce lequel a servi, car les deux ne posent pas les mêmes
gestes.
L'anonymisation passe sa liste noire entière — le SQL par un fichier, un
argument ne portant que 131 072 octets — et n'épargne plus les noms qu'elle
devait masquer. Elle laisse intacts les chemins d'identifiants qu'Odoo
repasse à `int()`, et tire ses nombres dans l'étendue mesurée de leur
colonne : la fiche masquée s'ouvre encore.
Une migration ratée ne passe plus pour réussie. Les verdicts de chaque
palier, de la 12 à la 18, remontent dans un écran de qualité, avec le passage
de journal qui les explique et la sortie des outils telle qu'ils l'écrivent :
un pseudo-terminal la capture sans faire taire les invites conditionnées par
`isatty`, ANSI retiré et secrets caviardés. Un code 1 y dit des trouvailles,
non un échec.
Trois dérives muettes deviennent dépistables : un dépôt d'addons absent d'un
palier, un type de vue supprimé qui survit dans des sources qu'aucune base ne
montre, un plan comptable qui gonfle sous un gabarit rechargé.
La liste de prix cesse d'être dupliquée à vide : la décision se prend sur ce
que `base.group_user` implique et non sur les groupes de l'exécutant, et une
liste partagée entre sociétés compte enfin pour chacune. Le reste tient la
chaîne : `odoo_bin.sh` lit le config.conf du dépôt par ODOO_RC, les bases se
nomment sans collision, le registre se précharge, le lanceur de tests
n'oublie plus de fichier, et un hook tient le sujet des commits.
--- EN ---
Twenty-two commits. A production copy now opens without reaching anything
outside it: Odoo's `exp_duplicate_database` cuts the source, regenerates the
uuid, carries the filestore over and neutralises — from 16 onwards only.
Below it a repository script takes over rather than refusing, and the run
announces which one served, because the two do not make the same gestures.
Anonymisation runs its whole blacklist through — the SQL by way of a file, a
single argument carrying no more than 131,072 bytes — and no longer spares
the names it was meant to mask. It leaves alone the identifier paths Odoo
passes back through `int()`, and draws its numbers from their own column's
measured range: the masked record still opens.
A failed migration no longer passes for a successful one. Every step's
verdicts, 12 through 18, surface in a quality screen, with the log passage
that explains them and the tools' output as they wrote it: a pseudo-terminal
captures it without silencing the prompts conditioned on `isatty`, ANSI
stripped and secrets redacted. There, exit code 1 means findings, not
failure.
Three silent drifts become detectable: an addons repository missing from one
step, a removed view type surviving in sources no database shows, a chart of
accounts swelling under a reloaded template.
The pricelist stops being duplicated empty: the decision is taken on what
`base.group_user` implies rather than on the runner's groups, and a pricelist
shared across companies at last counts for each of them. The rest holds the
chain: `odoo_bin.sh` reads the repository's config.conf through ODOO_RC,
databases are named without collision, the registry is preloaded, the test
runner no longer skips a file, and a hook holds commit subjects.
Assisted-by: Claude Opus 5
Une montée de version recharge le gabarit de localisation sans rien dire :
trois des scripts l10n du noyau appellent try_loading() sans
force_create=False, et tout compte que le gabarit n'apparie pas par code
est CRÉÉ. Les groupes ajoutés reclassent alors le plan existant.
Un compte absolu ne dit rien : seul l'ÉCART entre deux paliers de la même
migration se juge — comptes sans écriture, noms homonymes, grille apparue
de rien. L'outil ne répare pas : la clé naturelle de suppression attrape
aussi des comptes réappariés par code, et des ajoutés sont accrochés en ON
DELETE SET NULL. Il dit de rejouer le palier ; 24 tests le couvrent.
--- EN ---
A version bump reloads the localisation template silently: three of the
core l10n scripts call try_loading() without force_create=False, and every
account the template cannot match by code is CREATED. The groups thus
added then reclassify the existing chart.
An absolute count says nothing: only the GAP between two steps of one
migration can be judged — accounts with no entry, homonymous names, a
grouping grid from nothing. The tool does not repair: its natural deletion
key also catches accounts re-matched by code, and added ones are pinned by
ON DELETE SET NULL. It says to replay the step; 24 tests cover it.
Assisted-by: Claude Opus 5
(cherry picked from commit e99575967e0ad5b5122a2c35df3b9eaef7a72d53)
Odoo 17 créait une vue SQL pour account.root ; en 18 le modèle porte
_auto = False et _table_query = '0' : son nom n'entre plus dans aucune
requête, et le contrôle des tables manquantes ignore ces modèles.
Elle n'est pas seulement morte, elle est FAUSSE : bâtie sur la colonne code que
l'ORM 18 n'écrit plus, elle rend trop peu de racines. Elle est aussi l'unique
épingle des deux colonnes héritées où database_cleanup échoue, d'où ce retrait
avant le chargement en 18 ; aucun DROP COLUMN, OpenUpgrade les lit encore.
Sur base jetable, l'ordre est rejouable et laisse intactes une vue d'une
autre forme, une vue dont dépend un objet, une table homonyme.
--- EN ---
Odoo 17 created a SQL view for account.root; in 18 the model carries
_auto = False and _table_query = '0': its name no longer enters any query,
and the missing-table check ignores such models.
It is not merely dead, it is WRONG: built on the code column the 18 ORM no
longer writes, it returns too few roots. It is also the sole pin holding the
two legacy columns database_cleanup fails on, hence its removal before the
load into 18; no DROP COLUMN, OpenUpgrade still reads them afterwards.
On a throwaway database the statement replays cleanly and leaves alone a
view of another shape, a view something depends on, a table of that name.
Assisted-by: Claude Opus 5
(cherry picked from commit b50e2308cbdd1efdfa914497062919eab1bbd329)
L'écran peignait en échec tout code non nul, quand la convention écrite
dans todo_upgrade.run_tool dit : 0 rien à signaler, 1 des trouvailles, 2
l'outil a échoué. database_cleanup imprime lui-même « This is a warning,
not a failure » avant de rendre 1.
Un écran qui contredit l'outil apprend à ignorer les deux : du rouge
signalait une migration en échec là où rien n'avait échoué.
L'icône rejoint la couleur dans migration_status, et le panneau écrit le
sens du chiffre à côté de lui : « statut 1 (des trouvailles) ». Testé.
--- EN ---
The screen painted every non-zero code as a failure, where the convention
written in todo_upgrade.run_tool says: 0 nothing to report, 1 findings, 2
the tool failed. database_cleanup itself prints "This is a warning, not a
failure" before returning 1.
A screen that contradicts the tool teaches you to ignore both: red marked
a migration as failed where nothing had failed.
The icon now lives beside the colour in migration_status, and the panel
spells the number out: "status 1 (findings)". Covered by tests.
Assisted-by: Claude Opus 5
(cherry picked from commit 39d122965e7a09d710255fff061a7526a4077aaa)
« odoo_bin.sh db --drop » échoue par AccessDenied à chaque palier de
migration, et le clone bute ensuite sur « database already exists ».
db_restore.py lit ./config.conf, y voit « admin_passwd = admin » et
n'envoie donc aucun mot de passe ; odoo_bin.sh ne passait pas de « -c »,
donc Odoo lisait ~/.odoorc, qui porte un mot de passe haché.
ODOO_RC ferme la couture en un point plutôt qu'à vingt sites d'appel :
les versions 12 à 18 le lisent après « -c » et avant ~/.odoorc, donc un
choix explicite l'emporte. Vérifié : le drop passe, la précédence est testée.
--- EN ---
"odoo_bin.sh db --drop" fails with AccessDenied at every migration step,
and the clone then hits "database already exists".
db_restore.py reads ./config.conf, sees "admin_passwd = admin" and so
sends no master password; odoo_bin.sh passed no "-c", so Odoo read
~/.odoorc, which carries a hashed password.
ODOO_RC closes the seam in one place instead of twenty call sites:
versions 12 to 18 read it after "-c" and before ~/.odoorc, so an explicit
choice wins. Verified: the drop succeeds, and a test covers precedence.
Assisted-by: Claude Opus 5
(cherry picked from commit 9503d80982b725034513b610b527f29d49025381)
Cinq secondes ne suffisaient pas à LIRE la question. Le compte à rebours
n'existe pas pour aller vite mais pour qu'on puisse s'absenter ; trop
court, il fait l'inverse — on répond par réflexe, ou l'on subit un défaut
non lu. Et « test » ne disait rien de ce qu'on migrait : des migrations
successives portaient toutes le même nom, quand le fichier de sauvegarde
en porte déjà un parlant. Le nom est assaini — il finit dans un createdb —
et borné à 41 caractères : le pilote ajoute « _neutralize_upgrade_18 » et
PostgreSQL tronque à 63, ce qui ferait finir deux paliers sur le même nom.
Un téléchargement distant garde celui que le serveur a donné.
--- EN ---
Five seconds were not enough to READ the question. The countdown does not
exist to go fast but so you can step away; too short, it does the
opposite — you answer by reflex, or you get a default you never read. And
"test" said nothing about what was being migrated: successive migrations
all carried the same name, when the backup file already carries a telling
one. The name is sanitised — it ends up in a createdb — and capped at 41
characters: the driver appends "_neutralize_upgrade_18" and PostgreSQL
truncates at 63, which would land two steps on one name. A remote
download keeps the name the server gave.
Assisted-by: Claude Opus 5
(cherry picked from commit dad0f6b0ef4551898fe2964e177ff5c1c888b5dc)
Le journal d'étape notait la commande et son code de retour, jamais ce
qu'elle avait écrit : l'écran d'analyse ne pouvait rien montrer d'un
échec. Un tube aurait capturé et changé le programme — smoke_public_url
appelle can_ask(), qui exige stdin ET stdout sur un terminal, et derrière
un tube il cesse en silence d'offrir la réparation des vues COW. Un
pseudo-terminal lève le dilemme : l'enfant voit un vrai terminal, la
réponse tapée lui parvient, le code de retour survit. Neuf exécutions y
passent, dont check_hidden_models, qui tournait sans verdict retenu ;
deux restent dehors, pty.spawn naît en 0×0 et un plein écran s'y perdrait.
--- EN ---
The step log recorded the command and its exit code, never what it
wrote: the analysis screen could show nothing of a failure. A pipe would
have captured and changed the program — smoke_public_url calls can_ask(),
which requires stdin AND stdout to be terminals, and behind a pipe it
silently stops offering the COW view repair. A pty settles it: the child
sees a real terminal, a typed answer reaches it, the exit code survives.
Nine runs go through it, including check_hidden_models, which ran with no
verdict recorded; two stay out, pty.spawn starts at 0×0 and a full-screen
app would lay out on nothing.
Assisted-by: Claude Opus 5
(cherry picked from commit 81e9227502a0d16e6409338cf958495a5f8e3827)
L'écran de qualité ne listait que les échecs, quand la question devant
une base migrée est « qu'a-t-on vérifié » : les quatorze verdicts
s'affichent, de la 12 à la 18, seule façon de voir qu'un échec a été
rattrapé à un palier plus haut. Le panneau ne portait que la commande ;
il montre le passage du journal d'étape qui l'entoure, garde par tee ce
qu'il lance lui-même et le relit sans relancer. La sortie de l'outil,
elle, part sur le terminal : un tube ferait renoncer les pleins écrans.
Relancer un test d'un autre palier ouvrait la base avec la mauvaise
version, qui y écrit avant d'échouer ; l'écran demande avant de basculer.
--- EN ---
The quality screen listed failures only, when the question in front of a
migrated database is "what did we check": all fourteen verdicts now show,
12 through 18, the only way to see that a failure at one tier was
recovered higher up. The panel carried only the command; it shows the
step-log passage around it, keeps by tee what it runs itself and re-reads
that without rerunning. The tool output goes to the terminal: a pipe
would make full-screen tools give up. Replaying a test from another tier
opened the database with the wrong version, which writes before it
fails; the screen asks before switching the checkout.
Assisted-by: Claude Opus 5
(cherry picked from commit 2d460b7c777d39a887dabfe7cf5405864c6c3f8c)
Odoo 18 a supprimé le type de vue tree, sans conversion : un module
resté dessus ne s'installe pas, ou casse au clic (« View types not
defined tree found in act_window »). Les autres outils de la revue
lisent la BASE, où un module jamais installé ne laisse rien.
Le mot reste un identifiant valide : sur 465 occurrences, 80 cassent — le
noyau 18 garde account.view_invoice_tree en <list>. D'où lxml et ast,
jamais de regex : seule la position du littéral décide. Trois portes
filtrent avant tout motif : version, module installable, fichier chargé.
Balayage : 80 constats sur 2654 modules, 26 touchés.
--- EN ---
Odoo 18 removed the tree view type with no shim: a module still on it
fails to install, or breaks on click ("View types not defined tree found
in act_window"). The other review tools read the DATABASE, where a
module that never installed leaves nothing.
The word is still a valid identifier: of 465 occurrences, 80 break — the
18 core keeps account.view_invoice_tree in <list>. Hence lxml and ast,
never regex: only the literal's position decides. Three gates filter
before any pattern: version, installable module, loaded file. Sweep: 80
findings over 2654 modules, 26 affected.
Assisted-by: Claude Opus 5
(cherry picked from commit 38a91039d111b3fa6de32edf315c5caae8553c11)
Une migration 12 → 18 traverse six paliers, et le checkout bascule de
manifeste à chaque fois. Un dépôt d'addons absent du manifeste du 17
n'existe pas sur disque pendant l'étape 17 : Odoo déclare ses modules
introuvables, le pilote propose de les effacer, on répond oui, et la
fonctionnalité part sans qu'aucun échec ne soit signalé.
Seul le trou compte — présent avant et après, absent au milieu — et la
branche en amont le confirme : sur 35 trous, 19 sont de vraies
omissions, quinze déclarées en 16 et 18 mais pas en 17 ; les 35 auraient
fait 46 % de bruit. development.git est rétabli en 13 et en 15.
--- EN ---
A 12 → 18 migration crosses six steps, and the checkout switches
manifest each time. An addons repository missing from the 17 manifest
does not exist on disk during step 17: Odoo reports its modules as
missing, the driver offers to delete them, you answer yes, and the
feature is gone without a single failure being reported.
Only the hole counts — present before and after, absent in between — and
the upstream branch confirms it: of 35 holes, 19 are real omissions,
fifteen declared in 16 and 18 but not in 17; all 35 would have been 46%
noise. development.git is restored in 13 and in 15.
Assisted-by: Claude Opus 5
(cherry picked from commit d7613ea930d45153e9fb7c08460690a95e3dca0e)
Le contrôle jugeait cassée une langue dont `active` est NULL : listée
nulle part, plus réactivable. Faux dans la source 18 — un domaine
('active','=',False) compile en (IS NULL OR = FALSE) (models.py:3217),
l'action du menu Langues porte active_test: False, le tri passe par
COALESCE(active, FALSE) et la lecture rend bool(value).
Odoo écrit ce NULL : active = fields.Boolean() sans défaut
(res_lang.py:64) et un res.lang.csv sans la colonne, soit un NULL par
langue ajoutée au catalogue. « Zéro avant, non nul après » ne suffit
donc pas. Un test refuse désormais une clé que plus rien ne définit.
--- EN ---
The check called a language broken when `active` is NULL: listed
nowhere, no longer re-enablable. False in the 18 source — an
('active','=',False) domain compiles to (IS NULL OR = FALSE)
(models.py:3217), the Languages menu action carries active_test: False,
sorting goes through COALESCE(active, FALSE), reading returns bool(value).
Odoo writes that NULL itself: active = fields.Boolean() with no default
(res_lang.py:64) and a res.lang.csv without the column, one NULL per
language added to the catalogue. So "zero before, nonzero after" is not
enough. A test now refuses a key that nothing defines any more.
Assisted-by: Claude Opus 5
(cherry picked from commit ee932334cfde63c1af831316549a432c3d382721)
Le rapport comparait les paliers sans dire si la migration avait réussi,
alors que les verdicts dorment déjà dans lst_event du journal de
progression : des contrôles en échec y restent sans remonter nulle part.
Trois sections s'ajoutent sous les paliers : les verdicts, rattachés au
palier ODOO et non au compteur du pilote, décalé d'un rang ; où vivent les
traces, car config.conf laisse logfile= vide et la sortie d'Odoo meurt avec
le terminal ; et la revue, six étapes lançables par « r ». Le contrôle de
résidus porte la même section sans toucher son code de sortie : un verdict
vient du fichier, pas de la base.
--- EN ---
The report compared the tiers without saying whether the migration had
succeeded, while the verdicts already sit in lst_event of the progression
file: failed checks stay there and surface nowhere.
Three sections are added below the tiers: the verdicts, tied to the ODOO
tier and not to the driver counter, which is off by one; where the traces
live, since config.conf leaves logfile= empty and Odoo's output dies with
the terminal; and the review, six steps runnable with "r". The residue
check carries the same section without touching its exit code: a verdict
comes from the file, not from the database.
Assisted-by: Claude Opus 5
(cherry picked from commit b05e0333c4b94d58eb794f09a2459e41d826c655)
Le lanceur ne prenait que sept préfixes de noms, « le reste demandant une
base de données » : les 3703 tests du répertoire passent avec PostgreSQL
injoignable, et la suite n'en exécutait que 1131. Il balaie test/test_*.py.
Deux formes rendent un fichier muet sans erreur : unittest.main() posé en
plein milieu, qui sort avant que la seconde moitié soit définie (quatre
fichiers, 87 tests), et l'absence de bloc __main__, qui compte zéro (huit
fichiers, 174 tests). Une garde refuse ces deux formes et le retour d'une
liste de préfixes.
--- EN ---
The runner took seven filename prefixes only, "the rest needing a
database": all 3703 tests in the directory pass with PostgreSQL
unreachable, and the suite ran 1131 of them. It now globs test/test_*.py.
Two shapes make a file silent without error: unittest.main() placed
mid-file, which exits before the second half is defined (four files, 87
tests), and no __main__ block at all, which counts zero (eight files, 174
tests). A guard now refuses both shapes and the return of a prefix list.
Assisted-by: Claude Opus 5
(cherry picked from commit db71b333cc08ae0fce4ddaaf037357648b10236b)
`_activate_or_create_pricelists` ne compte pas une liste de prix partagée
entre sociétés (company_id vide) comme appartenant à la société : elle voit
une société « sans liste » et lui en fabrique une. Sur une base migrée qui
n'a rien perdu, cela ajoute un doublon vide à côté de la liste existante.
Elle interroge maintenant le détecteur `pricelist_missing` du même outil,
qui distingue déjà les deux cas.
Vérifié dans les deux sens sur copie jetable : liste présente, rien n'est
créé ; aucune liste, la réparation en crée une.
--- EN ---
`_activate_or_create_pricelists` does not count a pricelist shared across
companies (empty company_id) as belonging to the company: it sees a company
"without a pricelist" and makes one. On a migrated database that lost
nothing, that adds an empty duplicate beside the existing list.
It now asks the same tool's `pricelist_missing` detector, which already
tells the two cases apart.
Verified both ways on a throwaway copy: a pricelist present, nothing is
created; no pricelist, the repair creates one.
Assisted-by: Claude Opus 5
(cherry picked from commit b5bd2e4e44e89bdba4d639672611dcb964265987)
`env.user.has_group()` répond « oui » dès que l'exécutant est membre du
groupe, et la migration l'y ajoute en cours de route. Or la case des
réglages lit tout autre chose : ce que `base.group_user` IMPLIQUE
(res_config.py, « which groups are implied by the group Employee »).
Décider sur l'exécutant créait une liste de prix dans une base dont la
fonctionnalité est éteinte, et Odoo prévenait à chaque ouverture des
réglages qu'il allait l'archiver. Le contrôle « restant de migration »
posait la même mauvaise question ; les deux lisent désormais l'implication
du groupe. Vérifié sur copie jetable, dans les deux sens : fonctionnalité
éteinte, rien n'est signalé ; activée, constat et réparation reviennent.
--- EN ---
`env.user.has_group()` says yes as soon as the caller belongs to the
group, and the migration adds it along the way. But the settings checkbox
reads something else: what `base.group_user` IMPLIES (res_config.py,
"which groups are implied by the group Employee"). Deciding on the caller
created a pricelist in a database whose feature is off, and Odoo warned on
every opening of the settings that it would archive it. The
migration-residue check asked the same wrong question; both now read the
group implication. Verified on a throwaway copy, both ways: feature off,
nothing is reported; feature on, finding and repair come back.
Assisted-by: Claude Opus 5
(cherry picked from commit 38ba25e01894f45fb956bcbb08cc3d96a125e648)
`resource.calendar.attendance.hour_from` est un `float` qui porte une
HEURE DE LA JOURNÉE : un tirage uniforme sur 0 à 1000 le sort de 0..23 et
l'affichage de la fiche lève « ValueError: hour must be in 0..23 ». La
borne vit dans `time(int(integral), ...)` de resource/models/utils.py, et
aucune contrainte PostgreSQL ne la déclare : le schéma ne dit pas le SENS
de la donnée. « 0 à 1000 » est donc faux pour tout nombre borné par un
usage : heures, pourcentages, taux. On respecte désormais la seule borne
que les DONNÉES déclarent, leur propre étendue — min et max mesurés par
table, et 0 à 1000 quand elle est inconnue. Vérifié : les tirages tiennent
dans l'étendue mesurée, et la fiche s'affiche sans lever.
--- EN ---
`resource.calendar.attendance.hour_from` is a `float` holding an HOUR OF
DAY: a uniform draw over 0 to 1000 takes it out of 0..23 and displaying the
record raises "ValueError: hour must be in 0..23". The bound lives in
`time(int(integral), ...)` in resource/models/utils.py, and no PostgreSQL
constraint declares it: the schema does not say what the data MEANS. So "0
to 1000" is wrong for any number bounded by usage: hours, percentages,
rates. We now respect the only bound the DATA declares, its own range —
min and max measured per table, and 0 to 1000 when it is unknown. Checked:
draws stay inside the measured range, and the record displays without
raising.
Assisted-by: Claude Opus 5
(cherry picked from commit 8e0a19823714b1d18f05613d498f8136b682c047)
Rien ne tenait la convention sur le sujet : le tag est respecté partout,
c'est la longueur qui glisse. Le hook refuse le mécanique et rien de plus
— tag absent, plus de 72 caractères, sujet ouvrant sur une citation ; dire
sur quoi porte le code reste un jugement qu'aucun hook ne rendra. Il compte
des caractères et non des octets, sans quoi un sujet français de 72
caractères tomberait sur ses accents. Le refus enseigne le repli vers des
mots-clés plutôt que la troncature, et nomme `--no-verify` : un garde-fou
qui refuse trop est désinstallé. Les tests pèsent donc autant les
acceptations, « Merge branch » ou fixup de rebase. Le lanceur balaie le
préfixe test_git_ : 32 tests jamais exécutés, le total va de 1021 à 1071.
--- EN ---
Nothing held the subject convention: the tag is respected everywhere, it
is the length that slips. The hook refuses the mechanical and nothing more
— no tag, over 72 characters, a subject opening on a quotation; whether it
says what the code is about stays a judgement no hook will make. It counts
characters, not bytes, or a 72-character French subject would fall on its
accents. The refusal teaches the fallback to keywords rather than
truncation, and names `--no-verify`: a guard rail that refuses too much
gets uninstalled. So the tests weigh the acceptances as much, a "Merge
branch" or a rebase fixup. The runner sweeps the test_git_ prefix: 32
tests never ran, and the total goes from 1021 to 1071.
Assisted-by: Claude Opus 5
(cherry picked from commit c9abf4d1b723ae8ff3762d39bfe1d6982400d12d)
Le manuel encadrait le corps en détail — pourquoi, dix lignes par langue, ce
qu'on ne répète pas du diff — et ne disait du sujet que « courte, à
l'impératif ». Le sujet est pourtant lu cent fois pour une fois que le corps
l'est : git log --oneline, un blame, un bisect, une note de version.
Faute de règle, les sujets dérivent vers le symptôme et la métaphore, qui se
lisent bien sans nommer la partie du système en jeu. La règle ajoute une
épreuve, pas un gabarit : lire le sujet seul, sans diff ni corps, et savoir
ce qui change et où. Les trois exemples avant/après viennent de l'historique
du dépôt, un exemple inventé ne convainquant personne.
--- EN ---
The manual framed the body in detail — why, ten lines per language, what not
to repeat from the diff — and said of the subject only that it be short and
imperative. Yet the subject is read a hundred times for every reading of the
body: git log --oneline, a blame, a bisect, a release note.
With no rule, subjects drift towards the symptom and the metaphor, which read
well without naming the part of the system at stake. The rule adds a test,
not a template: read the subject alone, with no diff and no body, and be able
to say what changes and where. The three before/after pairs come from the
repository's own history, an invented example convincing nobody.
Assisted-by: Claude Opus 5
(cherry picked from commit c86357eab899c65f41287d4f19e88d0da98285c4)
Odoo ne charge le registre d'une base qu'à la PREMIÈRE requête : sur une
base migrée, la personne qui ouvre la page attend des dizaines de secondes.
La sonde prend ce temps à sa place et s'arrête à la première réponse : un
303, un 404 ou un 500 prouvent tous que le registre est chargé.
Elle ne peut pas nuire : elle rend TOUJOURS 0, meurt avec run.sh par un trap
et abandonne après deux minutes. Le port vient de la ligne de commande, puis
de config.conf, puis du journal, exact même quand le port demandé était pris ;
l'écoute sur une interface vide ou générale est sondée par le bouclage.
`--erplibre-disable-warmup-http` la coupe, et elle seule est RETIRÉE avant
odoo_bin.sh, qu'Odoo refuse ; `--no-http` et `--stop-after-init` aussi.
--- EN ---
Odoo only loads a database's registry on the FIRST request: on a migrated
database, whoever opens the page waits tens of seconds. The probe takes that
time instead and stops at the first answer: a 303, a 404 or a 500 all prove
the registry is loaded.
It cannot get in the way: it ALWAYS returns 0, dies with run.sh through a
trap and gives up after two minutes. The port comes from the command line,
then config.conf, then the log, exact even when the requested port was taken;
an empty or wildcard listen interface is probed on the loopback.
`--erplibre-disable-warmup-http` turns it off, and it alone is STRIPPED
before odoo_bin.sh, which Odoo rejects; `--no-http` and `--stop-after-init` too.
Assisted-by: Claude Opus 5
(cherry picked from commit d0943782029ac9a23830d8a8041fccbcac98b67d)
Odoo déclare `parent_path` en `char` mais y range un chemin d'identifiants
— « 1/7/12/ » — reparsé aussitôt par int() : un mot écrit là casse le premier
chargement de page. Sept modèles `_parent_store` en portent un dans une base
ordinaire, et account_payment_term passe de même `days_next_month` à int().
L'anonymisation écarte les deux noms connus, puis sonde le contenu : une colonne
dont chaque valeur est un chemin reste intacte, même dans un module maison. Les
barres obliques sont exigées : un numéro tout en chiffres y échapperait.
Vérifié sur une base de production : les sept modèles chargent, les
partenaires sont anonymisés.
--- EN ---
Odoo declares `parent_path` as `char` but stores an identifier path in it —
« 1/7/12/ » — parsed right back with int(): a word written there breaks the
first page load. Seven `_parent_store` models carry one in an ordinary
database, and account_payment_term likewise passes `days_next_month` to int().
Anonymisation skips the two known names, then probes the content: a column
whose every value is a path is left alone, even in an in-house module. The
slashes are required: a number of pure digits would escape it.
Verified on a production database: the seven models load, partners are
anonymised.
Assisted-by: Claude Opus 5
(cherry picked from commit b47c94524d75172e7afce96e62f3f15b7ad6e225)
Le SQL de la liste noire dépasse MAX_ARG_STRLEN, les 131 072 octets que Linux
impose à UN argument ; il passe par un fichier avec -f, qui garde
--single-transaction que l'entrée standard aurait perdu. Les colonnes texte à
longueur déclarée sont tronquées par left(..., n), l'identifiant en TÊTE sur
une colonne unique. Tous les identifiants sont cités : Odoo laisse nommer un
champ user ou order.
Écarter toute colonne sous CHECK laissait res_partner.name intact ; sur du
texte, seules les contraintes de FORME sont hors de portée. Vérifié sur les
quatre cas ; un UPDATE qui échoue n'écrit rien.
--- EN ---
The blacklist SQL exceeds MAX_ARG_STRLEN, the 131 072 bytes Linux allows for
ONE argument; it travels through a file with -f, which keeps
--single-transaction that stdin would have dropped. Text columns with a
declared length are truncated by left(..., n), the id FIRST on a unique column.
Every identifier is quoted: Odoo allows a field named user or order.
Skipping every column under a CHECK left res_partner.name untouched; on text,
only FORM constraints are out of reach. Checked on the four cases; an UPDATE
that fails writes nothing.
Assisted-by: Claude Opus 5
(cherry picked from commit 610f1d30414d578b49bff5649dbda82f4a2eb19f)
De 12 à 15 la neutralisation d'Odoo n'existe pas et la demande était refusée ;
le dépôt a pourtant sa technique de longue date, update_prod_to_dev.sh, et une
copie imparfaitement neutralisée vaut mieux qu'une copie brute. Le chemin suivi
est ANNONCÉ à l'exécution, car les deux ne posent pas les mêmes gestes : le
script ne pose pas is_neutralized, ne désactive pas les crons et laisse les
clés de paiement, là où il supprime les serveurs de courriel et pose un compte
de développement. Un seul cas reste refusé, le script introuvable, et son échec
fait échouer la copie : elle sortirait brute en s'annonçant neutralisée.
--- EN ---
From 12 to 15 Odoo's neutralisation does not exist and the request was refused;
yet the repository has long had its own technique, update_prod_to_dev.sh, and
an imperfectly neutralised copy beats a raw one. The route taken is ANNOUNCED
at run time, because the two do not make the same gestures: the script does not
set is_neutralized, does not disable crons and leaves the payment keys, where
it deletes the mail servers and sets up a development account. One case is
still refused, a missing script, and its failure fails the copy: it would come
out raw while announcing itself neutralised.
Assisted-by: Claude Opus 5
(cherry picked from commit bd7b648305a09c37adfe4b280e7479f1f178f20e)
La duplication passe par exp_duplicate_database d'Odoo plutôt que par CREATE
DATABASE ... TEMPLATE : lui seul coupe les connexions de la source, régénère
database.uuid, copie le filestore et neutralise. Les trois modules maison du
dépôt n'obtenaient aucun des quatre.
Sous Odoo 15 et avant la neutralisation n'existe pas : la demande est REFUSÉE,
jamais ignorée — une copie qu'on croit neutralisée est pire qu'une brute.
Vérifié sur la copie d'une base migrée 12 → 18 : is_neutralized posé, crons
réduits au seul autovacuum, clé de paiement effacée, filestore copié.
--- EN ---
Duplication goes through Odoo's exp_duplicate_database rather than CREATE
DATABASE ... TEMPLATE: only it drops the source's connections, regenerates
database.uuid, copies the filestore and neutralises. The repository's three
in-house modules obtained none of the four.
Under Odoo 15 and earlier neutralisation does not exist: the request is
REFUSED, never ignored — a copy believed neutralised is worse than a raw one.
Checked on the copy of a 12 → 18 migrated database: is_neutralized set, crons
reduced to autovacuum alone, payment key cleared, filestore copied.
Assisted-by: Claude Opus 5
(cherry picked from commit af99d450c12e70a891d01d0ccf556c1d560e943b)
Vingt-six commits : le déploiement Proxmox durci par l'usage, et deux tests
longs qui créent de vraies machines pour mesurer ce qu'aucune documentation ne
dit.
CE QUE LES MESURES ONT ÉTABLI
Sur 28 cœurs AMD, trois étages d'hyperviseurs imbriqués tiennent en 16 minutes
pour QEMU, 34 pour Proxmox. Le quatrième FONCTIONNE — un Proxmox s'y est
installé complètement — mais coûte 15 à 30 fois plus : 4 h 20 d'amorçage et
7 h 18 d'installation. Ce n'est pas un refus du matériel, c'est une
dégradation super-linéaire, et elle tombe là où les fabricants cessent de
documenter l'imbrication. La profondeur par défaut est donc trois.
CE QUE LES TESTS PROUVENT AU LIEU DE SUPPOSER
deploy_qemu.py n'échoue pas quand /dev/kvm manque : il pose --virt-type qemu
et crée une VM ÉMULÉE, sept minutes et demie de démarrage, sans qu'aucun code
de retour ne le dise. Chaque étage doit montrer /dev/kvm, « nested » à Y et un
domaine en type='kvm' — ce qui n'a pas été lu vaut NON. Sans cela, la descente
mesurerait de la TCG empilée en croyant mesurer de l'imbrication.
CE QUE « --detruire » NE FAIT JAMAIS
Détruire ce qu'il n'a pas créé. Un champ « cree », écrit à l'instant où la
machine existe, commande la liste, le repli par nom et le retrait des entrées
~/.ssh/config ; il refuse tant qu'une descente tourne, et chaque pile ne voit
que ses propres rapports.
CÔTÉ PROXMOX
Le pont interne ne prend plus l'adresse de sa propre passerelle, pmxcfs est
remis debout par l'écran lui-même, le suivi reconnaît une VM par son VMID et
son hôte plutôt que par son nom, et le pare-feu n'est plus démarré depuis
l'extérieur.
--- EN ---
Twenty-six commits: Proxmox deployment hardened by use, and two long tests
that create real machines to measure what no documentation states.
WHAT THE MEASUREMENTS ESTABLISHED
On 28 AMD cores, three levels of nested hypervisors take 16 minutes for QEMU,
34 for Proxmox. The fourth WORKS — a Proxmox installed completely there — but
costs 15 to 30 times more: 4h20 of boot and 7h18 of install. Not a hardware
refusal, a super-linear degradation, landing exactly where vendors stop
documenting nesting. The default depth is therefore three.
WHAT THE TESTS PROVE INSTEAD OF ASSUMING
deploy_qemu.py does not fail when /dev/kvm is missing: it sets --virt-type
qemu and creates an EMULATED VM, seven and a half minutes to boot, with no
exit code to say so. Every level must show /dev/kvm, "nested" at Y and a
type='kvm' domain — what was not read counts as NO. Without that, the descent
would measure stacked TCG believing it measured nesting.
WHAT "--detruire" NEVER DOES
Destroy what it did not create. A "cree" field, written the instant the
machine exists, governs the list, the fallback to the name and the removal of
~/.ssh/config entries; it refuses while a descent runs, and each stack sees
only its own reports.
ON THE PROXMOX SIDE
The internal bridge no longer takes its own gateway's address, pmxcfs is
brought back up by the screen itself, the monitor identifies a VM by its VMID
and host rather than by its name, and the firewall is no longer started from
outside.
Assisted-by: claude-opus-5
Cible de 6 Go et pas de 2 Go : le couple fait tomber le premier étage d'une
descente à dix sur exactement 24 Go, ce qu'une machine à 36 Go porte.
Descendre plus bas au fond ne servirait à rien. Ce qui compte n'est pas le
plancher mais l'ÉCART entre un parent et son enfant : mesuré à 127 Mo de libre
quand il n'était que d'un gibioctet, un parent qui ne respire pas sert mal la
machine qu'il héberge.
--- EN ---
A 6 GB target and a 2 GB step: the pair makes the first level of a ten-level
descent land on exactly 24 GB, which a 36 GB machine can carry.
Going lower at the bottom would gain nothing. What matters is not the floor
but the GAP between a parent and its child: measured at 127 MB free when it
was only one gibibyte, a parent with no room to breathe serves badly the
machine it hosts.
Assisted-by: claude-opus-5
(cherry picked from commit 01aab4d06b10334df9036f5404c6ed9c4ba3356c)
Trois mesures faites sur une descente à cinq étages, et une conclusion de ma
part corrigée par le contre-essai.
Le bail DHCP se fait attendre. L'étage 3 était créé, en type='kvm', et
« domifaddr » ne rendait rien : l'invité n'avait pas encore demandé son
adresse — 87 s puis 94 s selon les tours, quand deploy_qemu s'accorde 90 s et
rend 0 sans l'avoir trouvée. Lu une fois, cela ne prouvait rien.
Un redémarrage demandé à l'invité peut le laisser bloqué dans son
micrologiciel : RIP immobile 46 minutes, pas un octet lu, trois vCPU à fond.
J'ai d'abord conclu que c'était la taille de la mémoire, parce que la même
machine à 2 Go démarrait. Le contre-essai à 4 Go l'a réfuté : elle démarre
aussi, à froid. La différence est le REDÉMARRAGE, pas la mémoire — à chaud
elle reste dans l'UEFI, à froid elle charge son noyau en 60 à 90 s, à 2, 3 et
4 Go. La descente rallume donc une fois par le parent, et une seule : une
boucle de rallumage cacherait un vrai échec.
La mémoire de la pile QEMU est doublée pour une autre raison, mesurée elle
aussi : l'étage 2 avec 5 Go hébergeait un invité de 4 Go et n'avait plus que
127 Mo de libre. Ce n'est pas le plancher qui compte, c'est l'écart.
--- EN ---
Three measurements from a five-level descent, and a conclusion of mine
refuted by the counter-test.
The DHCP lease takes its time. Level 3 was created, type='kvm', and
"domifaddr" returned nothing: the guest had not yet asked for its address —
87 s then 94 s depending on the run, while deploy_qemu allows itself 90 s and
returns 0 without having found it. Read once, that proved nothing.
A reboot asked of the guest can leave it stuck in its firmware: static RIP for
46 minutes, not a byte read, three vCPU at full tilt. I first concluded it was
the memory size, because the same machine booted at 2 GB. The counter-test at
4 GB refuted it: it boots too, cold. The difference is the REBOOT, not the
memory — warm it stays in UEFI, cold it loads its kernel in 60 to 90 s, at 2,
3 and 4 GB. The descent therefore power-cycles once through the parent, and
only once: a restart loop would hide a real failure.
The QEMU stack's memory is doubled for another, also measured reason: level 2
with 5 GB hosted a 4 GB guest and had 127 MB left. It is not the floor that
matters, it is the gap.
Assisted-by: claude-opus-5
(cherry picked from commit e3f60e3ddf066eb76d434bbfe6b01f2271fb1874)
Trois défauts trouvés en une heure par le premier lancement réel — c'est ce
qu'un test d'intégration doit produire.
1. « --setup-host » a échoué en ZÉRO seconde sur « Unable to locate package
qemu-system-x86 », alors que le paquet existe : la VM venait de démarrer et
ses listes ne portaient que bookworm-security. Le message envoyait chercher
des paquets, pas des listes. Même parade qu'install_proxmox.sh — arrêter
apt-daily, puis réessayer.
2. Le réseau « default » de libvirt sert 192.168.122.0/24 à TOUS les étages.
L'étage 2, dont l'adresse VENAIT de ce réseau, voyait son propre net-start
refusé : « Network is already in use by interface enp1s0 ». Un invité qui
vit dans un réseau ne peut pas servir le même. Chaque étage prend le sien,
déduit de sa profondeur absolue, et le REDÉFINIT avant de le démarrer.
3. Le mien : l'extraction du moteur avait coupé preparer_systeme sur le
« return False » de sa boucle, sans son « return True ». La fonction rendait
None, donc l'étape échouait SANS RIEN DIRE, et les deux piles étaient
cassées. L'essai à blanc ne pouvait pas le voir — il sort avant. Un test
d'AST interdit désormais qu'une étape retombe sur None.
long_test/ était introuvable hors du menu : une ligne dans CLAUDE.md, trois
entrées au CHANGELOG, deux sections au README.
--- EN ---
Three defects found in one hour by the first real run — which is what an
integration test is for.
1. "--setup-host" failed in ZERO seconds on "Unable to locate package
qemu-system-x86" though the package exists: the VM had just booted and its
lists carried only bookworm-security. The message sent us looking for
packages, not for lists. Same remedy as install_proxmox.sh — stop
apt-daily, then retry.
2. libvirt's "default" network serves 192.168.122.0/24 at EVERY level. Level 2,
whose own address CAME from that network, had its net-start refused:
"Network is already in use by interface enp1s0". A guest living inside a
network cannot serve the same one. Each level takes its own, derived from
its absolute depth, and REDEFINES it before starting it.
3. Mine: extracting the engine had cut preparer_systeme at its loop's "return
False", without the final "return True". The function returned None, so the
step failed SAYING NOTHING, and both stacks were broken. The dry run could
not see it — it exits earlier. An AST test now forbids a step from falling
through to None.
long_test/ was undiscoverable outside the menu: one line in CLAUDE.md, three
CHANGELOG entries, two README sections.
Assisted-by: claude-opus-5
(cherry picked from commit e46bad408143f7511a04ffdc6a20efdb785f4b5e)
Créer une VM de tête pour héberger un hyperviseur qu'on possède déjà coûte
cinq minutes ET un étage d'imbrication — donc de la lenteur, puisque c'est
elle qu'on mesure. « --hote » part d'un hôte existant ; le menu le propose
sans le rechercher, l'hôte Proxmox déjà retenu étant lu par _pve_host(ask=False).
Trois conséquences que le code ne tirait pas :
- le plan se dimensionne sur la RACINE, lue par ssh. Le dimensionner sur la
machine locale quand les étages vivent ailleurs annoncerait des étages qui
ne tiennent pas ;
- les délais comptent la profondeur ABSOLUE. Un enfant de niveau 1 posé dans
une racine déjà au troisième étage est en réalité au quatrième, et héritait
de délais quatre fois trop courts — le défaut même que « delai » raconte
avoir corrigé ;
- la racine n'est pas un étage atteint. L'y compter décalait de un le total et
le code de sortie ; elle va dans une clé à part, et jamais « cree ».
« sudo » est DÉDUIT de « id -u » et non supposé, et une racine illisible fait
renoncer au lieu d'inventer une capacité.
Le menu offre les deux piles et défait chacune séparément — elles partagent le
dossier des rapports mais chacune ne connaît que les siens. Un test vérifie que
toute entrée affichée a son branchement : ils sont couplés par position, sans
garde.
80 tests, quatre garde-fous morts sous mutation.
--- EN ---
Creating a head VM to host a hypervisor you already own costs five minutes AND
one level of nesting — that is, slowness, which is the very thing being
measured. "--hote" starts from an existing host; the menu offers it without
searching, reading the already-chosen Proxmox host via _pve_host(ask=False).
Three consequences the code did not draw:
- the plan is sized on the ROOT, read over ssh. Sizing it on the local machine
while the levels live elsewhere would announce levels that do not fit;
- delays count ABSOLUTE depth. A level-1 child placed in a root already at the
third level is really at the fourth, and inherited delays four times too
short — the very defect "delai" recounts having fixed;
- the root is not a level reached. Counting it shifted the total and the exit
code by one; it goes in its own key, and never as "cree".
"sudo" is DEDUCED from "id -u" rather than assumed, and an unreadable root
makes us give up instead of inventing a capacity.
The menu offers both stacks and undoes each separately — they share the report
directory but each knows only its own. A test checks that every displayed entry
has its branch: they are coupled by position, with no guard.
80 tests, four guards die under mutation.
Assisted-by: claude-opus-5
(cherry picked from commit c2ab1a968346458925f55fc95619eb4ebd9d3efa)
Le pendant de deep_proxmox : des QEMU dans des QEMU. Le ralentissement du
quatrième étage vient du PROCESSEUR, mais le coût par étage vient de ce qu'on
installe — un nœud Proxmox pose un noyau, corosync, ceph et une interface web
là où un hôte libvirt pose libvirtd. Les deux mesures ensemble séparent ce qui
tient au matériel de ce qui tient à la pile.
Ce test ne peut pas se contenter de descendre. deploy_qemu.py ne passe jamais
« --cpu host-passthrough » et, quand /dev/kvm manque, il n'échoue PAS : il pose
« --virt-type qemu », avertit sur une ligne et crée une VM entièrement ÉMULÉE —
sept minutes et demie de démarrage, aucun code de retour pour le dire. Sans
garde, la descente mesurerait de la TCG empilée en croyant mesurer de
l'imbrication, et rendrait un chiffre plus flatteur et faux.
Chaque étage doit donc PROUVER : /dev/kvm lisible, « nested » à Y, et le
domaine de l'enfant en type='kvm'. Ce qui n'a pas été lu vaut NON — un
/sys/module absent, c'est un module non chargé, pas une permission.
nesting_plan reçoit ses coûts : les constantes vCPU décrivent la physique de
l'imbrication et valent pour les deux piles, les six nombres qui chiffrent un
Proxmox non. Un étage QEMU demande 2 Go et 20 Go, contre 4 et 25.
26 tests, six garde-fous morts sous mutation.
--- EN ---
The counterpart to deep_proxmox: QEMU inside QEMU. The fourth level's slowdown
comes from the PROCESSOR, but the per-level cost comes from what you install —
a Proxmox node lays down a kernel, corosync, ceph and a web UI where a libvirt
host lays down libvirtd. Together the two measurements separate what is due to
the hardware from what is due to the stack.
This test cannot merely descend. deploy_qemu.py never passes "--cpu
host-passthrough" and, when /dev/kvm is missing, it does NOT fail: it sets
"--virt-type qemu", warns on one line and creates a fully EMULATED VM — seven
and a half minutes to boot, no exit code to say so. Unguarded, the descent
would measure stacked TCG while believing it measured nesting, and return a
more flattering, false number.
Every level must therefore PROVE: /dev/kvm readable, "nested" at Y, and the
child's domain type='kvm'. What was not read counts as NO — an absent
/sys/module means an unloaded module, not a permission problem.
nesting_plan takes its costs: the vCPU constants describe the physics of
nesting and hold for both stacks, the six numbers that price a Proxmox do not.
A QEMU level asks 2 GB and 20 GB against 4 and 25.
26 tests, six guards die under mutation.
Assisted-by: claude-opus-5
(cherry picked from commit 39682cb1ce9648db91261387cae88c40c2a67837)
deep_proxmox.py passe de 1245 à 474 lignes : tout ce qui ne connaît ni « qm »
ni pmxcfs vit désormais dans descente.py, prêt pour un second test long.
L'extraction a mis à nu ce qui protégeait un hôte qu'on n'a pas créé : rien.
a_defaire exigeait « vmid » et « parent_alias », deux clés que seule une
descente écrit — la protection tenait parce qu'aucun champ ne décrivait un
hôte emprunté. Un champ « cree », écrit à l'instant de la création, la rend
explicite et ferme trois portes : la liste de destruction, le repli par NOM de
detruire_etage1, et le retrait des entrées ~/.ssh/config de l'utilisateur.
Quatrième porte : le dossier des rapports est partagé. « deep_qemu --detruire »
aurait pris le rapport le plus récent, fût-il celui d'une descente Proxmox. Le
rapport porte son outil ; un rapport plus ancien, qui n'en a pas, est placé par
le préfixe de son nom de fichier plutôt que d'être rendu indéfaisable.
detruire_etage1 ne devine plus le nom de sa cible : il est obligatoire. Et une
sixième étape est née — « cet étage peut-il héberger le suivant ? » — parce que
le contrôle du stockage était celui du DÉBUT de l'étage suivant.
64 tests, les cinq garde-fous morts sous mutation. Au passage : la classe
LongTestMenuMixin, que mon renommage de répertoire avait rebaptisée
long_testMenuMixin sans qu'aucun test le voie.
--- EN ---
deep_proxmox.py drops from 1245 to 474 lines: everything that knows neither
"qm" nor pmxcfs now lives in descente.py, ready for a second long test.
The extraction laid bare what protected a host we did not create: nothing.
a_defaire required "vmid" and "parent_alias", two keys only a descent writes —
the protection held because no field described a borrowed host. A "cree" field,
written the instant a machine is created, makes it explicit and closes three
doors: the destroy list, detruire_etage1's fallback to the NAME, and the
removal of the user's own ~/.ssh/config entries.
Fourth door: the report directory is shared. "deep_qemu --detruire" would have
taken the most recent report, Proxmox's included. Reports now carry their tool;
an older one without it is placed by its filename prefix rather than made
undestroyable.
detruire_etage1 no longer guesses its target's name: it is mandatory. And a
sixth step is born — "can this level host the next?" — because the storage
check was the one at the START of the next level.
64 tests, all five guards die under mutation. Along the way: the class
LongTestMenuMixin, which my directory rename had turned into
long_testMenuMixin without any test noticing.
Assisted-by: claude-opus-5
(cherry picked from commit e1bc9ae3cfacd36a502bc88dc0789a4e86ce986b)
LongTest était le SEUL répertoire en CamelCase que nous ayons créé. Les deux
exceptions sous script/ — OCA_maintainer-tools, OCA_odoo-module-migrator —
sont des noms de dépôts amont tirés par Google Repo, pas les nôtres. Tout le
reste est en minuscules avec des soulignés : image_db, code_generator,
fork_github_repo, shell_script_odoo.
Le nom avait été repris tel qu'il m'avait été dicté, sans être confronté à la
convention — le contrôle même que le reste de ce travail applique partout.
50 occurrences dans 8 fichiers. Le menu TODO résout le nouveau chemin, l'essai
à blanc passe, et les 125 tests des trois fichiers touchés restent verts.
--- EN ---
LongTest was the ONLY CamelCase directory we created. The two exceptions under
script/ — OCA_maintainer-tools, OCA_odoo-module-migrator — are upstream repo
names pulled by Google Repo, not ours. Everything else is lowercase with
underscores: image_db, code_generator, fork_github_repo, shell_script_odoo.
The name had been taken as dictated, without being checked against the
convention — the very check the rest of this work applies everywhere.
50 occurrences across 8 files. The TODO menu resolves the new path, the dry run
passes, and the 125 tests in the three touched files stay green.
Assisted-by: claude-opus-5
(cherry picked from commit 170ee61e50dfeff638c84c07eadac00c62526e4d)
Le défaut promettait dix étages qu'aucune machine ne tient. Une descente
complète par ligne, sur 28 cœurs :
étage 1 : 0 s d'amorçage, 200 s d'installation, 280 s en tout
étage 2 : 37 s, 344 s, 495 s
étage 3 : 93 s, 777 s, 1 064 s
étage 4 : 15 608 s, 26 306 s, n'a pas abouti
Trois étages coûtent une demi-heure. Le quatrième a coûté 4 h 20 d'amorçage et
7 h 18 d'installation sur la même machine : tout y est 15 à 30 fois plus lent,
pas une seule étape. C'est aussi là que les fabricants s'arrêtent — le
quatrième étage est le troisième hyperviseur imbriqué, AMD en documente deux.
La profondeur reste le seul paramètre, et le README dit désormais ce qu'on
achète en la montant.
--- EN ---
The default promised ten levels no machine can hold. One full descent per row,
on 28 cores:
level 1: 0 s boot, 200 s install, 280 s total
level 2: 37 s, 344 s, 495 s
level 3: 93 s, 777 s, 1 064 s
level 4: 15 608 s, 26 306 s, did not finish
Three levels cost half an hour. The fourth cost 4 h 20 of boot and 7 h 18 of
install on the same machine: everything there is 15 to 30 times slower, not one
step. It is also where the vendors stop — level 4 is the third nested
hypervisor, and AMD documents two.
Depth remains the only parameter, and the README now says what raising it buys.
Assisted-by: claude-opus-5
(cherry picked from commit 226d6ffa3c664ba9e1a6dfdf48d52027b52eda23)
Amorçage du quatrième étage, mesuré sur deux descentes complètes : 1 664 s à
2 vCPU, 15 608 s à 3. Un seul vCPU de plus, ×9,4. Aux étages 2 et 3 le même
vCPU ne coûte RIEN — ssh en 37 s et 93 s, comme à deux.
Le « gel » observé à 8 et 12 vCPU n'est probablement pas autre chose que cette
courbe poussée assez loin : 1 664 × 9,4 par vCPU dépasse vite toute patience,
et un RIP immobile à cinq minutes d'intervalle ne s'en distingue pas.
D'où un SEUIL de profondeur au lieu d'une largeur uniforme. Le troisième vCPU
reste aux étages 2 et 3, où il est gratuit et où il enlève le surengagement
qui affamait l'installation de l'étage 4 — celle-ci ne finissait pas avec un
parent à 2 vCPU, elle progresse avec un parent à 3. À partir du quatrième
étage, le strict minimum.
La combinaison ainsi obtenue — parent 3, enfant 2 — n'a jamais été mesurée :
les deux essais étaient (2, 2) et (3, 3).
--- EN ---
Fourth-level boot, measured on two full descents: 1,664 s at 2 vCPU, 15,608 s
at 3. One more vCPU, ×9.4. At levels 2 and 3 that same vCPU costs NOTHING —
ssh in 37 s and 93 s, same as at two.
The "freeze" seen at 8 and 12 vCPU is most likely nothing but this curve taken
far enough: 1,664 × 9.4 per vCPU quickly exceeds any patience, and a static
RIP five minutes apart is indistinguishable from it.
Hence a depth THRESHOLD instead of a uniform width. The third vCPU stays at
levels 2 and 3, where it is free and where it removes the overcommit that
starved level 4's install — which never finished with a 2-vCPU parent and does
progress with a 3-vCPU one. From the fourth level down, the strict minimum.
The resulting combination — parent 3, child 2 — has never been measured: the
two attempts were (2, 2) and (3, 3).
Assisted-by: claude-opus-5
(cherry picked from commit 9a5583a4b9461a087d161775764c560c82e0609e)
Ma propre conclusion de ce matin était fausse, et une mesure l'a réfutée.
J'avais écrit — code, README, commit — que le gel à 12 vCPU venait du
SURENGAGEMENT : cette VM avait douze vCPU sur un hôte qui en avait deux.
Descente réelle : l'étage 4 à huit vCPU, sur un parent qui en avait NEUF,
charge 1,47, aucun surengagement. Gelé pareil. 32 Mio lus en 106 minutes, même
RIP à trois relevés espacés de cinq minutes. C'est le nombre de vCPU de
l'invité imbriqué, et rien d'autre.
Le dimensionnement de bas en haut donnait 8 vCPU à l'étage 4, 7 au 5 : il
rendait larges précisément les étages qui doivent rester étroits. Trois
largeurs fixes le remplacent — métal, intermédiaire, fond. La mémoire et le
disque, eux, restent dimensionnés depuis le bas.
VCPU_INTERMEDIAIRE = 3 est une hypothèse assumée : deux démarre au quatrième
étage, huit gèle, rien n'est mesuré entre les deux.
--- EN ---
My own conclusion from this morning was wrong, and a measurement refuted it. I
had written — code, README, commit — that the 12-vCPU freeze came from
OVERCOMMIT: that VM had twelve vCPU on a host with two.
Real descent: level 4 at eight vCPU, on a parent with NINE, load 1.47, no
overcommit whatsoever. Frozen all the same. 32 MiB read in 106 minutes, same
RIP at three readings five minutes apart. It is the nested guest's vCPU count,
nothing else.
Bottom-up sizing gave level 4 eight vCPU and level 5 seven: it made wide
exactly the levels that must stay narrow. Three fixed widths replace it —
metal, intermediate, floor. Memory and disk stay sized from the bottom.
VCPU_INTERMEDIAIRE = 3 is an owned hypothesis: two boots at the fourth level,
eight freezes, nothing is measured in between.
Assisted-by: claude-opus-5
(cherry picked from commit ee45ff4f333c69e3862e277334cb34efa39bbd57)
Dernières trouvailles de la relecture, et la famille la plus tenace de ce
travail : une machine liée à ce qu'elle s'appelle plutôt qu'à ce qui
l'identifie.
« virsh undefine --remove-all-storage » partait sur le nom fixe deep-pve-1,
quel que soit le domaine qui le porte — la VM d'une descente précédente qu'on
voulait garder, ou une machine sans rapport. L'UUID est noté à la création et
vérifié avant de détruire ; un rapport ancien n'en a pas, on procède alors par
le nom faute de mieux, mais on le dit.
Le nom des étages imbriqués était de même déduit du numéro d'étage à la
RELECTURE. Un rapport écrit avant un changement de nom_etage aurait désigné
des machines qui ne sont pas les siennes. Il est écrit à la création.
Les deux meurent sous mutation. 52 tests dans ce fichier.
--- EN ---
Last findings from the review, and the most persistent family in this work: a
machine bound to what it is called rather than to what identifies it.
"virsh undefine --remove-all-storage" went by the fixed name deep-pve-1,
whatever domain carries it — a previous descent's VM one meant to keep, or an
unrelated machine. The UUID is recorded at creation and checked before
destroying; an older report has none, so we fall back to the name, and say so.
The nested levels' names were likewise derived from the level number at READ
time. A report written before a change to nom_etage would have named machines
that are not its own. It is now written at creation.
Both die under mutation. 52 tests in this file.
Assisted-by: claude-opus-5
(cherry picked from commit 93292653afb91351b0efa5700fcf66f6bb82604f)
Trois trouvailles de la relecture adversaire, toutes de la même famille : une
information qu'on possédait et qu'on jetait.
Le VMID ne remontait qu'au RETOUR de creer_enfant, qui enchaîne six commandes
sur le parent. Un échec à la quatrième — « qm resize » sur un stockage plein —
laissait une VM allumée et un disque alloué que le rapport ne nommait nulle
part : « --detruire » ne pouvait pas la défaire.
preparer_parent jetait le code de retour de ses lectures. Un « ip link show »
qui échoue se lisait « pas de pont », et de là on POSAIT un pont et un NAT sur
une machine qui en avait déjà un. Pour une lecture, le code de retour est la
seule chose qui distingue « j'ai lu, il n'y a rien » de « je n'ai pas pu lire ».
reparer_pmxcfs jetait le journal des unités PVE, que pve_unit_cmd joint exprès
à un échec. Il ne restait qu'un « /etc/pve : ABSENT » sans cause, à chercher
sur un hyperviseur mesuré 36 fois plus lent que son hôte.
Les trois meurent sous mutation, chacune avec son contrôle négatif.
--- EN ---
Three findings from the adversarial review, all the same family: information
we already held and threw away.
The VMID only surfaced on creer_enfant's RETURN, and that function chains six
commands on the parent. A failure at the fourth — "qm resize" on a full
storage — left a running VM and an allocated disk that the report named
nowhere: "--detruire" could not undo it.
preparer_parent discarded its reads' exit codes. An "ip link show" that fails
read as "no bridge", and from there we CREATED a bridge and a NAT on a machine
that already had one. For a read, the exit code is the only thing separating
"I read it, there is nothing" from "I could not read".
reparer_pmxcfs discarded the PVE units' journal, which pve_unit_cmd attaches
to a failure on purpose. All that remained was "/etc/pve : ABSENT" with no
cause, to be hunted on a hypervisor measured 36 times slower than its host.
All three die under mutation, each with its negative control.
Assisted-by: claude-opus-5
(cherry picked from commit 4c0279665e590169c23c4629e69ad945c4ae3fe4)
Incident sur une descente réelle : un agent de relecture, chargé de vérifier
ce que redemarrer_et_verifier PROUVE, l'a appelé sur l'étage 1 vivant. Le
reboot a éteint les étages 2, 3 et 4 d'un coup. La descente a alors attendu
son délai entier — quarante minutes — un ssh qui ne pouvait plus aboutir, puis
a conclu « jamais joignable ». L'attente surveille désormais la MAISON.
Le décompte de la destruction mentait dans l'autre sens : les étages
injoignables étaient annoncés « il reste des machines » alors que le disque de
l'étage 1, effacé, les contenait. Les entrées ~/.ssh/config sont retirées
aussi, sinon leur ProxyJump désigne un hôte disparu.
Et « arret » nommait la RAM quand le vCPU bornait : la chaîne était figée en
ram > disque > vcpu et évaluée à la profondeur demandée. Il nomme maintenant
le plus bas des trois plafonds, et les trois sont affichés.
--- EN ---
Incident on a real descent: a review agent, tasked with checking what
redemarrer_et_verifier PROVES, called it on the living level 1. The reboot
took levels 2, 3 and 4 down at once. The descent then waited its whole
timeout — forty minutes — for an ssh that could no longer land, and concluded
"never reachable". The wait now watches the HOUSE.
The destroy count lied the other way: unreachable levels were reported as "il
reste des machines" when level 1's erased disk contained them. The
~/.ssh/config entries are removed too, else their ProxyJump names a host that
is gone.
And "arret" named RAM when vCPU was the bound: the chain was frozen as
ram > disque > vcpu and evaluated at the requested depth. It now names the
lowest of the three ceilings, and all three are shown.
Assisted-by: claude-opus-5
(cherry picked from commit 2d84b62bdd9907e9a30383774015bcb1ae379de1)
Relecture adversaire du commit précédent : il avait CRÉÉ un danger. Le rapport
s'écrivant maintenant VM par VM, celui de la descente EN COURS est le plus
récent, et « --detruire » l'aurait choisi — qm destroy --purge sur l'arbre que
le processus installait encore. Deux garde-fous : un PID dans le rapport, et
un refus net tant qu'un autre deep_proxmox.py tourne. Le second est nécessaire
car une descente déjà lancée a l'ancien module en mémoire.
Reconnu par ARGUMENT, pas par sous-chaîne : mon propre « pgrep -f
deep_proxmox.py » de surveillance donnait deux faux positifs sur trois.
Trois autres, mêmes preuves :
- un rapport vide plus récent masquait celui qui nommait les VM réelles ;
- detruire() ne créditait jamais l'étage 1 : le décompte était décalé de un
dans tous les cas, donc l'avertissement sortait toujours ;
- _ssh_config_drop_hosts prenait l'indentation pour de la syntaxe. Sur un bloc
au corps non indenté, seule la ligne Host partait et ssh rattachait
« StrictHostKeyChecking no » au bloc précédent — un serveur de production.
Et un bloc partagé (« Host prod-db vm-a ») partait en entier.
Les cinq correctifs meurent sous mutation.
--- EN ---
Adversarial review of the previous commit: it had CREATED a hazard. With the
report now written VM by VM, the RUNNING descent's is the most recent, and
"--detruire" would have picked it — qm destroy --purge on the tree the process
was still installing. Two guards: a PID in the report, and a flat refusal
while another deep_proxmox.py runs. The second is needed because an
already-running descent holds the old module in memory.
Matched by ARGUMENT, not substring: my own monitoring "pgrep -f
deep_proxmox.py" produced two false positives out of three.
Three more, same evidence:
- a newer empty report masked the one naming the real VMs;
- detruire() never credited level 1: the count was off by one in every case,
so the warning always fired;
- _ssh_config_drop_hosts took indentation for syntax. On a block with an
unindented body only the Host line went, and ssh attached
"StrictHostKeyChecking no" to the preceding block — a production server.
And a shared block ("Host prod-db vm-a") went entirely.
All five fixes die under mutation.
Assisted-by: claude-opus-5
(cherry picked from commit 7d348d976f96e420b4fec4d879911b658a730ffa)
Descente de dix étages arrêtée pendant l'installation du quatrième : quatre
machines réelles restaient, et « --detruire » répondait « aucun rapport : rien
à défaire ». Le rapport ne s'écrivait qu'à la fin, donc le seul enregistrement
du couple (alias du parent, VMID) mourait avec le processus. Il fallait les
retrouver par leur NOM, ce que tout ce fichier s'applique à éviter.
En nettoyant à la main, second défaut : appelé sans nom à écrire — un retrait
pur, légitime, les machines n'existant plus — _write_ssh_config_entry écrivait
« Host » NU suivi d'un « HostName » vide dans le ~/.ssh/config réel, puis
mourait sur IndexError en annonçant l'ajout. Constaté, puis retiré du fichier.
Les deux correctifs meurent sous mutation : 3 tests et 2 tests.
--- EN ---
A ten-level descent stopped during the fourth level's install: four real
machines were left, and "--detruire" answered "no report: nothing to undo".
The report was only written at the end, so the sole record of the (parent
alias, VMID) pair died with the process. They had to be found by NAME, which
this whole file works to avoid.
Cleaning up by hand surfaced a second defect: called with no name to write — a
pure removal, legitimate since the machines are gone — _write_ssh_config_entry
wrote a BARE "Host" followed by an empty "HostName" into the real ~/.ssh/config,
then died on IndexError while announcing the addition. Observed, then removed.
Both fixes die under mutation: 3 tests and 2 tests.
Assisted-by: claude-opus-5
(cherry picked from commit e7c8b540c630b33c6eb1b1a2f51c01497e0b3ca0)
Le plan cédait à l'enfant ce que le parent pouvait céder. Descente réelle à
dix étages : l'étage 4 a reçu 44 Go et 2 vCPU sur un hôte qui en avait 2 —
cent pour cent de surengagement, à chaque étage. Son installation dure 2 h 52
et n'est pas finie, contre 793 s pour l'étage 3. Extrapolé, le dixième
demandait des années.
Le plus profond reçoit désormais ce qu'un Proxmox de test demande, et chaque
parent ajoute son seul surcoût : un vCPU, 2 Gio, 10 Go. Dix étages tiennent
sur 11 vCPU et 22 Go au premier, contre 50 Go avant.
Corrige aussi l'explication du gel à 12 vCPU : cette VM avait douze vCPU sur
un hôte qui en avait deux. C'est le surengagement qui gèle, pas le douze.
--- EN ---
The plan handed the child whatever the parent could spare. Real ten-level
descent: level 4 got 44 GB and 2 vCPU on a host that had 2 — a hundred
percent overcommit, at every level. Its install has run 2h52 and is not done,
against 793 s for level 3. Extrapolated, the tenth wanted years.
The deepest level now gets what a test Proxmox asks for, and each parent adds
its own overhead only: one vCPU, 2 GiB, 10 GB. Ten levels fit in 11 vCPU and
22 GB at the first, against 50 GB before.
Also corrects the account of the 12-vCPU freeze: that VM had twelve vCPU on a
host with two. Overcommit freezes, not the twelve.
Assisted-by: claude-opus-5
(cherry picked from commit 7cda84bf391ee3ed36c5953ca4b86df44bd09e3b)
La doc et l'en-tête de l'algorithme affirmaient qu'au quatrième étage le noyau
invité gelait « au même octet quelles que soient les ressources ». Lancer la
descente l'a réfuté : son propre quatrième étage, à 2 vCPU, a démarré, s'est
installé, et a écrit des gigaoctets. La VM examinée à la main en avait douze.
Ce n'était donc pas un plafond d'imbrication mais un plafond de PARALLÉLISME
sous imbrication — précisément ce que l'algorithme borne, et qui cesse ainsi
d'être une supposition.
Le « même octet », par ailleurs, ne voulait rien dire de ce qu'on lui faisait
dire : 33 682 432 octets, c'est 32 Mio, la taille des fichiers d'amorçage.
Retirer de la mémoire ne le déplaçait pas parce qu'il ne dépendait pas de la
mémoire, pas parce qu'un mur absolu s'y trouvait. La conclusion — ne pas
borner la RAM — reste juste ; sa justification était fausse.
Une affirmation fausse dans la documentation est pire que pas de
documentation : elle décide à la place du lecteur. Les deux passages disent
maintenant ce qui a été mesuré, sur quoi, et ce que la descente a montré
ensuite.
--- EN ---
The documentation and the algorithm's header claimed that at the fourth level
the guest kernel froze "at the same byte whatever the resources". Running the
descent refuted it: its own fourth level, at 2 vCPU, booted, installed, and
wrote gigabytes. The VM examined by hand had twelve.
So it was not a nesting ceiling but a PARALLELISM ceiling under nesting —
exactly what the algorithm caps, which thereby stops being a guess.
The "same byte", moreover, did not mean what it was made to mean: 33,682,432
bytes is 32 MiB, the size of the boot files. Removing memory did not move it
because it did not depend on memory, not because an absolute wall sat there.
The conclusion — do not cap RAM — still holds; its justification was wrong.
A false claim in documentation is worse than no documentation: it decides in
the reader's place. Both passages now say what was measured, on what, and what
the descent showed afterwards.
Assisted-by: Claude Opus 5
(cherry picked from commit b8c53eaf104f6891703e71b540c76ffd5994a2cb)
Trois pannes trouvées en LANÇANT la descente, aucune vue en la relisant — ni
par moi, ni par l'attaque adversariale.
Le premier « apt update » d'une image cloud échoue sur un verrou qui n'est pas
celui qu'on croit. Mesuré une seconde après le premier ssh :
E: Could not get lock /var/lib/apt/lists/lock.
It is held by process 1026 (apt-get)
Ce n'est pas cloud-init — « status --wait » avait rendu la main. C'est
apt-daily, le minuteur de Debian, qui se déclenche au démarrage. Et le verrou
des LISTES n'est pas couvert par « DPkg::Lock::Timeout », que l'installeur
réglait pourtant déjà à 600 s : cette attente ne vaut que pour dpkg. On arrête
donc les minuteurs, puis on RÉESSAIE — arrêter une unité n'interrompt pas
l'apt-get déjà en vol. Le défaut touchait tout déploiement Proxmox, pas
seulement ce test.
Le premier étage n'avait pas d'alias ssh. « deploy_qemu.py » en ligne de
commande n'écrit pas d'entrée ~/.ssh/config — le menu le fait, la CLI non. La
descente aurait attendu son plein délai avant de conclure « jamais joignable »
sur une VM qui répondait à son adresse. Elle l'écrit maintenant elle-même,
depuis l'adresse résolue, et refuse d'avancer si la VM n'en a pas.
Et la réserve de l'hôte est proportionnelle. Quatre gigaoctets sur une machine
de soixante, c'était 6 % laissés au système : le jour où les invités touchent
vraiment leur mémoire, c'est l'hôte qui part en swap — et la mesure serait
celle du swap, pas de l'imbrication. Un huitième, avec le plancher d'avant
pour les petites machines.
Ce que la descente a établi en trois étages : 392 s, 644 s, 1120 s, soit 1,7
fois par étage. Puis la poignée de main ssh passe de 77 à 1664 secondes au
quatrième — vingt fois d'un seul cran. Le coude est là.
Et le mur que j'avais pris pour une limite d'imbrication n'en était pas une.
La VM qui gelait au quatrième étage avait douze vCPU ; celle-ci en a deux et
elle passe, en écrivant. C'était une limite de parallélisme SOUS imbrication —
exactement ce que l'algorithme borne, vérifié pour la première fois plutôt que
supposé.
--- EN ---
Three faults found by RUNNING the descent, none seen by reading it — neither
by me nor by the adversarial attack.
A cloud image's first "apt update" fails on a lock that is not the one you
expect. Measured one second after the first ssh:
E: Could not get lock /var/lib/apt/lists/lock.
It is held by process 1026 (apt-get)
It is not cloud-init — "status --wait" had returned. It is apt-daily, Debian's
timer, firing at boot. And the LISTS lock is not covered by
"DPkg::Lock::Timeout", which the installer already set to 600 s: that wait
only applies to dpkg. So we stop the timers, then RETRY — stopping a unit does
not interrupt the apt-get already in flight. The defect affected every Proxmox
deployment, not just this test.
The first level had no ssh alias. "deploy_qemu.py" on the command line does not
write a ~/.ssh/config entry — the menu does, the CLI does not. The descent
would have waited its full timeout before concluding "never reachable" about a
VM answering at its address. It now writes the entry itself, from the resolved
address, and refuses to proceed if the VM has none.
And the host's reserve is proportional. Four gigabytes on a sixty-gigabyte
machine left 6 % to the system: the day the guests really touch their memory,
the host swaps — and the measurement would be of swap, not of nesting. One
eighth now, keeping the old floor for small machines.
What the descent established over three levels: 392 s, 644 s, 1120 s — 1.7x per
level. Then the ssh handshake goes from 77 to 1664 seconds at the fourth:
twenty times in one step. That is the elbow.
And the wall I had taken for a nesting limit was not one. The VM that froze at
the fourth level had twelve vCPU; this one has two and it gets through,
writing. It was a limit of parallelism UNDER nesting — exactly what the
algorithm caps, verified for the first time rather than assumed.
Assisted-by: Claude Opus 5
(cherry picked from commit 7f86562cbd8f10017dcb88fe4272efc162cbccbc)
Attaqué par trois lentilles sur le code écrit, avant de le lancer pour de
vrai. Deux fautes valaient à elles seules l'exercice.
Il n'aurait JAMAIS fonctionné. L'installeur était lancé par « sh », or il
porte « set -euo pipefail » et un shebang bash : sur Debian /bin/sh est dash,
qui répond « set: Illegal option -o pipefail » et sort à la PREMIÈRE ligne.
Chaque étage aurait échoué sur l'installation, à tous les coups.
Et « --detruire » pouvait emporter une machine étrangère. Il prenait toute
entrée ssh dont le nom CONTENAIT « deep-pve », puis sur son rebond détruisait
toute VM dont le nom contenait « deep-pve » — une « deep-pve-lab » de
production tombait dedans, et « --purge » emporte les disques. Son tri « du
plus profond au plus haut » comptait les « + » de l'alias, or alias_etage
remplace le « + » du parent par un « - » : chaque alias en portait exactement
UN, le tri ne triait rien, et la destruction partait du plus HAUT — le disque
du parent emportait ses enfants sans qu'on les ait nommés. Il ignorait
« --dry-run », ne lisait aucun code de retour, concluait « ✓ défait », et le
menu le lançait d'une touche.
Il ne détruit plus que ce que le RAPPORT nomme : un couple (parent, VMID) par
étage, du plus profond d'après le niveau lu, égalité stricte du nom, arrêt
CONSTATÉ avant destruction, codes de retour lus, et une confirmation par
« OUI » après la liste.
Six autres constats, tous réels. Le redémarrage se prouve par btime et non par
le seul noyau — rejoué sur un étage déjà installé, on validait un redémarrage
qui n'avait pas eu lieu, exactement le piège corrigé la semaine dernière dans
le suivi. La sonde de disponibilité ne demande plus sudo, sinon un sudo lent
se lisait « jamais joignable en ssh ». Les délais suivent la profondeur : le
script existe pour mesurer un ralentissement de 36x, et un plafond fixe
déclarait échouée une installation qui avançait. L'adresse fixe est contrôlée
AVANT de télécharger une image et de démarrer une VM. Le DNS de l'hôte suit la
spec, sinon apt meurt sans rien expliquer. Et l'essai à blanc ne prétend plus
avoir atteint quoi que ce soit — son rapport était indiscernable d'une
réussite, JSON compris.
L'algorithme aussi : profondeur 0 rendait un plan d'UN étage, donc
« --depth 0 » créait une VM ; et sur un hôte de quatre cœurs le premier étage
recevait UN vCPU quand son invité en recevait deux — un parent plus étroit que
son enfant.
Les tests mordent, prouvé par mutation : remplacer le calcul du premier étage
par la valeur imbriquée les laissait verts.
--- EN ---
Attacked by three lenses on the written code, before running it for real. Two
faults alone justified the exercise.
It would NEVER have worked. The installer was run by "sh", yet it carries "set
-euo pipefail" and a bash shebang: on Debian /bin/sh is dash, which answers
"set: Illegal option -o pipefail" and exits on the FIRST line. Every level
would have failed at install, every time.
And "--detruire" could take a stranger's machine. It took every ssh entry
whose name CONTAINED "deep-pve", then on its jump host destroyed every VM
whose name contained "deep-pve" — a production "deep-pve-lab" fell in, and
"--purge" takes the disks. Its "deepest first" sort counted the "+" in the
alias, yet alias_etage replaces the parent's "+" with a "-": every alias had
exactly ONE, the sort sorted nothing, and destruction started from the TOP —
the parent's disk took its children with it, unnamed. It ignored "--dry-run",
read no return code, concluded "✓ done", and the menu fired it on one key.
It now destroys only what the REPORT names: a (parent, VMID) pair per level,
deepest first by the recorded level, strict name equality, shutdown VERIFIED
before destruction, return codes read, and a "OUI" confirmation after the
list.
Six more findings, all real. The reboot is proven by btime, not by the kernel
alone — replayed on an already-installed level, we validated a reboot that
never happened, exactly the trap fixed last week in the monitor. The liveness
probe no longer asks for sudo, or a slow sudo read as "never reachable by
ssh". Timeouts follow the depth: the script exists to measure a 36x slowdown,
and a fixed ceiling declared failed an install that was progressing. The
static address is checked BEFORE downloading an image and starting a VM. The
host's DNS follows the spec, or apt dies explaining nothing. And the dry run
no longer claims to have reached anything — its report was indistinguishable
from a success, JSON included.
The algorithm too: depth 0 returned a ONE-level plan, so "--depth 0" created a
VM; and on a four-core host the first level got ONE vCPU while its guest got
two — a parent narrower than its child.
The tests bite, proven by mutation: replacing the first level's computation
with the nested value left them green.
Assisted-by: Claude Opus 5
(cherry picked from commit 64b8e5063bd7f420cdeb27b88f94043190b5ecd4)
La profondeur d'imbrication praticable ne se déduit pas, elle se mesure. Une
mesure à la main a trouvé, au quatrième étage, un invité 36 fois plus lent que
le temps réel — 583 secondes d'horloge pour 16 secondes de temps invité,
chaque ligne d'ACPI prenant une seconde — puis un noyau gelé au MÊME octet
quelles que soient les ressources. Un chiffre obtenu une fois, sur une
machine, n'est pas un chiffre.
D'où trois choses.
L'algorithme, en fonctions pures. Deux ressources s'épuisent en descendant :
la mémoire, chaque étage gardant de quoi faire tourner ses propres démons, et
le disque, celui de l'enfant vivant DANS celui du parent. Une troisième se
dégrade, et elle borne le vCPU à deux au-delà du premier étage : douze ont
gelé le noyau invité, les mêmes deux avançaient. La mémoire n'est PAS bornée —
la même VM gelait au même octet avec 9 Go et avec 2 Go, donc la rogner ne
gagnerait rien et priverait l'étage du dessous. Le plan est annoncé avant
toute création, et jamais au-delà de ce qui tient.
Le garde-fou dans l'écran. Il lisait la capacité de l'HÔTE et l'offrait en
entier : sur un troisième étage à 14 cœurs, il a proposé 12 vCPU à une VM qui
n'a jamais démarré. Le nombre n'était pas absurde pour la machine ; il l'était
pour sa profondeur, que l'écran ignorait. Elle se compte maintenant sur la
chaîne de ProxyJump — un rebond par étage, et c'est nous qui écrivons ces
entrées.
Le test long, dans LongTest/ et non dans test/ : le lanceur unitaire doit
rester lançable en quelques secondes, partout, y compris sans virtualisation.
La descente est uniforme — créer, attendre le ssh, installer, redémarrer et
vérifier le noyau, remettre pmxcfs debout, contrôler le stockage — et s'arrête
au premier étage qui échoue en NOMMANT l'étape. Il envoie notre
install_proxmox.sh par scp plutôt que de laisser la VM cloner le dépôt : c'est
notre code qu'on éprouve, et un correctif absent du distant a fait revenir le
même défaut sur trois VM.
--- EN ---
The practicable nesting depth cannot be deduced, only measured. A manual
measurement found, at the fourth level, a guest 36 times slower than real time
— 583 seconds of wall clock for 16 seconds of guest time, each ACPI line
taking a second — then a kernel frozen at the SAME byte whatever the
resources. A number obtained once, on one machine, is not a number.
Hence three things.
The algorithm, in pure functions. Two resources run out going down: memory,
each level keeping what its own daemons need, and disk, the child's living
INSIDE the parent's. A third degrades, and it caps the vCPU at two beyond the
first level: twelve froze the guest kernel, the same two progressed. Memory is
NOT capped — the same VM froze at the same byte with 9 GB and with 2 GB, so
trimming it would gain nothing and starve the level below. The plan is
announced before anything is created, and never beyond what fits.
The guard in the screen. It read the HOST's capacity and offered all of it: on
a third level with 14 cores it proposed 12 vCPU to a VM that never booted. The
number was not absurd for the machine; it was for its depth, which the screen
did not know. It is now counted on the ProxyJump chain — one hop per level,
and we are the ones writing those entries.
The long test, in LongTest/ and not test/: the unit runner must stay runnable
in seconds, anywhere, including without virtualisation. The descent is uniform
— create, wait for ssh, install, reboot and check the kernel, bring pmxcfs
back, check the storage — and stops at the first level that fails, NAMING the
step. It sends our install_proxmox.sh over scp instead of letting the VM clone
the repository: it is our code being exercised, and a fix absent from the
remote made the same defect return on three VMs.
Assisted-by: Claude Opus 5
(cherry picked from commit 4f70c461330cac6f46783a60e0f33052a979fa23)
Le conseil « rejouer install_proxmox.sh sur l'hôte » ne pouvait PAS marcher :
la VM clone le dépôt distant, donc sa copie du script est celle du distant —
tant que le correctif n'y est pas, celle qui ne corrige rien. Trois hôtes de
suite sont tombés dessus, avec le même message inutile. L'écran répare donc :
gel de cloud-init, réécriture de /etc/hosts, relance des unités, constat du
montage — le pendant exact de l'offre de créer un pont.
Écrit, puis ATTAQUÉ par trois lentilles sur le code réel. Ce qu'elles ont
mesuré valait la peine.
/etc/hosts se réécrivait en DEUX écritures — « sed -i » puis « printf >> » —
alors que la docstring promettait l'inverse. Sed refusé et ajout réussi, la
ligne 127.0.1.1 survivait EN PREMIER et la nôtre s'ajoutait une fois par
tentative ; sed réussi et ajout refusé, l'hôte perdait l'entrée de son nom, et
chaque sudo y attendait ensuite le résolveur. C'est maintenant un fichier
complet bâti dans un temporaire, VÉRIFIÉ, puis recopié — « cat > » et non
« mv », qui remplacerait l'inode et perdrait mode et propriétaire.
Le contrôle final s'en remettait à « getent hosts », qui réussit via mDNS même
quand rien n'a été écrit — et acceptait les fe80:: que notre propre code
rejette. Il relit désormais ce qui a été écrit.
awk remplace sed pour filtrer : « print » émet un saut de ligne, donc un
/etc/hosts non terminé par un — cloud-init n'en met pas — est normalisé. Sans
ça notre ligne se collait à la précédente et le nom du nœud partait sur
l'adresse d'une autre machine.
Trois autres, du même acabit. Les dépendants de pmxcfs sont relancés eux
aussi : actifs pendant la panne, ils échouaient sur ipcc_send_rec, et les
laisser donnait une GUI en « communication failure » juste après notre ✓. Un
silence du lien n'est plus lu comme une absence de montage. Et l'adresse n'est
mise en cause que si pve-cluster a réellement démarré.
Les tests exécutent les commandes au lieu de les relire, bouchons capables
d'ÉCHOUER : écriture refusée, fichier sans saut de ligne final, tabulations,
start qui rate, montage qui disparaît pendant la reconfirmation. Prouvé par
mutation — trois HOSTS-KO changés en HOSTS-OK font rougir le test.
--- EN ---
The advice "replay install_proxmox.sh on the host" could NOT work: the VM
clones the remote, so its copy of the script is the remote's — while the fix
is not there, the one that fixes nothing. Three hosts in a row hit it with the
same useless message. So the screen repairs: freeze cloud-init, rewrite
/etc/hosts, restart the units, verify the mount — the exact counterpart of the
offer to create a bridge.
Written, then ATTACKED by three lenses on the real code. What they measured
was worth it.
/etc/hosts was rewritten in TWO writes — "sed -i" then "printf >>" — while the
docstring promised the opposite. Sed refused and append succeeded: the
127.0.1.1 line survived FIRST and ours was added once per attempt; sed
succeeded and append refused: the host lost its own name entry, and every sudo
then waited on the resolver. It is now a complete file built in a temporary,
VERIFIED, then copied over — "cat >" not "mv", which would replace the inode
and lose mode and owner.
The final check relied on "getent hosts", which succeeds via mDNS even when
nothing was written — and accepted the fe80:: our own code rejects. It now
re-reads what was written.
awk replaces sed for filtering: "print" emits a newline, so an /etc/hosts with
no final one — cloud-init omits it — gets normalised. Without that our line
glued onto the previous one and the node's name pointed at another machine's
address.
Three more of the same kind. pmxcfs's dependents are restarted too: active
throughout the outage, they failed on ipcc_send_rec, and leaving them gave a
GUI in "communication failure" right after our ✓. A silent link is no longer
read as a missing mount. And the address is only blamed if pve-cluster
actually started.
The tests execute the commands instead of reading them, with stubs able to
FAIL: refused write, file with no final newline, tabs, a start that fails, a
mount that vanishes during reconfirmation. Proven by mutation — three
HOSTS-KO turned into HOSTS-OK make the test go red.
Assisted-by: Claude Opus 5
(cherry picked from commit d4f9358c6cb562029cc2ca9eb478d80c6a0a19a4)
Une révision adversariale de la réparation à distance a rendu un constat que
ses TROIS lentilles — réseau, systemd, shell — ont trouvé indépendamment :
démarrer pve-firewall peut couper le ssh qui répare. Sa configuration vit dans
/var/lib/pve-cluster/config.db, donc elle est invisible tant que /etc/pve
n'est pas monté — c'est-à-dire exactement dans l'état qu'on répare. On
appliquerait des règles qu'on ne peut pas lire, sur la seule voie d'accès à la
machine.
Il n'est pas nécessaire au but : le stockage et le suivi demandent pve-cluster
et pvestatd, l'interface web pveproxy. Il repartira au prochain démarrage,
quand /etc/pve sera monté à temps. Le retirer de la liste coûte donc rien et
supprime le seul geste qui pouvait isoler un hôte.
Deux autres constats de la même révision, également réels.
Le gel de cloud-init gardait sur l'EXISTENCE du fichier. Or « printf … > » le
TRONQUE avant d'écrire : une coupure au mauvais moment laisse zéro octet, et
la garde annonce « déjà gelé » pour toujours. cloud-init continue de remettre
127.0.1.1 à chaque démarrage et le défaut redevient invisible — celui-là même
que ce code existe pour supprimer. La garde porte maintenant sur le CONTENU.
Et les adresses de lien-local passaient pour routables. Mesuré : « hostname
--ip-address » peut ne rendre QUE des fe80::, et une APIPA en 169.254 passait
le seul test « ne commence pas par 127. ». pmxcfs n'a alors rien
d'utilisable, mais le diagnostic concluait l'inverse et renvoyait vers
journalctl au lieu de /etc/hosts.
Enfin « la sonde n'a pas répondu » n'est plus lu comme « rien n'est monté » :
un dépassement de délai rend les mêmes vides, et on affirmait une cause qu'on
n'avait pas constatée.
--- EN ---
An adversarial review of the remote repair produced one finding all THREE of
its lenses — network, systemd, shell — reached independently: starting
pve-firewall can cut the ssh doing the repair. Its configuration lives in
/var/lib/pve-cluster/config.db, so it is invisible while /etc/pve is unmounted
— exactly the state being repaired. We would apply rules we cannot read, over
the machine's only way in.
It is not needed for the goal: storage and monitoring need pve-cluster and
pvestatd, the web interface pveproxy. It will come back at the next boot, when
/etc/pve mounts in time. Removing it from the list costs nothing and removes
the one gesture that could isolate a host.
Two more findings from the same review, equally real.
The cloud-init freeze guarded on the file's EXISTENCE. But "printf … >"
TRUNCATES before writing: an ill-timed cut leaves zero bytes, and the guard
then reports "already frozen" forever. cloud-init keeps putting 127.0.1.1 back
at every boot and the defect becomes invisible again — the very one this code
exists to remove. The guard now looks at the CONTENT.
And link-local addresses counted as routable. Measured: "hostname
--ip-address" can return ONLY fe80:: entries, and an APIPA 169.254 passed the
lone "does not start with 127." test. pmxcfs then has nothing usable, yet the
diagnosis concluded the opposite and pointed at journalctl instead of
/etc/hosts.
Finally "the probe did not answer" is no longer read as "nothing is mounted": a
timeout returns the same emptiness, and we were asserting a cause we had not
measured.
Assisted-by: Claude Opus 5
(cherry picked from commit fa9fb729d82e8d1a8e4fb549cc8061c7281b5dcb)
« Le problème est revenu » — alors qu'il était corrigé la veille. La VM ne
reçoit pas le checkout d'ici : elle CLONE la branche depuis le dépôt distant.
Tout ce qui tourne dedans — install_proxmox.sh, les scripts d'installation, le
Makefile — vient donc de là.
Vécu deux fois de suite. Le correctif de /etc/hosts était commité ici, absent
du distant : chaque VM déployée ensuite recevait l'ancien script, et le même
défaut revenait à l'identique. Rien ne le disait, et il a fallu comparer les
deux versions du fichier à la main pour comprendre. Soixante-et-onze commits
séparaient les deux.
L'écart est donc dit AVANT de déployer, là où l'on peut encore renoncer : le
nombre, les trois premiers sujets, et « git push ». Sur les deux voies, car
les deux clonent.
Une branche que le distant ne connaît pas n'est pas un écart — c'est une
question qui ne se pose pas. La dire quand même vaudrait un avertissement à
chaque déploiement d'une branche neuve.
--- EN ---
"The problem came back" — though it had been fixed the day before. The VM does
not receive this checkout: it CLONES the branch from the remote. Everything
that runs inside it — install_proxmox.sh, the install scripts, the Makefile —
comes from there.
Twice in a row. The /etc/hosts fix was committed here and absent from the
remote: every VM deployed afterwards got the old script, and the same defect
returned unchanged. Nothing said so, and it took comparing both versions of
the file by hand to understand. Seventy-one commits separated them.
The gap is therefore stated BEFORE deploying, where you can still back out:
the count, the first three subjects, and "git push". On both paths, since both
clone.
A branch the remote does not know is not a gap — it is a question that does
not arise. Saying it anyway would mean a warning on every deployment of a new
branch.
Assisted-by: Claude Opus 5
(cherry picked from commit de27be5e736eb6e9bd01efd292e01c3b2231f91a)
Une cause, deux symptômes. « /cluster/resources » est bâti par pvestatd ;
celui-ci arrêté, l'hôte rend quand même une entrée par VM, mais
SQUELETTIQUE — ni nom, ni mémoire, ni disque, et « status: unknown ». Le
relevé était indexé par NOM : l'entrée disparaissait donc, la VM passait pour
absente alors que l'hôte venait de la nommer, et trois tours plus tard 🗑.
Comme « effacée » est un état TERMINAL, la ligne comptait pour finie — d'où
« 1/1 terminées · 00:09 » sur une installation qui tournait.
Le relevé est maintenant indexé par VMID, seul identifiant unique d'un hôte
Proxmox, et la correspondance vers les noms se fait là où le manifeste est
sous les yeux. Une entrée squelettique reste donc une VM présente, avec ce que
l'hôte sait d'elle — sa taille occupée, que « du » donne par VMID.
Reste à savoir pourquoi pvestatd était mort. Son journal le dit mot pour mot :
« ipcc_send_rec failed: Connection refused » — pve-cluster absent, c'est-à-dire
la panne /etc/hosts d'hier. Tous les services de Proxmox avaient échoué
ensemble, et systemd n'y revient jamais seul. L'installation relançait le seul
pve-cluster ; elle relance désormais l'ensemble, pve-cluster d'abord puisqu'il
monte /etc/pve.
Vérifié sur l'hôte : pvestatd relancé, et les colonnes passent de « - - - » à
« 3.4G/4.0G, 2.3G/25G, 2.2G écrit ».
--- EN ---
One cause, two symptoms. "/cluster/resources" is built by pvestatd; with it
stopped the host still returns one entry per VM, but SKELETAL — no name, no
memory, no disk, and "status: unknown". Readings were indexed by NAME, so that
entry vanished, the VM looked absent although the host had just named it, and
three rounds later 🗑. Since "deleted" is a TERMINAL state the row counted as
finished — hence "1/1 done · 00:09" on a running install.
Readings are now indexed by VMID, a Proxmox host's only unique identifier, and
the mapping to names happens where the manifest is at hand. A skeletal entry
therefore stays a present VM, with whatever the host does know about it — its
used size, which "du" reports per VMID.
Why was pvestatd dead? Its journal says it verbatim: "ipcc_send_rec failed:
Connection refused" — no pve-cluster, that is yesterday's /etc/hosts fault. All
of Proxmox's services had failed together, and systemd never returns to them on
its own. The installer restarted pve-cluster alone; it now restarts the whole
set, pve-cluster first since it mounts /etc/pve.
Verified on the host: pvestatd restarted, and the columns go from "- - -" to
"3.4G/4.0G, 2.3G/25G, 2.2G written".
Assisted-by: Claude Opus 5
(cherry picked from commit 3fb85f66842d4b0e9d6ae6446691229b31ef725a)
Rapporté sur un Proxmox imbriqué. « pvesm » ne parle qu'à travers /etc/pve,
monté par pmxcfs ; pmxcfs à terre, la commande répond « Connection refused »,
la liste est vide, et l'écran s'arrête sur « aucun stockage » — trois étages
au-dessus du défaut.
pmxcfs ne démarrait pas parce que le nom d'hôte ne résolvait que vers
127.0.1.1, et il cherche une adresse ROUTABLE. L'installation corrige bien
/etc/hosts, mais l'image cloud règle « manage_etc_hosts: True » : cloud-init
le réécrit à CHAQUE démarrage. C'est le redémarrage désormais automatique qui
l'a révélé — l'installation corrigeait, le reboot amorçait le bon noyau, et
cloud-init défaisait la correction dans le même mouvement. Un fichier de
surcharge le gèle.
Deuxième geste manquant : systemd marque pve-cluster « failed » après cinq
essais rapprochés et n'y revient JAMAIS seul. Corriger /etc/hosts ne suffisait
donc pas ; l'installation relance l'unité et CONSTATE le montage plutôt que de
le supposer.
Et l'écran nomme maintenant la cause quand il n'a pas de stockage, plutôt que
de laisser chercher.
Un détail qui aurait fait un faux diagnostic : la sonde de montage
n'interroge pas storage.cfg. Ce fichier N'EXISTE PAS sur une installation
neuve — Proxmox se contente alors de ses stockages par défaut, et « local »
répond parfaitement. Vérifié sur l'hôte : /etc/pve monté, storage.cfg absent,
« pvesm status » rendant local avec 25 Go libres. C'est « .version », fichier
virtuel de pmxcfs, qui fait foi.
--- EN ---
Reported on a nested Proxmox. "pvesm" only speaks through /etc/pve, mounted by
pmxcfs; with pmxcfs down the command answers "Connection refused", the list is
empty, and the screen stops at "no storage" — three floors above the defect.
pmxcfs would not start because the hostname resolved only to 127.0.1.1, and it
needs a ROUTABLE address. The installer does fix /etc/hosts, but the cloud
image sets "manage_etc_hosts: True": cloud-init rewrites it at EVERY boot. The
now-automatic reboot is what revealed it — the install fixed it, the reboot
booted the right kernel, and cloud-init undid the fix in the same motion. An
override file freezes it.
Second missing step: systemd marks pve-cluster "failed" after five rapid
attempts and never returns to it on its own. Fixing /etc/hosts was therefore
not enough; the installer restarts the unit and VERIFIES the mount rather than
assuming it.
And the screen now names the cause when it has no storage, instead of leaving
you to hunt.
One detail that would have made a false diagnosis: the mount probe does not
ask for storage.cfg. That file DOES NOT EXIST on a fresh install — Proxmox
then uses its default storages, and "local" answers perfectly. Verified on the
host: /etc/pve mounted, storage.cfg absent, "pvesm status" returning local with
25 GB free. It is ".version", a pmxcfs virtual file, that tells the truth.
Assisted-by: Claude Opus 5
(cherry picked from commit 6212853048ba8154f2833744e45076d70bd33c72)
Un Proxmox dans un Proxmox hérite du réseau interne de son parent : la VM
vivait en 10.10.10.152, passerelle 10.10.10.1. Le pont interne, lui, avait son
adresse CODÉE EN DUR à 10.10.10.1/24. Lui demander de la poser sur son propre
pont, c'est prendre l'adresse de sa passerelle et rendre tout le /24 local. La
machine s'isole au milieu de la commande qui la configure : « ifup » n'a jamais
rendu la main, la VM ne répondait plus ni en ssh ni en ping.
Le réseau est donc CHOISI, d'après ce que l'hôte connaît déjà — ses adresses et
ses routes, car une route sans adresse locale suffit à créer le conflit, et la
route par défaut en est l'exemple exact. Le chevauchement se calcule sur les
réseaux et non sur les trois premiers octets : « 10.0.0.0/8 » écarte alors bien
tous les candidats en 10.x. Plus aucun libre ? On le dit, plutôt que d'en
écraser un — écraser, ici, c'est couper la seule voie d'accès.
Le repli « ifreload -a » s'en va aussi. Il rechargeait TOUTES les interfaces, y
compris celle qui porte la session, et sur une image cloud l'interface
principale est décrite ailleurs — ifupdown2 la descend sans la remonter. Le
repli monte maintenant le pont à la main, sans toucher à rien d'autre ; la
strophe le rend persistant. La règle de masquerading se teste avant de
s'ajouter, donc une reprise n'empile rien.
Le test d'origine interdisait « 2>/dev/null » sur toute la ligne pour que
l'erreur d'ifup reste lisible. L'intention est gardée, portée sur l'appel à
ifup seul : le repli, lui, sonde légitimement.
--- EN ---
Proxmox inside Proxmox inherits its parent's internal network: the VM lived at
10.10.10.152, gateway 10.10.10.1. The internal bridge had its address HARDCODED
to 10.10.10.1/24. Asking it to put that on its own bridge takes its gateway's
address and makes the whole /24 local. The machine isolates itself in the
middle of the command configuring it: "ifup" never returned, the VM answered
neither ssh nor ping.
The subnet is now CHOSEN from what the host already knows — its addresses and
its routes, since a route with no local address is enough to collide, and the
default route is exactly that case. Overlap is computed on networks rather than
on the first three octets, so "10.0.0.0/8" correctly rules out every 10.x
candidate. None left? We say so rather than overwrite one — overwriting here
means cutting the only way in.
The "ifreload -a" fallback goes too. It reloaded ALL interfaces, including the
one carrying the session, and on a cloud image the main interface is described
elsewhere — ifupdown2 takes it down without bringing it back. The fallback now
raises the bridge by hand, touching nothing else; the stanza makes it
persistent. The masquerade rule is checked before being added, so a retry piles
nothing up.
The original test banned "2>/dev/null" across the whole line so ifup's error
stayed readable. That intent is kept, narrowed to the ifup call itself: the
fallback legitimately probes.
Assisted-by: Claude Opus 5
(cherry picked from commit 57991b186cf891b0db6b7228fb626c4c1af317cd)
[REF] déploiement : par VM, l'anonymisation, et le redémarrage Proxmox
Douze commits pour finir. La branche, le profil et le type se choisissent
désormais par VM : ils étaient globaux, ce qui obligeait à tout basculer pour
en déployer une seule autrement.
L'anonymisation d'une copie arrive sans IA et sans rien casser — c'est la
contrainte qui a dicté la forme. Une copie de production sert à reproduire un
défaut, donc les identifiants doivent rester cohérents entre les tables même
une fois les noms remplacés.
Proxmox VE n'existe qu'après un redémarrage, et install_proxmox.sh s'arrête
avant : lancé par ssh, un reboot couperait sa session. Le redémarrage revient
donc à l'enveloppe de lancement, qui survit à celui de la VM, et le ✅ ne
s'écrit qu'après vérification du noyau. Le garde du pont NAT part avec, là où
la conséquence est plutôt qu'à la confirmation de l'hôte.
Le reste ferme des portes trouvées ouvertes, et le journal des modifications
rattrape les 67 commits qu'il ignorait.
--- EN ---
Twelve commits to finish. Branch, profile and type are now chosen per VM:
they were global, which meant switching everything to deploy a single one
differently.
Anonymising a copy arrives without AI and without breaking anything — that
constraint dictated the shape. A production copy exists to reproduce a
defect, so identifiers must stay consistent across tables even once the names
are replaced.
Proxmox VE only exists after a reboot, and install_proxmox.sh stops before
it: launched over ssh, a reboot would cut its session. The reboot therefore
moves to the launching wrapper, which survives the VM's, and the ✅ is written
only after the kernel is verified. The NAT-bridge guard moves with it, to
where the consequence is rather than to host confirmation.
The rest closes doors found open, and the changelog catches up on the 67
commits it had ignored.
Assisted-by: Claude Opus 5
Le journal ne disait rien de Proxmox, ni de l'anonymisation, ni de
l'éclatement de todo.py — soit l'essentiel de ce qui attend un merge dans
master. Une relecture de 67 commits ne devrait pas commencer par lire 67
commits.
Les entrées suivent les six segments du plan de merge : ce qui précède la
factorisation, la factorisation elle-même, l'écran Proxmox, les réparations
de migration, l'audit, et le choix par VM.
Une section Modifié apparaît, qui manquait à Non publié : un déplacement de
9 500 lignes n'est ni un ajout ni un correctif, et le classer ailleurs
aurait menti sur sa nature.
--- EN ---
The log said nothing of Proxmox, nor of the anonymisation, nor of todo.py
being split — that is most of what is waiting to be merged into master. A
review of 67 commits should not have to start by reading 67 commits.
The entries follow the six segments of the merge plan: what precedes the
split, the split itself, the Proxmox screen, the migration repairs, the
audit, and the per-VM choice.
A Changed section appears, which Unreleased lacked: moving 9 500 lines is
neither an addition nor a fix, and filing it elsewhere would have misstated
what it is.
Assisted-by: Claude Opus 5
Proxmox VE n'existe qu'après un redémarrage : tant que la VM tourne le noyau
de son image cloud, elle n'a aucun module netfilter — ni pont NAT, ni invité.
install_proxmox.sh pose le noyau puis s'arrête, à raison, car lancé par ssh un
reboot couperait sa session et ferait passer l'installation pour un échec. On
le découvrait donc des jours plus tard, en créant un pont.
Le redémarrage revient à l'enveloppe de lancement, qui tourne sur NOTRE
machine et survit à celui de la VM : installation, reboot, attente, puis
vérification du noyau. Le ✅ ne s'écrit qu'après, et il veut donc dire
« hyperviseur utilisable ».
Trois choix méritent d'être dits. On ne redémarre qu'après un SUCCÈS —
redémarrer après un échec effacerait la seule machine sur laquelle on pouvait
chercher. On n'attend pas que ssh « revienne » mais que « uname -r » porte le
motif attendu : sshd répond encore une seconde ou deux après l'ordre, et on
lirait l'ancien noyau en croyant avoir la réponse. Et l'absence du noyau
attendu est un vrai ÉCHEC, pas un avertissement.
Le shell est exécuté par les tests, ssh bouchonné, dans les quatre cas — dont
celui où les deux premières lectures rendent l'ancien noyau. Un garde qu'on ne
sait pas éprouver s'ouvre le jour où il casse.
La note du sommaire ne paraît plus que sans suivi, où rien ne redémarre :
réclamer un redémarrage déjà fait est une consigne fausse.
--- EN ---
Proxmox VE only exists after a reboot: while the VM runs its cloud image's
kernel it has no netfilter module — no NAT bridge, no guest.
install_proxmox.sh installs the kernel then stops, rightly, since run over ssh
a reboot would cut its own session and make the install look failed. So you
found out days later, when creating a bridge.
The reboot moves to the launch wrapper, which runs on OUR machine and survives
the VM's: install, reboot, wait, then verify the kernel. The ✅ is written only
after, and therefore means "usable hypervisor".
Three choices worth stating. We reboot only after SUCCESS — rebooting after a
failure would wipe the one machine you could investigate. We do not wait for
ssh to "come back" but for "uname -r" to carry the expected pattern: sshd
answers for another second or two after the order, and we would read the old
kernel believing we had the answer. And a missing expected kernel is a real
FAILURE, not a warning.
The shell is executed by the tests, ssh stubbed, in all four cases — including
the one where the first two reads return the old kernel. A guard you cannot
exercise opens the day it breaks.
The summary note now appears only without monitoring, where nothing reboots:
asking for a reboot already done is a false instruction.
Assisted-by: Claude Opus 5
« Table does not exist » : six lignes d'iptables et « code de retour 1 »,
après avoir déjà posé la strophe dans /etc/network/interfaces. Rien dans ce
bruit ne dit qu'il faut redémarrer.
L'hôte tournait le noyau cloud de Debian, qui est dépouillé de tout netfilter
— aucun module NAT, ni legacy ni nft. Et le cas n'a rien d'exotique : c'est
notre propre install_proxmox.sh qui le produit. Il pose le noyau Proxmox sans
redémarrer, à raison — lancé par ssh, un reboot couperait la session et ferait
passer l'installation pour un échec. Une Proxmox imbriquée fraîchement
installée est donc TOUJOURS dans cet état.
L'avertissement sur le noyau existait déjà, mais à la CONFIRMATION de l'hôte,
et l'hôte est ensuite mémorisé : on revient des jours plus tard créer un pont,
et plus personne ne rappelle rien. Le garde va donc là où la conséquence
tombe, et AVANT toute écriture. Il interroge la table NAT elle-même et non le
NOM du noyau — « -pve » est un indice, pas une preuve — puis nomme le noyau
en cours, celui qui est posé, et la commande qui règle l'affaire.
Le sommaire de déploiement le dit désormais aussi, tant qu'on lit encore
l'écran plutôt qu'au bout d'un journal d'une heure.
--- EN ---
"Table does not exist": six lines of iptables and "exit code 1", after the
stanza had already been written into /etc/network/interfaces. Nothing in that
noise says a reboot is needed.
The host was running Debian's cloud kernel, stripped of all netfilter — no NAT
module, legacy or nft. And the case is not exotic: our own install_proxmox.sh
produces it. It installs the Proxmox kernel without rebooting, rightly — run
over ssh, a reboot would cut the session and make the install look failed. A
freshly installed nested Proxmox is therefore ALWAYS in this state.
The kernel warning already existed, but at host CONFIRMATION, and the host is
then remembered: you come back days later to create a bridge and nothing
reminds you. So the guard moves to where the consequence lands, and BEFORE any
write. It asks the NAT table itself rather than the kernel's NAME — "-pve" is
a hint, not a proof — then names the running kernel, the installed one, and
the command that settles it.
The deployment summary now says it too, while the screen is still being read
rather than at the end of an hour-long log.
Assisted-by: Claude Opus 5
La VM Proxmox locale effacée, le nettoyage a retiré son entrée ssh — c'était
juste — et GARDÉ les trois entrées qui rebondissaient par elle, en les
annonçant « mènent encore quelque part ». Trois culs-de-sac, désignés comme
vivants.
Deux fautes. Un ProxyJump valait preuve de vie À LUI SEUL, au motif qu'il
désigne une VM imbriquée que virsh ne connaîtra jamais : le raisonnement
oubliait que le rebond, lui, peut avoir disparu. Et chaque entrée était jugée
ISOLÉMENT, alors que retirer le parent orpheline ses enfants — qui
orphelinent les leurs. D'où un point fixe, et non une passe.
Un rebond qu'on ne gère pas — hôte personnel, adresse, nom DNS — reste
supposé vivant : on n'efface pas sur une supposition. Mais un nom de NOTRE
nommage sans entrée et sans domaine ne mène nulle part, et c'est exactement
l'état qu'un nettoyage précédent laisse derrière lui.
La liste des orphelines dit maintenant POURQUOI. « Son rebond n'existe
plus : erplibre-proxmox-9 » est la seule chose qui permet de répondre non en
connaissance de cause.
--- EN ---
With the local Proxmox VM deleted, the cleanup removed its ssh entry — rightly
— and KEPT the three entries hopping through it, announcing them as "still
lead somewhere". Three dead ends, labelled alive.
Two defects. A ProxyJump counted as proof of life ON ITS OWN, on the grounds
that it names a nested VM virsh will never know: the reasoning forgot the jump
itself can be gone. And each entry was judged IN ISOLATION, while removing a
parent orphans its children — which orphan theirs. Hence a fixed point, not a
single pass.
A jump we do not manage — personal host, address, DNS name — stays presumed
alive: we do not delete on a guess. But a name of OUR OWN convention with no
entry and no domain leads nowhere, and that is exactly the state a previous
cleanup leaves behind.
The orphan list now says WHY. "Its jump host is gone: erplibre-proxmox-9" is
the only thing that lets you answer no knowingly.
Assisted-by: Claude Opus 5
Deuxième constat faux du même outil, et la même cause : un indicateur
jamais confronté à la vraie condition.
Le contrôle cherchait l'xmlid `product.list0`. Or la réparation laisse
Odoo créer « Par défaut » SANS le poser. Mesuré sur la migration qui
vient de tourner : une liste de prix bien présente, quatre modèles de
rapprochement recréés, et mon rapport annonçait toujours « absente ». Il
aurait signalé de même la base d'un client ayant créé la sienne à la
main.
On cherche donc une LIGNE dans product_pricelist, protégée par
to_regclass pour le cas où le module n'est pas installé.
--- EN ---
Second false finding from the same tool, and the same cause: a proxy
never checked against the real condition.
It looked for the xmlid `product.list0`. But the repair lets Odoo create
« Par défaut » WITHOUT setting it. Measured on the migration that just
ran: a pricelist plainly there, four reconciliation models recreated —
and my report still said "missing". It would have flagged a customer
database whose pricelist was made by hand just the same.
So we look for a ROW in product_pricelist, guarded by to_regclass in case
the module is not installed.
Assisted-by: Claude Opus 5
Des mots pris dans une liste, des nombres tirés entre 0 et 1000, écrits
en SQL. Aucun modèle, aucun réseau — un test le vérifie sur les imports.
Le difficile n'est pas de remplacer, c'est de savoir ce qu'on n'a PAS le
droit de toucher. Mesuré sur une base 18 réelle : 505 champs `selection`
sont stockés en varchar, 2693 many2one sont des entiers, 194 textes sont
des jsonb par langue, 301 contraintes d'unicité attendent une collision.
« Tous les champs string » n'existe pas ; on croise ir_model_fields,
pg_attribute et pg_constraint, et aucune des trois ne suffit seule.
Trois pièges ont été trouvés en LANÇANT l'outil, pas en le relisant :
PostgreSQL refuse d'indexer un ARRAY[...] sans parenthèses,
res_partner.credit_limit est un jsonb qu'Odoo appelle float, et
crm_lead.probability porte un CHECK qui interdit 1000. Chaque fois
l'écriture a échoué et la base est restée intacte : une seule
transaction, tout ou rien.
Preuve sur copie jetable : empreinte du schéma identique, 848 tables,
6495 contraintes, arch_db et xmlid intacts, lang et many2one inchangés —
seules les colonnes visées ont changé.
--- EN ---
Words from a list, numbers drawn between 0 and 1000, written in SQL. No
model, no network — a test checks that on the imports.
The hard part is not replacing, it is knowing what must NOT be touched.
Measured on a real 18 database: 505 `selection` fields are stored as
varchar, 2693 many2one are integers, 194 texts are per-language jsonb,
301 unique constraints await a collision. "All string fields" does not
exist; we cross ir_model_fields, pg_attribute and pg_constraint, and none
of the three is enough alone.
Three traps were found by RUNNING it, not by rereading it: PostgreSQL
refuses to subscript a bare ARRAY[...], res_partner.credit_limit is a
jsonb Odoo calls float, and crm_lead.probability has a CHECK forbidding
1000. Each time the write failed and the database stayed intact: one
transaction, all or nothing.
Proof on a throwaway copy: identical schema fingerprint, 848 tables, 6495
constraints, arch_db and xmlids intact, lang and many2one unchanged —
only the targeted columns changed.
Assisted-by: Claude Opus 5
Le nom chaîné devient systématique, mais les entrées écrites AVANT portent le
nom court — et rien ne les retirerait : elles ne déclarent pas le nom qu'on
écrit maintenant. Deux blocs mèneraient à la même machine, exactement ce
qu'on venait d'enlever.
Le ProxyJump tranche : un bloc qui rebondit par CET hôte est le nôtre, on le
retire. Celui d'une VM locale homonyme n'en a pas, et on n'y touche jamais ;
celui d'un autre hôte Proxmox non plus.
Le drapeau Odoo gagne son test au passage. Il tombait pour la même raison que
les colonnes vides — la sonde est le dernier maillon de la suite distante, et
un parc où une seule VM n'a pas d'Odoo, un hyperviseur imbriqué par exemple,
finit en échec. Vérifié sur les trois VM : l'hôte rend bien « ODOO » pour les
deux qui écoutent, et le navigateur répondait 303 pendant que la colonne
disait « — ».
--- EN ---
The chained name becomes systematic, but entries written BEFORE carry the
short one — and nothing would retire them: they do not declare the name we
now write. Two blocks would lead to the same machine, exactly what we had
just removed.
The ProxyJump decides: a block hopping through THIS host is ours, so it goes.
A local namesake's has none, and is never touched; another Proxmox host's
neither.
The Odoo flag gains its test along the way. It failed for the same reason as
the empty columns — the probe is the remote pipeline's last link, and a fleet
where a single VM has no Odoo, a nested hypervisor for instance, ends in
failure. Verified on all three VMs: the host does return "ODOO" for the two
that listen, and the browser answered 303 while the column said "—".
Assisted-by: Claude Opus 5
Sur trois VM d'un même Proxmox, une seule avait ses colonnes vides — et les
deux autres montraient les chiffres d'une AUTRE machine. Deux fautes, dont
une était le miroir d'un correctif précédent.
Le code de sortie de la suite distante est celui de son DERNIER maillon, la
sonde Odoo. Tant qu'Odoo n'écoute pas — c'est-à-dire pendant TOUTE
l'installation, précisément quand on regarde — la boucle finit en échec et le
relevé, parfait, était jeté. On avait corrigé l'erreur inverse, un code 0 pris
pour une réponse ; exiger 0 était la même faute retournée. Seule une liste de
ressources analysable prouve une réponse.
Pendant ce temps, « virsh domstats » indexe par NOM, et un nom se partage :
les deux VM qui avaient un homonyme LOCAL affichaient ses chiffres. Mesuré —
1,5 Gio de RAM sur 12 et 58 Gio de disque sur 65, quand la vraie tournait avec
3 Gio et 25. Les relevés locaux d'une VM qui vit ailleurs sont donc retirés
AVANT d'ajouter ceux de l'hôte : un hôte muet laisse la colonne VIDE, ce qui
est vrai. Une colonne vide se remarque ; une colonne juste et fausse, non.
L'alias enfin. Prendre le nom court quand il se trouvait libre donnait un parc
incohérent : sur ce même déploiement, deux VM ont reçu « hôte+vm » — leurs
noms étaient pris par des domaines locaux — et la troisième son nom court. Une
convention qui dépend de ce qui traîne dans le fichier n'est pas une
convention. Le nom chaîné est systématique.
--- EN ---
Of three VMs on one Proxmox, only one had empty columns — and the other two
showed ANOTHER machine's figures. Two defects, one the mirror of an earlier
fix.
A remote pipeline's exit code is its LAST link's, the Odoo probe. While Odoo
is not listening — that is, during the WHOLE install, exactly when you are
watching — the loop ends in failure and the reading, perfectly good, was
thrown away. We had fixed the opposite error, a 0 taken for an answer;
demanding 0 was the same mistake reversed. Only a parsable resource list
proves an answer.
Meanwhile "virsh domstats" indexes by NAME, and a name is shared: the two VMs
with a LOCAL namesake displayed its figures. Measured — 1.5 GiB of RAM out of
12 and 58 GiB of disk out of 65, while the real one ran on 3 GiB and 25. Local
readings for a VM that lives elsewhere are therefore dropped BEFORE the host's
are added: a silent host leaves the column EMPTY, which is true. An empty
column gets noticed; a plausible wrong one does not.
The alias, finally. Taking the short name while it happened to be free gave an
inconsistent fleet: in that same deployment two VMs got "host+vm" — their
names were held by local domains — and the third its short name. A convention
that depends on what happens to sit in the file is not a convention. The
chained name is now systematic.
Assisted-by: Claude Opus 5
Sur Proxmox on déploie le plus souvent un parc MIXTE — un hyperviseur
imbriqué à côté de VM ERPLibre. C'est exactement le cas où un réglage par
machine sert, et c'est le seul écran qui ne l'offrait pas : ses rangées
n'avaient ni branche, ni profil, ni type.
Les trois choix et leur gestionnaire — quatre-vingts lignes — rejoignent le
socle. Les dupliquer aurait remis en place le mécanisme de dérive qu'on vient
d'enlever. L'écran QEMU/KVM perd encore 130 lignes sans qu'un widget, un
modèle ou une spec ne bouge : ancien et nouveau montés dans le même
processus, mêmes rangées, mêmes valeurs après avoir changé une branche, un
type et un profil.
Le déploiement suit : il lisait la seule valeur commune alors que le plan
portait déjà le choix par rangée. Une seule VM qui s'écarte suffit à rendre
la carte nécessaire — « len(set) > 1 » ne l'aurait pas vu.
Un défaut trouvé par un test, pas à l'usage : l'écho du montage se
reconnaissait à sa commande, or quand la commande imposée par le système
n'est pas dans la liste proposée, la liste retombe au rang 0 — et l'écho de
ce rang 0 effaçait l'imposition. Un Proxmox imbriqué reprenait ERPLibre et
Odoo 18. L'écho se reconnaît maintenant au RANG affiché.
--- EN ---
On Proxmox you usually deploy a MIXED fleet — a nested hypervisor next to
ERPLibre VMs. That is exactly where a per-machine setting earns its keep, and
it was the only screen without one: its rows had no branch, no profile, no
type.
The three choices and their handler — eighty lines — move into the shared
foundation. Duplicating them would have restored the very drift mechanism we
just removed. The QEMU/KVM screen loses another 130 lines with no widget,
model or spec moving: old and new mounted in one process, same rows, same
values after changing a branch, a type and a profile.
The deployment follows: it read the single common value while the plan
already carried the per-row choice. One VM that differs is enough to require
the map — "len(set) > 1" would not have seen it.
One defect found by a test, not by use: the mount echo was recognised by its
command, yet when the command imposed by the guest OS is absent from the
offered list, the list falls back to index 0 — and that index-0 echo erased
the imposition. A nested Proxmox took ERPLibre and Odoo 18 back. The echo is
now recognised by the DISPLAYED index.
Assisted-by: Claude Opus 5
« ir_model_relation nomme une table absente » : 0 avant la migration, 68
après. Le profil idéal — et aucune conséquence.
Son unique consommateur, _module_data_uninstall dans
base/models/ir_model.py, teste sql.table_exists() AVANT de supprimer : la
ligne périmée est ignorée, puis effacée. J'écrivais « la prochaine mise à
jour de module tente de la modifier et échoue » : c'est faux.
Les 68 appartiennent de plus à des modules INSTALLÉS, et database_cleanup
ne touche que les désinstallés — la réparation désignée n'en aurait
réparé aucune.
Un constat sans conséquence et sans geste possible est du bruit, quelle
que soit la netteté du signal. Restent trois constats, tous réels.
--- EN ---
« ir_model_relation names a missing table »: 0 before the migration, 68
after. The ideal profile — and no consequence whatsoever.
Its only consumer, _module_data_uninstall in base/models/ir_model.py,
tests sql.table_exists() BEFORE dropping: the stale row is skipped, then
unlinked. I wrote "the next module update tries to alter it and fails":
that is false.
The 68 also belong to INSTALLED modules, and database_cleanup only
touches uninstalled ones — the repair I named would have fixed none.
A finding with no consequence and no possible action is noise, however
clean the signal. Three findings remain, all real.
Assisted-by: Claude Opus 5
Le tableau de bord se rouvre sur un manifeste passé — c'est fait pour, les
installations partent détachées. Mais un nom de domaine se réemploie et un
VMID libéré est RÉATTRIBUÉ : effacer « le 101 » d'un run de mars, c'est
effacer ce qui porte le 101 aujourd'hui, et « erplibre-ubuntu-2604 » de mars
n'est pas celui d'aujourd'hui. Même famille que tout le reste — on jugeait
sur le nom, avec ici la pire conséquence.
La commande porte donc son garde, et non l'écran : elle protège ainsi tous
ses appelants, et la vérification se fait SUR la machine, à l'instant
d'effacer. Sur Proxmox, le VMID doit encore porter ce nom. En local, l'UUID
du domaine — relevé au lancement, seul instant où l'on sait que ce nom
désigne bien cette machine-là. Un manifeste écrit avant ce correctif n'en a
pas : il retombe sur la protection d'avant plutôt que de bloquer.
Le garde du VMID est une fonction à part, exécutable telle quelle. Il
traverse deux « shlex.quote » avant d'atteindre un dash, et un garde qu'on ne
sait pas éprouver s'OUVRE le jour où il casse. Vérifié sur erplibre-proxmox-9
sans rien détruire : le VMID 100 refusé sous un nom périmé, accepté sous le
sien.
--- EN ---
The dashboard reopens on a past manifest — by design, since installs run
detached. But a domain name gets reused and a freed VMID is REASSIGNED:
deleting "the 101" from a March run deletes whatever holds 101 today, and
March's "erplibre-ubuntu-2604" is not today's. Same family as the rest — we
judged by name, here with the worst consequence.
The command carries its guard, not the screen: that protects every caller,
and the check happens ON the machine, at the moment of deletion. On Proxmox
the VMID must still bear that name. Locally, the domain's UUID — recorded at
launch, the only moment we know that name means that machine. A manifest
written before this fix has none: it falls back to the previous protection
rather than blocking.
The VMID guard is its own function, runnable as is. It crosses two
"shlex.quote" layers before reaching a dash, and a guard you cannot exercise
OPENS the day it breaks. Verified on erplibre-proxmox-9 without destroying
anything: VMID 100 refused under a stale name, accepted under its own.
Assisted-by: Claude Opus 5
[FIX] proxmox : l'audit, la bonne machine, et deux analyses
Seize commits dont la moitié vient d'un audit, pas de l'usage — six défauts
trouvés en relisant, et quatre écrans qui parlaient d'une machine locale
alors qu'ils pilotaient une machine distante. Même famille de faute :
l'installation partait sur la mauvaise machine, et le disque annoncé était
celui de l'hôte.
Le guide de connexion manquait à toute VM distante depuis le début : on
savait la déployer sans savoir y entrer.
Deux analyses arrivent : l'état d'une instance, lu pour l'usage qu'on en
fait, et l'auscultation d'une base qui n'est pas ici. Une troisième dit
désormais CE QUI est parti avec une pièce jointe, au lieu de compter.
Un socle commun décrit le système invité, là où chaque formulaire le
redécrivait.
--- EN ---
Sixteen commits, half of them from an audit rather than from use — six
defects found by reading, and four screens that spoke of a local machine
while driving a remote one. The same family of fault: the install went to
the wrong machine, and the disk it reported was the host's.
The connection guide had been missing from every remote VM from the start:
we knew how to deploy one without knowing how to get in.
Two analyses arrive: the state of an instance, read for what it is used
for, and the examination of a database that is not here. A third now says
WHAT left with an attachment, instead of counting.
One shared base describes the guest system, where each form used to
describe it again.
Assisted-by: Claude Opus 5
La confirmation de suppression promettait à TOUTE VM « son disque qcow2
EFFACÉ », puis nommait /var/lib/libvirt/images/<nom>.qcow2. Sur une VM
Proxmox ce fichier n'existe pas — au mieux, au pire c'est celui d'une autre
VM du même nom. C'est la peur exacte qui avait fait remonter le nettoyage.
Elle nomme désormais l'hôte, le VMID et « qm destroy ».
« Console de l'hyperviseur » lisait le port par « virsh vncdisplay ». Un
Proxmox n'a pas de libvirt : l'échec se lisait « écran fermé » et on
conseillait « sudo virsh edit » sur une machine sans ce binaire. Ce n'est pas
un écran fermé, c'est la mauvaise question — Proxmox sert le sien par un
ticket. Les deux vrais chemins sont nommés : la console série, l'interface
web par tunnel.
La colonne Odoo était un 🟢 acquis pour toujours : « Odoo ne redescend pas en
cours d'install » est faux — le service redémarre au moins une fois, et il
lui arrive de mourir. Elle est relue, gratuitement sur Proxmox, toutes les
trente secondes ailleurs. Un hôte muet reste distinct d'un Odoo tombé.
Enfin « Versions principales » (F7) manquait à l'écran Proxmox, qui affiche
pourtant le même catalogue. Les trois gestes du catalogue vivent maintenant
dans le socle du plan, où ils ne peuvent plus diverger.
--- EN ---
The delete confirmation promised EVERY VM "its qcow2 disk ERASED", then named
/var/lib/libvirt/images/<name>.qcow2. On a Proxmox VM that file does not
exist — at best; at worst it is another VM's, of the same name. That is the
very fear that surfaced the cleanup report. It now names the host, the VMID
and "qm destroy".
"Hypervisor console" read the port through "virsh vncdisplay". Proxmox has no
libvirt: the failure read as "screen closed" and we advised "sudo virsh edit"
on a machine without that binary. It is not a closed screen, it is the wrong
question — Proxmox serves its own by ticket. Both real paths are named: the
serial console, the web interface through a tunnel.
The Odoo column was a 🟢 acquired forever: "Odoo does not go back down during
the install" is false — the service restarts at least once, and it does die.
It is re-read, free on Proxmox, every thirty seconds elsewhere. A silent host
stays distinct from a dead Odoo.
Finally "Main versions" (F7) was missing from the Proxmox screen, which shows
the same catalog. The catalog's three gestures now live in the plan
foundation, where they can no longer diverge.
Assisted-by: Claude Opus 5
L'entrée portait deux noms sur sa ligne « Host » — le chaîné « hôte+vm » et
le court : « Host erplibre-proxmox-9+erplibre-arch-latest
erplibre-arch-latest ». Le second est un doublon dès que le premier suffit.
ssh n'a besoin que d'un nom ; le doubler n'ajoute qu'une façon de plus
d'écrire la même adresse. Rapporté.
Un seul, donc, et choisi : le nom court quand il est LIBRE, c'est celui qu'on
tape ; le chaîné quand il désignerait une autre machine — une VM locale
homonyme, ou la VM d'un autre hôte Proxmox. Ce qui a forcé le changement est
nommé à l'écran plutôt que laissé en surprise.
« Pris » se juge sur le ProxyJump du bloc et non sur sa seule présence. Le
test l'a montré avant l'usage : notre propre entrée, réécrite à chaque
déploiement, se prenait pour une rivale et le nom basculait d'une fois sur
l'autre.
--- EN ---
The entry carried two names on its "Host" line — the chained "host+vm" and
the short one: "Host erplibre-proxmox-9+erplibre-arch-latest
erplibre-arch-latest". The second is redundant as soon as the first is
enough. ssh needs one name; doubling it only adds another way to write the
same address. Reported.
One name then, and a chosen one: the short one while it is FREE, since that
is what you type; the chained one when it would point at another machine — a
local VM of the same name, or another Proxmox host's VM. Whatever forced the
change is named on screen rather than left as a surprise.
"Taken" is judged on the block's ProxyJump, not on its mere presence. The
test showed it before use: our own entry, rewritten at every deployment, took
itself for a rival and the name flipped from one run to the next.
Assisted-by: Claude Opus 5
fix_duplicate_index et restore_config_defaults étaient écrits, éprouvés,
et absents du pilote. Chaque migration refabriquait donc ses index
redondants et reperdait sa liste de prix.
Mesuré sur DEUX chaînes 12 → 18 indépendantes, même base source : 68
relations orphelines, 9 langues au drapeau NULL, une liste de prix
absente, 376 paires d'index en double — les mêmes nombres des deux côtés.
Ce n'est pas un accident d'exécution, c'est le chemin lui-même.
Les index à partir du palier 17 : avant, la convention n'a pas changé.
Les réglages au DERNIER palier : l'outil charge le registre, et seul
l'état final compte. Les deux en wait_at_error=False — avec --apply, le
code 1 dit « il en reste », pas « je suis tombé », et cela n'arrête pas
six paliers.
--- EN ---
fix_duplicate_index and restore_config_defaults were written, proven, and
absent from the driver. Every migration therefore rebuilt its redundant
indexes and lost its default pricelist again.
Measured on TWO independent 12 → 18 chains from the same source: 68
orphan relations, 9 languages with a NULL flag, one missing pricelist,
376 duplicate index pairs — the same numbers on both. Not a fluke of one
run: the path itself.
Indexes from step 17 onward: before that the convention had not changed.
Config defaults at the LAST step: the tool loads the registry, and only
the final state matters. Both with wait_at_error=False — with --apply,
exit 1 means "some remain", not "I crashed", and that must not halt six
steps.
Assisted-by: Claude Opus 5
Type de VM, production, magasin d'applications, outils de développement,
fuseau horaire, interpréteur Python : six réglages qui décrivent l'invité, pas
la machine qui le porte. Ils valaient donc déjà sur Proxmox — l'écran n'en
offrait que trois. Une VM créée là-bas naissait serveur nu, sans outils et en
UTC, et rien ne le disait.
La duplication était le mécanisme de la dérive : chaque correctif se posait
sur un seul des deux écrans. Les six vivent maintenant dans un socle commun,
widgets ET logique, et le contexte qui les nourrit est écrit une fois. L'écran
QEMU/KVM perd 330 lignes sans qu'un widget ni une valeur de spec ne bouge —
vérifié en montant l'ancien et le nouveau dans le même processus.
Trois conséquences se sont propagées seules : le disque annoncé (bureau et
outils compris) atteint enfin « qm resize », le parallélisme suit les cœurs de
l'hôte au lieu d'un plafond de quatre, et le nom prend le suffixe du bureau —
sans lui, une VM graphique et sa jumelle serveur se disputaient le même.
Deux défauts nommés au passage. Le fuseau : « qm set » n'en pose pas, il part
maintenant par ssh avant l'installation. Et l'architecture d'une VM Proxmox
venait de « virsh », qui ne connaît que les domaines d'ici — une VM ARM prise
pour x86_64 recevait Android Studio, que Google ne publie pas pour elle.
Le test porte sur la PARITÉ, pas sur six comportements : ajouter un réglage à
un seul écran le fait échouer. Il a d'abord échoué à se lancer — hors des
préfixes du lanceur, douze tests n'ont jamais tourné et le total n'avait pas
bougé. La règle de nommage est maintenant dans son en-tête.
--- EN ---
VM type, production, app store, development tools, timezone, Python
interpreter: six settings that describe the guest, not the machine hosting it.
They already applied to Proxmox — the screen offered three. A VM created there
was born a bare server, no tools, in UTC, and nothing said so.
Duplication was the mechanism of the drift: each fix landed on one screen
only. The six now live in a shared foundation, widgets AND logic, and the
context feeding them is written once. The QEMU/KVM screen loses 330 lines with
no widget and no spec value moving — verified by mounting the old and the new
in one process.
Three consequences followed on their own: the announced disk (desktop and
tools included) finally reaches "qm resize", parallelism follows the host's
cores instead of a cap of four, and the name takes the desktop suffix —
without it a graphical VM and its server twin fought over the same one.
Two defects named along the way. The timezone: "qm set" sets none, it now goes
over ssh before the install. And a Proxmox VM's architecture came from
"virsh", which only knows local domains — an ARM VM taken for x86_64 got
Android Studio, which Google does not publish for it.
The test covers PARITY, not six behaviours: adding a setting to one screen
alone fails it. It first failed to run at all — outside the runner's prefixes,
twelve tests never ran and the total had not moved. The naming rule is now in
its header.
Assisted-by: Claude Opus 5
Dans l'écran de choix, « Vues personnalisées » et « Champs x_ » arrivent
avec la leur, héritée du menu Analyse ; « Restant de migration » et
« État de l'instance » sortaient nues. Quatre lignes dont deux commencent
en retrait se lisent comme deux listes.
--- EN ---
In the chooser, « Customised views » and « x_ fields » carry theirs,
inherited from the Analyse menu; « Migration leftovers » and « State of
the instance » came out bare. Four lines where two start indented read as
two lists.
Assisted-by: Claude Opus 5
Le même chiffre veut dire deux choses opposées. Zéro cron actif est le
succès attendu d'une copie et une panne totale sur une production. Un
rapport qui ignore cela crie au loup sur ce qu'on vient de demander, et
l'on cesse de le lire. L'attente est donc déclarée, copy ou live, et
chaque contrôle dit ce qu'il juge sous l'une et sous l'autre.
Deux contrôles ont été ÉCARTÉS sous copy après mesure : sur la base 12
d'origine, jamais démarrée, 11 crons étaient déjà en retard et db_backup
déjà vide — notre propre update_prod_to_dev les efface. Les afficher en
rouge aurait été du bruit ; en vert, un mensonge. Ils sont montrés non
jugés, avec la raison.
Le code Python en base a été mesuré et abandonné : 132 actions serveur,
zéro citant un modèle inexistant, et les 3 « modèles sans table » sont
ir.autovacuum et deux autres modèles abstraits d'Odoo.
--- EN ---
The same number means two opposite things. Zero active cron is the
expected success of a copy and a total outage on production. A report
that ignores this cries wolf over what was just requested, and stops
being read. The expectation is therefore declared, copy or live, and each
check states what it judges under either.
Two checks were DROPPED under copy after measuring: on the untouched 12
source database, 11 crons were already late and db_backup already empty —
our own update_prod_to_dev deletes them. Red would have been noise; green
a lie. They are shown unjudged, with the reason.
In-database Python was measured and dropped: 132 server actions, none
naming a missing model, and the 3 "models without a table" are
ir.autovacuum and two other Odoo abstract models.
Assisted-by: Claude Opus 5
Trois autres chemins menaient au 🗑 sur un seul incident, et « effacée » gèle
la ligne pour de bon. Un « virsh list » en échec condamnait TOUT le parc
local. Un statut Proxmox hors des trois attendus — prelaunch, suspended,
internal-error — passait pour une disparition. Et le code de sortie de la
suite distante est celui de son DERNIER maillon : un pvesh en panne se lisait
« l'hôte a répondu sans elle ». Ce qui prouve une réponse, c'est désormais une
liste de ressources analysable.
Le plan annonçait « 25G » quand « qm resize » recevait 20 : la marge
d'ERPLibre se perdait en route, la VM naissait trop petite. « Changer l'état »
choisissait par NOM, or seul le VMID est unique sur un hôte — cocher une VM
en éteignait deux homonymes. L'entrée 13 volait son alias à une VM locale du
même nom. Enfin le déploiement par QUESTIONS avait vieilli seul : il partage
maintenant l'épilogue de l'écran, donc le guide, l'alias protégé, les colonnes
vivantes et le sommaire.
--- EN ---
Three more paths led to 🗑 on a single incident, and "deleted" freezes the row
for good. One failing "virsh list" condemned the WHOLE local fleet. A Proxmox
status outside the three expected ones — prelaunch, suspended, internal-error
— passed for a disappearance. And a remote pipeline's exit code is its LAST
link's: a broken pvesh read as "the host answered without it". Proof of an
answer is now a parsable resource list.
The plan announced "25G" while "qm resize" got 20: ERPLibre's margin was lost
on the way and the VM was born too small. "Change state" selected by NAME,
yet only the VMID is unique on a host — ticking one VM shut down two
namesakes. Menu entry 13 stole its alias from a local VM of the same name.
Finally the QUESTION-driven deployment had aged alone: it now shares the
screen's epilogue — guide, protected alias, live columns and summary.
Assisted-by: Claude Opus 5
Rapporté sur Arch : « pas l'écran de connexion, avec le guide qui dit de
prendre pacman, comme sur ubuntu ». Ce n'était pas Arch — c'était Proxmox.
La voie libvirt livre /etc/motd par le « write_files » de cloud-init, et
« qm set » n'offre pas cela : AUCUNE VM déployée sur un hôte Proxmox n'avait
de guide, quelle que soit sa distribution.
Une troisième voie de livraison, par ssh une fois la VM debout, avec la MÊME
source — « guide_files », qui connaissait déjà pacman. Le guide n'annonce le
dépôt que s'il y sera : un guide qui promet ce qui n'existe pas est pire que
pas de guide. Écrit sur la VM Arch de l'utilisateur pour le vérifier.
--- EN ---
Reported on Arch: "no login screen, with the guide telling you to use pacman,
like on ubuntu". It was not Arch — it was Proxmox. The libvirt path delivers
/etc/motd through cloud-init's "write_files", and "qm set" offers no such
thing: NO VM deployed on a Proxmox host had a guide, whatever its distro.
A third delivery path, over ssh once the VM is up, from the SAME source —
"guide_files", which already knew pacman. The guide only announces the
repository if it will be there: a guide promising what does not exist is worse
than none. Written onto the user's Arch VM to check it.
Assisted-by: Claude Opus 5
Rapporté : une VM Arch à peine déployée sur Proxmox s'affichait 🗑 dès le
premier tour. « Effacée » est un état TERMINAL — la ligne gèle et ne revient
jamais — et il se déduisait d'UN relevé manquant. Or l'hôte peut être occupé,
la VM en train de naître, le relevé en cache d'avant sa création. On distingue
désormais « l'hôte n'a pas répondu » (on ne sait rien) de « l'hôte a répondu
sans elle » (on compte, trois fois), et la case part de « - » plutôt que d'un
sablier qui affirmerait qu'on attend quelque chose.
L'écran Proxmox n'offrait pas le choix de l'interpréteur Python : il envoyait
donc toujours « automatique », et comme mise n'est jamais installé d'office,
c'était pyenv — qui COMPILE Python depuis le tar.xz. Le choix existe
maintenant des deux côtés, avec le même garde-fou : rien n'est imposé quand
aucune architecture retenue n'est servie par mise.
--- EN ---
Reported: an Arch VM barely deployed on Proxmox showed 🗑 on the very first
pass. "Deleted" is a TERMINAL state — the row freezes and never comes back —
and it was inferred from ONE missing reading. Yet the host may be busy, the VM
may be starting, the reading may be cached from before it existed. We now tell
"the host did not answer" (we know nothing) from "the host answered without
it" (count, three times), and the cell starts at "-" rather than an hourglass
claiming we await something.
The Proxmox screen offered no Python interpreter choice: it therefore always
sent "automatic", and since mise is never installed by default, that meant
pyenv — which COMPILES Python from the tar.xz. The choice now exists on both
sides, with the same guard: nothing is imposed when no selected architecture
is served by mise.
Assisted-by: Claude Opus 5
Les analyses existaient ; le chemin d'AVANT manquait. La base d'un client
est dans un zip, derrière une URL, ou vivante sur un serveur.
« Restant de migration » a dû être écrit : check_migration_quality compare
les bases de PALIER et exige le journal de progression — devant une
sauvegarde isolée, ni l'un ni l'autre n'existe.
Ses compteurs évidents ont été écartés après mesure. Comparés à la base
d'ORIGINE : champs sans colonne 25 → 72, modèles sans table 90 → 158.
Vingt-cinq et quatre-vingt-dix AVANT toute migration : du bruit. Ne
restent que les constats faux en eux-mêmes, 0 avant, non nuls après —
9 langues au drapeau NULL, 68 tables m2m absentes, 414 index doublés.
Le passe-plat RPC n'accepte que la lecture. psql l'obtient du serveur ;
une session RPC n'a rien d'équivalent, et la liste blanche est donc
appliquée dans le passe-plat, pas chez l'appelant.
--- EN ---
The analyses existed; the path BEFORE them did not. A customer database
sits in a zip, behind a URL, or live on a server.
« Migration leftovers » had to be written: check_migration_quality
compares STEP databases and needs the progression log — facing a lone
backup, neither exists.
Its obvious counters were dropped after measuring. Against the ORIGINAL
database: fields with no column 25 → 72, models with no table 90 → 158.
Twenty-five and ninety BEFORE any migration: noise. Only what is wrong in
itself remains, 0 before and non-zero after — 9 languages with a NULL
flag, 68 missing m2m tables, 414 duplicated indexes.
The RPC proxy only reads. psql gets that from the server; an RPC session
has no equivalent, so the allowlist lives in the proxy, not the caller.
Assisted-by: Claude Opus 5
La colonne Odoo testait le port 8069 depuis le poste : une VM sur pont
interne n'y répond jamais, elle restait « — » quel que soit l'état d'Odoo.
Le test part maintenant DE L'HÔTE, glissé dans l'appel des statistiques déjà
payé — aucun aller-retour de plus. Éprouvé sur une VM d'essai servant sur
8069 : 🟢, et « — » sur la voisine qui n'a rien.
Deux dernières actions visaient encore la mauvaise machine. La touche « w »
ouvrait une page morte : l'adresse d'un pont interne n'est pas routable
d'ici, elle passe donc par un tunnel local le temps de la visite — tenu par
son PID, car « pkill -f <motif> » tuait le shell qui l'avait lancé, le motif
figurant dans sa propre ligne de commande. Et la SUPPRESSION appelait
« virsh undefine <nom> », qui aurait effacé le domaine local homonyme : elle
passe par « qm destroy <vmid> » sur l'hôte.
--- EN ---
The Odoo column probed port 8069 from the workstation: a VM on an internal
bridge never answers there, so it stayed "—" whatever Odoo was doing. The
probe now runs FROM THE HOST, folded into the stats call already paid for —
no extra round trip. Proven on a test VM serving on 8069: 🟢, and "—" on the
neighbour that serves nothing.
Two last actions still aimed at the wrong machine. Key "w" opened a dead
page: an internal-bridge address is not routable from here, so it now goes
through a local tunnel for the length of the visit — held by its PID, since
"pkill -f <pattern>" killed the very shell that had launched it, the pattern
being in its own command line. And DELETION called "virsh undefine <name>",
which would have erased the homonymous local domain: it now goes through
"qm destroy <vmid>" on the host.
Assisted-by: Claude Opus 5
« s » ouvrait encore la VM locale homonyme : la vue de progression n'avait
que le NOM de la VM, et l'entrée ~/.ssh/config n'existe pas encore à ce
moment. Le déploiement lui passe maintenant « ssh -J <hôte> user@<ip> », qui
ne dépend de rien. Deux voisines du même défaut, jamais rapportées mais aussi
graves : la console ouvrait « virsh console <nom> » — celle de la VM LOCALE —
et la pause suspendait la locale. Les deux passent par le VMID sur l'hôte.
La colonne Disque annonçait « 6.0G/6.0G » sur une VM qui n'avait écrit que
1,2 Go : « du -sb » rend la taille APPARENTE, et un disque raw creux la donne
entière. « du -sB1 » compte les blocs. Enfin l'écran de déploiement dit ce qui
l'attend : « Quitter (q) pour lancer l'installation d'ERPLibre » — on
attendait devant une fenêtre terminée sans le savoir.
--- EN ---
"s" still opened the homonymous local VM: the progress view only had the VM's
NAME, and the ~/.ssh/config entry does not exist yet at that point. The
deployment now hands it "ssh -J <host> user@<ip>", which depends on nothing.
Two neighbours of the same defect, never reported but just as serious: the
console opened "virsh console <name>" — the LOCAL VM's — and pause suspended
the local one. Both now go through the VMID on the host.
The Disk column claimed "6.0G/6.0G" on a VM that had written 1.2 GB: "du -sb"
returns the APPARENT size, and a sparse raw disk gives it in full. "du -sB1"
counts blocks. Finally the deployment screen says what awaits it: "Quit (q)
to start the ERPLibre install" — one waited before a finished window without
knowing.
Assisted-by: Claude Opus 5
Rapporté, et c'est le plus grave de la série. Une VM déployée sur Proxmox
sous le nom « erplibre-ubuntu-2604 » — nom déjà porté par un domaine LOCAL —
a vu son installation d'ERPLibre + Odoo partir sur la VM locale. Deux causes
enchaînées : l'entrée ~/.ssh/config volait l'alias de la locale, et le
lanceur détaché ré-résout l'adresse par virsh à chaque tour, qui a répondu
avec le domaine homonyme. Le journal l'écrivait — « → 192.168.123.118 » —
sans que rien n'alerte.
Une VM distante n'est plus ré-résolue : son alias est la seule vérité,
puisqu'il porte le rebond. Et son alias suit la convention des VM imbriquées,
« hôte+vm », le nom court n'étant ajouté que s'il est libre — l'écran le dit.
S'y ajoute le sommaire final qui manquait, à l'image de QEMU/KVM : ce qui
existe, son adresse, sa commande ssh, son journal.
--- EN ---
Reported, and the worst of the series. A VM deployed on Proxmox under the
name "erplibre-ubuntu-2604" — a name already held by a LOCAL domain — had its
ERPLibre + Odoo install land on the local VM. Two chained causes: the
~/.ssh/config entry stole the local one's alias, and the detached launcher
re-resolves the address through virsh on every pass, which answered with the
homonymous domain. The log said so — "→ 192.168.123.118" — with nothing to
raise an alarm.
A remote VM is no longer re-resolved: its alias is the only truth, since it
carries the jump. And its alias follows the nested-VM convention, "host+vm",
the short name being added only when free — the screen says so. Plus the
final summary that was missing, mirroring QEMU/KVM: what exists, its address,
its ssh command, its log.
Assisted-by: Claude Opus 5
« 409 pièces jointes perdues » au palier 17 → 18 n'en recouvrait presque
aucune. Sur les 516 lignes parties, 452 avaient perdu leur CHAMP PORTEUR
aux paliers 13 et 14 : elles étaient déjà illisibles — Odoo lève un
KeyError en les contrôlant. Ce ne sont pas des données, ce sont des
débris, et la 18 les ramasse.
On ne DÉCLARE pas cela dans SEMANTIC_MAP. Cette carte nomme une TABLE, et
la cause n'est pas la table, ce sont ces lignes-là ; déclarée, elle
rangerait toute perte future de ir_attachment sous « changement d'Odoo »,
cinq mille factures comprises. On la DÉDUIT, ligne par ligne, dans le
même vocabulaire.
Reste 64 lignes en rouge au palier 18 : leur champ est toujours là. Elles
demandent un contrôle d'existence d'enregistrement que je n'ai pas
mesuré, donc je ne l'affirme pas.
--- EN ---
« 409 attachments lost » at the 17 → 18 step covered almost none. Of the
516 rows that went, 452 had lost their CARRYING FIELD at steps 13 and 14:
they were already unreadable — Odoo raises a KeyError checking them. Not
data, debris, and 18 sweeps them up.
We do NOT declare this in SEMANTIC_MAP. That map names a TABLE, and the
cause is not the table but those rows; declared, it would file every
future ir_attachment loss under « an Odoo change », five thousand
invoices included. We DEDUCE it, row by row, in the same vocabulary.
64 rows stay red at step 18: their field is still there. They need a
record-existence check I have not measured, so I do not claim it.
Assisted-by: Claude Opus 5
Elle éprouvait 45 modèles sur 125 portant une règle globale, contre
quatre utilisateurs internes — et les quatre étaient administrateurs. Un
modèle que seuls les administrateurs peuvent lire passait donc au vert :
c'est exactement la forme du bug DMS qui a motivé cet outil, vue d'un
autre angle.
Elle ne peut pas créer un témoin ordinaire — ce serait une écriture.
Elle peut dire qu'elle n'en avait pas, annoncer sa couverture au lieu du
seul nombre éprouvé, et déclarer qu'un masquage codé en Python lui
échappe puisqu'elle part d'ir_rule. Un vert qui prouve moins qu'il n'en
a l'air est pire qu'un rouge.
--- EN ---
It tested 45 models out of the 125 carrying a global rule, against four
internal users — and all four were administrators. A model only admins
can read therefore passed green: exactly the shape of the DMS bug that
motivated this tool, seen from another angle.
It cannot create an ordinary witness — that would be a write. It can say
it had none, announce its coverage rather than only the number checked,
and declare that masking coded in Python escapes it since it starts from
ir_rule. A green that proves less than it looks is worse than a red.
Assisted-by: Claude Opus 5
The checker knew only the pack layout. A real build ships one tar.gz per
repository, so it raised "<slug> : index.json absent" and, being guarded by
`|| exit 1`, stopped compile_and_run.sh before cap sync — no APK. Broken
since 2026-08-20 for anyone on the current mobile main: the parent half of
that work landed, the mobile half producing packs never did.
It now accepts both layouts, so whichever half lands next, it holds.
Two things got better on the way. The byte-for-byte comparison against the
source — the only check that proves fidelity rather than coherence — was
reporting zero comparisons, because no entry matched the shape it looked
for; it now compares twenty. And presence is no longer sampled: streaming
all 139 archives costs 6 s and accounts for every one of the 124 350
promised files, where a sample of twenty could not see a ghost it did not
draw.
The test guarding the ZIP limit demanded a `chunk` field on every file —
the pack layout, not the limit. It counts entries now: 278 against 65 535.
Its real-bundle class had been taught to skip on this very symptom rather
than fail; it runs again.
--- FR ---
Le vérificateur ne connaissait que la disposition en packs. Une compilation
réelle livre un tar.gz par dépôt : il levait « <slug> : index.json absent »
et, gardé par `|| exit 1`, arrêtait compile_and_run.sh avant cap sync — pas
d'APK. Cassé depuis le 2026-08-20 pour quiconque est sur le main mobile
actuel : la moitié parente de ce travail a atterri, la moitié mobile qui
produit les packs jamais.
Il accepte désormais les deux dispositions : quelle que soit la moitié qui
atterrit ensuite, il tient.
Deux choses se sont améliorées en chemin. La comparaison octet pour octet
contre la source — la seule qui prouve la fidélité et non la cohérence —
rapportait zéro comparaison, faute d'entrée à la forme attendue ; elle en
compare vingt. Et la présence n'est plus échantillonnée : traverser les 139
archives coûte 6 s et rend compte de chacun des 124 350 fichiers promis, là
où vingt tirages ne pouvaient pas voir un fantôme non tiré.
Le test qui gardait la limite du ZIP exigeait un champ `chunk` sur chaque
fichier — la disposition, pas la limite. Il compte les entrées désormais :
278 pour 65 535. Sa classe sur le vrai bundle avait appris à s'ignorer sur
ce symptôme même plutôt qu'à échouer ; elle tourne à nouveau.
Assisted-by: Claude Opus 5
[ADD] migration : réparer les copies de site, durcir Proxmox
Seize commits, deux fronts qui avancent en parallèle.
Côté migration, ce sont des dégâts qu'un palier laisse et qu'aucun
événement ne répare : des copies de site qui ne savent plus se rendre, les
index qu'Odoo 17 crée en double, des réglages qu'aucun hook ne remet. Une
prédiction s'y ajoute — dire AVANT le palier quelle copie rendra 500 après
— parce que le constater après coûte une restauration.
Côté Proxmox, l'écran crée le pont manquant, suit une VM distante et change
son état. Et le rebond devient le seul chemin vers la VM : viser l'hôte
directement marchait tant que la VM avait une adresse routable, ce qui n'est
pas le cas général.
Un module fautif n'emporte plus tout le lot : une désinstallation qui
échoue arrêtait la liste entière.
--- EN ---
Sixteen commits, two fronts moving in parallel.
On migration, these are the wounds a bump leaves and no event heals: site
copies that no longer render, the indexes Odoo 17 creates twice, settings
no hook restores. A prediction joins them — saying BEFORE the bump which
copy will answer 500 after it — because finding out afterwards costs a
restore.
On Proxmox, the screen creates the missing bridge, follows a remote VM and
changes its state. And the jump host becomes the only route to the VM:
aiming at the host directly worked as long as the VM had a routable
address, which is not the general case.
A faulty module no longer takes the whole batch down: one failed uninstall
used to stop the entire list.
Assisted-by: Claude Opus 5
Suite du nettoyage. Le tri des entrées ~/.ssh/config comparait lui aussi le
NOM aux noms de domaines : après le renommage de la VM, son alias
« erplibre-ubuntu-2404 » ne correspondait plus à rien et a été effacé, alors
qu'il menait à une machine en marche. Une entrée est conservée si son adresse
est celle d'un domaine vivant, si elle porte un rebond — donc écrite pour une
VM que virsh ne verra jamais — ou si son nom est une VM de l'hôte Proxmox. Et
l'écran nomme ce qu'il garde, comme pour les fichiers.
Même racine pour l'adresse affichée : « virsh domifaddr --source arp »
remonte les passerelles des ponts, et le repli « la dernière candidate » y
tombait dès que le bail portait l'ancien nom d'hôte. La VM renommée était
annoncée en 192.168.122.1 au lieu de 192.168.123.170. On préfère désormais le
bail, puis l'agent, puis l'ARP, et les adresses de l'hôte sont écartées.
--- EN ---
More of the same cleanup. Sorting ~/.ssh/config entries also compared the
NAME against domain names: after the VM was renamed, its alias
"erplibre-ubuntu-2404" matched nothing and was deleted, though it led to a
running machine. An entry is kept if its address belongs to a live domain, if
it carries a jump — hence written for a VM virsh will never see — or if its
name is a VM of the Proxmox host. And the screen names what it keeps, as it
does for files.
Same root for the displayed address: "virsh domifaddr --source arp" returns
the bridges' gateways, and falling back to "the last candidate" landed there
as soon as the lease carried the old hostname. The renamed VM was announced
as 192.168.122.1 instead of 192.168.123.170. The lease now wins over the
agent, which wins over ARP, and the host's own addresses are excluded.
Assisted-by: Claude Opus 5
Le seau « NON déclarés par OpenUpgrade » comptait 565 champs au palier
16 → 17, dont 397 `__last_update` — un champ magique qu'Odoo 17 cesse
d'inscrire et qui n'a jamais eu de colonne. Un chiffre de tête qui fait
peur pour rien fait ignorer le rapport entier.
`store=false` le dit sans ambiguïté, et `id` s'y ajoute : il porte une
donnée, mais celle de la ligne, pas la sienne. Ils vont dans une
catégorie à part, en teinte calme, et NOMMÉE — « __last_update × 101
modèle(s) » explique à lui seul le gros chiffre.
Mesuré sur la chaîne 12 → 18 : le total passe de 1176 à 491, le pire
palier de 565 à 57. Les quatre vrais champs techniques perdus restent
visibles.
--- EN ---
The « NOT declared by OpenUpgrade » bucket held 565 fields at the 16 → 17
step, 397 of them `__last_update` — a magic field Odoo 17 stops
recording, which never had a column. A headline number that frightens
for nothing gets the whole report ignored.
`store=false` says so unambiguously, and `id` joins it: it carries data,
but the row's, not its own. They go to a separate bucket, in a quiet
tint, and NAMED — « __last_update × 101 model(s) » explains the big
number on its own.
Measured on the 12 → 18 chain: the total drops from 1176 to 491, the
worst step from 565 to 57. The four genuinely lost technical fields stay
visible.
Assisted-by: Claude Opus 5
Trois défauts rapportés sur un déploiement Proxmox. La branche proposée
était « dependabot/pip/aiobotocore-3.1.3 » : « git ls-remote » rend la liste
par ordre alphabétique, et l'écran en prenait la première. Il propose
maintenant la branche du DÉPÔT — celle qu'on a sous les yeux — puis develop,
puis master ; la liste met ces trois-là en tête et relègue les branches de
robot à la fin. Les deux écrans partagent la règle.
La vue de progression n'affichait la sortie qu'à la FIN du travail :
« subprocess.run » ne rend rien avant. Sur Proxmox, une VM demande le
téléchargement de 325 Mio puis l'import du disque — plusieurs minutes de bloc
vide. Elle lit maintenant ligne à ligne. Et « s » y ouvre un ssh sur la VM
créée, par son nom, donc par l'entrée ~/.ssh/config qui porte le rebond.
--- EN ---
Three defects reported on a Proxmox deployment. The branch offered was
"dependabot/pip/aiobotocore-3.1.3": "git ls-remote" returns the list in
alphabetical order and the screen took its first entry. It now offers the
CHECKOUT's branch — the one in front of you — then develop, then master; the
list puts those three first and pushes robot branches to the end. Both
screens share the rule.
The progress view only showed output at the END of a job: "subprocess.run"
returns nothing before that. On Proxmox a VM needs a 325 MiB download then a
disk import — minutes of an empty block. It now reads line by line. And "s"
opens an ssh to the created VM, by name, hence through the ~/.ssh/config
entry that carries the jump.
Assisted-by: Claude Opus 5
« --uninstall » prend une liste virgulée et Odoo annule la transaction
entière au premier échec : soit tout part, soit rien. Mesuré sur une
chaîne 12 → 18 — crm_phone échoue sur une colonne absente de res_users
et fait tomber les 22 autres avec lui, dont huit modules maison sans
code en 13. Ceux-là sont alors montés d'un palier « installed » sans
rien pour les charger, et ne sont partis que trois paliers plus loin,
par accident.
Le lot part toujours d'abord — un démarrage d'Odoo par nom se paierait
cher pour rien. Mais s'il échoue, on reprend un par un : ce qui peut
partir part, et l'on nomme ce qui résiste.
S'ajoute la liste 12 → 13, qui n'existait pas : sans elle l'étape
« Uninstall module » n'avait rien à faire.
--- EN ---
« --uninstall » takes a comma list and Odoo rolls the whole transaction
back on the first failure: all or nothing. Measured on a 12 → 18 chain —
crm_phone fails on a column missing from res_users and drags the other
22 down with it, including eight in-house modules with no code in 13.
Those rode a step up « installed » with nothing to load them, and only
left three steps later, by accident.
The batch still goes first — one Odoo start per name would cost dearly
for nothing. But if it fails, we retry one by one: what can leave
leaves, and we name what resists.
Plus the 12 → 13 list, which did not exist: without it the « Uninstall
module » step had nothing to do.
Assisted-by: Claude Opus 5
Les trois manques restants, demandés. Les colonnes vivantes du suivi — écrit
par seconde, RAM, disque — venaient de virsh, qui ne connaît pas les VM d'un
hôte Proxmox : elles restaient vides, et le relevé d'état les déclarait même
« effacées », ce qui éteignait le reste. L'hôte sait tout cela en un appel
(« pvesh get /cluster/resources »), et le relevé prend la forme de celui de
virsh pour que rien en aval ne distingue la source. Un appel par hôte, mis en
cache cinq secondes : une poignée de main ssh coûte 1 s, virsh 0,03 s.
« Lister les VM » propose maintenant d'en changer l'état, comme QEMU/KVM —
éteindre proprement avant de couper le courant, l'ordre le dit. Et le menu
accepte les commandes ajoutées par todo.json. Enfin « models » manquait aux
traductions : le rapport de migration sortait « 812 models » en français.
--- EN ---
The three remaining gaps, as asked. The dashboard's live columns — written per
second, RAM, disk — came from virsh, which knows nothing of a Proxmox host's
VMs: they stayed empty, and the state probe even declared them "gone", which
switched off the rest. The host knows all of it in one call ("pvesh get
/cluster/resources"), and the reading takes virsh's own shape so nothing
downstream tells the sources apart. One call per host, cached five seconds: an
ssh handshake costs 1 s, virsh 0.03 s.
"List VMs" now offers to change their state, like QEMU/KVM — clean shutdown
before pulling the plug, the order says so. And the menu accepts the commands
todo.json adds. Finally "models" was missing from the translations: the
migration report printed "812 models" in French.
Assisted-by: Claude Opus 5
Sans pont, « qm create » est impossible — et l'écran refusait de déployer
« aucun pont sur l'hôte » sans offrir le moindre moyen d'en avoir un. Une
Proxmox installée SUR Debian n'en a jamais : l'ISO en crée un, pas la
procédure sur Debian.
Deux moments, donc. Avant l'écran, la question se pose dans le terminal, où
l'on peut expliquer les deux voies et montrer ce qui s'exécute. Dans l'écran,
le sélecteur porte « ➕ créer un pont interne vmbr0 (10.10.10.1/24) + NAT » :
la création part dans un fil, l'affichage reste vivant, et le pont créé se
sélectionne tout seul. Elle ne demande rien parce qu'un pont interne ne
touche à aucune interface physique ; un pont sur le LAN déplace l'adresse de
l'hôte et coupe la session, donc il reste manuel.
--- EN ---
With no bridge, "qm create" is impossible — and the screen refused to deploy
"no bridge on the host" without offering any way to get one. A Proxmox
installed ON Debian never has one: the ISO creates it, the Debian procedure
does not.
Two moments, then. Before the screen, the question is asked in the terminal,
where both ways can be explained and the commands shown. In the screen, the
selector carries "➕ create an internal vmbr0 (10.10.10.1/24) + NAT": creation
runs in a thread, the display stays alive, and the new bridge selects itself.
It asks nothing because an internal bridge touches no physical NIC; a bridge
on the LAN moves the host's address and cuts the session, so it stays manual.
Assisted-by: Claude Opus 5
Elle interrogeait `db --list`, qui ne LIT jamais le mot de passe :
mesuré, `MASTER_PWD="ceci_est_faux" odoo-bin db --list` sort en 0. La
boucle des dix essais acceptait donc le premier mot saisi, juste ou
faux, et le refus n'arrivait qu'au `--restore` — une fois la base déjà
supprimée. C'était exactement ce que cette boucle devait éviter.
Seule l'action `drop` consulte le secret, et elle le fait AVANT de
regarder la base : `check_super` d'abord, `db_exists` ensuite. Sur un
nom tiré d'un uuid4, elle répond sans rien toucher. Mesuré : mauvais mot
de passe → code 1 et AccessDenied ; bon → code 0 ; huit bases avant,
huit après.
--- EN ---
It probed `db --list`, which never READS the master password: measured,
`MASTER_PWD="ceci_est_faux" odoo-bin db --list` exits 0. The ten-attempt
loop therefore accepted the first password typed, right or wrong, and
the refusal only came at `--restore` — once the database was already
dropped. Precisely what that loop existed to avoid.
Only the `drop` action reads the secret, and it does so BEFORE looking
at the database: `check_super` first, `db_exists` after. On a uuid4 name
it answers without touching anything. Measured: wrong password → exit 1
and AccessDenied; right → exit 0; eight databases before, eight after.
Assisted-by: Claude Opus 5
Deux enregistrements ont cessé d'être LIVRÉS en données pour devenir le
produit d'un geste : créer une société, cocher une case, charger un plan
comptable. Une migration n'en fait aucun. Le nettoyage des orphelins les
emporte et rien ne les remet.
`product.list0` est déclaré jusqu'en 16 : 1 liste en 16, 0 en 17, alors
que le groupe compte six membres — tout devis s'ouvre alors sans liste
de prix. Le modèle de rapprochement est déclaré en 12 seulement : 0 dès
la 13, pour trois journaux de trésorerie.
On n'invente rien : `_activate_or_create_pricelists` et `_load_data` du
plan comptable, les méthodes qu'Odoo aurait appelées. Éprouvé sur copie :
0 → 1 liste, 0 → 4 modèles, un devis reprend « Par défaut (CAD) », un
second passage ne double rien.
--- EN ---
Two records stopped being SHIPPED as data and became the product of a
gesture: creating a company, ticking a box, loading a chart of accounts.
A migration does none of them. The orphan cleanup takes them away and
nothing brings them back.
`product.list0` is declared up to 16: 1 pricelist in 16, 0 in 17, while
the group has six members — every quotation then opens without a
pricelist. The reconciliation model is declared in 12 only: 0 from 13 on,
for three cash journals.
Nothing is invented: `_activate_or_create_pricelists` and the chart
template's `_load_data`, the methods Odoo itself would have called.
Proven on a copy: 0 → 1 pricelist, 0 → 4 models, a quotation picks up
« Par défaut (CAD) », a second pass duplicates nothing.
Assisted-by: Claude Opus 5
Rapporté, et c'est le pire défaut possible ici. Après avoir renommé une VM
en « erplibre-ubuntu-2404-MIGRATION », le nettoyage offrait au « rm -f » son
disque de 63 Go, son seed et son nvram — les trois attachés à une VM EN
MARCHE. L'orphelinat se jugeait sur le NOM du fichier comparé aux noms de
domaines ; un renommage suffisait donc à condamner une VM de production.
L'autorité est désormais libvirt : ce qu'un domaine référence n'est pas
orphelin, quel que soit son nom, et l'écran nomme ce qu'il conserve et pour
qui. Un second contrôle, indépendant, épargne aussi ce qu'un processus tient
ouvert. L'effacement d'une VM demande de même ses fichiers à libvirt : par le
nom, il laissait les 63 Go derrière lui.
--- EN ---
Reported, and it is the worst possible defect here. After renaming a VM to
"erplibre-ubuntu-2404-MIGRATION", cleanup offered its 63 GB disk, its seed
and its nvram to "rm -f" — all three attached to a RUNNING VM. Orphanhood was
judged on the file NAME against domain names; a rename was therefore enough
to condemn a production VM.
Libvirt is now the authority: what a domain references is not an orphan,
whatever its name, and the screen names what it keeps and for whom. A second,
independent check also spares whatever a process holds open. Deleting a VM
likewise asks libvirt for its files: by name, it left the 63 GB behind.
Assisted-by: Claude Opus 5
Une VM créée sur l'hôte Proxmox vit derrière lui, sur un pont interne : son
adresse n'est pas routable d'ici, et seule l'entrée ~/.ssh/config avec son
ProxyJump y mène. Décocher « ajouter une entrée » tout en demandant une
installation laissait donc le suivi frapper à une porte qui n'existe pas.
L'entrée est maintenant écrite quand une installation ou le suivi la
réclame, et on le dit. Sans rien à faire dans la VM, le choix est respecté.
Trouvé par l'audit du découpage, pas par l'exécution : c'est un cas que
personne n'avait joué.
--- EN ---
A VM created on the Proxmox host lives behind it, on an internal bridge: its
address is not routable from here, and only the ~/.ssh/config entry with its
ProxyJump leads there. Unticking "add an entry" while asking for an install
therefore left the monitor knocking at a door that does not exist. The entry
is now written whenever an install or the dashboard needs it, and we say so.
With nothing to do inside the VM, the choice stands.
Found by the split's audit, not by running it: nobody had played that case.
Assisted-by: Claude Opus 5
Quatre tests comparaient des mots français à une sortie traduite : ils
échouaient dès que EL_LANG passait à « en », pour une raison étrangère à ce
qu'ils vérifient. Ils comparent maintenant à t(clé). La suite passe dans les
deux langues, ce qui est la seule façon de le savoir.
Et le transfert mobile s'IGNORE quand le paquet est à moitié construit
(manifeste plein, index absents) au lieu de remonter une erreur : un état
incomplet n'est pas une régression du transfert.
--- EN ---
Four tests compared French words against translated output: they failed as
soon as EL_LANG turned to "en", for a reason foreign to what they check. They
now compare against t(key). The suite passes in both languages, which is the
only way to know it.
And the mobile transfer now SKIPS when the bundle is half-built (manifest
full, indexes missing) instead of raising an error: an incomplete state is
not a regression of the transfer.
Assisted-by: Claude Opus 5
« Il manque plein d'informations qu'il y avait avant » : l'écran de
télémétrie construit son arbre en LISANT le code — un fichier, sa première
classe. Depuis que les menus QEMU/KVM et Proxmox vivent dans des mixins,
leurs colonnes avaient disparu de cet écran ; les commandes s'exécutaient
toujours, mais on ne pouvait plus les lancer de là. L'arbre lit maintenant
aussi les mixins, trouvés dans les imports de todo.py — un mixin ajouté
demain apparaîtra sans qu'on y pense.
Le menu Proxmox n'avait pas d'étiquette : son fil d'Ariane s'arrêtait deux
niveaux plus haut, sur « Deploy ». Vérifié : 16 commandes QEMU/KVM et 18
Proxmox dans l'arbre, contre zéro et zéro.
--- EN ---
"A lot of information that used to be there is missing": the telemetry screen
builds its tree by READING the code — one file, its first class. Since the
QEMU/KVM and Proxmox menus moved into mixins, their columns had vanished from
that screen; the commands still ran, but could no longer be launched from
there. The tree now reads the mixins too, found in todo.py's own imports — a
mixin added tomorrow shows up without anyone thinking about it.
The Proxmox menu had no label: its breadcrumb stopped two levels up, at
"Deploy". Verified: 16 QEMU/KVM commands and 18 Proxmox ones in the tree,
against zero and zero.
Assisted-by: Claude Opus 5
Rapporté. La chaîne, en trois maillons : sur un hôte sans pont, « ip -o link
show type bridge » ne rend RIEN, la sortie ne contient donc que
l'avertissement de ssh sur la clé d'hôte — que le lecteur a pris pour un nom
de pont. « (ED25519) » s'est retrouvé dans « --net0 virtio,bridge=… », enrobé
de « sudo sh -c », et dash a répondu ce que l'utilisateur a lu. Le bruit de
ssh est maintenant retiré à la source, et un pont doit avoir la forme d'un
lien pour en être un.
Éprouvé sur l'hôte réel, VM créée puis détruite : le pont ne montait pas
(ifupdown2 accuse « another instance » quand /run/network manque — un
mensonge), le noyau Debian n'a ni module bridge ni table NAT, et une VM en
adresse fixe n'avait aucun résolveur. Le déploiement écrit désormais un
journal par VM sous ~/.erplibre/proxmox-deploy et en donne le chemin.
--- EN ---
Reported. The chain, in three links: on a host with no bridge, "ip -o link
show type bridge" returns NOTHING, so the output holds only ssh's host-key
warning — which the parser took for a bridge name. "(ED25519)" landed in
"--net0 virtio,bridge=…", wrapped in "sudo sh -c", and dash answered what the
user read. Ssh's noise is now stripped at the source, and a bridge must have
the shape of a link to be one.
Proven on the real host, VM created then destroyed: the bridge would not come
up (ifupdown2 claims "another instance" when /run/network is missing — a lie),
the Debian kernel has neither the bridge module nor the NAT table, and a
statically addressed VM had no resolver at all. Deployment now writes one log
per VM under ~/.erplibre/proxmox-deploy and prints its path.
Assisted-by: Claude Opus 5
`make_index_name` rend `{table}__{colonne}_index` depuis la 17 — deux
soulignés. Le nouvel index est créé, l'ancien reste. Mesuré sur une
chaîne 12 → 18 : 1 paire en 12, 3 en 16, 370 en 17, 365 en 18. Inerte à
la lecture, coûteux à l'écriture — deux arbres B entretenus à chaque
INSERT — et c'est le seul défaut de la famille qui empire tout seul.
L'outil s'abstient plus qu'il ne supprime : contrainte, clé primaire,
index partiel ou calculé, méthode ou classe d'opérateurs différentes,
convention non reconnaissable. Sur la base réelle, 367 sûrs sur 376.
Éprouvé sur une copie : 364 retirés, 10 Mo libérés, les 6301 contraintes
identiques au nom près, Odoo charge sans une ligne de journal, et un
« -u all » complet n'en recrée aucun.
--- EN ---
`make_index_name` returns `{table}__{column}_index` since 17 — two
underscores. The new index is created, the old one stays. Measured on a
12 → 18 chain: 1 pair in 12, 3 in 16, 370 in 17, 365 in 18. Inert on
read, costly on write — two B-trees maintained per INSERT — and the only
defect of this family that worsens on its own.
The tool abstains more than it drops: constraint, primary key, partial or
computed index, differing access method or operator class, unrecognisable
convention. On the real database, 367 safe out of 376.
Proven on a copy: 364 dropped, 10 MB freed, the 6301 constraints
identical name for name, Odoo loads without a single log line, and a full
« -u all » recreates none of them.
Assisted-by: Claude Opus 5
`check_cow_views` ne voyait que la rupture qui ARRÊTE la migration : la
forme que l'arch doit avoir change. Deux autres la laissent finir sans un
mot — un ancrage qu'une vue héritière de la cible réclame, un t-call vers
un gabarit que la cible ne livre plus — et ne se voient qu'à l'ouverture
de la page, c'est-à-dire jamais avant la fin.
Rejouée sur la chaîne 12 → 18, la prédiction nomme le défaut de /contact
dès le palier 13 → 14, en 0,8 s. Il avait attendu six paliers.
Ces copies ne sont PAS neutralisées : chacune porte une page écrite par
quelqu'un. Le pilote appelle la réparation après OpenUpgrade, là où la
vue module porte enfin l'arch de la cible.
--- EN ---
`check_cow_views` only saw the break that STOPS the migration: the shape
the arch must have changes. Two others let it finish without a word — an
anchor a target child view requires, a t-call to a template the target no
longer ships — and only show when the page is opened, which is to say
never before the end.
Replayed on the 12 → 18 chain, the prediction names /contact's defect as
early as the 13 → 14 step, in 0.8 s. It had waited six steps.
Those copies are NOT neutralized: each holds a page someone wrote. The
driver calls the repair after OpenUpgrade, where the module view finally
carries the target's arch.
Assisted-by: Claude Opus 5
`check_cow_views` cherche la rupture qui ARRÊTE la migration : la forme
que l'arch doit avoir change. Deux autres la laissent finir sans un mot.
Un ancrage manquant : une vue héritière fait un xpath sur `//t[@t-set=…]`
que le module a gagné en chemin ; la copie, page d'utilisateur, n'est
jamais réécrite. Un t-call pendant : le gabarit appelé n'existe plus dans
la cible. Mesuré sur une 12 → 18 réelle : /contact rendait 500 depuis le
palier 14 → 15, quatre paliers de silence, et le test de fumée le voyait
sans savoir le nommer.
Le premier se répare depuis la vue module, en gardant la page telle que
son auteur l'a écrite. Le second se retire, et l'humain décide.
--- EN ---
`check_cow_views` looks for the break that STOPS the migration: the shape
the arch must have changes. Two others let it finish without a word.
A missing anchor: a child view xpaths on `//t[@t-set=…]` that the module
gained along the way; the copy, a user page, is never rewritten. A
dangling t-call: the template called no longer exists in the target.
Measured on a real 12 → 18: /contact returned 500 since the 14 → 15 step,
four steps of silence, and the smoke test saw it without naming it.
The first is repaired from the module view, keeping the page as its
author wrote it. The second is removed, and the human decides.
Assisted-by: Claude Opus 5
[ADD] proxmox : l'écran de déploiement sur hôte distant
Le déploiement Proxmox existait en ligne de commande depuis le segment
précédent. Ces sept commits lui donnent son écran, et rendent au découpage
ce qu'il avait laissé derrière.
L'écran récapitule dans le terminal avant de créer : une VM distante coûte
assez cher à défaire pour qu'on relise ses paramètres une fois de plus. Il
dit aussi la place qui reste sous le plan de déploiement, et distingue
« hôte injoignable » de « hôte qui n'est pas Proxmox » — deux pannes que le
même message confondait, alors qu'elles ne se corrigent pas pareil.
Deux correctifs viennent du déplacement lui-même : des colonnes de
télémétrie perdues en route, et un reste de code que le découpage avait
oublié.
--- EN ---
Proxmox deployment already worked from the command line, from the previous
segment. These seven commits give it a screen, and give the split back what
it left behind.
The screen recaps in the terminal before creating: a remote VM costs enough
to undo that its parameters deserve one more read. It also says how much
room is left under the deployment plan, and separates "host unreachable"
from "host that is not Proxmox" — two failures the same message conflated,
though they are not fixed the same way.
Two fixes come from the move itself: telemetry columns lost on the way, and
a leftover the split had forgotten.
Assisted-by: Claude Opus 5
« Installer ERPLibre » commandait TOUTE installation, l'hyperviseur Proxmox
VE compris : décochée, une VM Proxmox restait une Debian nue sans que rien
ne l'explique. Elle devient « Installer un logiciel dans la VM », passe sous
le type de VM — juste avant les sections qu'elle commande — et le suivi la
quitte, puisqu'il regarde la VM arriver même quand rien ne s'installe.
Ce qu'elle rend sans effet se grise, titre compris. Trois états et non deux :
sans installation mais AVEC un bureau, le magasin d'applications et les
outils de la phase « avant » servent encore ; seuls ceux qui vivent dans le
dépôt s'éteignent. Griser en bloc aurait menti autant que de tout laisser.
--- EN ---
"Install ERPLibre" commanded EVERY install, the Proxmox VE hypervisor
included: unticked, a Proxmox VM stayed a bare Debian with nothing to explain
it. It becomes "Install software in the VM", moves under the VM type — right
before the sections it commands — and the dashboard leaves it, since that
watches the VM arrive even when nothing is installed.
What it makes ineffective now greys out, title included. Three states, not
two: with no install but WITH a desktop, the application store and the
"before" tools still act; only those living in the repository go dark.
Greying the lot would have lied as much as greying nothing.
Assisted-by: Claude Opus 5
Rapporté : « je n'arrive pas à me connecter, pourtant il est accessible ».
La machine répondait bel et bien — c'est Proxmox VE qui n'y était pas. Un
seul message couvrait les deux pannes, et la seule ligne montrée en preuve
était l'avertissement de ssh sur la clé d'hôte, qui envoyait chercher un
problème de réseau inexistant.
On demande donc à ssh s'il passe avant de conclure, et le bruit de la clé
d'hôte ne sort plus comme diagnostic. Machine joignable sans Proxmox : la
commande qui l'installe est affichée telle quelle. Vérifié sur les deux VM
du parc — l'une répond sans pveversion, l'autre ne répond plus.
--- EN ---
Reported: "I cannot connect, yet it is reachable". The machine did answer —
Proxmox VE simply was not on it. One message covered both failures, and the
only line shown as evidence was ssh's host-key warning, which sent the
reader looking for a network problem that did not exist.
So we now ask ssh whether it gets through before concluding, and the
host-key noise no longer comes out as a diagnosis. Reachable without
Proxmox: the command that installs it is printed as is. Checked against both
VMs here — one answers without pveversion, the other no longer answers.
Assisted-by: Claude Opus 5
Choisir « Proxmox VE » comme système, c'est demander qu'il soit installé.
L'invite en ligne le savait ; le formulaire posait « ERPLibre + Odoo 18 »,
lui ajoutait les 5 Go réservés au dépôt et annonçait une cible make dans le
guide de la VM. La règle vit maintenant en un seul endroit, les deux
chemins la lisent, et un choix explicite l'emporte toujours sur elle.
Trois défauts trouvés derrière. Une commande par VM n'était retenue que si
DEUX VM différaient : déployée seule, la VM Proxmox retombait sur la
commande commune. Le disque choisi à la main disparaissait quand rien
n'était installé — 60 G demandés, 20 G créés. Et une taille absente des
préréglages marquait la rangée ✎ dès son montage.
--- EN ---
Choosing "Proxmox VE" as the system means asking for it to be installed.
The command-line prompt knew that; the form set "ERPLibre + Odoo 18", added
the 5 GB meant for the repository and advertised a make target in the VM's
guide. The rule now lives in one place, both paths read it, and an explicit
choice always wins over it.
Three defects behind it. A per-VM command was only used when TWO VMs
differed: deployed alone, the Proxmox VM fell back to the common command.
A hand-picked disk size vanished when nothing was installed — 60 G asked,
20 G created. And a size absent from the presets marked its row ✎ on mount.
Assisted-by: Claude Opus 5
La ligne de totaux annonçait « ~126 G » sans dire sur quoi : la demande
seule ne dit pas si ça rentre, et on l'apprenait au déploiement. Elle dit
maintenant la demande, ce qui reste et la capacité — « ~126 G / 20 G libres
sur 270 G » — et prévient dès que le plan dépasse. Les trois limites (RAM,
disque, cœurs) s'affichent ensemble : n'en montrer qu'une cachait les
autres. Sur Proxmox, la place vient du stockage choisi, que « pvesm status »
donnait déjà.
Deux défauts trouvés en le faisant : la marque de génération, exigée de tous
les widgets, faisait taire chaque réglage commun de l'écran Proxmox, et
« [x1] » disparaissait, lu comme une balise Rich.
--- EN ---
The totals line said "~126 G" without saying out of what: the demand alone
does not tell whether it fits, and one found out at deploy time. It now says
the demand, what is left and the capacity — "~126 G / 20 G free of 270 G" —
and warns as soon as the plan exceeds it. The three limits (RAM, disk,
cores) show together: showing only one hid the others. On Proxmox the room
comes from the chosen storage, which "pvesm status" already gave.
Two defects found on the way: the generation mark, required of every widget,
silenced each common setting on the Proxmox screen, and "[x1]" vanished,
read as a Rich tag.
Assisted-by: Claude Opus 5
L'écran montre le plan, mais la création part sur une machine qui n'est pas
la nôtre, et l'hôte va demander sudo juste après. La ligne dit donc où,
quoi et combien — hôte, stockage, pont, puis une ligne par VM avec son VMID
et son adresse — et attend un oui. Le déploiement QEMU/KVM le fait déjà ;
c'était la seule étape qui manquait ici.
--- EN ---
The screen shows the plan, but creation goes to a machine that is not ours,
and the host will ask for sudo right after. So the recap says where, what
and how many — host, storage, bridge, then one line per VM with its VMID
and address — and waits for a yes. The QEMU/KVM deployment already does
this; it was the only step missing here.
Assisted-by: Claude Opus 5
Deux imports de todo.py n'avaient plus d'usager : « grp » est parti avec le
code qui posait les droits d'un groupe, et « getpass » est refait localement
par la seule fonction qui s'en sert. Trois fichiers neufs avaient leurs
imports dans le désordre, que le prochain « make format » aurait reformatés
en salissant un diff sans rapport.
--- EN ---
Two of todo.py's imports had no user left: « grp » went with the code that
set a group's rights, and « getpass » is re-imported locally by the only
function that uses it. Three new files had their imports out of order, which
the next « make format » would have reshuffled, dirtying an unrelated diff.
Assisted-by: Claude Opus 5
Le déploiement Proxmox se faisait par vingt questions, l'une après
l'autre, sans jamais voir le plan entier. Il a maintenant le même écran
que QEMU/KVM — catalogue à gauche, plan à droite, totaux dessous — et une
touche pour revenir aux questions. Il n'en redit rien : 690 lignes contre
1 340, tout le reste vient du socle commun.
Ce que Proxmox a en propre est montré AVANT de lancer : le VMID, parce
que l'hôte ne dit « déjà pris » qu'après avoir téléchargé l'image, et
l'adresse qui s'en déduit sur un pont interne. Le stockage et le pont sont
lus sur l'hôte, jamais devinés. L'icône 🗄 distingue l'entrée du menu de
celle qui déploie ici même.
--- EN ---
Deploying on Proxmox meant twenty questions, one after another, never
seeing the whole plan. It now has the same screen as QEMU/KVM — catalogue
left, plan right, totals below — and a key to fall back to the questions.
It repeats none of it: 690 lines against 1,340, everything else comes
from the shared foundation.
What belongs to Proxmox is shown BEFORE launching: the VMID, because the
host only says "already taken" after downloading the image, and the
address derived from it on an internal bridge. Storage and bridge are read
from the host, never guessed. The 🗄 icon tells the menu entry apart from
the one that deploys right here.
Assisted-by: Claude Opus 5
todo.py passait 13 000 lignes : plus personne n'y trouvait où une chose
vivait. Il en garde 4 400 — les menus et les aides générales — et six
fichiers portent chacun un sujet, assemblés en mixins sur la classe TODO.
Aucun membre perdu : 438 avant, 438 après, et treize sources modifiées
seulement là où un appel de classe devait changer de nom.
Les deux formulaires de déploiement posent le même travail : ils partagent
maintenant la logique pure, le CSS, la fabrique des rangées de ressources
et les gestes du plan (surcharges, verrous, exemplaires, renommage).
Vérifié en rendant le formulaire QEMU avant et après, sur neuf gestes :
même écran au SVG près, même état, même spec.
--- EN ---
todo.py had passed 13,000 lines: nobody could find where anything lived.
It keeps 4,400 — the menus and the general helpers — and six files each
own one subject, assembled as mixins on the TODO class. No member lost:
438 before, 438 after, and thirteen sources changed only where a
class-level call had to change name.
Both deployment forms do the same work: they now share the pure logic, the
CSS, the resource-row factory and the plan's gestures (overrides, locks,
copies, renaming). Verified by rendering the QEMU form before and after
across nine gestures: same screen down to the SVG, same state, same spec.
Assisted-by: Claude Opus 5
[ADD] migration : faire tourner la chaîne 12 → 18, et Proxmox VE
Seize commits antérieurs à l'éclatement de todo.py, et qui vivent donc encore
dedans : les grouper évite de trancher, pour chacun, s'il se relit avant ou
après un déplacement de 9 500 lignes.
Sept font tourner la chaîne 12 → 18, qui mourait à chaque palier autrement :
une ancre française encodée en pourcent qu'OpenUpgrade recolle en sélecteur
CSS, un échec gravé comme fait parce que la progression rend l'objet stocké,
un clone rebâti sans la préparation qui écarte le problème qu'il retrouve, un
autre qui ne rejouait qu'une part de sa liste, xlsxwriter jamais déclaré,
web_responsive que seule la 18 rend incompatible, et « dict | None » évalué au
chargement par le venv de la 12, en Python 3.7.
Les deux analyses en découlent : « qui dépend de qui », parce qu'au palier
17 → 18 la requête a dû être écrite à la main, et les filtres i/u/t sur les
états de passage qu'Odoo ne devrait pas garder.
Le reste ouvre Proxmox VE, localement puis sur hôte distant, relève ce que
chaque VM écrit — figée ou en train de compiler, elles se ressemblaient — rend
le suivi indépendant de l'installation, n'annonce plus un montage sshfs qui a
échoué, et fait choisir sa base à run.sh sans bloquer systemd.
--- EN ---
Sixteen commits that predate the todo.py split and therefore still live inside
it: grouping them avoids ruling, one by one, on whether each reads before or
after a 9 500-line move.
Seven make the 12-to-18 chain run, where every bump died differently: a
percent-encoded French anchor that OpenUpgrade glues into a CSS selector, a
failure engraved as done because the progress map returns the stored object, a
rebuilt clone without the preparation that avoids the problem it then meets,
another that replayed only part of its list, xlsxwriter never declared,
web_responsive that only 18 makes incompatible, and "dict | None" evaluated at
import by the 12's venv, on Python 3.7.
Both analyses follow from that: "who depends on whom", because at the 17-to-18
bump the query had to be written by hand, and the i/u/t filters on the
transitional states Odoo should not keep.
The rest opens Proxmox VE, locally then on a remote host, measures what each VM
writes — frozen or compiling, they looked alike — makes monitoring independent
of the install, stops announcing an sshfs mount that failed, and has run.sh
pick its database without blocking systemd.
Assisted-by: Claude Opus 5
« ./run.sh » sans argument partait sans base et l'on choisissait dans le
gestionnaire web. Il choisit maintenant : une seule base, il démarre
dessus ; plusieurs, il affiche un menu numéroté.
Ce qui décide n'est pas le menu mais l'endroit où il ne doit PAS s'ouvrir.
systemd écrit « ExecStart=/bin/bash …/run.sh » sans argument, avec
Restart=always : une question posée là serait une boucle de redémarrage.
Le défaut implicite exige donc un terminal sur stdin ET sur stderr — pas
stdout, qui est toujours un tube dans la substitution qui nous lit.
Mesuré : sans terminal, la ligne d'arguments est identique à l'octet et
la sonde, qui coûte 0,8 s, n'est jamais appelée.
--- EN ---
« ./run.sh » with no argument started without a database and one picked
in the web manager. It now picks: a single database, it starts on it;
several, it shows a numbered menu.
What decides is not the menu but where it must NOT open. systemd writes
« ExecStart=/bin/bash …/run.sh » with no argument and Restart=always: a
question asked there would be a restart loop. The implicit default
therefore requires a terminal on stdin AND on stderr — not stdout, which
is always a pipe inside the substitution that reads us. Measured: with no
terminal the argument line is byte-for-byte identical and the 0.8 s probe
is never called.
Assisted-by: Claude Opus 5
Nouvelle entrée sous QEMU/KVM, avec l'équivalent de ses dix-sept commandes.
Toute la différence tient en une phrase : l'hyperviseur est ailleurs. On
choisit donc l'hôte — VM QEMU locale, adresse, ou ~/.ssh/config — et on le
vérifie : pveversion le prouve, id/sudo décident du privilège, et une clé
d'hôte inconnue s'enregistre par ssh-keyscan plutôt qu'en désactivant le
contrôle.
Quatre pièges trouvés sur un hôte réel. Une Proxmox installée sur Debian n'a
aucun pont : on en propose un INTERNE, car ajouter l'interface physique
déplace l'adresse de l'hôte et coupe la session — à distance, sans retour.
--- EN ---
A new entry under QEMU/KVM, with the counterpart of its seventeen commands.
The whole difference fits in one sentence: the hypervisor is elsewhere. So the
host is chosen — local QEMU VM, address, or ~/.ssh/config — and then checked:
pveversion proves it, id/sudo decide about privilege, and an unknown host key
is recorded with ssh-keyscan rather than by disabling the check.
Four traps found on a real host. A Proxmox installed on Debian has no bridge:
we offer an INTERNAL one, because adding the physical NIC moves the host
address and cuts the session — remotely, with no way back.
Assisted-by: Claude Opus 5
web_responsive avait bien été retiré, et il est revenu. Deux endroits
bâtissent la base intermédiaire : l'étape « Uninstall module », et
« Choose delete missing module » qui la jette et la refait depuis la
version précédente. Le second ne rejouait que les modules choisis là.
Relevé sur test_neutralize_upgrade_18 : retrait au rang 218, clone refait
au rang 230, et la 18 a refusé de charger sur l'exclusion de
muk_web_theme. Les deux chemins passent maintenant par
`uninstall_list_for`, donc ils ne peuvent plus diverger ; un test le
tient par l'AST, pour tout chemin à venir.
--- EN ---
web_responsive had indeed been removed, and it came back. Two places
build the intermediate database: the « Uninstall module » step, and
« Choose delete missing module » which throws it away and rebuilds it
from the previous version. The second replayed only the modules chosen
there.
Traced on test_neutralize_upgrade_18: removal at rank 218, clone rebuilt
at rank 230, and 18 refused to load on muk_web_theme's exclusion. Both
paths now go through `uninstall_list_for`, so they cannot diverge again;
a test holds that through the AST, for any future path.
Assisted-by: Claude Opus 5
Trois filtres sous la main plutôt qu'un cycle à parcourir. « u » est le
seul qui montrait quelque chose d'invisible jusqu'ici : les états de
passage — to install, to upgrade, to remove — qu'Odoo traverse et ne
devrait pas garder. Mesuré sur test_neutralize_upgrade_13 en pleine
migration : 22 modules figés en « to remove ».
L'en-tête les annonce, le rapport texte les nomme avec leur état, et
« non installés » ne les ramasse plus : un module en « to remove » EST
encore installé, il s'en va. La même touche fait l'aller et le retour.
--- EN ---
Three filters under the hand rather than a cycle to walk. « u » is the
only one showing something invisible until now: the transient states —
to install, to upgrade, to remove — that Odoo passes through and should
not keep. Measured on test_neutralize_upgrade_13 mid-migration:
22 modules frozen in « to remove ».
The header announces them, the text report names them with their state,
and « not installed » no longer collects them: a module in « to remove »
IS still installed, it is on its way out. The same key goes and returns.
Assisted-by: Claude Opus 5
Décocher l'installation d'ERPLibre faisait disparaître le tableau de bord. La
case « suivi » vivait DANS le groupe de l'installation, build_spec ne la
recopiait même pas dans la spec, et l'épilogue était gardé par « if install or
desktop » : sans rien à installer, il ne se passait rien.
Le suivi devient un choix du DÉPLOIEMENT. Et sans rien à installer, la
commande distante ne vaut plus « true » — journal vide, ✅ instantané : elle
regarde la VM ARRIVER, attend cloud-init, puis relève système, noyau, adresse,
disque et mémoire. Le journal cesse aussi d'annoncer une installation ERPLibre
qui n'a pas lieu.
--- EN ---
Unchecking the ERPLibre install made the dashboard vanish. The "monitoring"
checkbox lived INSIDE the install group, build_spec did not even copy it into
the spec, and the deploy epilogue was gated by "if install or desktop": with
nothing to install, nothing happened.
Monitoring is now a DEPLOYMENT-level choice. And with nothing to install, the
remote command is no longer "true" — empty log, instant ✅: it watches the VM
ARRIVE, waits for cloud-init, then reports system, kernel, address, disk and
memory. The log also stops announcing an ERPLibre install that never happens.
Assisted-by: Claude Opus 5
Le menu Analyse disait quels modules manquent, jamais qui dépend de qui.
« Puis-je retirer celui-ci » se réglait donc à la main : au palier
17 → 18, il a fallu écrire la requête pour savoir si web_responsive
pouvait partir.
L'écran liste les modules et « d » parcourt quatre relations : ce dont il
dépend, ce qui en dépend, tout ce qu'il entraîne, tout ce qui tombe avec
lui. « f » filtre, « / » cherche — une base en porte trois mille. La
réponse qui compte est écrite en toutes lettres : deux dépendants
déclarés dont zéro installé, c'est un retrait sans danger.
--- EN ---
The Analyse menu told which modules were missing, never which depends on
which. « Can I remove this one » was therefore answered by hand: at the
17 → 18 step we had to write the query to learn whether web_responsive
could go.
The screen lists the modules and « d » walks four relations: what it
needs, what needs it, everything it pulls in, everything that falls with
it. « f » filters, « / » searches — a database holds three thousand of
them. The answer that matters is spelled out: two declared dependents of
which zero installed means removal is safe.
Assisted-by: Claude Opus 5
Proxmox ne publie aucune image cloud : son ISO est un installateur qui formate
le disque. On prend donc la voie que l'amont documente lui-même — Proxmox VE
sur Debian — depuis l'image cloud trixie, partagée avec un déploiement
Debian 13 au lieu d'être téléchargée deux fois.
s390x n'y est pas et n'y sera pas par cette voie : le dépôt n'a aucun index
binary-s390x. arm64 y est, officiel depuis PVE 9. Le catalogue le dit AVANT le
déploiement, au lieu d'échouer au premier apt.
Vérifié sur une VM réelle : pve-manager 9.2.11, noyau 7.0.14-12-pve, quatre
services actifs, interface web en HTTP 200.
--- EN ---
Proxmox publishes no cloud image: its ISO is an installer that formats the
disk. So we take the path upstream documents itself — Proxmox VE on Debian —
from the trixie cloud image, shared with a Debian 13 deployment instead of
being downloaded twice.
s390x is not there and will not be by this route: the repository has no
binary-s390x index. arm64 is, official since PVE 9. The catalog says so BEFORE
the deployment rather than failing at the first apt.
Verified on a real VM: pve-manager 9.2.11, kernel 7.0.14-12-pve, four services
active, web UI answering HTTP 200.
Assisted-by: Claude Opus 5
La migration lance ses outils avec le venv de la version Odoo courante.
Au premier palier c'est celui de la 12, en 3.7, où « dict | None » (3.10)
et « tuple[str, str] » (3.9) sont ÉVALUÉS au chargement du module. La
restauration du zip mourait donc sur un TypeError avant d'avoir rien
fait, dans execute.py — importé par db_restore.py.
`from __future__ import annotations` existe depuis 3.7 et le dépôt s'en
sert déjà dans treize fichiers. Un test le vérifie maintenant sur toute
la fermeture d'imports des outils que le pilote lance, points d'entrée
lus dans le pilote pour que le script ajouté demain soit couvert.
--- EN ---
The migration runs its tools with the venv of the current Odoo version.
At the first step that is 12's, on 3.7, where « dict | None » (3.10) and
« tuple[str, str] » (3.9) are EVALUATED when the module loads. Restoring
the zip therefore died on a TypeError before doing anything at all, in
execute.py — imported by db_restore.py.
`from __future__ import annotations` has existed since 3.7 and the repo
already uses it in thirteen files. A test now checks the whole import
closure of the tools the driver launches, with the entry points read
from the driver so tomorrow's script is covered too.
Assisted-by: Claude Opus 5
Quand OpenUpgrade échoue, le pilote remet le drapeau de clonage à zéro
pour que la base intermédiaire soit refaite depuis la version d'avant.
Mais les étapes qui avaient préparé CE clone gardaient le leur : le SQL
de pré-migration, les désinstallations, les installations. La base neuve
repartait sans sa préparation, et OpenUpgrade retombait sur le problème
même que ce SQL existe pour écarter.
Vu sur test_neutralize_upgrade_18 : clone à refaire, et pourtant
fix_migration_odoo170_to_odoo180.sql déjà consigné comme appliqué.
Les trois drapeaux tombent maintenant avec le clone.
--- EN ---
When OpenUpgrade fails, the driver clears the clone flag so the
intermediate database is rebuilt from the previous version. But the
steps that had prepared THAT clone kept theirs: the pre-migration SQL,
the uninstalls, the installs. The fresh database started without its
preparation, and OpenUpgrade met the very problem that SQL exists to
prevent.
Seen on test_neutralize_upgrade_18: clone pending, yet
fix_migration_odoo170_to_odoo180.sql already recorded as applied.
The three flags now fall with the clone.
Assisted-by: Claude Opus 5
`lst_upgrade_odoo` n'est pas une copie : `dct_progression.get()` rend
l'objet stocké. La commande y était inscrite AVANT de tourner, donc le
premier `write_config()` la gravait — y compris celui du chemin d'échec,
qui remet pourtant le drapeau de clonage à zéro pour forcer un nouvel
essai. La reprise sautait alors OpenUpgrade.
Mesuré sur test_neutralize_upgrade_18, arrêté sur l'erreur des thèmes :
base = 17.0.1.3, clone à refaire, et sa commande de migration 18 déjà
consignée. Relancer aurait laissé une base 17 sous le code 18.
On l'inscrit après la réussite, là où le commentaire la situait déjà.
--- EN ---
`lst_upgrade_odoo` is not a copy: `dct_progression.get()` returns the
stored object. The command was recorded BEFORE it ran, so the first
`write_config()` persisted it — including the one on the failure path,
which resets the clone flag precisely to force a fresh attempt. A resume
then skipped OpenUpgrade.
Measured on test_neutralize_upgrade_18, halted on the theme error:
base = 17.0.1.3, clone pending, and its 18 migration command already
recorded. Resuming would have left a 17 database under 18 code.
We record it after success, where the comment already placed it.
Assisted-by: Claude Opus 5
Monter en 18 mourait sur « MuK Backend Theme et Web Responsive sont
incompatibles ». muk_web_theme n'excluait que web_enterprise en 16 et
en 17 ; la 18 y ajoute web_responsive. Les deux cohabitaient donc
légalement depuis la 12. On retire web_responsive au palier 17 → 18,
pendant que l'état est encore légal ; rien n'en dépend.
Deux défauts trouvés en le câblant. Odoo sort en 0 quand « --uninstall »
ne retire rien : muk_web_theme a traversé quatre paliers en étant réputé
parti. On lit maintenant l'état en base. Et les étapes désinstaller et
installer rangeaient leur drapeau sous la clé de l'étape migration —
à la reprise, OpenUpgrade était sauté pour ces paliers.
--- EN ---
Upgrading to 18 died on « MuK Backend Theme and Web Responsive are
incompatible ». muk_web_theme excluded only web_enterprise in 16 and 17;
18 adds web_responsive. The pair had been legal since 12. We drop
web_responsive at the 17 → 18 step, while the state is still legal;
nothing depends on it.
Wiring it up surfaced two defects. Odoo exits 0 when « --uninstall »
removes nothing: muk_web_theme crossed four steps while believed gone.
We now read the state back from the database. And the uninstall and
install steps stored their flag under the migrate step's key — on
resume, OpenUpgrade was skipped for those steps.
Assisted-by: Claude Opus 5
The 15 bump died on
Unable to upgrade module "report_xlsx" because an external
dependency is not met: Python library not installed: xlsxwriter
report_xlsx declares {"python": ["xlsxwriter", "xlrd"]} and the 15
pyproject held xlrd alone: the pair arrived half. Every other version
from 12 to 18 declares it -- 15 was the only gap.
Version 1.4.5, as in 16 and 17, and well within what Python 3.8
supports. poetry lock --no-update touched exactly one package: nothing
else moved.
--- FR ---
Le palier 15 mourait sur « Python library not installed: xlsxwriter ».
report_xlsx déclare {"python": ["xlsxwriter", "xlrd"]} et le pyproject
de la 15 ne portait que xlrd : la paire est arrivée à moitié. Toutes les
autres versions de 12 à 18 le déclarent — la 15 était le seul trou.
Version 1.4.5, comme en 16 et 17, largement dans ce que Python 3.8
supporte. poetry lock --no-update n'a touché qu'un paquet : rien
d'autre n'a bougé.
Assisted-by: Claude Opus 5
OpenUpgrade's website post-migration gathers the href of every page
anchor and glues them into a CSS selector:
"selector": ", ".join([link.attrib["href"] for link in links])
An href is not a selector. A French anchor written #principes-mn%C3%A9-
moniques puts a % in it, which no CSS identifier may hold, and the whole
migration dies on SelectorSyntaxError.
Proven by replaying that exact code on the database: three views failed
before, one of them with the % at position 53 -- the very position in
the log. After the fix, three views processed, none failed. Decoding is
enough: the parser accepts #principes-mnémoniques and refuses the
encoded form.
Only page views, only anchor hrefs, only %XX in hex. A % elsewhere in a
URL is legitimate and stays. The decoder lives in pg_temp and leaves
nothing behind.
--- FR ---
La post-migration website d'OpenUpgrade ramasse les href des ancres
d'une page et les recolle en sélecteur CSS. Or un href n'est pas un
sélecteur : une ancre française encodée y met un %, interdit dans un
identifiant CSS, et la migration meurt.
Prouvé en rejouant ce code exact sur la base : trois vues échouaient,
dont une avec le % en position 53 — celle du journal. Après correctif,
trois vues traitées, zéro échec. Décoder suffit : le parseur accepte
#principes-mnémoniques et refuse la forme encodée.
Seulement les vues de page, seulement les href d'ancre, seulement les
%XX hexadécimaux. Un % ailleurs dans une URL est légitime et reste. Le
décodeur vit dans pg_temp et ne laisse rien derrière lui.
Assisted-by: Claude Opus 5
Après un code 1, le menu affichait « Monté sur … », la commande pour démonter
et celle pour ouvrir le répertoire : le montage n'avait pas eu lieu, et on
cherchait des fichiers dans un répertoire vide. Le succès ne s'affiche plus
qu'en cas de succès, et le point de montage inutilisé est retiré.
L'échec, lui, avait une cause : sshfs lit « a+b » comme un chaînage d'hôtes et
ne consulte jamais ~/.ssh/config pour l'alias entier. Or c'est todo.py qui
nomme les VM « rebond+domaine », et cette seconde moitié est un domaine
libvirt, pas un alias SSH du rebond. On résout donc l'alias par « ssh -G » et
on rend à sshfs une cible qu'il ne peut plus mal lire, ProxyJump comprise.
--- EN ---
After exit code 1, the menu still printed "Mounted on …", the unmount command
and the file-manager command: nothing had been mounted, and one went looking
for files in an empty directory. The success block now only prints on success,
and the unused mount point is removed.
The failure itself had a cause: sshfs reads "a+b" as host chaining and never
consults ~/.ssh/config for the whole alias. But todo.py is what names VMs
"jump+domain", and that second half is a libvirt domain, not an SSH alias on
the jump host. So we resolve the alias with "ssh -G" and hand sshfs a target
it can no longer misread, ProxyJump included.
Assisted-by: Claude Opus 5
Le tableau disait la durée et la taille du disque. Il ne disait pas si une VM
TRAVAILLAIT : une installation figée et une qui compile s'y ressemblaient.
Trois chiffres par VM, d'un seul appel « virsh domstats » pour tout le parc
(0,03 s) : ce qu'elle écrit, sa RAM occupée/totale, son disque occupé/total.
Le débit est une moyenne sur DIX secondes — le disque d'une installation
travaille par rafales, et l'instantané n'y montrait que des 0 et des pics.
Le ballon mémoire est réarmé au tour lent : sans période de collecte, libvirt
rend le dernier rapport du pilote, vieux d'une demi-heure. Et cinq caractères
récupérés sur trois colonnes trop larges font tenir la ligne en 150 colonnes.
--- EN ---
The table showed elapsed time and disk size. It did not show whether a VM was
WORKING: a stalled install and a compiling one looked alike.
Three numbers per VM, from a single "virsh domstats" call for the whole fleet
(0.03 s): bytes written, RAM used/total, disk used/total. The write figure is
a TEN-second average — an install's disk works in bursts, and the snapshot
showed only zeros and spikes.
The memory balloon is re-armed on the slow tick: with no collection period,
libvirt hands back the driver's last report, half an hour old. And five
characters reclaimed from three oversized columns keep the row inside 150.
Assisted-by: Claude Opus 5
[FIX] release: what the build chain still lacked
Four blockers met on real machines, each silent in its own way.
pyproj needs the proj BINARY, not only its headers, and the distributions
that lag behind the version it wants now get PROJ built from source rather
than a failure three steps later.
A systemd unit launching run.sh died on 203/EXEC -- the code systemd
returns when it cannot execute, which says nothing about why. Going
through bash makes the reason visible.
pykcs11 does not compile with SWIG 4.3 and above without help.
A make target runs the unit tests, with the mobile dependency declared, so
the suite can be run without knowing which extras it needs. One test was
checking the mode umask decides rather than the exec bit git stores, and
passed or failed depending on the machine.
--- FR ---
Quatre blocages rencontrés sur des machines réelles, chacun muet à sa
façon.
pyproj exige le BINAIRE proj, pas seulement ses en-têtes, et les
distributions en retard sur la version voulue reçoivent désormais un PROJ
bâti depuis les sources plutôt qu'un échec trois étapes plus loin.
Une unité systemd lançant run.sh mourait sur 203/EXEC — le code que
systemd rend quand il ne peut pas exécuter, et qui ne dit rien du
pourquoi. Passer par bash rend la raison visible.
pykcs11 ne se compile pas sans aide avec SWIG 4.3 et au-delà.
Une cible make lance les tests unitaires, avec la dépendance mobile
déclarée, pour que la suite se lance sans savoir quels extras elle exige.
Un test vérifiait le mode que décide umask plutôt que le bit d'exécution
que stocke git, et passait ou échouait selon la machine.
Assisted-by: Claude Opus 5
The Unreleased section described the previous cycle. It named the COW
tools and the QEMU deployment, then stopped -- and this branch is mostly
what came after: an Odoo migration that drives itself, a state screen, a
quality report, and the repairs each bump turned out to need.
Twenty-one entries, fourteen of them Added. Read from the commits rather
than from memory, and grouped by what a reader would look for: the
migration run, its state, its quality, its repairs, its smoke tests. The
five commits that only touch documentation or tests are left out; the
ones that change what the tool does are all there.
Nothing already listed is repeated. The COW tools, the analysis toolkit
and the deployment form keep the entries they had.
--- FR ---
La section Unreleased décrivait le cycle précédent. Elle nommait les
outils COW et le déploiement QEMU, puis s'arrêtait — or cette branche est
surtout ce qui a suivi : une migration Odoo qui se conduit seule, un écran
d'état, un rapport de qualité, et les réparations que chaque palier a
révélées nécessaires.
Vingt et une entrées, dont quatorze sous Ajouté. Lues dans les commits
plutôt que de mémoire, et regroupées selon ce qu'un lecteur cherche :
l'exécution de la migration, son état, sa qualité, ses réparations, ses
tests de fumée. Les cinq commits qui ne touchent que la documentation ou
les tests sont écartés ; ceux qui changent ce que fait l'outil y sont
tous.
Rien de déjà listé n'est redit. Les outils COW, la boîte à outils
d'analyse et le formulaire de déploiement gardent leurs entrées.
Assisted-by: Claude Opus 5
Running the suite for real turned up seven errors I had just caused. The
fake probe took one argument, and probe_master_password now takes two.
Worse than the signature: two assertions checked that the probed command
CONTAINED "--master_password=bon". They pinned exactly the exposure the
previous commit removed -- a test can hold a defect in place as firmly as
it holds a guarantee.
They now assert the opposite, which is the property worth keeping: the
password reaches the probe beside the command, and the command carries
neither the value nor the option.
--- FR ---
Exécuter la suite pour de vrai a fait apparaître sept erreurs que je
venais de causer. La fausse sonde prenait un argument, et
probe_master_password en prend désormais deux.
Pire que la signature : deux assertions vérifiaient que la commande sondée
CONTENAIT « --master_password=bon ». Elles verrouillaient exactement
l'exposition que le commit précédent a retirée — un test tient un défaut
en place aussi fermement qu'une garantie.
Elles affirment maintenant l'inverse, qui est la propriété à conserver :
le mot de passe parvient à la sonde à CÔTÉ de la commande, et la commande
ne porte ni la valeur ni l'option.
Assisted-by: Claude Opus 5
Same exposure as the master password, same fix. kdbx_manager put the Odoo
password straight into the web_login command; /proc/<pid>/cmdline is
readable by every user on the machine, and no downstream filter reaches
that.
The command now carries the NAME of an environment variable, never the
value. One name per entry, because several credentials go out in a single
"parallel" call and a single variable could not tell them apart.
get_extra_command_user therefore returns (fragments, variables), and the
two call sites hand the variables to exec_command_live, which already
merged an environment.
Two things found on the way. web_login re-sent config.default_password_auth
when it retried after dismissing a modal, ignoring whatever the caller had
passed -- the retry silently fell back to "admin". And install_forgejo
printed the admin password back to the terminal, hence into the install log
and any CI capture; its own header already documents the default.
A test pins the guarantee: the fragment must not contain the password.
--- FR ---
Même exposition que pour le mot de passe maître, même correctif.
kdbx_manager mettait le mot de passe Odoo directement dans la commande
web_login ; /proc/<pid>/cmdline est lisible par tout utilisateur de la
machine, et aucun filtre en aval ne l'atteint.
La commande porte désormais le NOM d'une variable d'environnement, jamais
la valeur. Un nom par entrée, car plusieurs identifiants partent dans un
seul appel « parallel » et une variable unique ne saurait les distinguer.
get_extra_command_user rend donc (fragments, variables), et les deux
appelants confient les variables à exec_command_live, qui fusionnait déjà
un environnement.
Deux trouvailles en chemin. web_login renvoyait config.default_password_auth
à la reprise après une modale, ignorant ce que l'appelant avait fourni — la
reprise retombait en silence sur « admin ». Et install_forgejo réaffichait
le mot de passe administrateur, donc dans le journal d'installation et
toute capture de CI ; son propre en-tête documente déjà le défaut.
Un test verrouille la garantie : le fragment ne doit pas porter le secret.
Assisted-by: Claude Opus 5
Redacting what we print treats the symptom. The password was still an
argument, and /proc/<pid>/cmdline is readable by EVERY user on the
machine for as long as the command runs -- an exposure no filter reaches.
It now travels in MASTER_PWD. The probe sets it on the child it spawns;
once accepted it is placed in this process's environment, so every later
call inherits it without argv ever carrying it. /proc/<pid>/environ is
readable only by its owner.
Worth knowing for anyone reading the old code: the option was appended to
every invocation, but odoo's db command reads it in the drop branch
alone. list, restore and clone were carrying a secret they never used.
The redaction stays. It is the last line, not the first, and other
options still put secrets on command lines.
--- FR ---
Caviarder ce qu'on affiche traite le symptôme. Le mot de passe restait un
argument, et /proc/<pid>/cmdline est lisible par TOUT utilisateur de la
machine tant que la commande tourne — une exposition qu'aucun filtre
n'atteint.
Il voyage désormais dans MASTER_PWD. La sonde le pose sur l'enfant
qu'elle lance ; une fois accepté, il est placé dans l'environnement de ce
processus, si bien que tous les appels suivants en héritent sans qu'argv
le porte jamais. /proc/<pid>/environ n'est lisible que par son
propriétaire.
À savoir pour qui relit l'ancien code : l'option était ajoutée à chaque
invocation, alors que la commande db d'odoo ne la lit que dans la branche
drop. list, restore et clone portaient un secret dont ils ne faisaient
rien.
Le caviardage reste. Il est le dernier rempart, pas le premier, et
d'autres options mettent encore des secrets sur des lignes de commande.
Assisted-by: Claude Opus 5
CodeQL raised seven high-severity alerts on this branch. Three were real,
and the same secret was behind all of them: the Odoo master password,
which db_restore appends to its command line as soon as the database
declares one.
The command itself was printed raw -- "print(arg)" -- so the password
reached stdout, and any terminal capture with it. The probe output was
logged raw too, and a refused attempt echoes the command it tried.
Wider than that: the runner filtered the command it was about to run, but
not what came back. A tool that reprints its own arguments -- "set -x", a
traceback, odoo_bin.sh -- put the secret straight back into the terminal
AND into the log file the sink writes. Every subprocess line now goes
through the same filter as the command.
The four remaining alerts sit on expressions already wrapped in
redact_secrets(). CodeQL does not cross re.sub, so it cannot see the
barrier; the mitigation is real and they are false positives.
--- FR ---
CodeQL a levé sept alertes de sévérité haute sur cette branche. Trois
étaient réelles, et le même secret était derrière : le mot de passe maître
d'Odoo, que db_restore ajoute à sa ligne de commande dès que la base en
exige un.
La commande elle-même était imprimée telle quelle — « print(arg) » — donc
le mot de passe atteignait la sortie standard, et toute capture de
terminal avec elle. La sortie de la sonde était journalisée brute
également, et un essai refusé réaffiche la commande tentée.
Plus large : le lanceur filtrait la commande qu'il allait exécuter, mais
pas ce qui en revenait. Un outil qui réaffiche ses propres arguments —
« set -x », une trace, odoo_bin.sh — remettait le secret dans le terminal
ET dans le fichier de journal. Chaque ligne du sous-processus passe
désormais par le même filtre que la commande.
Les quatre alertes restantes portent sur des expressions déjà entourées de
redact_secrets(). CodeQL ne franchit pas re.sub et ne voit donc pas la
barrière ; la mitigation est réelle, ce sont des faux positifs.
Assisted-by: Claude Opus 5
Toute installation d'Odoo 14, 15 ou 17 échoue depuis que SWIG 4.5 est paru
sur PyPI : « ‘PyInt_FromLong’ was not declared in this scope », 55 fois.
pykcs11 — tiré par endesive — ne livre aucun wrapper pré-généré, et son
« requires = ["swig"] » n'est pas borné : c'est la DERNIÈRE version publiée
qui tourne, pas celle du système. Or SWIG 4.3 a retiré les alias Python 2
qu'il écrivait lui-même, et le typemap CK_RV de pykcs11 en utilise un.
On rend l'alias au préprocesseur, identique token pour token à celui de
SWIG 4.2. CPPFLAGS et non CFLAGS : un .cpp passe par compiler_so_cxx.
Vérifié sur la VM et ici : poetry install rend 0, import PyKCS11 passe.
--- EN ---
Every Odoo 14, 15 and 17 install has been failing since SWIG 4.5 landed on
PyPI: "'PyInt_FromLong' was not declared in this scope", 55 times. pykcs11
— pulled in by endesive — ships no pre-generated wrapper, and its
`requires = ["swig"]` is unbounded: the LATEST published version runs, not
the system one. SWIG 4.3 dropped the Python 2 aliases it used to emit
itself, and pykcs11's CK_RV typemap uses one of them.
We hand the alias back to the preprocessor, token for token identical to
SWIG 4.2's. CPPFLAGS, not CFLAGS: a .cpp goes through compiler_so_cxx.
Verified on the VM and here: poetry install returns 0, import PyKCS11 works.
Assisted-by: Claude Opus 5
Ces 382 tests ne tournaient que lancés à la main, donc jamais. « make test »
demande une base de données et plusieurs minutes ; ceux-ci lisent le code et
exécutent les fragments de shell générés, sudo, pgrep et pkill bouchonnés, en
une dizaine de secondes. Deux cibles : test_unit, et test_unit_file pour la
boucle d'écriture.
La dépendance à mobile/erplibre_home_mobile est DITE plutôt que supposée : le
lanceur l'annonce présente ou absente, et les tests du vrai transfert se
déclarent ignorés — avec la commande qui manque — au lieu de passer en silence.
Vérifié dans les trois états : dépôt absent, présent non compilé, compilé.
Au passage, compile_and_run.sh vérifie le transfert des dépôts, comme
l'installation d'une VM et par le même script.
--- EN ---
These 382 tests only ran when invoked by hand, so never. "make test" wants a
database and several minutes; these read the code and run the generated shell
fragments with sudo, pgrep and pkill stubbed, in about ten seconds. Two targets:
test_unit, and test_unit_file for the writing loop.
The dependency on mobile/erplibre_home_mobile is STATED rather than assumed: the
runner announces it present or absent, and the real-transfer tests declare
themselves skipped — naming the missing command — instead of passing quietly.
Checked in all three states: repo absent, present but unbuilt, built.
Along the way, compile_and_run.sh verifies the repo transfer, like a VM install
and through the same script.
Assisted-by: Claude Opus 5
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)
erplibre.service mourait en 3 ms sur openSUSE s390x, « status=203/EXEC »,
sans jamais entrer dans le script. Ce code ne dit pas que run.sh a
echoue : il dit que systemd n'a pas pu l'EXECUTER.
Quatre causes le produisent — bit x absent, shebang qui ne resout pas,
/home monte noexec, SELinux refusant l'execve (Leap 16 est passe a
SELinux). Les distinguer demande un acces a la machine ; les traiter
ensemble ne le demande pas.
Passe a « /bin/bash run.sh », le fichier n'est plus qu'une donnee lue :
noexec et SELinux ne portent que sur l'execve, et le bit x devient sans
objet. Mesure : un script en 644 refuse en direct, execute par bash.
Les trois generateurs ecrivaient la meme ligne, les trois sont corriges.
Le venv n'y est pour rien — odoo_bin.sh l'active deja, et c'est celui
d'Odoo, pas celui des outils.
--- EN ---
erplibre.service died in 3 ms on openSUSE s390x, "status=203/EXEC",
never entering the script. That code does not say run.sh failed: it says
systemd could not EXECUTE it.
Four causes produce it — missing x bit, unresolvable shebang, /home
mounted noexec, SELinux denying execve (Leap 16 switched to SELinux).
Telling them apart needs access to the machine; handling them together
does not.
Run as "/bin/bash run.sh", the file is merely data being read: noexec
and SELinux only cover execve, and the x bit becomes moot. Measured: a
644 script refused directly, executed fine through bash.
All three generators wrote the same line; all three are fixed. The venv
is not involved — odoo_bin.sh already activates it, and it is Odoo's,
not the tooling one.
Assisted-by: Claude Opus 5
(cherry picked from commit 6f8cee84b72fd016fa188d204f280b011594627c)
openSUSE eclate PROJ en trois paquets — libproj25 la bibliotheque,
proj-devel les en-tetes, proj les outils. Seul proj-devel etait pose, et
il ne tire PAS le troisieme.
pyproj n'a pas de roue s390x : il compile, et sa configuration execute
« proj » pour localiser l'installation. D'ou l'arret sur « proj
executable not found. Please set the PROJ_DIR variable », en plein
milieu d'un poetry install, sans que rien n'ait manque plus tot.
apt nommait deja proj-bin. dnf s'en remettait a une arete transitive :
elle tient sur RHEL, elle manque sur openSUSE. On la nomme donc partout
plutot que d'en dependre.
--- EN ---
openSUSE splits PROJ into three packages — libproj25 the library,
proj-devel the headers, proj the tools. Only proj-devel was installed,
and it does NOT pull the third.
pyproj has no s390x wheel: it builds, and its configuration runs "proj"
to locate the installation. Hence the stop on "proj executable not
found. Please set the PROJ_DIR variable", mid poetry install, with
nothing missing earlier.
apt already named proj-bin. dnf relied on a transitive edge: it holds on
RHEL, it is absent on openSUSE. So we name it everywhere rather than
depend on it.
Assisted-by: Claude Opus 5
(cherry picked from commit c02805a42eebf23380762ff6fc56db0aec1680b5)
[ADD] release: look at a database before trusting it
Three questions a restored or migrated database cannot answer on its own,
and now can.
Which website copies shadow a view, and how far they have drifted from
it -- the diff is shown per copy rather than left to be guessed.
Which modules the database lacks against the default package, with an
offer to install those that are ready. The suggestion is not blind: a
module that would not install is not proposed.
Whether the filestore actually landed. A restore that dropped its
attachments looked identical to one that did not. The check says whether
the file is missing, whether the record behind it still exists, and
offers the cleanups -- purging once at the end rather than record by
record, and reporting the 30 MB it recovered.
Along the way, db_restore asks the master password again instead of dying
on a typo: an hour of bumps was a steep price for one letter.
--- FR ---
Trois questions auxquelles une base restaurée ou migrée ne savait pas
répondre seule, et qu'elle sait maintenant.
Quelles copies de site masquent une vue, et de combien elles s'en sont
écartées — l'écart est montré copie par copie plutôt que laissé à deviner.
Quels modules manquent à la base par rapport au paquet par défaut, avec
une offre d'installer ceux qui sont prêts. La suggestion n'est pas
aveugle : un module qui ne s'installerait pas n'est pas proposé.
Si le filestore est réellement arrivé. Une restauration qui avait perdu
ses pièces jointes ressemblait trait pour trait à une réussie. La
vérification dit si le fichier manque, si l'enregistrement derrière existe
encore, et propose les nettoyages — en purgeant une fois à la fin plutôt
qu'enregistrement par enregistrement, et en annonçant les 30 Mo récupérés.
Au passage, db_restore redemande le mot de passe maître au lieu de mourir
sur une faute de frappe : une heure de paliers était cher payé pour une
lettre.
Assisted-by: Claude Opus 5
It was asked once. Wrong, and Odoo raises AccessDenied, check_output
raises CalledProcessError, nothing catches it, and the migration dies on
a traceback. After an hour of version bumps that is a steep price for
one letter. Ten attempts now.
Only a refused PASSWORD is asked again. Any other failure stops and is
shown: asking ten times in front of an unreachable database would hide
the real fault behind a prompt, and one would hunt for a password.
AccessDenied is matched on the class, never on its message, which is
translated.
The attempt is probed with --list, which changes nothing. Validating
here avoids failing half-way, once the database has already been
dropped.
--- FR ---
Il était demandé une fois. Faux, et Odoo lève AccessDenied,
check_output lève CalledProcessError, rien ne l'attrape, la migration
meurt sur une trace. Après une heure de paliers, c'est cher payé pour
une lettre. Dix essais désormais.
Seul un MOT DE PASSE refusé fait reposer la question. Tout autre échec
arrête et s'affiche : dix invites devant une base injoignable
cacheraient la panne, et l'on chercherait un mot de passe. AccessDenied
se reconnaît à la CLASSE, jamais au message, qui est traduit.
L'essai est éprouvé sur --list, qui ne modifie rien. Valider là évite
d'échouer à mi-parcours, une fois la base déjà supprimée.
Assisted-by: Claude Opus 5
Not between bumps, and the measurement says why: two to eleven fields
vanish at one step and COME BACK at the next -- hr.employee.phone,
account.move.statement_id. "The field is gone" is a transient state
while a migration runs. And there would be nothing to gain: 1881 dead
rows appear at the 13 bump and the count never moves again, so one
final pass takes them all.
The nesting is born once, at the restore, and the clone copies it
identically into every step -- the six databases carried the same 1168
files. It is offered where it is born, never on a closed stdin.
Widened too: the tool was named after missing files and so looked only
at those. 1860 rows in 18 hold a live file for a field that is gone --
31 MB of res.partner.image and thumbnails from before Odoo 13 computed
them. Odoo's collector will never touch them while the row exists.
--- FR ---
Pas entre les paliers, et la mesure dit pourquoi : deux à onze champs
disparaissent à une étape et REVIENNENT à la suivante --
hr.employee.phone, account.move.statement_id. « Le champ n'existe plus »
est transitoire tant que la migration court. Et il n'y aurait rien à y
gagner : 1881 lignes mortes naissent au palier 13 et le compte ne bouge
plus, donc une passe finale les prend toutes.
Le nichage naît une fois, à la restauration, et le clone le recopie
partout — les six bases portaient les mêmes 1168 fichiers. Il se répare
là où il naît, jamais sur un stdin fermé.
Élargi aussi : l'outil portait le nom des fichiers absents et ne
regardait donc qu'eux. 1860 lignes en 18 retiennent un fichier bien
présent pour un champ disparu — 31 Mo d'images res.partner et de
vignettes d'avant qu'Odoo 13 ne les calcule.
Assisted-by: Claude Opus 5
Deduplicating by file was right for COUNTING and wrong for DELETING:
twenty-two rows shared two files, so the purge only ever offered one at
a time and had to be replayed. It now gathers every row whose own field
is dead, and never a live row sharing the same file.
"root" held the root of all filestores instead of this database's
directory, so tidying looked for a nested folder at
<data_dir>/filestore/filestore and answered "nothing to tidy" in front
of 1168 stranded files. It now finds 112 to move up and 1056 duplicates.
limit=0 means "no cap" everywhere else, but the slice [:0] is empty:
"Show every entry" printed "… 3 more" and showed none of them.
The report was captured once, so after a purge it replayed the state
from before -- one then purged rows already gone, believing the work
unfinished. A repair now says whether it did something, and the report
is re-read when it did.
"DELETE 0" was announced as a success. The count now comes from what
PostgreSQL said, and saying nothing is not the same as deleting nothing.
--- FR ---
Dédupliquer par fichier était juste pour COMPTER et faux pour EFFACER :
vingt-deux lignes partageaient deux fichiers, la purge n'en offrait
qu'une à la fois. Elle prend maintenant toutes les lignes dont le champ
est mort, et jamais une ligne vivante partageant le même fichier.
« root » portait la racine de tous les filestores au lieu du dossier de
la base : le rangement cherchait à <data_dir>/filestore/filestore et
répondait « rien à ranger » devant 1168 fichiers échoués. Il en trouve
112 à remonter et 1056 doublons.
limit=0 veut dire « tout » partout ailleurs, mais [:0] est vide : « Tout
afficher » annonçait « … 3 de plus » sans en montrer un seul.
Le rapport n'était lu qu'une fois : après une purge il rejouait l'état
d'avant, et l'on repurgeait des lignes déjà effacées. Une réparation dit
maintenant si elle a fait quelque chose, et le rapport est relu alors.
« DELETE 0 » passait pour un succès. Le compte vient de ce que
PostgreSQL a annoncé, et ne rien dire n'est pas ne rien supprimer.
Assisted-by: Claude Opus 5
"Show every entry" was the only bare label in menus where every other
line carried one, so it read as an oversight -- and it was. It takes
the 📜 that "Show every table" already uses for the same gesture, and
"List the known packages" gets one too rather than being left as the
last bare line.
The guard reads the labels straight out of the _analyse_follow_up calls
and checks both languages, so the next entry added without an icon
fails here instead of being noticed six months later. A second test
bounds the extraction: were it to stop finding anything, the first
would pass while checking nothing.
--- FR ---
« Tout afficher » était le seul libellé nu dans des menus où toutes les
autres lignes en portaient une : ça se lisait comme un oubli, et c'en
était un. Il prend le 📜 qu'« Afficher toutes les tables » utilise déjà
pour le même geste, et « Lister les packages connus » en reçoit une
plutôt que de rester la dernière ligne nue.
Le garde lit les libellés directement dans les appels à
_analyse_follow_up et vérifie les deux langues : la prochaine entrée
sans icône tombera là, pas dans l'œil de quelqu'un six mois plus tard.
Un second test borne l'extraction — si elle ne trouvait plus rien, le
premier passerait sans rien vérifier.
Assisted-by: Claude Opus 5
A lost image on a deleted task is not a loss -- nobody will ever look
for it. On a LIVING task it is one, and it is the only one worth
regretting. The report now says which: project.task #15 and
calendar.event #1 both still exist, so those two really are gone.
Three states, not two: "could not check" must not read as "it is gone",
or a real loss gets filed as a false alarm.
Two repairs sit in the follow-up menu. Purging rows whose field no
longer exists deletes by ID, never by a rebuilt domain -- replaying the
reasoning in SQL would open the door to deleting more than was shown.
Tidying the nested filestore moves up what is missing and deletes pure
duplicates, never overwriting a file already in place.
--- FR ---
Une image perdue sur une tâche supprimée n'est pas une perte : personne
ne la cherchera. Sur une tâche VIVANTE, c'en est une, et la seule à
regretter. Le rapport le dit : project.task #15 et calendar.event #1
existent encore, ces deux-là sont bien perdues.
Trois états, pas deux : « pas pu vérifier » ne doit pas se lire « a
disparu », sans quoi une vraie perte passe pour une fausse alerte.
Deux réparations dans le menu de suite. La purge efface par IDENTIFIANT,
jamais par un domaine reconstruit -- rejouer le raisonnement en SQL
ouvrirait la porte à effacer plus que ce qui a été montré. Le rangement
remonte ce qui manque et supprime les doublons purs, sans jamais
écraser un fichier déjà en place.
Assisted-by: Claude Opus 5
Odoo's shutil.move renames when the destination is absent and NESTS when
it exists, so a leftover filestore/<db>/ sends a whole backup into
filestore/<db>/filestore/, where Odoo never looks. That happened once
here and the clone copied it into all seven databases of the chain --
1168 files, 133 MB each, and nothing said a word.
The check runs after a real restore only. A clone copies its source as
it stands, faults included: checking the mirror would say the same thing
twice, and in the wrong place. It warns and names the fix rather than
aborting -- the database is restored and usable, it is the layout that
is wrong.
--- FR ---
Le shutil.move d'Odoo renomme quand la destination est absente et
IMBRIQUE quand elle existe : un filestore/<base>/ resté là envoie toute
une sauvegarde dans filestore/<base>/filestore/, où Odoo ne regarde
jamais. C'est arrivé une fois ici et le clone l'a recopié dans les sept
bases de la chaîne -- 1168 fichiers, 133 Mo chacune, sans un mot.
Le contrôle ne suit qu'une vraie restauration. Un clone recopie sa
source telle quelle, défauts compris : contrôler le miroir dirait deux
fois la même chose, au mauvais endroit. Il avertit et nomme la
correction plutôt que d'interrompre -- la base est restaurée et
utilisable, c'est la disposition qui cloche.
Assisted-by: Claude Opus 5
"254 attachment files missing" leaves nothing to decide. The useful
split is how many are gone and how many are lying around. Measured on
the migrated 18: three are lost, one waits in a backup zip, and 250
point at a field that no longer exists -- res.country.image is
image_url, computed, since 13, so nothing reads them and there is
nothing to recover.
The tool searches the other databases' filestores, the nested ones Odoo
never reads, and the backup zips' central directory. Only the truly lost
are listed one by one; naming the rest would bury them.
--- FR ---
« 254 fichiers absents » ne laisse rien à décider. Le partage utile est
entre ce qui est perdu et ce qui traîne quelque part. Mesuré sur la 18
migrée : trois sont perdus, un attend dans une sauvegarde, et 250
pointent vers un champ disparu -- res.country.image est image_url,
calculé, depuis la 13 : rien ne les lit, rien à récupérer.
L'outil cherche dans les filestores des autres bases, dans les
filestores imbriqués qu'Odoo ne lit jamais, et dans le répertoire
central des sauvegardes. Seuls les vrais perdus sont listés un à un ;
nommer les autres les enterrerait.
Assisted-by: Claude Opus 5
After the report, only the "available" ones are offered — an unknown
module is not in the addons path and an uninstallable one has a broken
dependency, so listing them would buy three failures. How many were
left out is stated, else the count would look like a bug.
This is the only write in the Analyse menu, so its header no longer
claims otherwise. Three guards: the checkout must match the database
version (an Odoo 18 run against a 12 rewrites it before failing), both
questions default to no, and a rejected token is always shown.
--- FR ---
Après le rapport, seuls les « available » sont proposés — un module
inconnu n'est pas dans le chemin des addons, un cassé a une dépendance
morte : les lister achèterait trois échecs. Le nombre d'écartés est dit,
sinon l'écart de comptage passerait pour un bogue.
C'est la seule écriture du menu Analyse, dont l'en-tête ne prétend donc
plus le contraire. Trois garde-fous : le checkout doit être sur la
version de la base (un Odoo 18 lancé sur une 12 la réécrit avant
d'échouer), les deux questions valent non par défaut, et un jeton
refusé est toujours montré.
Assisted-by: Claude Opus 5
It shipped without the execute bit while carrying a shebang and a main,
so it only ran when prefixed with python3 — and nothing said so before
the attempt. The new test ties the two together in BOTH directions: a
library module marked executable invites a run it cannot serve.
--- FR ---
Livré sans le bit d'exécution alors qu'il porte un shebang et un main :
il ne se lançait qu'en le préfixant de python3, et rien ne le signalait
avant l'essai. Le test neuf lie les deux dans LES DEUX SENS — un module
de bibliothèque marqué exécutable invite à un lancement impossible.
Assisted-by: Claude Opus 5
image_db.py --check_addons_exist asks whether a module is on DISK.
Nothing asked whether a given DATABASE has it. After six migration
steps, that is the question: the 18 instance grown from 12 has only 4
of the 15 modules odoo18.0_base ships.
Five verdicts, not one "missing": an available module installs, an
unknown one needs the addons path repaired first, an uninstallable one
has a broken dependency no install will work around.
shortdesc is varchar up to 15 and jsonb after, and step databases of
both shapes appear in one session — so the column type is read, never
assumed.
--- FR ---
image_db.py --check_addons_exist demande si un module est sur le
DISQUE. Personne ne demandait si une BASE donnée l'a. Après six paliers,
c'est pourtant la question : l'instance 18 issue de la 12 n'a que 4 des
15 modules d'odoo18.0_base.
Cinq verdicts, pas un « manquant » : un module disponible s'installe, un
inconnu exige d'abord de réparer le chemin des addons, un cassé a une
dépendance qu'aucune installation ne contournera.
shortdesc est varchar jusqu'en 15 et jsonb ensuite, et les deux formes
se présentent dans la même session — le type est lu, jamais supposé.
Assisted-by: Claude Opus 5
The analysis counted 62 website copies and pointed at other tools to judge
them. But the comparison that matters for a copy needs no registry at all:
both arches are in the database, paired by key — the very pairing Odoo makes.
So it works where the module-source comparison is refused, on a database whose
version differs from the checkout, and on a backup zip.
On the 12.0 database at hand, where the other comparison cannot run: 47 of the
62 copies have a twin, all 47 compared in under a second, 12 differ. The other
35 are byte-for-byte identical to their module view — they carry no
customization at all, which is what decides whether neutralizing costs
anything.
The fields are named as the module comparison names them, so the full-screen
browser and the text report work without knowing which comparison produced the
data. A copy without a twin is left alone: it is a page made in the editor,
with nothing to compare against.
Checked on that database and on a real backup; 8 tests, including that
re-indentation alone is not a difference and that a missing arch yields no
verdict rather than « identical ».
--- FR ---
L'analyse comptait 62 copies de site web et renvoyait vers d'autres outils
pour les juger. Or la comparaison qui compte pour une copie n'a besoin d'aucun
registre : les deux arch sont dans la base, appariées par la clé — exactement
l'appariement que fait Odoo. Elle marche donc là où celle avec la source du
module est refusée : une base dont la version diffère du checkout, et une
sauvegarde zip.
Sur la base 12.0 en cours, où l'autre comparaison ne peut pas tourner : 47 des
62 copies ont une jumelle, les 47 comparées en moins d'une seconde, 12
diffèrent. Les 35 autres sont identiques octet pour octet à leur vue de module
— elles ne portent aucune personnalisation, ce qui décide si les neutraliser
coûte quelque chose.
Les champs portent les noms de la comparaison avec le module, donc l'écran de
navigation et le rapport texte marchent sans savoir laquelle des deux a
produit la donnée. Une copie sans jumelle est laissée telle quelle : c'est une
page faite dans l'éditeur, il n'y a rien à quoi la comparer.
Vérifié sur cette base et sur une vraie sauvegarde ; 8 tests, dont qu'une
ré-indentation seule n'est pas un écart et qu'une arch absente ne rend aucun
verdict plutôt que « identique ».
Assisted-by: Claude Opus 5
[ADD] release: a VM you can develop in, from the TODO menu
A deployed VM was a server. It can now be a workstation: PyCharm,
Android Studio, GNOME extensions, an Android emulator and an adb tunnel
for scrcpy that needs no X11. The mobile app is built and tested inside
it, and the VM fails if the build does.
Debian reaches s390x, where no cloud image is published, through
debian-installer -- a fixed address per VM because the initrd cannot do
DHCP there, network-console disabled by the lever d-i provides, and the
machine powered back on once the installer is done.
Hardware is set per machine rather than per fleet: the host GPU, the CPU
mode, the screens, the network. virt-viewer opens a screen from the menu,
and a VM greets its SSH login with the commands of its own distribution.
Forgejo comes along as a tickable option: a git forge on the host, for
sharing code between machines without leaving the network.
--- FR ---
Une VM déployée était un serveur. Elle peut désormais être un poste de
travail : PyCharm, Android Studio, extensions GNOME, un émulateur Android
et un tunnel adb pour scrcpy qui ne demande aucun X11. L'application
mobile y est compilée et testée, et la VM échoue si la compilation échoue.
Debian atteint s390x, où aucune image cloud n'est publiée, par
debian-installer — une adresse fixe par VM car l'initrd n'y sait pas faire
de DHCP, network-console désactivé par le levier que d-i prévoit, et la
machine rallumée une fois l'installateur terminé.
Le matériel se règle par machine et non par parc : le GPU de l'hôte, le
mode CPU, les écrans, le réseau. virt-viewer ouvre un écran depuis le
menu, et une VM accueille sa connexion SSH avec les commandes propres à sa
distribution.
Forgejo vient avec : une forge git sur l'hôte, en option cochable, pour
partager du code entre machines sans quitter le réseau.
Assisted-by: Claude Opus 5
Le formulaire matériel ne réglait que vCPU, RAM, 3D et démarrage. Trois
manques : le mode CPU, qui décide si on peut virtualiser DANS la VM, les
écrans du virtio-gpu, et le réseau — dont le passage au pont, seul moyen
d'exposer la VM sur le LAN.
La vram n'est pas offerte : domxml-to-native prouve que QEMU ne la reçoit
jamais sur un virtio-gpu, seul max_outputs y arrive.
Vérifié sur un domaine jetable et un pont d'essai : max_outputs=2, -cpu
host, vnet sur le pont, MAC et emplacement PCI conservés. 486 tests.
--- EN ---
The hardware form only set vCPU, RAM, 3D and autostart. Three gaps: the CPU
mode, which decides whether one can virtualize INSIDE the VM, the virtio-GPU
screens, and the network — including the switch to a bridge, the only way to
put the VM on the LAN.
vram is not offered: domxml-to-native proves QEMU never receives it on a
virtio-GPU, only max_outputs gets through.
Verified on a throwaway domain and a test bridge: max_outputs=2, -cpu host,
vnet on the bridge, MAC and PCI slot preserved. 486 tests.
Assisted-by: Claude Opus 5
Une VM graphique sans accélération rend tout par le processeur : le bureau,
et l'émulateur Android qui tourne dedans — 32 % d'images en retard, mesuré.
Le déploiement prend donc le GPU de l'hôte dès qu'un nœud de rendu existe.
Une VM déjà installée n'avait aucune voie : ni vCPU, ni RAM, ni 3D. Le menu
d'état les règle maintenant, pendant qu'elle est éteinte — le seul moment où
libvirt les lit.
Trois pièges du terrain : « --memory N » ne touche que le ballon, l'ajout
d'egl-headless n'est pas idempotent, et son retrait sans cible emporte la
console VNC. Vérifié sur un domaine jetable, 459 tests verts.
--- EN ---
A graphical VM without acceleration renders everything on the CPU: the
desktop, and the Android emulator inside it — 32 % janky frames, measured.
The deployment now takes the host GPU as soon as a render node exists.
An installed VM had no path at all: no vCPU, no RAM, no 3D. The state menu
now sets them while the VM is shut off — the only moment libvirt reads them.
Three field traps: "--memory N" only moves the balloon, adding egl-headless
is not idempotent, and removing it untargeted takes the VNC console with it.
Verified on a throwaway domain, 459 tests green.
Assisted-by: Claude Opus 5
Écrire hw.lcd.* dans le config.ini de l'AVD ne servait à rien : l'émulateur
réécrit ce fichier depuis le profil du téléphone au premier démarrage, et l'AVD
repartait en 1080x2400 densité 420 — quatre fois les pixels voulus. Constaté sur
la VM, où le réglage était censé s'appliquer depuis des semaines.
La taille passe donc au lancement, et la DENSITÉ avec elle. C'est ce point qui
surprend, et il est mesuré sur une charge identique : 540x1140 en densité 420 est
PIRE que le plein écran — 81 ms de médiane contre 40, 57 % d'images en retard
contre 37, tout étant rendu énorme. En densité 240 : 38 ms, 32 %, et le 99e
centile tombe de 950 ms à 250.
« -no-snapshot-save » vient avec : ce menu propose de tuer l'émulateur par
pkill, et le lancement suivant mourait alors sur « A snapshot operation is
pending ». Vérifié après un pkill : plus aucun FATAL.
--- EN ---
Writing hw.lcd.* into the AVD's config.ini did nothing: the emulator rewrites
that file from the phone profile on first boot, and the AVD came back at
1080x2400 density 420 — four times the intended pixels. Found on the VM, where
the setting was supposed to have applied for weeks.
The size therefore moves to launch time, and the DENSITY with it. That is the
surprising part, measured on an identical workload: 540x1140 at density 420 is
WORSE than the full screen — 81 ms median against 40, 57 % janky frames against
37, everything rendered huge. At density 240: 38 ms, 32 %, and the 99th
percentile drops from 950 ms to 250.
"-no-snapshot-save" comes along: this menu offers to kill the emulator with
pkill, and the next start then died on "A snapshot operation is pending".
Checked after a pkill: no FATAL left.
Assisted-by: Claude Opus 5
« RAM » disait l'allocation. Elle dit maintenant l'usage, dans la même colonne :
« 4.7G/32G ». Sur un hyperviseur, savoir qu'une VM de 32 Go n'en occupe que 4,7
décide s'il reste de la place pour la suivante — l'allocation seule ne le dit
pas. La formule est « available - usable » de virsh dommemstat, calibrée contre
le « free » de deux VM : 1186 contre 1216 Mo, et 4831 contre 4838. Et la période
de collecte est posée d'abord, sans quoi le ballon ne rafraîchit rien — une VM
qui occupait 4,8 Go en annonçait 490 Mo.
L'uptime vient de l'âge du processus QEMU : libvirt ne l'expose ni dans dominfo,
ni dans domstats, ni par l'agent, mais ce processus est né avec le domaine. Les
colonnes ont été resserrées pour que la ligne tienne en 80 caractères avec le
nom entier de la VM.
--- EN ---
"RAM" showed the allocation. It now shows the use, in the same column:
"4.7G/32G". On a hypervisor, knowing that a 32 GB VM only occupies 4.7 decides
whether there is room for the next one — the allocation alone does not say. The
formula is virsh dommemstat's "available - usable", calibrated against the "free"
of two VMs: 1186 against 1216 MB, and 4831 against 4838. And the collection
period is set first, without which the balloon refreshes nothing — a VM using
4.8 GB reported 490 MB.
Uptime comes from the age of the QEMU process: libvirt exposes it neither in
dominfo, nor domstats, nor through the agent, but that process was born with the
domain. Columns were tightened so the line fits in 80 characters with the VM's
full name.
Assisted-by: Claude Opus 5
Les images sont revenues dans les packs, les catalogues gettext en sont sortis :
80 841 fichiers en 233 tranches au lieu de 116 156 en 391, et un APK de 354 Mo
à 2 844 entrées. La doc portait les chiffres d'avant.
Elle dit aussi ce qui n'allait pas de soi : l'APK ne suit pas la charge. Le
texte se compresse, le PNG non — 857 Mo de .po coûtaient 152 Mo d'APK, quand
218 Mo d'images en coûtent 218. D'où les deux leviers, nommés.
--- EN ---
Images came back into the packs and gettext catalogues left: 80,841 files in 233
slices instead of 116,156 in 391, and a 354 MB APK with 2,844 entries. The doc
still carried the earlier figures.
It also states what was not obvious: the APK does not follow the payload. Text
compresses, PNG does not — 857 MB of .po cost 152 MB of APK, where 218 MB of
images cost 218. Hence the two knobs, named.
Assisted-by: Claude Opus 5
Le contournement a vécu : les dépôts n'étaient plus embarqués du tout, l'APK
était refusé pour ses 123 678 entrées quand un ZIP en tient 65 535. Ils entrent
désormais en packs — tranches de 4 Mo et un index par dépôt disant où trouver
chaque fichier — ce qui ramène le compte à 391 entrées sans rien perdre du
contenu. Le côté application est dans le dépôt mobile ; ce commit porte la
vérification et retire le contournement.
Mesuré sur une VM : 139 dépôts, 116 156 fichiers, APK de 282 Mo à 3 002 entrées,
et 20 fichiers relus depuis les packs identiques octet pour octet à leur source.
L'installation le vérifie et échoue sinon : une application qui ne porte pas le
code qu'elle doit montrer n'est pas celle demandée.
--- EN ---
The stopgap has served its time: the repositories were not embedded at all, and
the APK was refused for its 123,678 entries where a ZIP holds 65,535. They now
enter as packs — 4 MB slices and one index per repository saying where each file
lives — which brings the count to 391 entries without losing any content. The
app side lives in the mobile repository; this commit carries the verification
and drops the workaround.
Measured on a VM: 139 repositories, 116,156 files, a 282 MB APK with 3,002
entries, and 20 files read back from the packs identical byte for byte to their
source. The install verifies it and fails otherwise: an app that does not carry
the code it must show is not the one that was asked for.
Assisted-by: Claude Opus 5
C'est la voie la plus courte : virt-viewer parle à libvirt par « qemu+ssh », lit
le port de l'écran par libvirt et monte SON tunnel — aucun « ssh -L » à tenir
ouvert, rien à deviner. Le menu tunnel le propose donc en cinquième choix.
La seule question qui compte est celle de l'affichage, et c'est l'environnement
qui tranche, pas une question de plus. Un affichage présent (poste, ou ssh -X) :
virt-viewer est installé s'il manque — apt, dnf, pacman ou zypper — puis lancé
détaché. Aucun affichage : la commande est donnée pour le poste, et rien n'est
installé sur une machine sans écran.
--- EN ---
The shortest path: virt-viewer talks to libvirt over "qemu+ssh", reads the
display port from libvirt and builds its OWN tunnel — no "ssh -L" to keep open,
nothing to guess. The tunnel menu offers it as a fifth choice.
The only question that matters is the display, and the environment answers it
rather than one more prompt. A display present (workstation, or ssh -X):
virt-viewer gets installed if missing — apt, dnf, pacman or zypper — then
launched detached. No display: the command is handed over for the workstation,
and nothing is installed on a screenless machine.
Assisted-by: Claude Opus 5
Une VM graphique peut arriver sur une console texte — graphical.target est
atteinte avant que le paquet du bureau soit là, et « systemctl enable gdm » rend
0 sans rien faire sur Debian et Ubuntu, où l'unité n'a pas de WantedBy. La
commande qui répare tient sur une ligne ; encore faut-il la lire quelque part.
Le guide de connexion porte donc un bloc « Bureau », avec l'état et le
« enable --now ». Il n'apparaît que si la VM a été déployée avec un bureau :
sur un serveur, ces commandes ne mèneraient à aucune unité. Le drapeau existait
déjà côté déploiement, il n'y avait qu'à le passer.
--- EN ---
A graphical VM can land on a text console — graphical.target is reached before
the desktop package exists, and "systemctl enable gdm" returns 0 doing nothing
on Debian and Ubuntu, where the unit has no WantedBy. The command that repairs
it is one line; it still has to be readable somewhere.
The login guide therefore carries a "Desktop" block, with the state and the
"enable --now". It only shows when the VM was deployed with a desktop: on a
server those commands would point at no unit. The flag already existed on the
deploy side; it only had to be passed along.
Assisted-by: Claude Opus 5
Une VM graphique restait sur une console texte jusqu'au premier redémarrage.
GNOME installé, gdm3 installé, graphical.target par défaut, lien
display-manager.service posé par le paquet — et rien à l'écran. Deux causes
superposées, mesurées sur erplibre-ubuntu-2604-gnome :
graphical.target était DÉJÀ atteinte quand le paquet est arrivé, et une cible
active ne rattrape pas un service ajouté après coup. Et « systemctl enable gdm »
rend 0 sans rien faire sur Debian et Ubuntu : l'unité n'a pas de « WantedBy »,
seulement l'alias que le paquet pose lui-même.
Le bureau est donc démarré, avec repli sur le service de la saveur, et l'échec
se dit au lieu de se taire. Vérifié : bureau arrêté puis fragment rejoué ->
gnome-shell revient, écran de connexion GDM à l'image.
--- EN ---
A graphical VM stayed on a text console until its first reboot. GNOME
installed, gdm3 installed, graphical.target the default, the
display-manager.service alias in place by the package — and nothing on screen.
Two causes stacked, measured on erplibre-ubuntu-2604-gnome:
graphical.target had ALREADY been reached when the package arrived, and an
active target does not pick up a service added afterwards. And "systemctl enable
gdm" returns 0 doing nothing on Debian and Ubuntu: the unit has no "WantedBy",
only the alias the package installs itself.
The desktop is therefore started, with a fallback to the flavour's service, and
a failure says so instead of staying quiet. Verified: desktop stopped then the
fragment replayed -> gnome-shell back, GDM greeter on screen.
Assisted-by: Claude Opus 5
Dix lignes de ce chemin s'affichaient en anglais dans une session française,
dont celle qui compte : « then point your VNC client at localhost:5900 ». C'est
l'écran d'une VM qu'on va chercher là, et le mode d'emploi arrivait à moitié
traduit.
Le diagnostic de l'autre branche l'était aussi — la VM sans port VNC, celle
qu'il faut redéfinir. Vérifié sur les deux VM du parc : celle qui expose son
écran et celle qui n'en expose pas.
--- EN ---
Ten lines of that path showed in English in a French session, including the one
that matters: "then point your VNC client at localhost:5900". What is being
fetched there is a VM's screen, and the instructions arrived half translated.
The other branch's diagnostic was in the same state — the VM with no VNC port,
the one that needs redefining. Checked on both VMs of the fleet: the one that
exposes its screen and the one that does not.
Assisted-by: Claude Opus 5
Tout push finissait sur « Forgejo: Internal Server Error Decoding Failed », et
le message ne désigne pas la cause. Le journal, lui, la donne : 403 sur
/api/internal/hook/pre-receive, refusé par le contrôle du jeton interne. Le
serveur comparait l'INTERNAL_TOKEN qu'il tenait EN MÉMOIRE à celui que le hook
venait de lire sur le disque — deux valeurs différentes — et répondait 403 à son
propre hook, que celui-ci ne sait pas décoder.
La cause est ici : « systemctl enable --now » ne touche pas un service déjà
actif. Le script redémarre donc quand le binaire, la configuration ou l'unité
ont changé, et se tait sinon. Vérifié sur la VM : configuration régénérée
service actif -> redémarrage -> push accepté ; relance sur forge saine ->
aucun redémarrage, push toujours accepté.
--- EN ---
Every push ended on "Forgejo: Internal Server Error Decoding Failed", and the
message does not name the cause. The log does: 403 on
/api/internal/hook/pre-receive, refused by the internal token check. The server
was comparing the INTERNAL_TOKEN it held IN MEMORY with the one the hook had
just read from disk — two different values — and answered 403 to its own hook,
which cannot decode a 403.
The cause is here: "systemctl enable --now" does not touch an already active
service. The script now restarts when the binary, the configuration or the unit
changed, and stays quiet otherwise. Verified on the VM: config regenerated with
the service active -> restart -> push accepted; replay on a healthy forge -> no
restart, push still accepted.
Assisted-by: Claude Opus 5
Les outils de la phase « après » vivent DANS le dépôt : la compilation mobile,
l'AVD, et maintenant le script Forgejo. Sur une VM « bureau seul », sans clone,
ils n'existent pas — et ils étaient écartés en silence. Une case cochée passait
donc pour honorée.
La commande le dit désormais, en nommant les outils concernés. Trois lignes qui
évitent de chercher pourquoi la forge demandée n'est nulle part.
--- EN ---
The "after" phase tools live IN the repository: the mobile build, the AVD, and
now the Forgejo script. On a desktop-only VM, with no clone, they do not exist —
and they were dropped in silence. A ticked checkbox therefore passed for
honoured.
The command now says so, naming the tools concerned. Three lines that save
hunting for why the requested forge is nowhere to be found.
Assisted-by: Claude Opus 5
« hostname -I » est un drapeau de net-tools. L'inetutils d'Arch ne le connaît
pas et peut rendre le NOM de la machine — une ROOT_URL bâtie sur un nom non
résolvable est pire qu'un repli, et l'option est censée marcher sur toutes les
plateformes ERPLibre.
Trois candidats désormais, chacun validé comme adresse IPv4 avant d'être
retenu : hostname -I, puis « ip route get », puis la première adresse globale.
localhost ferme la marche — une forge joignable en local vaut mieux qu'un
script qui s'arrête. Les trois voies sont couvertes par des tests qui
bouchonnent hostname et ip.
--- EN ---
"hostname -I" is a net-tools flag. Arch's inetutils does not know it and may
return the machine NAME — a ROOT_URL built on an unresolvable name is worse than
a fallback, and this option is meant to work on every ERPLibre platform.
Three candidates now, each validated as an IPv4 address before being kept:
hostname -I, then "ip route get", then the first global address. localhost
closes the march — a forge reachable locally beats a script that stops. All
three paths are covered by tests that stub hostname and ip.
Assisted-by: Claude Opus 5
Une case au déploiement, et une forge git auto-hébergée répond sur le port 3000,
git par SSH sur 2222. Le travail vit dans un script dédié, appelable seul sur
une machine existante : une seule autorité pour les deux usages.
Le binaire officiel est statique, donc le même fichier sert apt, dnf, pacman et
zypper — c'est ce qui rend l'option portable sans une branche par distribution.
Les architectures suivent l'amont (amd64, arm64, arm-6) ; la case se grise sur
s390x plutôt que de poser un binaire inexécutable. Les quatre secrets sont
écrits par le script : sans oauth2.JWT_SECRET, Forgejo tente de les persister
lui-même et boucle sur un app.ini qu'il n'a pas le droit d'écrire.
Vérifié sur une VM : somme de contrôle validée, service actif, API qui répond,
dépôt créé puis cloné par git, et relance en 1,5 s sans rien réécrire.
--- EN ---
One checkbox at deploy time, and a self-hosted git forge answers on port 3000,
git over SSH on 2222. The work lives in a dedicated script, callable on its own
for an existing machine: one authority for both uses.
The official binary is static, so the same file serves apt, dnf, pacman and
zypper — that is what makes the option portable without a branch per
distribution. Architectures follow upstream (amd64, arm64, arm-6); the checkbox
greys out on s390x rather than dropping a binary that cannot run. The script
writes all four secrets itself: without oauth2.JWT_SECRET, Forgejo tries to
persist them and loops on an app.ini it is not allowed to write.
Verified on a VM: checksum validated, service active, API answering, a repo
created then cloned over git, and a replay in 1.5 s rewriting nothing.
Assisted-by: Claude Opus 5
Deux défauts empêchaient le .idea d'exister. La configuration d'abord :
« make pycharm_configure » lance le script avec le python SYSTÈME, qui n'a pas
xmltodict — « ModuleNotFoundError », mesuré. update_env_version.pycharm_update()
l'appelle depuis .venv.erplibre ; la cible make et l'étape font désormais pareil.
L'ouverture ensuite : la première tentative sur un dépôt neuf peut n'écrire
aucun .idea, son configurateur d'interpréteur plantant sur « homeDir is null »,
là où la suivante l'écrit en 25 s — constaté sur deux VM. L'étape retente donc
une fois, en gardant les deux journaux. Vérifié sur erplibre-ubuntu-2604-gnome,
caches effacés : erplibre.iml, misc.xml, modules.xml, vcs.xml, et 0 processus
survivant.
--- EN ---
Two defects kept .idea from existing. The configuration first: "make
pycharm_configure" runs the script with the SYSTEM python, which lacks
xmltodict — "ModuleNotFoundError", measured. update_env_version.pycharm_update()
calls it from .venv.erplibre; the make target and the step now do the same.
The open next: the first attempt on a fresh repo can write no .idea at all, its
interpreter configurator dying on "homeDir is null", where the next one writes
it in 25 s — seen on two VMs. The step therefore retries once, keeping both
logs. Verified on erplibre-ubuntu-2604-gnome with caches wiped: erplibre.iml,
misc.xml, modules.xml, vcs.xml, and 0 surviving processes.
Assisted-by: Claude Opus 5
« ⚠ pas de .idea » à chaque installation : PyCharm ouvrait un dépôt cloné mais
pas installé, son configurateur d'interpréteur Python échouait faute de venv, et
il renonçait avant d'écrire quoi que ce soit. Le même appel sur un dépôt
installé écrit erplibre.iml, misc.xml, modules.xml et vcs.xml en cinq minutes —
mesuré sur la VM.
L'ouverture passe donc après le make, et « make pycharm_configure » la suit :
pycharm_update() s'était déjà exécuté pendant l'installation, quand il n'y avait
rien à configurer. Le groupe rend toujours 0 — un bonus ne rougit pas une VM —
et la phase mobile, qui porte le verdict, reste après lui.
--- EN ---
"⚠ no .idea" on every install: PyCharm was opening a repo that was cloned but
not installed, its Python interpreter configurator failed for lack of a venv,
and it gave up before writing anything. The same call on an installed repo
writes erplibre.iml, misc.xml, modules.xml and vcs.xml in five minutes —
measured on the VM.
The open therefore moves after the make, with "make pycharm_configure" behind
it: pycharm_update() had already run during the install, when there was nothing
to configure. The group always returns 0 — a bonus does not redden a VM — and
the mobile phase, which carries the verdict, still comes after it.
Assisted-by: Claude Opus 5
Rejouer une installation est le cas normal — une qui est morte, un outil ajouté
après coup — et le téléchargement en est la partie longue : environ cinq
minutes pour PyCharm, autant pour Android Studio, à chaque fois. Les deux
étapes vérifient donc /opt avant de sortir curl.
Mesuré sur erplibre-ubuntu-2604-gnome, IDE déjà posés : les deux étapes passent
de dix minutes à 0,094 s au total. Le reste rejoue quand même — lanceur, alias,
raccourci de bureau — il est idempotent et bon marché. Un test vérifie que la
garde n'avale pas l'échec du cas où il faut bel et bien télécharger.
--- EN ---
Replaying an install is the normal case — one that died, a tool added later —
and the download is the long part: about five minutes for PyCharm, as much for
Android Studio, every time. Both steps now check /opt before reaching for curl.
Measured on erplibre-ubuntu-2604-gnome with both IDEs already in place: the two
steps drop from ten minutes to 0.094 s total. The rest still replays — launcher,
alias, desktop entry — it is idempotent and cheap. A test checks the guard does
not swallow the failure of the case where downloading is actually needed.
Assisted-by: Claude Opus 5
Le sablier ne distingue pas une installation qui travaille d'une qui est morte :
le marqueur de sortie manque dans les deux cas. Une session ssh emportée, et le
tableau de bord a affiché « ⏳ » pendant 54 minutes sans que rien ne cloche à
l'œil.
La colonne d'état porte maintenant le silence du journal — « ⏳ silence 48min ».
C'est un chiffre, pas un verdict. Le seuil de dix minutes vient d'une mesure :
le téléchargement d'Android Studio tient ~5 min sans une ligne, et l'étape
« APK debug » davantage, son détail partant dans le journal de la VM. Plus bas,
chaque installation deviendrait une alerte, et l'alerte cesserait d'être lue.
--- EN ---
The hourglass does not tell a working install from a dead one: the exit marker
is missing in both cases. An ssh session was reaped, and the dashboard showed
"⏳" for 54 minutes with nothing looking wrong.
The state column now carries the log's silence — "⏳ silent 48min". It is a
figure, not a verdict. The ten-minute threshold comes from a measurement: the
Android Studio download holds ~5 min without a line, and the "debug APK" step
longer, its detail going to the VM's own log. Any lower and every install would
become an alert, and the alert would stop being read.
Assisted-by: Claude Opus 5
Le filet de fermeture de PyCharm cherchait « /opt/pycharm » dans les lignes de
commande. Or le script d'installation est passé en argument à ssh, et il
contient ce chemin : le pkill a tué la session ssh qui portait une installation
en cours. Elle est morte sans marqueur de sortie, et le tableau de bord a
montré un sablier pendant 54 minutes. Exécuter la suite de tests suffisait à
déclencher le défaut, puisqu'un test rejoue l'étape.
Le filet vise désormais les NOMS de processus, bornés au compte courant.
Mesuré dans la VM : par nom, 3 processus réels et aucun faux ; par ligne de
commande, 4 — le ssh compris. Un test plante un témoin nommé « sleep » dont la
ligne contient le chemin de l'IDE, et les tests bouchonnent pgrep et pkill.
--- EN ---
PyCharm's closing net looked for "/opt/pycharm" in command lines. But the
install script is passed to ssh as an argument, and it contains that path: the
pkill killed the ssh session carrying a running install. It died with no exit
marker, and the dashboard showed an hourglass for 54 minutes. Running the test
suite was enough to trigger it, since one test replays the step.
The net now targets process NAMES, scoped to the current account. Measured in
the VM: by name, 3 real processes and no false ones; by command line, 4 — the
ssh included. A test plants a witness named "sleep" whose command line holds
the IDE path, and the tests stub pgrep and pkill.
Assisted-by: Claude Opus 5
La barre montrait le CPU et le disque, jamais la mémoire. C'est pourtant la
seule des trois dont l'épuisement ne se voit nulle part ailleurs : une
compilation mobile s'est fait tuer par le noyau sur une VM de 12 Go sans swap
pendant que la barre affichait une charge tranquille et du disque de reste.
Lue dans /proc/meminfo, sans dépendance — ce suivi tourne sur l'hyperviseur,
donc sous Linux, d'où viennent déjà getloadavg et libvirt. « MemAvailable »
plutôt que « MemFree », presque nul dès que le cache travaille. Le swap
n'occupe la barre que s'il existe, et alors même à zéro : une machine qui
commence à échanger explique une lenteur. Au passage, « charge » et « libre »
s'affichaient en français dans une session anglaise.
--- EN ---
The bar showed CPU and disk, never memory. Yet memory is the one of the three
whose exhaustion shows up nowhere else: a mobile build was killed by the kernel
on a 12 GB VM with no swap while the bar displayed a quiet load and disk to
spare.
Read from /proc/meminfo, no dependency — this monitor runs on the hypervisor,
so on Linux, where getloadavg and libvirt already come from. "MemAvailable"
rather than "MemFree", near zero as soon as the cache is working. Swap takes
room in the bar only when it exists, and then even at zero: a machine starting
to swap explains a slowdown. Along the way, "load" and "free" were showing in
French in an English session.
Assisted-by: Claude Opus 5
La compilation butait sur « Too many zip entries 123678 (MAX=65535) » : un APK
est un ZIP, et le dépôt mobile verse 122 684 fichiers d'assets pour 337 qui
sont l'application. Le levier existe et il est documenté chez lui
(doc/SERVICES.md) : ERPLIBRE_MANIFEST_PATH, ici pointé sur un manifeste vide —
« ces dépôts-là : aucun ». Le plugin l'annonce, « 0 repos ».
Mesuré sur erplibre-ubuntu-2604-gnome : dist passe de 123 019 fichiers à 336,
l'APK sort à 59 Mo et 2 472 entrées, et la phase mobile entière rend 0, tests
Vitest compris — 75 fichiers, 1938 tests. Qui veut les dépôts pose la variable
lui-même : elle est respectée. Mesure d'attente, à retirer quand ils tiendront
sous le plafond du ZIP.
--- EN ---
The build hit "Too many zip entries 123678 (MAX=65535)": an APK is a ZIP, and
the mobile repo pours 122,684 asset files in for 337 that are the application.
The lever exists and that repo documents it (doc/SERVICES.md):
ERPLIBRE_MANIFEST_PATH, pointed here at an empty manifest — "those repos:
none". The plugin says so itself, "0 repos".
Measured on erplibre-ubuntu-2604-gnome: dist drops from 123,019 files to 336,
the APK comes out at 59 MB with 2,472 entries, and the whole mobile phase
returns 0, Vitest included — 75 files, 1938 tests. Set the variable yourself
and the repos come back. A stopgap, to drop once they fit under the ZIP
ceiling.
Assisted-by: Claude Opus 5
La liste s'arrêtait aux quatre premières et laissait croire que le reste
tombait dans « aucun motif connu ». Les deux pannes rencontrées cette semaine
y manquaient : un démon Gradle tué par le noyau, et un APK refusé pour ses
122 684 fichiers d'assets alors qu'un ZIP tient 65535 entrées.
La seconde n'a pas de correctif de notre côté, et la doc le dit : elle
appartient au dépôt mobile.
--- EN ---
The list stopped at the first four, implying the rest fell into "no known
pattern". Both failures met this week were missing from it: a Gradle daemon
killed by the kernel, and an APK refused for its 122,684 asset files when a ZIP
holds 65535 entries.
The second one has no fix on our side, and the doc says so: it belongs to the
mobile repository.
Assisted-by: Claude Opus 5
Sur erplibre-ubuntu-2604-gnome, l'APK s'est fait tuer par le noyau. La cause
est ici : « $! » désigne xvfb-run, un script, et le tuer n'atteint ni PyCharm
ni Xvfb — l'IDE tournait encore 45 minutes après son étape, avec 1,9 Go, quand
Gradle a demandé ses 6,8 Go sur 12. C'est le GROUPE qu'on tue maintenant, et
plus rien ne survit : mesuré, 2 Go rendus.
Le .idea n'était jamais écrit non plus : 122 684 des 123 021 fichiers d'assets
du dépôt mobile épuisaient les 65 536 watches inotify. Relevées à 524288, le
projet se crée. Restent 4 Go de swap avant de compiler, et un diagnostic qui
nomme la mémoire — avec le compte de l'oom-killer — puis la limite ZIP de
65 535 entrées, sur laquelle la compilation bute désormais, en amont.
--- EN ---
On erplibre-ubuntu-2604-gnome the APK was killed by the kernel. The cause is
here: "$!" is xvfb-run, a script, and killing it reaches neither PyCharm nor
Xvfb — the IDE was still running 45 minutes after its step, holding 1.9 GB,
when Gradle asked for its 6.8 GB out of 12. The GROUP is killed now, and
nothing survives it: 2 GB given back, measured.
The .idea was never written either: 122,684 of the mobile repo's 123,021 asset
files exhausted the 65,536 inotify watches. Raised to 524288, the project gets
created. Also 4 GB of swap before building, and a diagnostic naming memory —
with the oom-killer count — then the 65,535-entry ZIP limit the build now hits,
upstream of us.
Assisted-by: Claude Opus 5
Le volet « d » et le compteur du tableau de bord cherchaient la sous-chaîne
« error ». Le journal de l'installation qui vient d'échouer — APK tué par le
noyau sur erplibre-ubuntu-2604-gnome — n'en contient AUCUNE : 0 ligne sur
8765, mesuré. Le volet annonçait « aucune erreur détectée » sur une machine
morte, et le tableau de bord 0 erreur.
Comptent désormais les marqueurs qui ne disent jamais « error » : « ⚠ ÉCHEC »,
« FAILURE », une trace Python, un « fatal: » de git, une mort par mémoire. Le
volet ouvre sur un résumé — l'étape en échec et son diagnostic, les signaux
durs, puis les répétitions comptées par forme. Sur ce journal : 1 étape nommée,
2 signaux, là où il n'affichait rien.
--- EN ---
The "d" pane and the dashboard counter looked for the "error" substring. The
log of the install that just failed — APK killed by the kernel on
erplibre-ubuntu-2604-gnome — contains NONE: 0 lines out of 8765, measured. The
pane said "no error detected" about a dead machine, and the dashboard 0 errors.
Markers that never say "error" now count: "⚠ ÉCHEC", "FAILURE", a Python
traceback, a git "fatal:", a death by memory. The pane opens on a summary — the
failed step with its diagnostic, the hard signals, then repeats counted by
shape. On that log: 1 named step and 2 signals, where it showed nothing.
Assisted-by: Claude Opus 5
Trois défauts vus en conduisant le menu sur de vraies VM. « setsid » détache,
donc son code de retour vaut 0 même quand rien ne se lance : le menu disait
« Démarré » sur une VM sans SDK, dont le journal disait « not found ». Le
démarrage attend maintenant de VOIR le processus, et à défaut cite le journal.
Une sonde préalable lit binaire et AVD d'un coup : une VM déployée sans cocher
l'outil est le cas normal, pas une panne. Vérifié sur deux VM réelles — outillée
(True), migration (« aucun binaire emulator »), sans rien y démarrer.
Et tout ce qui n'était pas « 2 » démarrait l'émulateur : un « n » de travers
suffisait. Au passage, « Choice » n'était traduit dans aucun des trois menus
qui l'affichent.
--- EN ---
Three defects found while driving the menu against real VMs. setsid detaches,
so its exit code is 0 even when nothing launches: the menu said "Started" on a
VM with no SDK, whose log said "not found". Starting now waits to SEE the
process, and quotes the log when it never appears.
A prior probe reads binary and AVD in one go: a VM deployed without ticking the
tool is the normal case, not a failure. Verified on two real VMs — tooled
(True), migration ("no emulator binary") — without starting anything there.
And anything that was not "2" started the emulator; a stray "n" was enough.
Along the way, "Choice" was untranslated in all three menus showing it.
Assisted-by: Claude Opus 5
Le menu Execute avait ce garde-fou, le menu QEMU non — et c'est lui qui vient
de renumérer, l'émulateur Android s'insérant avant « List available images ».
Sa forme est pire à l'œil : une liste de dictionnaires où les « section » ne
consomment pas de numéro, donc le décalage ne se voit pas en lisant.
Le test relit les deux écritures et les apparie, puis une table dit où chaque
entrée doit mener. Inverser les deux derniers crans du dispatch le fait bien
tomber, en nommant l'entrée fautive.
--- EN ---
The Execute menu had this guard, the QEMU menu did not — and the QEMU one is
what just got renumbered, the Android emulator slotting in before "List
available images". Its shape is worse to eyeball: a list of dicts where
"section" entries consume no number, so a shift does not show when reading.
The test reads both spellings and pairs them, then a table states where each
entry must lead. Swapping the last two dispatch branches does make it fail,
naming the offending entry.
Assisted-by: Claude Opus 5
Les deux commandes documentées échouent. « emulator » sans chemin absolu rend
« command not found », parce qu'un `ssh hôte 'commande'` ne lit ni ~/.profile
ni ~/.bashrc — l'erreur a été rencontrée telle quelle. Et le rendu annoncé,
« swiftshader_indirect », n'existe plus : l'émulateur répond « Selected GPU
option is not valid » et le code pose « swangle » depuis un moment.
La doc pointe maintenant d'abord le menu de todo.py, qui démarre l'émulateur
sans fenêtre et donne le tunnel adb : scrcpy reçoit du H.264 encodé par
l'appareil, là où `ssh -X` fait traverser chaque image en pixels bruts.
--- EN ---
Both documented commands fail. Bare `emulator` gives "command not found",
because `ssh host 'command'` reads neither ~/.profile nor ~/.bashrc — the
error was hit exactly like that. And the advertised renderer,
`swiftshader_indirect`, no longer exists: the emulator answers "Selected GPU
option is not valid", and the code has been setting `swangle` for a while.
The doc now points at todo.py's menu first, which starts the emulator without
a window and hands over the adb tunnel: scrcpy receives H.264 encoded by the
device, where `ssh -X` ships every frame as raw pixels.
Assisted-by: Claude Opus 5
Le choix 3 du menu tunnel levait « _qemu_console_tunnel() takes 1 positional
argument but 3 were given » : la fonction lit name et src sans les recevoir.
flake8 le disait déjà (F821 sur name et src), personne ne l'écoutait.
Ce menu n'avait aucun test, et c'est ce qui a laissé passer l'appel. Ses
quatre choix sont donc parcourus pour de vrai, jusqu'à la commande imprimée,
console comprise. Le défaut remis en place fait bien tomber les tests.
--- EN ---
Choice 3 of the tunnel menu raised "_qemu_console_tunnel() takes 1 positional
argument but 3 were given": the function reads name and src without taking
them. flake8 already said so (F821 on name and src); nobody listened.
That menu had no test at all, which is how the call shipped. All four of its
choices are now walked for real, down to the printed command, the console
included. Putting the defect back does make the tests fail.
Assisted-by: Claude Opus 5
Le tunnel n'était que du texte à recopier, et le démarrage restait manuel :
un second émulateur sur le même AVD tue le premier (« Running multiple
emulators »), rencontré deux fois. Le menu le détecte donc avant de lancer.
La fenêtre décide du reste. Sans elle, todo.py démarre à distance, détaché
par setsid dans le groupe kvm, et enchaîne sur scrcpy ; avec elle, la
commande doit partir du poste qui possède l'affichage, pas d'ici.
Mesuré : l'émulateur n'écoute que sur le 127.0.0.1 de la VM — l'hyperviseur
est refusé sur IP:5555 — d'où le -J qui met la VM en dernier saut. Vérifié
sur erplibre-mobile-proof : poignée de main adb CNXN rendant
sdk_gphone64_x86_64, enveloppe détachée survivant au ssh ; 30 tests.
--- EN ---
The tunnel was only text to copy, and starting the emulator stayed manual:
a second emulator on the same AVD kills the first ("Running multiple
emulators"), hit twice. The menu now detects it before starting.
The window decides the rest. Without one, todo.py starts it remotely,
detached by setsid in the kvm group, and chains into scrcpy; with one, the
command must run from the workstation that owns the display, not from here.
Measured: the emulator only listens on the VM's 127.0.0.1 — the hypervisor
is refused on IP:5555 — hence the -J putting the VM last. Verified on
erplibre-mobile-proof: an adb CNXN handshake returning sdk_gphone64_x86_64,
a detached wrapper outliving the ssh; 30 tests.
Assisted-by: Claude Opus 5
X11 carries raw pixels: 0.62 megapixel per frame even after shrinking the
screen, rendered in software. scrcpy receives an H.264 stream encoded BY the
device, so the emulator runs with no window at all — no X11 anywhere. The
tunnel menu gained a fourth kind, reusing the target list it already reads from
~/.ssh/config, ProxyJump included: the hard part was already solved there.
It forwards 5555, the emulator's own adb port, not 5037: tunnelling the adb
server would force the user to kill the one on their workstation, which holds
the same port. Verified through the tunnel from the hypervisor: an adb CNXN
handshake answers device::ro.product.name=sdk_gphone64_x86, exactly what adb
connect does. ss -ltn in the VM confirms 5554, 5555 and 5037 all listen on
127.0.0.1.
--- FR ---
X11 transporte des pixels bruts : 0,62 mégapixel par image même après réduction
de l'écran, en rendu logiciel. scrcpy reçoit un flux H.264 encodé PAR
l'appareil, si bien que l'émulateur tourne sans aucune fenêtre — plus de X11
nulle part. Le menu de tunnel gagne un quatrième type, qui réutilise la liste de
cibles qu'il lit déjà dans ~/.ssh/config, ProxyJump compris : le plus dur y
était déjà résolu.
Il redirige 5555, le port adb de l'émulateur lui-même, et non 5037 : tunneliser
le serveur adb obligerait à tuer celui du poste, qui occupe le même port.
Vérifié à travers le tunnel depuis l'hyperviseur : une poignée de main adb CNXN
répond device::ro.product.name=sdk_gphone64_x86, ce que fait exactement adb
connect. « ss -ltn » dans la VM confirme que 5554, 5555 et 5037 écoutent tous
sur 127.0.0.1.
Assisted-by: Claude Opus 5
Reported from a workstation: "Selected GPU option 'swiftshader_indirect' is
not valid, switching to auto", then "Your GPU drivers may have a bug". That
mode no longer exists in emulator 37.1; it fell back to swangle by itself, so
it worked while printing two errors that read like a fault. emulator -help-gpu
lists exactly four modes: auto, host, swiftshader, swangle. The AVD now asks
for swangle. Checked on the VM: zero GPU errors where there were two,
vulkan:swiftshader gles:swangle selected outright, boot in 55 s.
--- FR ---
Remonté depuis un poste : « Selected GPU option 'swiftshader_indirect' is not
valid, switching to auto », puis « Your GPU drivers may have a bug ». Ce mode
n'existe plus dans l'émulateur 37.1 ; il retombait de lui-même sur swangle,
donc cela fonctionnait en affichant deux erreurs qui se lisent comme une panne.
« emulator -help-gpu » énumère exactement quatre modes : auto, host,
swiftshader, swangle. L'AVD demande désormais swangle. Vérifié sur la VM : zéro
erreur GPU là où il y en avait deux, vulkan:swiftshader gles:swangle choisis
d'emblée, boot en 55 s.
Assisted-by: Claude Opus 5
"It launches but it is too slow." The Pixel profile gives 1080x2400 — 2.6
megapixels pushed frame by frame through SSH, in software rendering. The AVD
now declares 540x1140 at 240 dpi: 0.62 megapixel, 4.2 times less. Measured on
the VM after the change: wm size reports 540x1140, and a full-screen capture
drops from 220 KB to 49 KB. Android handles the density and the app does not
notice; whoever wants the real size overrides it with -skin 1080x2400.
The printed command also gained -XC over -X, X11 compression being free on a
remote display, and -no-boot-anim. Checked: ca.erplibre.home relaunched at the
new size, MainActivity resumed.
--- FR ---
« Ça se lance mais c'est trop lent. » Le profil Pixel donne 1080x2400, soit
2,6 mégapixels poussés image par image dans SSH, en rendu logiciel. L'AVD
déclare maintenant 540x1140 à 240 ppp : 0,62 mégapixel, 4,2 fois moins. Mesuré
sur la VM après le changement : « wm size » rend 540x1140, et une capture plein
écran tombe de 220 Ko à 49 Ko. Android gère la densité et l'application ne s'en
aperçoit pas ; qui veut la taille réelle l'écrase par « -skin 1080x2400 ».
La commande affichée gagne aussi « -XC » au lieu de « -X », la compression X11
étant gratuite sur un écran distant, et « -no-boot-anim ». Vérifié :
ca.erplibre.home relancé à la nouvelle taille, MainActivity au premier plan.
Assisted-by: Claude Opus 5
The app runs in the emulator now, and two of my own checks were wrong. With an
injected ABI, AGP writes to intermediates/apk/debug, not outputs/apk/debug: a
SUCCESSFUL build was reported "no APK produced" because only the second path
was searched. That same mode marks the APK testOnly, so adb refuses it without
-t — INSTALL_FAILED_TEST_ONLY. Both measured on the emulator, where
ca.erplibre.home then installed, launched, and ran its SQLite migrations.
The manifest also stops tracking sentencepiece at master, which made the build
non-reproducible and, since August, unbuildable: master fetches protobuf and
compiles protoc for the Android target before running it on the host. v0.2.1
ships its .pb.cc pre-generated. Its own absl subset still lacks
flags/flag.cc, so that library remains to be sorted out upstream.
--- FR ---
L'application tourne dans l'émulateur, et deux de mes propres contrôles étaient
faux. Avec une ABI injectée, AGP écrit dans intermediates/apk/debug et non dans
outputs/apk/debug : une compilation RÉUSSIE était rapportée « aucun APK
produit » parce que je ne regardais que le second chemin. Ce même mode marque
l'APK testOnly, et adb le refuse sans -t — INSTALL_FAILED_TEST_ONLY. Les deux
mesurés sur l'émulateur, où ca.erplibre.home s'est ensuite installé, lancé, et
a joué ses migrations SQLite.
Le manifeste cesse aussi de suivre sentencepiece à master, ce qui rendait la
compilation non reproductible et, depuis août, impossible : master récupère
protobuf et compile protoc pour la cible Android avant de l'exécuter sur
l'hôte. La v0.2.1 livre ses .pb.cc pré-générés. Son propre sous-ensemble absl
manque encore flags/flag.cc : cette bibliothèque reste à régler en amont.
Assisted-by: Claude Opus 5
Reported from a workstation: "emulator: command not found". The line the
emulator step printed relied on PATH, and "ssh host 'command'" reads neither
~/.profile nor ~/.bashrc — Ubuntu even opens the latter with a return for
non-interactive shells. So what install-android.sh writes there never applies
to those commands. Both printed lines now carry absolute paths.
Behind it, a second one: the emulator ships TWO qemu binaries and only the
headless one does without PulseAudio. The windowed one — the ssh -X case —
links libpulse.so.0, absent from cloud images, and stops on "cannot open
shared object file" even with -no-audio. Measured: it is the only missing
library, the Qt dependencies travel in the bundle. Checked after the fix: the
windowed binary starts and reports its version.
--- FR ---
Remonté depuis un poste : « emulator: command not found ». La ligne affichée
par l'étape émulateur comptait sur le PATH, or « ssh hôte 'commande' » ne lit
ni ~/.profile ni ~/.bashrc — Ubuntu ouvre même le second par un return pour
les shells non interactifs. Ce que install-android.sh y écrit ne s'applique
donc jamais à ces commandes. Les deux lignes affichées portent maintenant des
chemins absolus.
Derrière, une seconde : l'émulateur livre DEUX binaires qemu et seul le
headless se passe de PulseAudio. Celui qui ouvre une fenêtre — le cas du
ssh -X — lie libpulse.so.0, absente des images cloud, et s'arrête sur
« cannot open shared object file » même avec -no-audio. Mesuré : c'est la
seule bibliothèque qui manque, les dépendances Qt voyagent dans le bundle.
Vérifié après correction : le binaire fenêtré démarre et donne sa version.
Assisted-by: Claude Opus 5
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
install-android.sh writes its exports into ~/.bashrc, which a GNOME session
never reads: Android Studio launched from the menu saw no ANDROID_HOME and
offered to download a second SDK, next to the one the mobile build had just
installed. environment.d is the channel the user session actually reads, so
both point at $HOME/android. An empty ~/.android/repositories.cfg is created
too — without it the first-run wizard stops on an error instead of offering
anything.
--- FR ---
install-android.sh écrit ses exports dans ~/.bashrc, qu'une session GNOME ne
lit jamais : Android Studio lancé depuis le menu ne voyait aucun ANDROID_HOME
et proposait de télécharger un second SDK, à côté de celui que la compilation
mobile venait de poser. environment.d est le canal que la session utilisateur
lit vraiment, et les deux pointent désormais $HOME/android. Un
~/.android/repositories.cfg vide est créé au passage : sans lui, l'assistant
de première ouverture s'arrête sur une erreur au lieu de proposer quoi que ce
soit.
Assisted-by: Claude Opus 5
A VM was declared ready without anything proving it. The mobile option now
adds the repository to the manifest (additive, so it rides along an Odoo 18
install), runs the mobile repository's own install-android.sh — licences
accepted included — then npm ci, vite build, cap sync, gradlew assembleDebug
and npm test. A failure fails the VM: the exit code reaches the dashboard.
Two gaps in that upstream installer had to be filled: unzip and wget, which
no cloud image ships, and the SDK platform — it installs android-34 while
variables.gradle asks for compileSdk 36, so the number is read from the file
rather than frozen. Gradle writes tens of megabytes and hundreds of harmless
lines carrying the word error: that output goes to a file of its own, and the
log gets the named cause instead.
--- FR ---
Une VM était déclarée prête sans que rien ne le prouve. L'option mobile ajoute
maintenant le dépôt au manifeste (additif, donc il accompagne une installation
Odoo 18), lance l'install-android.sh du dépôt mobile lui-même — licences
acceptées comprises —, puis npm ci, vite build, cap sync, gradlew
assembleDebug et npm test. Un échec fait échouer la VM : le code de sortie
remonte au tableau de bord.
Deux manques de cet installateur amont ont dû être comblés : unzip et wget,
qu'aucune image cloud ne livre, et la plateforme SDK — il pose android-34
quand variables.gradle réclame compileSdk 36, d'où le chiffre lu dans le
fichier plutôt que figé. Gradle écrit des dizaines de mégaoctets et des
centaines de lignes anodines portant le mot error : cette sortie part dans un
fichier à part, et le journal reçoit la cause nommée.
Assisted-by: Claude Opus 5
Two measurements, one after the other. The unified PyCharm that
code=PCC&latest now serves stops on its licence: the log says
NoValidIdeLicense then "Get licenses: request requires authentication", and
no project is ever opened — so no .idea, so nothing for the install to
configure. The Community line asks for no account and is still patched
(2025.2.6.2 on 2026-07-29); it is resolved from the release feed, so no
version is frozen here.
That build then froze 1.3 s after startup: the trust dialog, invisible under
Xvfb and waiting for a click. idea.trust.all.projects unblocks it. Checked
on an Ubuntu 26.04 VM: .idea complete in 195 s, and pycharm_configuration.py
writes its exclusions into erplibre.iml.
--- FR ---
Deux mesures, l'une après l'autre. Le PyCharm unifié que sert désormais
code=PCC&latest s'arrête sur sa licence : le journal dit NoValidIdeLicense
puis « Get licenses: request requires authentication », et aucun projet ne
s'ouvre — donc pas de .idea, donc rien à configurer pour l'installation. La
ligne Community ne demande aucun compte et reste corrigée (2025.2.6.2 le
2026-07-29) ; elle est résolue depuis le flux des versions, sans qu'aucun
numéro ne soit figé ici.
Ce build se figeait ensuite 1,3 s après le démarrage : la fenêtre de
confiance, invisible sous Xvfb et attendant un clic.
idea.trust.all.projects la lève. Vérifié sur une VM Ubuntu 26.04 : .idea
complet en 195 s, et pycharm_configuration.py écrit ses exclusions dans
erplibre.iml.
Assisted-by: Claude Opus 5
A graphical VM was a desktop and nothing else: every developer tool had to
be installed by hand afterwards. A check list now carries them, filtered
per machine — Android Studio is x86_64 only, Google publishes no Linux
aarch64 build — and their disk cost reaches the plan before any qcow2 is
created. They are installed BEFORE the clone: PyCharm writes the .idea/ of
the repository, and the install that follows is what runs
pycharm_configuration.py, through update_env_version.pycharm_update().
Its launcher is named studio, which is enough to conclude the install
failed; it now answers to android-studio too. GNOME extensions come from
the site by UUID, per running Shell: the same endpoint serves gTile v59
for GNOME 46 and v62 for 48. Checked with stubs: every tool can fail and
the install's exit code still wins, 45 tests.
--- FR ---
Une VM graphique n'était qu'un bureau : chaque outil de développement
restait à poser à la main. Une liste à cocher les porte, filtrés machine
par machine — Android Studio n'existe qu'en x86_64, Google ne publiant
aucune archive Linux aarch64 — et leur place disque atteint le plan avant
qu'un seul qcow2 ne soit créé. Ils sont posés AVANT le clone : PyCharm
écrit le .idea/ du dépôt, et c'est l'installation qui suit qui lance
pycharm_configuration.py, via update_env_version.pycharm_update().
Son lanceur s'appelle studio, ce qui suffit à conclure à un échec ; il
répond désormais aussi à android-studio. Les extensions GNOME viennent du
site par UUID, selon le Shell qui tourne : le même point d'entrée sert
gTile v59 pour GNOME 46 et v62 pour 48. Vérifié avec des leurres : chaque
outil peut échouer sans que le code de sortie de l'installation ne change,
45 tests.
Assisted-by: Claude Opus 5
The catalogue spans four package managers and the operator changes
distribution at every deployment, yet nothing in the VM said which one it
was. /etc/motd now carries the commands of the machine you just entered,
and the host's git identity lands in ~/.gitconfig so a commit made there
is not signed erplibre@<vm-name>.
The seven cloud images were mounted read-only to settle the mechanism:
sshd is PrintMotd no everywhere and pam_motd shows the file, so it appears
once and never for ssh host 'command'. Checked: cloud-init schema reports
Valid schema on the 8 catalogue combinations, the YAML round-trip is
byte-identical, and the s390x initrd was rebuilt and unpacked. Its
early_command gained the `true` guard it lacked: the last diagnostic
returns 1 when enc1 is absent, stopping the installer it was meant to
explain.
--- FR ---
Le catalogue couvre quatre gestionnaires de paquets et l'opérateur change
de distribution à chaque déploiement, sans que rien dans la VM ne dise
laquelle. /etc/motd porte maintenant les commandes de la machine où l'on
vient d'entrer, et l'identité git de l'hôte atterrit dans ~/.gitconfig :
un commit fait là ne porte plus erplibre@<nom-de-vm>.
Les sept images cloud ont été montées en lecture seule pour trancher le
mécanisme : sshd est en PrintMotd no partout et c'est pam_motd qui affiche
le fichier, donc un seul affichage, et jamais pour ssh hôte 'commande'.
Vérifié : cloud-init schema rend Valid schema sur les 8 combinaisons du
catalogue, l'aller-retour YAML est octet pour octet, et l'initrd s390x a
été reconstruit puis déplié. Son early_command a reçu la garde `true` qui
lui manquait : son dernier diagnostic rend 1 quand enc1 est absente, et
arrêtait l'installateur qu'il devait éclairer.
Assisted-by: Claude Opus 5
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)
« This domain is not running » apres une installation reussie. Le disque
portait 1,22 Gio et le XML persistant amorcait deja sur « hd » : rien
n'avait echoue, la VM etait simplement eteinte.
virt-install mene l'installation en deux temps — amorcage transitoire
sur kernel+initrd, puis configuration definitive sur disque — et le
passage se fait par un ARRET. C'est virt-install qui rallume ensuite,
sauf qu'avec « --wait 0 » il est deja parti.
On ne peut pas le laisser attendre : sous emulation l'installation dure
des heures, et le deploiement rendrait la main a ce rythme. Un veilleur
detache fait donc le dernier geste, avec 6 h de garde.
Mesure : domaine « shut off », veilleur lance, domaine « running ».
Et la VM installee repond en SSH.
--- EN ---
"This domain is not running" after a successful install. The disk held
1.22 GiB and the persistent XML already booted from "hd": nothing had
failed, the VM was simply powered off.
virt-install runs the install in two stages — a transient kernel+initrd
boot, then the final disk-boot config — and the handover goes through a
SHUTDOWN. virt-install powers it back on afterwards, except that with
"--wait 0" it is already gone.
We cannot let it wait: under emulation the install takes hours, and
deployment would return at that pace. So a detached watcher makes the
last move, with a 6 h guard.
Measured: domain "shut off", watcher started, domain "running". And the
installed VM answers over SSH.
Assisted-by: Claude Opus 5
(cherry picked from commit 9c6cdb7f14ca504fd9d0855ba0dacc3dbf43c04f)
Deux blocages, deux mecanismes propres a IBM Z.
network-console n'est pas une question a laquelle repondre : il demarre
sshd et ATTEND une connexion, indefiniment. Preseeder son mot de passe
ne fait avancer que d'un ecran. d-i prevoit le levier — un composant
dont « .isinstallable » sort en erreur quitte le menu. On ajoute donc a
l'initrd une version qui refuse toujours ; le fichier ecrit APRES
l'original prend sa place, le noyau depliant le cpio sequentiellement.
partman-auto n'est pas tire d'office sur s390x, ou la voie attendue est
le partitionnement DASD manuel. Mesure : « /lib/partman/
automatically_partition/ No such file or directory », d'ou « No root
file system is defined ». anna/choose_modules le reclame.
Mesure apres correctif : recette atomic appliquee, aucun ecran bloquant,
l'installateur deballe le systeme de base.
--- EN ---
Two stops, two IBM Z mechanisms.
network-console is not a question to answer: it starts sshd and WAITS
for a connection, forever. Preseeding its password only advances one
screen. d-i provides the lever — a component whose ".isinstallable"
exits non-zero leaves the menu. So the initrd gets a version that always
refuses; the file written AFTER the original wins, since the kernel
unpacks the cpio sequentially.
partman-auto is not pulled by default on s390x, where manual DASD
partitioning is the expected path. Measured: "/lib/partman/
automatically_partition/ No such file or directory", hence "No root file
system is defined". anna/choose_modules asks for it.
Measured after the fix: atomic recipe applied, no blocking screen, the
installer unpacks the base system.
Assisted-by: Claude Opus 5
(cherry picked from commit 1fb06ad84b65f43e9ffd1604b4e3d3a7aef9aaf2)
« Premiere libre en partant du haut » donnait la MEME adresse a deux VM
deployees en parallele : ni l'une ni l'autre n'est montee quand l'autre
cherche, donc aucune ne voit l'autre. Mesure — debian-12 et debian-13
ont tous deux pris .250 et se sont disputes l'adresse, une seule
survivant. C'est ce qui faisait echouer le 12 quand le 13 passait.
Le depart du balayage vient desormais du NOM de la VM, par crc32. Les
noms different toujours, la collision disparait, et le tirage reste
stable d'un redeploiement a l'autre. Le balayage garde ses garde-fous :
baux existants et adresses qui repondent restent ecartes.
Verifie : debian-12 -> .216, debian-13 -> .218.
--- EN ---
"First free from the top" gave the SAME address to two VMs deployed in
parallel: neither is up when the other looks, so neither sees the other.
Measured — debian-12 and debian-13 both took .250 and fought over it,
only one surviving. That is what made 12 fail while 13 went through.
The scan now starts from the VM NAME, via crc32. Names always differ,
the collision is gone, and the draw stays stable across redeployments.
The scan keeps its guards: existing leases and answering addresses are
still skipped.
Verified: debian-12 -> .216, debian-13 -> .218.
Assisted-by: Claude Opus 5
(cherry picked from commit 91592383e213ad98873125866e6120e5da5874fe)
Sur IBM Z, d-i propose systematiquement de poursuivre par SSH — la
console y est historiquement limitee. Il refuse un mot de passe vide et
s'arretait sur « Empty password ».
Preseede, le mot de passe passe. Mais l'ecran suivant montre que cela ne
suffit PAS : network-console demarre sshd et attend une connexion de
l'utilisateur « installer ». Il ne rend jamais la main. Le rendre non
assiste demande de l'empecher de s'executer, pas de lui repondre.
Le secret ne vit que le temps de l'installateur, sur le reseau libvirt,
et disparait avec lui.
--- EN ---
On IBM Z, d-i always offers to continue over SSH — the console there is
historically limited. It refuses an empty password and stopped on
"Empty password".
Preseeded, the password goes through. But the next screen shows this is
NOT enough: network-console starts sshd and waits for the "installer"
user to connect. It never returns. Making this unattended requires
preventing it from running, not answering it.
The secret lives only for the installer's lifetime, on the libvirt
network, and vanishes with it.
Assisted-by: Claude Opus 5
(cherry picked from commit 13f0f201678d2ef866fb2342ec16f958d44b0351)
Le syslog de d-i a tranche : « Menu item 'netcfg-static' selected », puis
« Taking down interface enc1 ». netcfg-dhcp n'apparait JAMAIS — il n'est
pas dans l'initrd s390x, et aucun variant netboot n'existe pour cette
architecture (404 sur trixie comme sur bookworm).
Aucun DHCP n'etait donc tente. Sept hypotheses ont cherche pourquoi il
echouait ; il n'avait jamais lieu. C'est la convention IBM Z, ou le
reseau se donne au parmfile.
deploy_qemu choisit desormais une adresse libre en HAUT de la plage —
dnsmasq attribue depuis le bas — et la preseede. Mesure : l'ecran
d'adressage statique a disparu, l'installateur poursuit.
--- EN ---
d-i's syslog settled it: "Menu item 'netcfg-static' selected", then
"Taking down interface enc1". netcfg-dhcp NEVER appears — it is not in
the s390x initrd, and no netboot variant exists for this architecture
(404 on trixie and bookworm alike).
So no DHCP was ever attempted. Seven hypotheses looked for why it
failed; it never happened. This is the IBM Z convention, where the
network is given in the parmfile.
deploy_qemu now picks a free address at the TOP of the range — dnsmasq
allocates from the bottom — and preseeds it. Measured: the static
addressing screen is gone, the installer moves on.
Assisted-by: Claude Opus 5
(cherry picked from commit 8c630969a605ec191a65dc93896014ac9e3a1227)
Quatre lignes avaient ete empilees sur des hypotheses successives —
link_wait_timeout, dhcp_timeout, dhcp_options, choose_interface. Aucune
n'a jamais ete verifiee, et l'essai nu le montre : sans elles, le
comportement est EXACTEMENT le meme.
Elles restaient donc comme du bruit, en laissant croire que la question
du reseau avait ete traitee. Le blocage sur l'adressage statique
persiste, avec un lien UP,LOWER_UP et un DHCP qui repond en deux
secondes a un udhcpc manuel.
--- EN ---
Four lines had been stacked on successive hypotheses —
link_wait_timeout, dhcp_timeout, dhcp_options, choose_interface. None
was ever verified, and the bare run shows it: without them the behaviour
is EXACTLY the same.
They remained as noise, suggesting the network question had been dealt
with. The static-addressing stop persists, with a UP,LOWER_UP link and a
DHCP server answering a manual udhcpc in two seconds.
Assisted-by: Claude Opus 5
(cherry picked from commit f52bc66a3b70075831e1a7bfdd2dd7b2a352ad32)
Le blocage sur l'adressage statique n'etait pas diagnosticable : netcfg
ecrit ses traces dans le syslog INTERNE de d-i, qu'on ne lit qu'en
ouvrant un shell a la main sur une console serie.
Un preseed/early_command ecrit desormais l'etat du reseau sur la
console, donc dans le journal. Il a immediatement montre que l'interface
etait ETEINTE — « enc1: <BROADCAST,MULTICAST> qdisc noop » — alors qu'un
udhcpc manuel obtenait un bail en deux secondes. Le reseau n'a jamais
ete en cause.
La commande allume donc enc1 avant que netcfg ne decide. L'interface est
bien UP,LOWER_UP ensuite, ce qui est correct en soi — mais netcfg
demande TOUJOURS une adresse statique. La cause reste a trouver.
--- EN ---
The static-addressing stop was not diagnosable: netcfg writes its traces
to d-i's INTERNAL syslog, readable only by opening a shell by hand on a
serial console.
A preseed/early_command now writes the network state to the console,
hence to the log. It immediately showed the interface was DOWN — "enc1:
<BROADCAST,MULTICAST> qdisc noop" — while a manual udhcpc obtained a
lease in two seconds. The network was never at fault.
So the command brings enc1 up before netcfg decides. The interface is
UP,LOWER_UP afterwards, which is right in itself — but netcfg STILL asks
for a static address. The cause remains to be found.
Assisted-by: Claude Opus 5
(cherry picked from commit e594fe5eab87d5060b878e44f9cf484e6d7b9e7f)
« auto=true » vise le preseed par URL : il reordonne l'installation pour
monter le reseau avant tout le reste, afin d'aller chercher le fichier.
Le notre est embarque dans l'initrd, il n'y a rien a telecharger.
Le garder faisait donc courir netcfg tres tot pour rien. Cela n'a pas
suffi a debloquer l'installation — le blocage sur l'adressage statique
demeure — mais l'argument n'avait aucune raison d'etre la.
--- EN ---
"auto=true" targets URL preseeding: it reorders the install to bring the
network up before anything else, so the file can be fetched. Ours is
embedded in the initrd; there is nothing to download.
Keeping it ran netcfg very early for no reason. This did not unblock the
install — the static-addressing stop remains — but the argument had no
business being there.
Assisted-by: Claude Opus 5
(cherry picked from commit b805d352e0c3505cdb2522e1023c70e0dc506f15)
« L'installation a echoue, pas de sortie pertinente » : une console pty
ne garde RIEN. Quand d-i s'arrete, il l'ecrit a l'ecran d'une VM que
personne ne regarde, et il ne reste rien a lire. La voie installateur
ecrit desormais un journal qui survit a l'arret du domaine.
Ce journal a immediatement nomme la premiere cause : d-i s'arretait sur
« Configure the network device », une question propre a s390x posee par
le udeb s390-netdevice — ctc, qeth, iucv ou virtio. Elle n'a AUCUNE
valeur par defaut, donc priority=critical ne la saute pas. Preseedee a
virtio, elle disparait.
Reste un second arret, non resolu : netcfg n'essaie aucun DHCP et tombe
sur la saisie d'une adresse statique. Ni le delai de lien, ni le nom
explicite de l'interface n'y changent quoi que ce soit.
--- EN ---
"The install failed, no relevant output": a pty console keeps NOTHING.
When d-i stops, it says so on the screen of a VM nobody watches, and
nothing is left to read. The installer path now writes a log that
outlives the domain.
That log immediately named the first cause: d-i stopped on "Configure
the network device", an s390x-only question from the s390-netdevice
udeb — ctc, qeth, iucv or virtio. It has NO default, so
priority=critical does not skip it. Preseeded to virtio, it is gone.
A second stop remains, unsolved: netcfg attempts no DHCP and falls to
static address entry. Neither the link timeout nor naming the interface
explicitly changes anything.
Assisted-by: Claude Opus 5
(cherry picked from commit d1a371a8f4775e8488522fba24a79775a5a101e8)
L'ecran de deploiement portait sa PROPRE copie de S390X_DISTROS, sous un
commentaire promettant qu'elle restait « coherente avec deploy_qemu.py ».
Une copie ne tient aucune promesse : Debian a gagne s390x la-bas et
l'ecran ne le proposait toujours pas.
_qemu_arch_distros lit desormais ARCH_DISTRO_SUPPORT, et _qemu_arches_for
y passe aussi pour que « toutes les architectures » n'offre rien que
deploy_qemu refuserait ensuite. Les tuples locaux restent en repli si
l'import echoue. L'import est memorise : le catalogue l'interrogeait une
fois par couple (distro, version).
Plancher memoire de 2048 Mio sur la voie installateur, annonce et jamais
abaissant : d-i deplie un systeme de fichiers en RAM la ou une image
cloud arrive installee, et le manque s'y voit comme un ecran fige.
--- EN ---
The deploy screen carried its OWN copy of S390X_DISTROS, under a comment
promising it stayed "consistent with deploy_qemu.py". A copy keeps no
promise: Debian gained s390x over there and the screen still did not
offer it.
_qemu_arch_distros now reads ARCH_DISTRO_SUPPORT, and _qemu_arches_for
goes through it too, so "all architectures" offers nothing deploy_qemu
would later refuse. The local tuples remain as a fallback if the import
fails. The import is memoised: the catalogue queried it once per
(distro, version) pair.
A 2048 MiB memory floor on the installer path, announced and never
lowering: d-i unpacks a filesystem into RAM where a cloud image arrives
installed, and running short shows up as a frozen screen.
Assisted-by: Claude Opus 5
(cherry picked from commit f0ee70c1ac43ba2bc9f5fb78fe71f821a15daf7d)
Debian ne publie aucune image cloud s390x — verifie sur le miroir :
bookworm et trixie ne servent que amd64, arm64, ppc64el et riscv64. Le
port existe pourtant, « binary-s390x » repond 200, et l'installateur
livre kernel + initrd pour les deux versions.
D'ou une seconde voie de deploiement, choisie par uses_installer() :
disque VIERGE au lieu d'un qcow2 converti, amorcage kernel+initrd au
lieu de --import, et un preseed a la place du seed cloud-init. Le
preseed refait ce que fait cloud-init — nom d'hote, utilisateur, cles
SSH, sudo, fuseau, paquets — sinon d-i pose la question sur une console
que personne ne regarde.
Le preseed voyage DANS l'initrd : pas de serveur HTTP a maintenir
pendant l'installation, et rien qui depende du moment ou le reseau
monte.
Verifie contre l'initrd s390x reel : preseed.cfg relu a la racine des
966 entrees, 1807 octets identiques a l'ecriture. Les voies image cloud
sont inchangees — amd64, arm64 et Ubuntu s390x gardent --import.
--- EN ---
Debian publishes no s390x cloud image — checked against the mirror:
bookworm and trixie only serve amd64, arm64, ppc64el and riscv64. Yet
the port exists, "binary-s390x" returns 200, and the installer ships
kernel + initrd for both versions.
Hence a second deployment path, picked by uses_installer(): a BLANK
disk instead of a converted qcow2, kernel+initrd boot instead of
--import, and a preseed in place of the cloud-init seed. The preseed
redoes what cloud-init does — hostname, user, SSH keys, sudo, timezone,
packages — otherwise d-i asks on a console nobody watches.
The preseed travels INSIDE the initrd: no HTTP server to keep alive
during the install, and nothing depending on when the network comes up.
Verified against the real s390x initrd: preseed.cfg read back at the
root of 966 entries, 1807 bytes identical to what was written. Cloud
image paths are unchanged — amd64, arm64 and Ubuntu s390x keep --import.
Assisted-by: Claude Opus 5
(cherry picked from commit d26ddee95bb5b3b3627950c33879155fb28bba58)
Le choix [3] listait les domaines libvirt de la machine qui execute
todo.py. Or on pilote un parc imbrique depuis l'exterieur : cette
machine ne connait pas les VM d'un orchestrateur, et la bonne cible
n'apparaissait donc jamais dans la liste.
L'ecran VNC appartient a QEMU, donc a l'hyperviseur. Tunneler vers
l'invite ne trouve rien : le socket n'existe pas de ce cote. La cible
est le ProxyJump declare pour l'hote, lu par « ssh -G » — la seule
lecture qui couvre Match, wildcards et Include. Le nom compose
« saut+vm » n'est qu'un libelle.
Le port est lu sur cet hyperviseur, sans sudo d'abord : le groupe
libvirt suffit souvent, et « sudo -n » distant echoue faute de TTY.
--- EN ---
Choice [3] listed the libvirt domains of the machine running todo.py.
But a nested fleet is driven from outside: that machine knows nothing
of an orchestrator's VMs, so the right target never showed up.
The VNC screen belongs to QEMU, hence to the hypervisor. Tunnelling to
the guest finds nothing: the socket does not exist on that side. The
target is the ProxyJump declared for the host, read via "ssh -G" — the
only reading that covers Match, wildcards and Include. The composite
"jump+vm" name is just a label.
The port is read on that hypervisor, without sudo first: libvirt group
membership often suffices, and remote "sudo -n" fails for lack of a TTY.
Assisted-by: Claude Opus 5
(cherry picked from commit 2fb846d502cc8026732b58e1f487d7a6726f17eb)
My own regression. The tuple went from three fields to four and I
missed recheck_after_reset, so a live migration died on "too many values
to unpack" -- AFTER the COW copy had been reset, at the very moment the
tool was about to prove the fix worked.
Both sites wanted only the URL, so they index instead of unpacking. That
survives the next field; a comment saying "always four elements" does
not.
The pass had no test at all, which is why the suite and the mutations
both stayed green. It has three now, plus a guard that fails on any
three-field unpack of that list.
--- FR ---
Ma régression. Le tuple est passé de trois à quatre champs et j'ai
manqué recheck_after_reset : une migration en cours est morte sur « too
many values to unpack » — APRÈS la réinitialisation de la copie COW, au
moment précis où l'outil allait prouver que le correctif tenait.
Les deux sites ne voulaient que l'URL : ils indexent au lieu de
dépaqueter. Cela survit au prochain champ ; un commentaire « toujours
quatre éléments » non.
Cette passe n'avait aucun test, d'où le vert de la suite et des
mutations. Elle en a trois, plus un garde qui tombe sur tout
dépaquetage à trois champs de cette liste.
Assisted-by: Claude Opus 5
The report named the sitemap URL, never the one the redirect chain
ended on. On this site every page goes through two or three hops --
measured, 146 for 55 pages, between the language prefix and the
canonical slug -- so a 500 at the end was reported against a page that
answers perfectly well. One goes and checks it, finds it healthy, and
concludes the tool is wrong.
urllib carries the answer: HTTPError.url is the URL that produced the
error, not the one requested. fetch now returns it and the report shows
it when it differs.
A timeout was never reported as 500 -- fetch returns 0 and the report
writes "no answer" -- but the evidence for a real 500 did evaporate: the
Odoo log was opened with "w", so replaying the test erased the trace of
the failure one had just seen. One generation is kept now.
--- FR ---
Le rapport nommait l'URL du sitemap, jamais celle où la chaîne de
redirections aboutit. Sur ce site chaque page en traverse deux ou trois
— mesuré, 146 pour 55 pages — donc un 500 au bout était imputé à une
page qui répond très bien. On va la vérifier, on la trouve saine, et
l'on conclut que l'outil se trompe.
urllib porte la réponse : HTTPError.url est l'URL qui a produit
l'erreur. `fetch` la rend, et le rapport l'affiche quand elle diffère.
Un dépassement de délai n'a jamais été rendu comme un 500 — `fetch`
rend 0, écrit « aucune réponse » — mais la preuve d'un vrai 500
s'évaporait : le journal Odoo était ouvert en « w », donc rejouer le
test effaçait la trace qu'on venait de voir. Une génération est gardée.
Assisted-by: Claude Opus 5
[ADD] release: an Odoo migration that drives itself
A migration used to be a sequence of commands and a person watching. It
now runs: it repairs, replays, takes the default after five seconds, and
names the answer it is about to take before taking it.
What each bump breaks is predicted rather than discovered. Customized
SCSS, themes, DMS visibility lost with MuK's access model, views whose
stored type contradicts their parent, the <tree> tags Odoo 18 renamed to
<list> -- each has a repair offered where the failure is blamed.
Nothing is called done on a promise. Every public URL is requested, /my
and every app are opened as the neutralization test user, and the views
behind a failing URL are named. The OCA database cleanup runs first, so a
page does not fail on leftovers.
Two screens make a long run legible: « t » shows where it stands, with
coloured commands, elapsed time and one log file per step; the quality
report says what the run gained and lost, tells Odoo's own redesigns from
real losses, and lays OpenUpgrade's declared changes over the real ones.
--- FR ---
Une migration était une suite de commandes et quelqu'un pour la
surveiller. Elle s'exécute maintenant : elle répare, rejoue, prend le
défaut au bout de cinq secondes, et nomme la réponse qu'elle va prendre
avant de la prendre.
Ce que chaque palier casse est prévu plutôt que découvert. SCSS
personnalisé, thèmes, visibilité DMS perdue avec le modèle d'accès de MuK,
vues dont le type stocké contredit leur parent, balises <tree> qu'Odoo 18
a renommées en <list> — chacun reçoit une réparation, proposée là où la
panne est imputée.
Rien n'est déclaré terminé sur parole. Chaque URL publique est demandée,
/my et chaque application sont ouvertes sous l'utilisateur de test de
neutralisation, et les vues derrière une URL en échec sont nommées. Le
nettoyage de base OCA passe d'abord, pour qu'une page n'échoue pas sur des
restes.
Deux écrans rendent une longue exécution lisible : « t » montre où elle en
est, commandes en couleur, durée écoulée, un fichier de journal par étape ;
le rapport de qualité dit ce qu'elle a gagné et perdu, distingue les
refontes propres à Odoo des vraies pertes, et superpose les changements
déclarés par OpenUpgrade aux réels.
Assisted-by: Claude Opus 5
OpenUpgrade converts the COLUMN and never the ARCH:
def _fix_list_view_type(cr):
cr.execute("UPDATE ir_ui_view SET type='list' WHERE type='tree'")
so the load dies on "the root node of a list view should be <list>".
A module view recovers at its next update, which rewrites the arch from
XML. A view with no xmlid -- a hand-made list, a website copy -- is
rewritten by nothing and stays broken forever. The report says which is
which, because the two call for different work.
Every occurrence, not just the root: a <tree> nested in a form is a
one2many list and is refused just the same. Odoo 18's own addons hold
none, so nothing legitimate is at risk. Gated on version 18: before it,
the tag is correct and "fixing" it would break healthy views.
Four tests run the SQL against a real PostgreSQL. A text assertion
cannot see what a query does -- it took a live run to prove every
language of the jsonb arch is converted, not just en_US.
--- FR ---
OpenUpgrade convertit la COLONNE et jamais l'ARCH, d'où l'échec sur « le
nœud racine d'une vue list devrait être <list> ». Une vue de module s'en
remet à sa prochaine mise à jour ; une vue sans xmlid — liste faite
main, copie de site — n'est réécrite par rien. Le rapport distingue les
deux, car le travail diffère.
Toutes les occurrences, pas seulement la racine : un <tree> imbriqué
dans un formulaire est une liste one2many, refusée pareillement. Les
addons d'Odoo 18 n'en portent aucun. Bridé à la 18 : avant, la balise
est juste.
Quatre tests exécutent le SQL contre un vrai PostgreSQL. Une assertion
sur du texte ne voit pas ce qu'une requête fait — il a fallu l'exécuter
pour prouver que toutes les langues du jsonb sont converties.
Assisted-by: Claude Opus 5
The question was asked once, at step one, and a flag kept it from ever
returning. But a theme only becomes incompatible at a given bump, hours
later -- asking at the start could not cover it. Entry [6] appears when
TWO conditions hold: a theme is installed, and the recent output names
it. One condition alone would offer to wreck the site's design over an
error that has nothing to do with it.
Also, the 17 to 18 rename OpenUpgrade declares and never applies:
forum.post / tag_ids : column1 is now 'forum_post_id' ('forum_id')
website_forum/18.0.1.2/ holds only an analysis, no script, so the load
dies on a foreign key to a column that does not exist and leaves the
database half migrated.
--- FR ---
La question était posée une fois, à l'étape 1, et un drapeau
l'empêchait de revenir. Or un thème ne devient incompatible qu'à un
palier donné, des heures plus tard : la poser au départ ne pouvait pas
suffire. L'entrée [6] paraît quand DEUX conditions tiennent — un thème
installé, et la sortie récente qui le nomme. Une seule offrirait de
casser le design du site pour une panne étrangère.
Et le renommage 17 → 18 qu'OpenUpgrade déclare sans jamais l'appliquer :
forum.post / tag_ids : column1 is now 'forum_post_id' ('forum_id')
website_forum/18.0.1.2/ ne porte qu'une analyse, aucun script : le
chargement meurt sur une clé étrangère vers une colonne absente et
laisse la base à moitié migrée.
Assisted-by: Claude Opus 5
Entry [5] never asked "Correct them?". The tool ran, printed its
diagnosis, exited 1 -- and todo_upgrade_execute read that as a failure
and reopened ITS error menu on top of ours. The menu looped and nothing
was ever corrected.
wait_at_error=False on both calls, as the COW tool next door already
does. The fake in the test now models the real contract: it refuses to
return a non-zero status when the flag is missing, exactly as the real
one refuses by recursing into its prompt.
--- FR ---
L'entrée [5] ne posait jamais la question « Les corriger ? ». L'outil
tournait, affichait son diagnostic, sortait 1 — et todo_upgrade_execute
y lisait un échec et rouvrait SON menu d'erreur par-dessus le nôtre. Le
menu tournait en rond et rien n'était corrigé.
wait_at_error=False sur les deux appels, comme le fait déjà l'outil COW
juste à côté. Le faux du test modèle désormais le vrai contrat : il
refuse de rendre un statut non nul quand le drapeau manque, comme le
vrai refuse en repartant dans son invite.
Assisted-by: Claude Opus 5
Odoo refused to load a database: it validated a <search> arch with tree
rules. The view is not a COW copy -- the COW tools were right to say
they had nothing to reset -- its stored `type` simply lies.
Nothing would ever have fixed it. In ir_ui_view.py, `type` is filled in
`create`, and only when absent; `write` never recomputes it. A wrong
value stays wrong, and `-u module` fails on the validation it causes
before it could rewrite anything.
Plain SQL, no ORM: the registry is what will not load, and a repair that
needed Odoo to fix what stops Odoo would be useless.
The rule is Odoo's own -- an inherited view takes its parent's type --
and it holds: zero disagreement on a pristine 18 install and on four
migrated databases, exactly one on the database that refused to load.
--- FR ---
Odoo refusait de charger une base : il validait un arch <search> avec
les règles d'un tree. La vue n'est pas une copie COW — les outils COW
avaient raison de dire qu'ils n'avaient rien à réinitialiser — c'est son
`type` stocké qui ment.
Rien ne l'aurait jamais réparé. Dans ir_ui_view.py, `type` est rempli
dans `create`, et seulement s'il est absent ; `write` ne le recalcule
jamais. Une valeur fausse le reste, et `-u module` échoue sur la
validation qu'elle provoque avant de pouvoir réécrire quoi que ce soit.
En SQL, sans ORM : c'est le registre qui ne charge plus, et une
réparation qui aurait besoin d'Odoo ne servirait à rien.
La règle est celle d'Odoo — une vue héritée prend le type de son parent
— et elle tient : zéro écart sur une 18 neuve et sur quatre bases
migrées, exactement un sur celle qui refusait de charger.
Assisted-by: Claude Opus 5
The report counted + and -. A field that stops being stored is neither:
it loses its column and keeps its existence. Read as a loss it cries
wolf every step; ignored it would mask a real one. OpenUpgrade already
knows, in the upgrade_analysis.txt files the checkout carries -- the
same source the OCA coverage pages are generated from, read locally, at
the checkout's exact version.
Three categories keep the signal from drowning: a field whose model went
away is not a second finding (544 of them on one real step), a field of
a module OpenUpgrade does not analyse was never its business, and the
rest is grouped by field name -- __last_update counted itself 391 times.
--- FR ---
Le rapport comptait des + et des -. Un champ qui cesse d'être stocké
n'est ni l'un ni l'autre : il perd sa colonne et garde son existence. Lu
comme une perte, il alarme à chaque palier ; ignoré, il en masquerait
une vraie. OpenUpgrade le sait déjà, dans les upgrade_analysis.txt que
porte le checkout -- la source des pages de couverture de l'OCA, lue
localement, à la version exacte.
Trois catégories évitent que le signal se noie : un champ dont le modèle
a disparu n'est pas une trouvaille de plus (544 sur un palier réel), un
champ d'un module non analysé n'a jamais relevé d'OpenUpgrade, et le
reste est groupé par nom -- __last_update se comptait 391 fois.
Assisted-by: Claude Opus 5
The repair now runs by itself where the breakage happens: MuK becomes
OCA DMS at 13 and nowhere else, so the hook is gated on that bump. It
stays quiet on databases without DMS and on ones already repaired, and
a successful --apply now exits 0 instead of 1.
The wider hole stays open otherwise: data PRESENT that a global rule
hides entirely. Row counts said everything was there — true. The smoke
test served every page — true. Nobody could reach the records. The new
check runs at every bump and names any model with rows that no active
internal user can see a single one of. Proven both ways on a copy: 85
models clean after the repair, dms.file and dms.directory named before
it.
--- FR ---
La réparation s'exécute désormais là où la casse a lieu : MuK devient
OCA DMS au palier 13 et nulle part ailleurs, d'où le garde. Elle se tait
sur une base sans DMS et sur une base déjà réparée, et un --apply réussi
rend 0 au lieu de 1.
Le trou plus large restait ouvert : des données PRÉSENTES qu'une règle
globale masque entièrement. Les comptages disaient « tout est là » —
vrai. Le test de fumée servait les pages — vrai. Personne n'atteignait
les données. Le nouveau test tourne à chaque palier et nomme tout modèle
dont aucun utilisateur interne actif ne voit une seule ligne. Éprouvé
dans les deux sens sur une copie : 85 modèles sains après réparation,
dms.file et dms.directory nommés avant.
Assisted-by: Claude Opus 5
Nothing was lost at the 13 bump: 69 files, 16 folders and 23 MB of
content_binary are identical from 12 to 18. What changed is the security
model. MuK filtered on company alone; OCA DMS adds a GLOBAL rule on
permission_read, granted only through a dms.access.group or through
storages saved as attachment. The migration created no group — MuK had
none to convert — and the storages are database. Both doors shut, every
user sees zero.
Reports without writing unless --apply. The visibility count uses a real
user: the global rule spares the superuser, so a sudo count would call a
mute database healthy.
--- FR ---
Rien n'a été perdu au palier 13 : 69 fichiers, 16 dossiers et 23 Mo de
content_binary sont identiques de la 12 à la 18. C'est le modèle de
sécurité qui a changé. MuK ne filtrait que sur la société ; OCA DMS
ajoute une règle GLOBALE sur permission_read, accordée par une
dms.access.group ou par un stockage en attachment. La migration n'a créé
aucun groupe — MuK n'en avait aucun à convertir — et les stockages sont
en database. Les deux portes fermées, personne ne voit rien.
Rapport sans écriture sauf --apply. Le comptage de visibilité passe par
un vrai utilisateur : la règle globale épargne le super-utilisateur, donc
un comptage en sudo déclarerait saine une base muette.
Assisted-by: Claude Opus 5
ir_property never empties, it GROWS — 211 rows in 12, 457 in 17 — then
vanishes in 18. Its fields are jsonb columns there, verified on
res_partner.property_payment_term_id.
mail_tracking_value is a REAL loss, not a rename: `field` goes from
varchar to a foreign key in 14, and what would not resolve was deleted.
1528 of the 2336 belonged to the removed agile module; 706 more survived
under a new name. New kind "pruned" so the report cannot call a living
table retired.
--- FR ---
ir_property ne se vide jamais, elle GROSSIT — 211 lignes en 12, 457 en
17 — puis disparaît en 18. Ses champs y sont des colonnes jsonb, vérifié
sur res_partner.property_payment_term_id.
mail_tracking_value est une VRAIE perte, pas un renommage : `field`
passe de varchar à clé étrangère en 14, et ce qui ne se résolvait pas a
été supprimé. 1528 des 2336 venaient du module agile retiré ; 706 autres
ont survécu sous un autre nom. Nouveau genre « pruned » pour que le
rapport ne déclare pas retirée une table bien vivante.
Assisted-by: Claude Opus 5
Verified bump by bump rather than deduced from a name that looks alike:
1269 rows in 12, 13 and 14, the table disappears in 15 and
mail_notification holds exactly 1269. Not one lost. That row-for-row
carry-over is what earns the entry — a neighbouring name would have
proved nothing.
It is dated at 15 and not earlier: the table is still full at 14, and an
entry that applied sooner would mask a loss that happened before the
redesign.
The unexplained list goes from 56 to 55.
--- FR ---
[ADD] qualité de migration : needaction est devenu notifications en 15
Vérifié palier par palier plutôt que déduit d'un nom qui se ressemble :
1269 lignes en 12, 13 et 14, la table disparaît en 15 et
mail_notification en compte exactement 1269. Pas une perdue. C'est ce
report à l'unité près qui autorise l'entrée — un nom voisin n'aurait rien
prouvé.
Elle est datée de 15 et pas avant : la table est encore pleine en 14, et
une entrée qui s'appliquerait plus tôt masquerait une perte survenue avant
la refonte.
La liste des pertes inexpliquées passe de 56 à 55.
Assisted-by: Claude Opus 5
Fifty-seven losses are read from the top, not in alphabetical order. They
are now sorted by rows LOST, not by rows there before: a table of ten
thousand that drops two matters less than one of a thousand that empties.
« d » cycles the pane through the complete lists — modules, models,
fields, COW copies, tables — and back to the summary. The summary cuts at
eight entries and is right to; but when one is looking for whether ONE
module survived, the truncated list does not answer, and that is exactly
when it is needed.
Two inventories were missing and both matter. FIELDS: a lost field is a
lost column of data, finer than a model, which can survive emptied of
half of its own. COW COPIES by key: it is the key one resets, and by the
key one finds them again across versions. On a real 12 → 18 they read
11 036 → 15 069 fields and 64 → 131 copies, of which 28 disappeared —
customisations nothing was reporting until now.
One mode replaces two flags: « show missing files » and « show the model
list » cannot both be true, and two booleans let that impossible state be
written. The mode is named in the sub-title, because a pane that changes
without saying why reads as a broken screen.
--- FR ---
[ADD] qualité de migration : les plus grosses pertes d'abord, les listes derrière « d »
Cinquante-sept pertes se lisent par le haut. Elles sont triées sur le
volume PERDU, non sur le volume présent avant : une table de dix mille qui
en perd deux compte moins qu'une de mille qui se vide.
« d » fait défiler le panneau à travers les listes entières — modules,
modèles, champs, copies COW, tables — puis revient au résumé.
Deux inventaires manquaient. Les CHAMPS : un champ perdu est une colonne
de données perdue. Les COPIES COW par leur clé : sur une vraie 12 → 18,
28 ont disparu — des personnalisations que rien ne signalait.
Un seul mode remplace deux drapeaux, qui laissaient écrire un état
impossible. Il est nommé dans le sous-titre.
Assisted-by: Claude Opus 5
« 81 tables lost rows » buried the questions worth asking. The largest of
them — ir_translation, 32 984 rows — is a redesign Odoo made in 16, when
translations moved into jsonb columns. Putting redesigns and real losses
on the same footing is the surest way not to see the second kind.
A map now names what Odoo moves or retires, and the report splits the
list in two: unexplained first, then what Odoo did on purpose. On a real
12 → 18 the split is 57 and 14, and the partition is exact — an explained
loss is annotated, never removed, because removing it was the one thing
that could hide a real one.
Every entry was VERIFIED on that migration by counting both sides, not
written from memory: crm_lead_tag 6 → crm_tag +6, mail_channel 26 →
discuss_channel +26, account_invoice 651 → account_move +441. A map
written from memory would explain losses that are not losses.
And a merge whose target gained nothing says so: the explanation does not
hold, and that is exactly what the map was meant to surface.
--- FR ---
[ADD] qualité de migration : distinguer les refontes d'Odoo des vraies pertes
« 81 tables ont perdu des lignes » enterrait les questions qui valaient la
peine. La plus grosse — ir_translation, 32 984 lignes — est une refonte
d'Odoo 16, quand les traductions sont passées en colonnes jsonb.
Une carte nomme désormais ce qu'Odoo déplace ou retire, et le rapport
sépare la liste en deux : l'inexpliqué d'abord, puis ce qu'Odoo a fait
exprès. Sur une vraie 12 → 18 : 57 et 14, et la partition est exacte —
une perte expliquée est annotée, jamais retirée.
Chaque entrée a été VÉRIFIÉE sur cette migration en comptant les deux
côtés : crm_lead_tag 6 → crm_tag +6, mail_channel 26 → discuss_channel
+26, account_invoice 651 → account_move +441.
Et une fusion dont la table d'accueil n'a rien reçu le dit : l'explication
ne tient pas, et c'est précisément ce que la carte devait révéler.
Assisted-by: Claude Opus 5
An entry with no icon, in a menu where every other one has one, reads as
unfinished. The section gets 🚚 and the entry 📐 — the same symbol the
quality report already wears in its own title, because it is the same
thing.
The spacing follows a convention this menu keeps without stating it: an
icon of « neutral » width — 🗄, 🖼 — occupies one column in a terminal
and takes TWO spaces to line up, while a wide one — 📏, 📐 — takes one.
Getting it wrong shifts the line, and nothing says so until it is under
your eyes. A test now states it.
--- FR ---
[FIX] todo analyse : donner son icône à l'entrée de migration
Une entrée sans icône, dans un menu où toutes les autres en ont une, se
lit comme une entrée inachevée. La section reçoit 🚚 et l'entrée 📐 — le
symbole que le rapport de qualité porte déjà dans son propre titre,
puisque c'est la même chose.
L'espacement suit une convention que ce menu tient sans la dire : une
icône de largeur « neutre » — 🗄, 🖼 — s'affiche sur une colonne dans un
terminal et prend DEUX espaces pour s'aligner, une icône large — 📏, 📐 —
un seul. Se tromper décale la ligne, et rien ne le signale avant de
l'avoir sous les yeux. Un test l'énonce désormais.
Assisted-by: Claude Opus 5
« 254 attachment files missing » does not say which. « m » now lists
them, grouped by model AND FIELD — the field is the most useful thing in
the row, because it says which field lost its image. On a real migration
it splits into 234 res.country/image flags, 13 payment.provider logos,
and a handful of scattered attachments including one 255 kB event photo:
the first two are module data a reinstall restores, the last is not, and
the raw list put them on the same footing.
The metadata is read ONLY when asked. One more query per database would
lengthen a survey that runs in four seconds, for something one looks at
by asking for it.
And every figure of a step now carries its change against the previous
one. « 2283 views » is a number; « +61 » is information. The first step
gets none: inventing a zero there would claim a comparison that does not
exist.
--- FR ---
[ADD] qualité de migration : nommer les fichiers absents, et montrer les écarts
« 254 fichiers de pièces jointes absents » ne dit pas lesquels. « m » en
donne la liste, groupée par modèle ET PAR CHAMP — le champ est le
renseignement le plus utile de la ligne, car il dit lequel a perdu son
image. Sur une vraie migration : 234 drapeaux res.country/image, 13 logos
de fournisseurs de paiement, et une poignée de pièces jointes éparses dont
une photo d'événement de 255 ko. Les deux premiers groupes sont des
données de module qu'une réinstallation restaure, le dernier non.
Les métadonnées ne sont lues QU'À LA DEMANDE : une requête de plus par
base allongerait un parcours qui tient en quatre secondes.
Et chaque chiffre d'un palier porte son écart avec le précédent. « 2283
vues » est un nombre, « +61 » est une information. Le premier palier n'en
a pas : y inventer un zéro annoncerait une comparaison qui n'existe pas.
Assisted-by: Claude Opus 5
Pressing « k » crashed with « asyncio.run() cannot be called from a
running event loop ». `suspend()` hands the terminal over but does NOT
stop the loop, and `app.run()` calls `asyncio.run()` underneath. A
subprocess has its own loop and paints the terminal it was given.
My test asserted that suspend() was CALLED, and that structure was
correct — the launch inside it was not. Structure is not behaviour, and
the test that would have caught this is the one that presses the key.
It exists now, and a guard refuses the nested start with a sentence
instead of forty lines of traceback.
The screen module also lost its shebang: it has no main, so the line
claimed something that was not true, and the permission rule was right
to say so.
--- FR ---
[FIX] état de migration : ouvrir l'écran de qualité dans son processus
« k » plantait sur « asyncio.run() cannot be called from a running event
loop ». `suspend()` rend le terminal mais n'arrête PAS la boucle, et
`app.run()` appelle `asyncio.run()` en dessous. Un sous-processus a sa
propre boucle.
Mon test vérifiait que suspend() était APPELÉ — et cette structure était
juste ; c'est le lancement à l'intérieur qui ne l'était pas. La structure
n'est pas le comportement, et le test qui aurait attrapé cela est celui
qui presse la touche. Il existe désormais, et un garde-fou refuse le
lancement imbriqué par une phrase plutôt que par quarante lignes de trace.
Le module d'écran perd aussi son shebang : sans `main`, cette ligne
annonçait une intention qui n'existait pas.
Assisted-by: Claude Opus 5
A migration leaves one database per step and they all still exist, so the
tool compares them side by side rather than replaying anything. Six Odoo
starts would cost an hour, write to the databases and need the checkout
switched at each step; the same inspection in SQL takes under half a
second per database and touches nothing. Measured on a real migration:
seven databases surveyed in 3.8 seconds.
It reports what each step gained and lost — modules, models, views, menus,
attachments — and ends on the comparison of the ENDS, which is not the sum
of the steps: a module dropped at 15 and put back at 17 lost nothing, and
adding the steps would count it twice.
The signal that matters is rows. A module removed is visible; a table
going from four thousand rows to zero is visible nowhere.
Two rename heuristics were tried and rejected on real data before the one
that holds. Row count alone paired an account tag table with dms_directory
— both had seven rows. A shared five-letter word paired two cleanup
tables. Overall name similarity separates them. And a renamed table stays
in the loss list, annotated: removing it was the real danger, since a
wrong pairing would have hidden a genuine loss.
--- FR ---
[ADD] analyse : ce qu'une migration a gagné et perdu, palier par palier
Une migration laisse une base par palier et elles existent toutes encore :
l'outil les compare côte à côte plutôt que de rejouer quoi que ce soit.
Six démarrages d'Odoo coûteraient une heure et écriraient dans les bases ;
la même inspection en SQL prend moins d'une demi-seconde par base. Mesuré
sur une vraie migration : sept bases inspectées en 3,8 secondes.
Le bilan final compare les EXTRÉMITÉS, ce qui n'est pas la somme des
paliers : un module retiré en 15 puis remis en 17 n'a rien perdu.
Le signal qui compte, ce sont les lignes. Un module en moins se voit ; une
table qui passe de quatre mille lignes à zéro ne se voit nulle part.
Deux rapprochements de renommage ont été essayés et rejetés sur des
données réelles. Et une table renommée reste dans la liste des pertes,
annotée : l'en retirer était le vrai danger.
Assisted-by: Claude Opus 5
A step log reaches thirteen megabytes — measured on a real migration.
Nobody reads that, and the question one asks in front of it is two words
long: where did it go wrong? The screen now answers it.
Each step carries its count of ERROR and CRITICAL, and the pane lists the
DISTINCT messages with how many times each occurred. Forty-eight
« Model X has no table » is one problem seen forty-eight times, not
forty-eight problems, and the raw list buries everything else. WARNING is
left out of the count: a migration produces thousands, and a total that
includes them means nothing.
Each message keeps its logger and its DATABASE, which is what tells the
six bumps apart — they shared one file before a step opened its own.
Measured: thirteen megabytes scanned in 0.09 s, seventy occurrences
reduced to fifteen messages, and cached on (size, mtime) because the
screen repaints on every keystroke.
--- FR ---
[ADD] état de migration : lire le journal pour que personne n'ait à le faire
Un journal d'étape atteint treize mégaoctets — mesuré. Personne ne le
lit, et la question qu'on se pose devant lui tient en deux mots : où
est-ce que ça a mal tourné ? L'écran y répond désormais.
Chaque étape porte son compte d'ERROR et de CRITICAL, et le panneau liste
les messages DISTINCTS avec leur nombre. Quarante-huit fois « Model X has
no table » est un problème vu quarante-huit fois, pas quarante-huit
problèmes. Les WARNING sont hors du compte : une migration en produit des
milliers.
Chaque message garde son logger et sa BASE, ce qui distingue les six
paliers — ils partageaient un fichier avant qu'une étape n'ouvre le sien.
Mesuré : treize mégaoctets analysés en 0,09 s, soixante-dix occurrences
ramenées à quinze messages.
Assisted-by: Claude Opus 5
Every prompt now carries « ⏱5s » before the question. One that looks like
it waits forever does not invite you to step away, which is the whole
point of auto-run. The same clock reports the answer afterwards: it
announces the wait, then says what it decided.
Enter on the auto-run question already meant no; it now says so, with an
explicit default instead of a deduction. And the flag is cleared before
asking — an ERPLIBRE_AUTO_EXECUTE inherited from the shell would have
answered yes on someone's behalf, and that answer commits every later one.
« p » cycles three states rather than toggling one: a plain toggle freed
four lines, while what takes the room is the left COLUMN — on a server log
every character of width counts. All → no summary → detail only, and back.
The state is named in the sub-title, which stays visible in all three: a
panel that vanishes without a word reads as a broken screen.
--- FR ---
[ADD] migration : annoncer le compte à rebours, et trois états de panneaux
Chaque invite porte désormais « ⏱5s » devant la question. Une invite qui a
l'air d'attendre indéfiniment n'invite pas à s'absenter, et c'est pourtant
tout l'intérêt du mode auto. Le même chronomètre rend compte ensuite.
Entrée sur la question d'auto-exécution voulait déjà dire non ; elle le
DIT maintenant, par un défaut explicite plutôt qu'une déduction. Et le
drapeau est effacé avant de demander : une variable héritée du shell
aurait répondu « oui » à la place de quelqu'un.
« p » enchaîne trois états au lieu d'en basculer un : ce qui prend la
place, c'est la colonne de gauche. Tout → sans résumé → détail seul, et
l'on revient. L'état est nommé dans le sous-titre.
Assisted-by: Claude Opus 5
From the first write to the LAST one. The progression file is rewritten
after every move, so its update date is the end — or the present moment
while the migration is still running. Both dates were already shown; what
was missing was the one number one actually wants.
The statistics screen already computed this. It is reused rather than
rewritten: two formulas would give two durations for the same migration
depending on which screen one opens.
--- FR ---
[ADD] état de migration : combien de temps elle a duré
Du premier écrit au DERNIER. Le fichier de progression est réécrit après
chaque geste, donc sa date de mise à jour est la fin — ou l'instant
présent tant que la migration tourne. Les deux dates étaient déjà
affichées ; il manquait le seul chiffre qu'on cherche.
L'écran de statistiques portait déjà ce calcul. Il est réutilisé plutôt
que réécrit : deux formules donneraient deux durées pour la même
migration selon l'écran qu'on ouvre.
Assisted-by: Claude Opus 5
Four keys, and one bug behind them. « l » separates the commands from the
server log: the first says what was LAUNCHED, the second what it
ANSWERED, and an update writing tens of thousands of lines buries three
commands. « p » hides the summary panel, « - » and « + » move the split,
« r » re-reads the disk — the migration writes while one watches, and
closing the screen to see the next bump is what one ended up doing.
The « missing logs » had two causes, both real. A tail was shown without
saying it was one; it now names how many lines are hidden. And the first
two steps run before the database is named, so their logs landed under
« sans-nom » — outside the migration they belong to, invisible from the
screen. They are brought back the moment the name is known, appended
never overwritten.
The step 4 bug was already fixed: its log held all six bumps because only
print_step opened one, and the bump loop never calls it.
--- FR ---
[ADD] état de migration : l, p, r et les deux touches de taille
Quatre touches, et un défaut derrière. « l » sépare les commandes du
journal : la première dit ce qui a été LANCÉ, le second ce que cela a
RÉPONDU, et une mise à jour qui écrit des dizaines de milliers de lignes
enterre trois commandes. « p » cache le panneau de résumé, « - » et « + »
déplacent la séparation, « r » relit le disque — la migration écrit
pendant qu'on regarde.
Les « logs manquants » avaient deux causes. On montrait une fin sans dire
que c'en était une ; le nombre de lignes cachées est désormais nommé. Et
les deux premières étapes tournent avant que la base ne soit nommée :
leurs journaux atterrissaient sous « sans-nom », hors de la migration à
laquelle ils appartiennent. Ils la rejoignent dès que le nom est connu.
Assisted-by: Claude Opus 5
You were right that it read as global — and the cause ran deeper than the
display. Twenty step headers go through add_comment_progression against
seven through print_step, and the whole version-bump loop uses only the
first. The current step was set in the other one, so every tool verdict
of every bump carried a stale step.
The header itself now becomes the step, at the one place the journal is
already cut on. And the summary groups by (step, tool) instead of by tool
alone: a migration runs the smoke test at EVERY bump, and one line said
« smoke_public_url ✅ » while bump 14 had passed and bump 17 had fallen.
Within a step the last verdict still wins, with its run count — that is a
repair, not two bumps. The order is the journal's, because sorting step
names puts « 4.10 » before « 4.2 ».
--- FR ---
[FIX] état de migration : un résultat de test appartient à une étape
Vous aviez raison, cela se lisait comme global — et la cause était plus
profonde que l'affichage. Vingt en-têtes d'étape passent par
add_comment_progression contre sept par print_step, et toute la boucle des
paliers n'utilise que la première. L'étape courante était posée dans
l'autre : chaque verdict d'outil portait donc une étape périmée.
L'en-tête devient désormais l'étape, au seul endroit où le journal est
déjà découpé. Et le résumé groupe par (étape, outil) : une migration lance
le test de fumée à CHAQUE palier, et une seule ligne annonçait
« smoke_public_url ✅ » quand le palier 14 était passé et le 17 tombé.
Dans une étape, le dernier verdict l'emporte toujours — c'est une
réparation, pas deux paliers.
Assisted-by: Claude Opus 5
A list of commands in flat text blends into its own headings the moment it
outgrows the screen — which is exactly when it gets read. Commands are now
cyan, steps bold blue, failed ones red, and each verdict wears the colour
of its meaning: 1 is amber, because « there is something to look at » is
not a crash and painting it red worries for nothing.
Colour is refused three times over, and each refusal has cost someone: a
log file full of escape codes, a grep that finds nothing, a terminal that
prints them as text. A pipe is not a screen, and NO_COLOR is honoured.
The full screen goes through Text.from_ansi, which does two things: it
renders the colours, and it takes the rest literally. Textual parses Rich
markup, so a command containing « [1] » was being eaten as a tag and
vanished from the pane without a word. That was true before the colour.
--- FR ---
[ADD] état de migration : colorer les commandes, et savoir s'en abstenir
Une liste de commandes en texte plat se confond avec ses titres dès
qu'elle dépasse l'écran — et c'est justement quand elle le dépasse qu'on
la lit. Les commandes sont en cyan, les étapes en bleu gras, celles qui
ont échoué en rouge, et chaque verdict porte la couleur de son sens : 1
est ambre, car « il y a quelque chose à regarder » n'est pas une panne.
La couleur se refuse trois fois, et chaque refus a coûté à quelqu'un : un
fichier de journal truffé de codes d'échappement, un grep qui ne trouve
plus rien, un terminal qui les affiche en clair.
Le plein écran passe par Text.from_ansi, qui rend les couleurs ET prend le
reste au pied de la lettre : une commande contenant « [1] » était avalée
comme du balisage Rich et disparaissait sans un mot.
Assisted-by: Claude Opus 5
« ⏱ → d » named a reply that was not on the menu. The prompt reads
« Enter = delete, after saving them, k = keep » and mentions « d »
nowhere, so the line asking to be trusted with a decision described it in
a vocabulary the reader had never been given.
The decision itself was right — Enter deletes, and that is what happened.
Only its report was written from the inside. It now says Enter, in the
migration's language, with the value in brackets for whoever wants the
precision. What the caller receives is unchanged.
--- FR ---
[FIX] migration : le compte à rebours nomme la réponse que l'invite offrait
« ⏱ → d » nommait une réponse qui n'était pas au menu. L'invite annonce
« Entrée = effacer, après les avoir sauvegardés, k = garder » et ne
mentionne « d » nulle part : la ligne qui demandait qu'on lui confie une
décision la décrivait donc dans un vocabulaire jamais montré.
La décision, elle, était juste — Entrée efface, et c'est ce qui a eu lieu.
Seul son compte rendu était écrit du dedans. Il dit maintenant Entrée,
dans la langue de la migration, la valeur entre parenthèses pour qui veut
la précision. Ce que l'appelant reçoit ne change pas.
Assisted-by: Claude Opus 5
No timeout was hit and no test was skipped. The back office failed for the
same reason the site did: the COW copy of website.submenu breaks
/web/login exactly as it breaks the public pages — both go through the
same layout. The pass simply ran BEFORE the reset, and unlike the URLs it
was never looked at again. It is now, on the same second server.
« Session expired » described the consequence and hid the cause. The login
page returned 500 and nothing said so, so one looks at the password. The
status of that page, and a missing CSRF token, are now named.
Diagnosing this, I started Odoo 18 on a 17 database and got 500 on all
thirty-seven URLs and on /web/login: a report that says the site is
entirely broken when nothing is. database_cleanup already refused that;
the smoke tools now share the same guard rather than reimplementing it.
--- FR ---
[FIX] smoke : juger le back-office APRÈS la réparation, et dire pourquoi
Aucun délai n'a été atteint et aucun test n'a été sauté. Le back-office a
échoué pour la raison même qui cassait le site : la copie COW de
website.submenu casse /web/login comme elle casse les pages publiques —
les deux passent par le même gabarit. La passe tournait avant la
réinitialisation et, contrairement aux URL, n'était jamais revue.
« Session expired » décrivait la conséquence et cachait la cause : la page
de connexion rendait 500 sans que rien ne le dise, et l'on cherchait du
côté du mot de passe.
En diagnostiquant, j'ai lancé un Odoo 18 sur une base 17 : 500 partout, un
rapport qui déclare le site entièrement cassé quand rien ne l'est.
database_cleanup refusait déjà cela ; les outils de fumée partagent
désormais sa garde au lieu d'en écrire une seconde.
Assisted-by: Claude Opus 5
The state screen showed « no tool has run yet » after closing and
reopening. It was reading the progression file, and that file is archived
and reset when a migration restarts — so everything it knew vanished at
the exact moment one wants to understand why the restart was needed.
Each step now has its own log file, appended never overwritten, and the
failures and tool verdicts go to an append-only JSONL beside them. Both
outlive the progression, and the screen reads disk first, memory second,
without counting the overlap twice.
The command output itself is captured where every line already passes,
in the executor's read loop: the terminal still shows it live and nothing
about the run changes. What goes through the real terminal cannot be
captured — a pipe there makes full screens refuse, that lesson is paid —
so those keep at least their command and their exit code.
--- FR ---
[ADD] migration : garder les journaux sur disque, un fichier par étape
L'écran d'état affichait « aucun outil n'a encore tourné » après une
fermeture. Il lisait le fichier de progression, or celui-ci est archivé
puis remis à zéro quand on recommence : tout ce qu'il savait disparaissait
au moment précis où l'on cherche pourquoi il a fallu recommencer.
Chaque étape a désormais son fichier, en ajout et jamais en écrasement, et
les échecs comme les verdicts d'outils vont dans un JSONL à côté. Les deux
survivent à la progression, et l'écran lit le disque d'abord.
La sortie des commandes est captée là où chaque ligne passe déjà, dans la
boucle de lecture de l'exécuteur : le terminal la montre toujours en
direct. Ce qui passe par le vrai terminal n'est pas captable — un tube y
ferait renoncer les pleins écrans — et garde au moins son verdict.
Assisted-by: Claude Opus 5
After several hours of migration the archive is what one wanted anyway,
and the prompt asked for it with an empty default: pressing Enter — or
letting auto-run answer — walked past the only artifact of the whole run.
The three-way answer moved into a function of its own, because the third
way is the one that traps. « n » refuses, « y » or Enter takes the
timestamped name, and EVERYTHING ELSE is a filename. So « non.zip » is a
file, not a refusal: comparing the whole answer rather than its first
letter is what keeps it one.
--- FR ---
[FIX] migration : Entrée exporte la sauvegarde à la fin
Au bout de plusieurs heures de migration, l'archive est ce qu'on voulait
de toute façon, et l'invite la proposait avec un défaut vide : appuyer sur
Entrée — ou laisser l'auto-exécution répondre — passait à côté du seul
artefact de toute la course.
La réponse à trois sens est devenue une fonction à part, car c'est le
troisième qui piège. « n » refuse, « y » ou Entrée prend le nom horodaté,
et TOUT LE RESTE est un nom de fichier. « non.zip » est donc un fichier et
non un refus : comparer la réponse entière plutôt que sa première lettre
est ce qui le garantit.
Assisted-by: Claude Opus 5
The statistics screen answers « what was removed, and why ». The state
screen answers « where are we, and what broke ». Two neighbouring
questions asked at the same moment: separating them by a menu entry
rather than by two commands to remember is what makes them usable.
Same letter as the prompts. One that changes meaning from one screen to
the next is not learned, it is looked up — and nobody looks it up.
Adding it surfaced two ways that screen could not survive auto-run. The
interface question is the FIRST one asked after auto-run is switched on,
and it was a bare input(): an unattended migration stopped there before
it had begun. The statistics menu was one too. And the state screen
writes the progression before reading it — but the statistics screen runs
before the progression is even loaded, so that write failed on an
attribute that does not exist yet.
--- FR ---
[ADD] migration : atteindre l'état depuis les statistiques aussi
L'écran de statistiques répond « qu'a-t-on supprimé, et pourquoi ». Celui
de l'état répond « où en est-on, et qu'est-ce qui a cassé ». Deux
questions voisines, posées au même moment : les séparer par une entrée de
menu plutôt que par deux commandes à retenir est ce qui les rend
utilisables.
La même lettre que dans les invites. Une lettre qui change de sens d'un
écran à l'autre ne s'apprend pas, elle se cherche — et personne ne la
cherche.
L'ajout a révélé deux façons dont cet écran ne survivait pas au mode
auto : la question d'interface, PREMIÈRE posée après l'activation, était
un input() nu, et le menu des statistiques aussi. Et l'écran d'état écrit
la progression avant de la lire, alors que les statistiques s'ouvrent
avant même qu'elle ne soit chargée.
Assisted-by: Claude Opus 5
A migration crosses six bumps, runs hundreds of commands and lasts hours.
The journal said what had been LAUNCHED; it never said what came of it.
Three hours in, one reads two hundred command lines without knowing which
one failed, nor what the smoke test concluded.
« v » could not carry this: it already means « view the differences » in
three prompts, and a letter meaning two things is worse than a letter
meaning nothing. « t » was free, and it is the same everywhere — one
shared string carries both shortcuts, so no prompt can drift.
Looking is not answering: the same question comes back afterwards.
What was missing was the data. Failures and tool verdicts are now
recorded with the step they happened in, bounded so a progression file
cannot grow without end. A tool rerun after a repair keeps its LAST
verdict and the count of its runs — showing both without distinction
would read a repair as a lasting failure.
--- FR ---
[ADD] migration : « t » montre où en est la migration
Une migration traverse six paliers, lance des centaines de commandes et
dure des heures. Le journal disait ce qui avait été LANCÉ, jamais ce que
cela avait donné. Trois heures plus tard on relit deux cents lignes sans
savoir laquelle a échoué, ni ce que le test de fumée a conclu.
« v » ne pouvait pas porter cela : il veut déjà dire « voir les
différences » dans trois invites, et une lettre qui signifie deux choses
est pire qu'une lettre qui ne signifie rien. « t » était libre, et il est
le même partout — une seule chaîne porte les deux raccourcis.
Regarder n'est pas répondre : la même question revient ensuite.
Ce qui manquait, c'étaient les données. Les échecs et les verdicts
d'outils sont désormais retenus avec l'étape où ils se sont produits.
Assisted-by: Claude Opus 5
The back-office pass was already there, and it works. What did not work
was the way it declined: one discreet line at the end of a long report,
saying « the database was not neutralized ». On six databases of a real
migration the test user is present up to the 15 bump and GONE at 17 and
18 — so the pass stopped silently exactly where a migration does the most
damage, and said something that was not even true.
The migration knows what it neutralized, so it now asks for the back
office by name. A missing test user on a database it neutralized is a
finding, printed loudly and counted as a failure. A missing tool is too:
returning None made the whole pass vanish without a word.
And it says UP FRONT which passes will run, on that database, by name.
--- FR ---
[FIX] migration : un back-office sauté ne doit pas se lire comme un sain
La passe back-office était déjà là et elle fonctionne. Ce qui ne
fonctionnait pas, c'est sa façon de renoncer : une ligne discrète en fin
d'un long rapport, disant « la base n'a pas été neutralisée ». Sur les six
bases d'une vraie migration, l'utilisateur test est présent jusqu'au
palier 15 et ABSENT en 17 et 18 — la passe s'arrêtait donc sans bruit là
où une migration fait le plus de dégâts, en disant quelque chose de faux.
La migration sait ce qu'elle a neutralisé : elle réclame désormais le
back-office. Un utilisateur test manquant sur une base qu'elle a
neutralisée est une trouvaille, affichée fort et comptée comme un échec.
Un outil absent aussi : rendre None faisait disparaître la passe entière.
Et elle annonce AVANT de lancer ce qui sera parcouru.
Assisted-by: Claude Opus 5
Six « press to continue » prompts on the module-code migration were bare
input() calls. Auto-run never reached them, so it stopped there and said
nothing — the question had been asked, after all. They now go through the
timed reader, where Enter and the countdown mean the same thing.
They were English too, on a path the rest of which speaks the system
language.
The guard that forbids a bare input() only looked at a handful of
methods, and internal_module_upgrade was not among them — which is
exactly how these six survived the first sweep. It is now covered, and
the module menu's own prompts are documented as deliberately blocking:
they ask for a module name, a path, a version, and « » after five
seconds would be a wrong answer, not a convenience.
--- FR ---
[FIX] migration : l'étape de migration de code n'attend plus indéfiniment
Six invites « appuyez pour continuer » de la migration de code étaient des
input() nus. L'auto-exécution ne les atteignait pas : elle s'arrêtait là
sans rien dire — la question avait bien été posée. Elles passent
désormais par le lecteur temporisé, où Entrée et le compte à rebours font
la même chose.
Elles étaient aussi en anglais, sur un chemin dont tout le reste parle la
langue du système.
Le garde-fou qui interdit les input() nus ne regardait qu'une poignée de
méthodes, et internal_module_upgrade n'en faisait pas partie — c'est
ainsi que ces six-là avaient survécu. Il la couvre maintenant, et les
invites du menu de modules sont documentées comme bloquantes à dessein :
elles demandent un nom, un chemin, une version.
Assisted-by: Claude Opus 5
The failure that stops an upgrade is almost always the same one — a COW
copy left behind on the previous version — and the repair is known. So
Enter now repairs, and a repair that actually changed something replays
the command by itself.
A default that acts must know when to stop, and here it must twice over.
Repairing when there is nothing left to repair, then offering it again,
loops without end: measured, « no COW copy has drifted » over and over.
And a repair that does not help would replay the command forever. Three
attempts, then the prompt says plainly that this one needs a developer.
The turn counter is deliberately redundant with that logic: both guard
the same failure, but the counter holds even if the logic is broken one
day by accident. An endless loop in an unattended migration costs a
night.
Also: the smoke tool forced `ask=input` on its own prompt, which
short-circuited auto-run — the question waited for a keystroke nobody
was there to give.
--- FR ---
[FIX] migration : réparer, rejouer, et savoir s'arrêter
L'échec qui arrête une migration est presque toujours le même — une copie
COW restée sur la version d'avant — et la réparation est connue. Entrée
répare donc, et une réparation qui a vraiment changé quelque chose rejoue
la commande d'elle-même.
Un défaut qui agit doit savoir s'arrêter, et ici deux fois plutôt qu'une.
Réparer quand il n'y a plus rien à réparer, puis le reproposer, boucle
sans fin : mesuré, « Aucune copie COW n'a dérivé », encore et encore. Et
une réparation qui ne suffit pas rejouerait indéfiniment. Trois
tentatives, puis l'invite dit qu'il faut un développeur.
Le compteur de tours double volontairement cette logique : il tient même
si elle est cassée un jour par mégarde.
Assisted-by: Claude Opus 5
Seventeen minutes with no output looks exactly like an infinite loop. It
was not one: measured on the running process, zero lock waits and queries
changing every sample. It was working, silently, one module every thirty
seconds.
Both halves were mine. Purging line by line — added so one refusal could
not sink a category — calls button_immediate_uninstall() per line, and
that reloads the WHOLE registry: 5984 modules re-read each time. The
batch is now purged in one call, exactly as the OCA wizard intends, and
the per-line isolation only costs when a refusal actually happens.
And the tool captured its child's output, so nothing showed before the
end. It now relays each step as it arrives, with elapsed seconds, and a
timer kills the process group when the deadline passes.
--- FR ---
[FIX] database_cleanup : purger le lot, et dire ce qu'on fait
Dix-sept minutes sans une ligne ressemblent trait pour trait à une boucle
infinie. Ce n'en était pas une : mesuré sur le processus vivant, zéro
verrou en attente et des requêtes qui changeaient à chaque instantané. Il
travaillait, en silence, à raison d'un module toutes les trente secondes.
Les deux moitiés étaient de mon fait. Purger ligne par ligne — ajouté
pour qu'un refus n'emporte pas la catégorie — appelle
button_immediate_uninstall() par ligne, ce qui recharge TOUT le registre :
5984 modules relus à chaque fois. Le lot est désormais purgé en un seul
appel, comme le module OCA le prévoit, et l'isolement ne coûte que
lorsqu'un refus survient vraiment.
Et l'outil capturait la sortie de son enfant : rien avant la fin. Il
relaie maintenant chaque étape, temps écoulé compris.
Assisted-by: Claude Opus 5
The portal is a third rendering, neither the public site nor the back
office: QWeb frontend with counters that each query their own model. The
sitemap does not list /my — the page needs a session — and no RPC call
goes through it. A migration can break it with nothing else noticing.
Measured on a real database: /my answered 500 on a user field a module no
longer defines, while every public page and sixteen apps were fine.
Two guards the run proved necessary. Requested without a session, /my
redirects to the login form and answers 200: counting that as a success
would announce a healthy portal never seen. And the production error page
shows no traceback, so the reason comes from the server log — attributed
by PATH, because the portal is checked first and taking the last trace
blamed it for an app's failure. A wrong cause costs more than none.
--- FR ---
[ADD] migration : ouvrir /my avec l'utilisateur test, et accuser la bonne requête
Le portail est un troisième rendu, ni le site public ni le back-office :
du QWeb frontend, avec ses compteurs qui interrogent chacun leur modèle.
Le sitemap ne liste pas /my — la page demande une session — et aucun appel
RPC n'y passe. Une migration peut le casser sans que rien ne le dise.
Mesuré sur une vraie base : /my rendait 500 sur un champ utilisateur qu'un
module ne définit plus, alors que les pages publiques et seize
applications allaient bien.
Deux garde-fous que l'essai a rendus nécessaires. Sans session, /my
redirige vers le formulaire de connexion et rend 200 : le compter pour une
réussite annoncerait un portail jamais vu. Et la page d'erreur de
production ne montre aucune trace : la raison vient du journal, attribuée
par CHEMIN — le portail est interrogé en premier, et prendre la dernière
trace l'accusait de la panne d'une application.
Assisted-by: Claude Opus 5
The public smoke test opens what a visitor reaches. It says nothing about
the back office, which is where a migration does most of its damage: a
field dropped from a model but still named in a form, a module installed
in the database whose code no longer ships with the target version. None
of it stops the module loading — it stops the day someone opens the app.
Neutralizing installs a `test` / `test` login carrying the SYSTEM user's
groups, and it survives the module's uninstall. So the tool checks for
that user rather than trusting a flag, and it rides the server the public
pass already started: booting Odoo is what costs minutes, not requests.
Measured on a real 18.0 database of 25 apps, which found four defects of
mine: web_search_read changed signature in 17, a bare 404 hides an
unregistered model, embedded sub-views are not the parent's fields, and
an empty psql result meant two different things.
--- FR ---
[ADD] migration : ouvrir chaque application avec l'utilisateur test
Le test de fumée public ouvre ce qu'un visiteur atteint. Il ne dit rien du
back-office, où une migration fait pourtant l'essentiel de ses dégâts : un
champ retiré du modèle mais toujours nommé dans un formulaire, un module
installé en base dont le code n'accompagne plus la version cible. Rien de
cela n'arrête le chargement ; cela arrête le jour où l'on ouvre l'appli.
La neutralisation pose un compte `test` / `test` portant les groupes du
superutilisateur, et il survit à la désinstallation du module. L'outil
vérifie donc cet utilisateur plutôt qu'un drapeau, et réutilise le serveur
déjà démarré : c'est le démarrage qui coûte, pas les requêtes.
Mesuré sur une vraie base 18.0 de 25 applications, ce qui a révélé quatre
défauts de mon fait.
Assisted-by: Claude Opus 5
Auto-run promised to "take the default after five seconds", but every
default was EMPTY: it took nothing. Worse, half the prompts of a
migration are asked by separate processes — the theme uninstaller, the
stale-SCSS detector, the smoke test. They knew nothing of auto-run and
waited forever for a keystroke that never came.
The countdown now lives in one file and travels through the ENVIRONMENT,
the only channel a fork shares. Enter takes the default everywhere, not
only under auto-run: a prompt that prints (Y/n) and does otherwise is
worse than no prompt. Every text was rewritten to say what Enter does,
and every default kept an explicit way out.
Two defaults now write. Both are tenable only because the backup runs
first, and a test locks that ORDER rather than trusting a promise.
--- FR ---
[ADD] migration : faire d'Entrée la réponse qu'on donne toujours
L'auto-exécution promettait « le défaut après cinq secondes », mais tous
les défauts étaient VIDES : elle ne prenait rien. Pire, la moitié des
invites d'une migration sont posées par d'autres processus — le
désinstalleur de thème, le détecteur de SCSS figé, le test de fumée. Ils
ignoraient l'auto-exécution et attendaient sans fin une frappe.
Le compte à rebours tient désormais dans un seul fichier et voyage par
l'ENVIRONNEMENT, le seul canal qu'un fork partage. Entrée vaut le défaut
partout, pas seulement en auto : une invite qui affiche (Y/n) et fait
l'inverse est pire que pas d'invite. Chaque texte dit ce que fait Entrée,
et chaque défaut garde une issue explicite.
Deux défauts écrivent. Ils ne tiennent que parce que la sauvegarde passe
d'abord, et un test verrouille cet ORDRE plutôt qu'une promesse.
Assisted-by: Claude Opus 5
One refusal killed seven categories: modules died on « savepoint ...
does not exist », then columns, tables, data, menus, indexes and
properties all reported « current transaction is aborted ». Six
victims that never got to try.
The savepoints were mine and they could not work. The OCA module
commits on its own — purge_columns.py:57 calls cr.commit(), and
purge_modules.find() purges at line 91 before returning. A COMMIT
destroys every savepoint, so ours vanished under our feet and nothing
put the transaction back on its feet.
Each entry is committed as it succeeds, and any failure rolls back.
The dry run rolls back too: find() was writing for real.
--- FR ---
[FIX] database_cleanup : rattraper la transaction, pas le point de reprise
Un seul refus en tuait sept : modules mourait sur « savepoint ... does
not exist », puis colonnes, tables, données, menus, index et
propriétés signalaient tous « current transaction is aborted ». Six
victimes qui n'ont jamais eu leur tour.
Les points de reprise étaient les miens et ne pouvaient pas tenir. Le
module OCA valide de lui-même — purge_columns.py:57 appelle cr.commit(),
et purge_modules.find() purge dès la ligne 91. Or un COMMIT détruit
tout point de reprise : le nôtre disparaissait sous nos pieds, et rien
ne remettait la transaction d'aplomb.
Chaque entrée est validée dès qu'elle réussit, tout échec défait la
sienne. La simulation défait aussi : find() écrivait pour de bon.
Assisted-by: Claude Opus 5
Three defects, all mine, all found on a real run.
Creating a wizard could fail and leave the transaction ABORTED. The next
name read died on it, outside any guard, and the whole script stopped
with no report at all — only a traceback. Creating and reading the names
now happen inside the savepoint, and a report is printed whatever
happens: knowing what was done matters more than the trace of what
broke.
« No orphaned models found » is a UserError: the module signals the
EMPTY by raising. Counting it as a failure made a healthy database look
broken, four warnings out of five kinds.
The module was installed at step 3, after being used at step 2, so the
first run had no wizard at all and answered « nothing to do ». It is now
installed by the tool itself, and step 3 no longer asks to redo by hand
what has just been done automatically.
--- FR ---
[FIX] migration : le nettoyage pose son module, et survit à un refus
Trois défauts, tous à moi, tous trouvés sur une vraie exécution.
Créer un assistant pouvait échouer en laissant la transaction AVORTÉE.
La lecture de nom suivante mourait dessus, hors de tout garde, et le
script s'arrêtait sans aucun rapport — juste une trace. La création et
la lecture des noms sont désormais dans le point de reprise, et un
rapport est imprimé quoi qu'il arrive : savoir ce qui a été fait vaut
mieux que la trace de ce qui a cassé.
« No orphaned models found » est une UserError : le module signale le
VIDE en levant. Le compter comme un échec faisait passer une base saine
pour cassée, quatre avertissements sur cinq catégories.
Le module était installé à l'étape 3, après avoir servi à l'étape 2 : le
premier passage n'avait donc aucun assistant et répondait « rien à
faire ». L'outil le pose lui-même, et l'étape 3 ne demande plus de
refaire à la main ce qui vient d'être fait.
Assisted-by: Claude Opus 5
A migration asks dozens of questions whose answer is almost always the
one offered, and someone has to stand there pressing Enter for hours.
Asked before the version choice — so it covers that choice too, now
that it has a default — and off by default: it decides in your place.
Every prompt of the migration goes through one reader, seventeen of
them. A prompt left as a bare input() would know nothing of auto mode
and would block the run with nothing to say why; a test reads the
function and rejects any that appears.
click.prompt had to go: it cannot hand back control after a delay, so
auto would have stopped at the first question. select() rather than a
thread or an alarm — a thread would leave a blocked input() behind it,
stealing the next keystroke.
--- FR ---
[ADD] migration : une auto-exécution qui prend le défaut après cinq secondes
Une migration pose des dizaines de questions dont la réponse est presque
toujours celle proposée, et il faut rester devant à taper Entrée pendant
des heures. Posée avant le choix de version — donc elle vaut aussi pour
lui, maintenant qu'il a un défaut — et éteinte par défaut : elle décide
à votre place.
Toutes les invites de la migration passent par une seule lecture,
dix-sept d'un coup. Une invite laissée en input() nu ne saurait rien du
mode auto et bloquerait la migration sans rien dire ; un test lit la
fonction et refuse toute apparition.
click.prompt devait partir : il ne sait pas rendre la main après un
délai, l'auto se serait arrêté à la première question. select() plutôt
qu'un fil ou une alarme — un fil laisserait un input() bloqué derrière
lui, qui volerait la frappe suivante.
Assisted-by: Claude Opus 5
The eight purges are not independent: purging a model frees the columns
that referenced it, purging a table frees the data pointing at it. One
pass is never enough, so the requested order runs again until a full
pass repairs nothing new.
Refusals are expected — a foreign key still holds, a module says no.
Purging a list at once loses everything to the first one, so each entry
purges inside its own savepoint: a refusal rolls back that entry alone.
What one pass could not take, the next may, once its neighbours are
gone. Leftovers are reported as a warning: a database can carry some
that nothing removes, and stopping there would help no one.
It refuses a version mismatch. Measured while building it: a shell on
Odoo 14 opened against a 17.0 database went rewriting ir_model before
dying on a jsonb it did not know. An older Odoo does not merely fail on
a newer database — it writes on the way.
--- FR ---
[ADD] migration : lancer le nettoyage OCA avant de tester les pages
Les huit purges ne sont pas indépendantes : purger un modèle libère les
colonnes qui le référençaient, purger une table libère les données qui
la visaient. Une passe ne suffit jamais, l'ordre demandé est donc rejoué
jusqu'à ce qu'une passe entière ne répare plus rien.
Les refus sont attendus — une clé étrangère tient, un module dit non.
Purger d'un bloc perdrait tout au premier : chaque entrée passe dans son
propre point de reprise, un refus n'emporte que la sienne. Ce qu'une
passe n'a pu prendre, la suivante le peut, une fois les voisines
parties. Les restes sont un avertissement : une base peut en porter que
rien ne retire, et s'arrêter là n'aiderait personne.
Il refuse une version qui ne correspond pas. Mesuré en le construisant :
un shell en Odoo 14 ouvert sur une base 17.0 est parti réécrire ir_model
avant de mourir sur un jsonb inconnu de lui. Un Odoo plus ancien
n'échoue pas simplement sur une base plus récente — il écrit en chemin.
Assisted-by: Claude Opus 5
A QWebException carries no [view_id … parent_id …] block — it names the
template. The tool only read the inheritance context, so it answered
« no parent view named » on the one failure that hit everything.
Measured at bump 17: a frozen copy of website.submenu still called
submenu.clean_url(), renamed _clean_url() in that version. Every page
renders the menu, so 34 of 37 public URLs returned 500, and nothing
pointed at the view. Resetting that one copy brought all 37 back.
Only keys that actually have a COW copy are proposed: naming one
without would send a reset against a module view, which does nothing.
--- FR ---
[FIX] migration : nommer le gabarit quand l'échec vient du rendu
Une QWebException ne porte pas de bloc [view_id … parent_id …] : elle
nomme le gabarit. L'outil ne lisait que le contexte d'héritage, et
répondait donc « aucune vue parente nommée » sur la seule panne qui
touchait tout.
Mesuré au palier 17 : une copie figée de website.submenu appelait
encore submenu.clean_url(), renommée _clean_url() par la version. Toute
page affiche le menu, donc 34 URL publiques sur 37 rendaient 500, sans
que rien ne désigne la vue. Réinitialiser cette seule copie les a
toutes ramenées.
Seules les clés ayant vraiment une copie COW sont proposées : en nommer
une sans copie enverrait réinitialiser une vue module, donc ne rien
faire.
Assisted-by: Claude Opus 5
The text report puts a thousand lines between the two things that decide:
what the copy holds that the module view does not — all a reset gives up
— and which child no longer finds its anchor, which is why anything
breaks. Space switches between them, « c » copies the reset command.
Offered as [4] on the error prompt, next to check and reset, and run on
the real terminal: a full screen started through the capturing executor
falls back to the text report with nothing to tell the two apart.
The diff is rendered in one place, shared with the command line. Two
renderings would drift without anything saying so.
--- FR ---
[ADD] migration : parcourir les copies COW dérivées en plein écran
Le rapport texte met mille lignes entre les deux choses qui décident :
ce que la copie porte et que la vue module n'a pas — tout ce qu'une
réinitialisation abandonne — et quel enfant ne trouve plus son ancrage,
la raison pour laquelle quoi que ce soit casse. L'espace bascule, « c »
copie la commande de réparation.
Proposé en [4] à l'invite d'erreur, à côté de vérifier et réinitialiser,
et lancé sur le vrai terminal : un plein écran passé par l'exécuteur qui
capture retombe sur le rapport texte, sans rien qui les distingue.
Le diff est rendu à un seul endroit, partagé avec la ligne de commande.
Deux rendus dériveraient sans que rien ne le signale.
Assisted-by: Claude Opus 5
Without a starting point, a page that already answered 500 reads as
damage done by the migration, and the search goes the wrong way for
hours. Measured on the real one: two URLs were already failing before
anything had been migrated.
Asked in step 2, on the database before the bump — not on a bump
database that does not exist yet — and it says what it measures: a page
broken now will still be broken after, and that is not the migration.
--- FR ---
[ADD] migration : mesurer les URL publiques avant le premier palier aussi
Sans point de départ, une page qui rendait déjà 500 se lit comme un
dégât de la migration, et l'on cherche des heures du mauvais côté.
Mesuré sur la vraie : deux URL cassaient avant que quoi que ce soit
n'ait été migré.
Posée à l'étape 2, sur la base d'avant le palier — pas sur une base de
palier qui n'existe pas encore — et elle dit ce qu'elle mesure : une
page cassée maintenant le sera encore après, et ce ne sera pas la
migration.
Assisted-by: Claude Opus 5
Answering « all » reset one copy of two and reported success. Two
defects behind it, both mine.
A requested key matching no finding did nothing, silently: the tool
returned early on « nothing drifted » and never looked. Detection is
differential — it only sees a copy whose CHILD breaks — so a stale copy
without children escapes it. A key can now be reset outside detection,
an unknown one is named, and the exit code is 2.
And the culprit is not always the parent. On /contactus the parent was
identical to its module view; the CHILD held the stale arch. Both are
proposed now, parent first — it is the more common case.
Measured on the migration: 33 of 33 public URLs answer.
--- FR ---
[FIX] migration : réinitialiser la copie vraiment périmée, et signaler une clé sans objet
Répondre « toutes » réinitialisait une copie sur deux et annonçait un
succès. Deux défauts derrière, tous deux à moi.
Une clé demandée ne correspondant à aucun constat ne faisait rien, en
silence : l'outil sortait sur « rien n'a dérivé » sans jamais chercher.
La détection est différentielle — elle ne voit qu'une copie dont un
ENFANT casse — donc une copie périmée sans enfant lui échappe. Une clé
peut désormais être réinitialisée hors détection, une clé inconnue est
nommée, et le code de sortie vaut 2.
Et le coupable n'est pas toujours le parent. Sur /contactus, le parent
était identique à sa vue module ; c'est l'ENFANT qui portait l'arch
périmée. Les deux sont proposés, le parent d'abord — le cas le plus
fréquent.
Mesuré sur la migration : 33 URL publiques sur 33 répondent.
Assisted-by: Claude Opus 5
Deleting the leftovers failed on « the database search does not have the
ids (('4457',)) and has extra ids ((4457,)) ». psql returns text; the ids
went into browse() as strings, Odoo compared them against integers, found
nothing and refused the whole batch.
Nothing was lost: the backup runs before the deletion, and the tool said
plainly that nothing was removed. Measured after the fact — 15 files
saved, 15 attachments still in database.
--- FR ---
[FIX] addons : parcourir les restes par entier, pas par la chaîne de psql
L'effacement échouait sur « la recherche en base n'a pas les identifiants
(('4457',)) et a des identifiants supplémentaires ((4457,)) ». psql rend
du texte ; les identifiants partaient dans browse() en chaînes, Odoo les
comparait à des entiers, ne trouvait rien et refusait tout le lot.
Rien n'a été perdu : la sauvegarde précède l'effacement, et l'outil a dit
franchement que rien n'avait été retiré. Vérifié après coup — 15 fichiers
sauvegardés, 15 pièces jointes toujours en base.
Assisted-by: Claude Opus 5
The theme uninstaller ends by asking what to do with the leftovers, and
the migration ran it through the capturing executor. Its stdout was a
pipe, Python buffers by blocks, so the prompt stayed invisible while the
process waited. It reads as a freeze: you press Enter blind, the first
keystroke answers unseen and the extra ones fall into the next question.
Two locks, because one is not enough. The migration runs the script on
the real terminal. And the three tools that ask now require BOTH ends:
something to read the answer from, and something to show the question
on. Guarding on stdin alone was the bug — measured, stdin tty=True with
stdout tty=False, and the question was asked into a pipe.
--- FR ---
[FIX] migration : ne jamais poser une question que le terminal ne montre pas
Le désinstalleur de thème finit par demander quoi faire des restes, et
la migration le lançait par l'exécuteur qui capture. Sa sortie partait
dans un tube, Python bufferise par blocs, et l'invite restait invisible
pendant l'attente. Cela se lit comme un blocage : on tape Entrée à
l'aveugle, la première frappe répond sans être vue et les suivantes
tombent dans la question d'après.
Deux verrous, car un seul ne suffit pas. La migration lance le script
sur le vrai terminal. Et les trois outils qui questionnent exigent
désormais les DEUX bouts : de quoi lire la réponse, et de quoi montrer
la question. Ne garder que stdin était le défaut — mesuré, stdin
tty=True et stdout tty=False, la question partait dans un tube.
Assisted-by: Claude Opus 5
The permission test also demanded no group-write, measured on disk.
Git stores only the exec bit — 100644 or 100755 — and the rest comes
from the umask of whoever checks out. On a umask 0002 machine every
checkout yields 775, so the test failed thirteen times for a reason
that is not in the repository.
It now reads the index, the only mode the repo carries and hands to
others. A file made executable locally without being committed works
here and nowhere else — that is what this catches.
--- FR ---
[FIX] test : vérifier le bit que git stocke, pas le mode que l'umask fixe
Le test de permissions exigeait aussi l'absence d'écriture par le
groupe, mesurée sur le disque. Git ne stocke que le bit d'exécution —
100644 ou 100755 — et le reste vient de l'umask de celui qui fait le
checkout. Sur un poste en umask 0002, chaque checkout produit 775 : le
test échouait treize fois, pour une raison absente du dépôt.
Il lit désormais l'index, seul mode que le dépôt porte et transmet. Un
fichier rendu exécutable localement sans être commité marche ici et
nulle part ailleurs — c'est ce que ce test attrape.
Assisted-by: Claude Opus 5
click now receives the rank of the highest version, so it prints « [6] »
and returns « 6 » on Enter. The answer follows the normal path — the
special case for an empty line is gone, and with it a second behaviour
to keep in agreement with the first.
The rank is computed, never written down: 6 is where 18.0 sits today,
and one more version in the catalogue moves it. A test replays a
catalogue with 19.0 and expects [7].
--- FR ---
[UPD] migration : laisser click porter le défaut, calculé sur le menu
click reçoit désormais le rang de la version la plus haute : il affiche
« [6] » et rend « 6 » sur Entrée. La réponse suit le chemin normal — le
cas particulier de la ligne vide disparaît, et avec lui un second
comportement à tenir d'accord avec le premier.
Le rang est calculé, jamais écrit : 6 est la place de 18.0 aujourd'hui,
et une version de plus au catalogue la déplace. Un test rejoue un
catalogue avec 19.0 et attend [7].
Assisted-by: Claude Opus 5
(cherry picked from commit 5f0b0110d610187298e0129e45cef28e14bba092)
Migrating means going all the way, and that choice had to be typed
every time. Enter did nothing visible: click.prompt without a default
re-asks on an empty line without printing anything, so a default added
without `default=""` would never have been reached and nothing would
have said so.
The highest is computed, not read off the end of the list: display
order is not a guarantee, and « 9.0 » sorts after « 18.0 » as a string.
The prompt announces it — a default nobody sees is a default nobody
uses. No choice at all means no default rather than a crash.
--- FR ---
[ADD] migration : Entrée vise la version Odoo la plus élevée
Migrer, c'est aller au bout, et ce choix devait être tapé chaque fois.
Entrée ne faisait rien de visible : click.prompt sans défaut redemande
sur une ligne vide sans rien afficher, si bien qu'un défaut ajouté sans
`default=""` n'aurait jamais été atteint, sans que rien ne le signale.
La plus haute est calculée, pas lue au bout de la liste : l'ordre
d'affichage n'est pas une garantie, et « 9.0 » se trie après « 18.0 »
en chaînes. L'invite l'annonce — un défaut qu'on ne montre pas est un
défaut que personne n'utilise. Aucun choix possible ne donne aucun
défaut plutôt qu'une erreur.
Assisted-by: Claude Opus 5
(cherry picked from commit f0861363f496cdc3c0bb02216d30dd0aa8d3697b)
The smoke test stopped at « these URLs answer 500 ». Turning that into a
fix meant reading an id out of a traceback and translating it to a key
by hand, mid-migration — the copy where a character goes missing.
It now reads the error context Odoo logs — [view_id: N, parent_id: M],
the one line it does not translate — resolves the parent to its key,
offers the reset numbered with « all », and re-requests the failing URLs
afterwards. Applying without re-asking would be calling it fixed
without having seen it answer.
Two defects found while measuring, both mine. ./run.sh is a bash
wrapper: terminate() killed it and left odoo-bin holding the port, six
orphans in six runs, each later run silently querying the first one's
server. And the log was read before stopping, so only the 24 startup
lines existed — hence « no view in cause » on pages that named one.
--- FR ---
[ADD] migration : nommer les vues derrière une URL en échec, et corriger
Le test s'arrêtait à « ces URL répondent 500 ». En faire un correctif
demandait de relever un id dans une trace et de le traduire en clé à la
main, en pleine migration — la recopie où un caractère se perd.
Il lit désormais le contexte qu'Odoo journalise — [view_id: N,
parent_id: M], la seule ligne qu'il ne traduit pas —, résout le parent
en clé, propose la réinitialisation numérotée avec « toutes », et
redemande ensuite les URL en échec. Appliquer sans redemander, ce
serait déclarer réparé sans l'avoir vu répondre.
Deux défauts trouvés en mesurant, tous deux à moi. ./run.sh est une
enveloppe bash : terminate() la tuait et laissait odoo-bin tenir le
port, six orphelins en six essais, chaque essai suivant interrogeant
sans le savoir le serveur du premier. Et le journal était lu avant
l'arrêt, donc seules les 24 lignes de démarrage existaient — d'où
« aucune vue en cause » sur des pages qui en nommaient une.
Assisted-by: Claude Opus 5
(cherry picked from commit 30fbcd1aee20c4028ea6b24bd04eb518f0587ffe)
A migration can load every module, log nothing, and still serve 500s on
pages nobody thought to open. Measured on the real one: 2 of 33 public
URLs failed — a blog post and /contactus — after a bump the log called
successful.
The list is the sitemap, what Odoo publishes for search engines. It
cannot be read from odoo-bin shell: enumerate_pages() asks for
http.root.get_db_router(request.db) and raises « object unbound »
without a real request. So the server is started on its own port,
asked, and always stopped — a forgotten one holds the port and fails
the next bump.
Offered before the Selenium prompt, default no: it boots a server and
can take minutes.
--- FR ---
[ADD] migration : interroger chaque URL publique avant de conclure
Une migration peut charger tous ses modules, ne rien écrire au journal,
et servir quand même des 500 sur des pages que personne n'ouvre.
Mesuré : 2 URL publiques sur 33 échouaient — un billet de blogue et
/contactus — après un palier que le journal disait réussi.
La liste est le sitemap, celle qu'Odoo publie pour les moteurs. Elle ne
se lit pas depuis odoo-bin shell : enumerate_pages() réclame
http.root.get_db_router(request.db) et lève « object unbound » sans
requête réelle. Le serveur est donc démarré sur son propre port,
interrogé, et toujours arrêté — un serveur oublié tient le port et fait
échouer le palier suivant.
Proposé avant l'invite Selenium, par défaut non : cela démarre un
serveur et peut durer.
Assisted-by: Claude Opus 5
(cherry picked from commit 277e85b3d06173beeb92be792467751b31ac0696)
« Command returned error code: 1 » followed a theme that was removed
correctly. 1 is this toolkit's « there are findings », but the report
was the uninstaller's last command, so its code became the script's;
and the COW check was still read through the capturing executor, which
announces any non-zero code as an error.
The leftovers can now be dealt with instead of only listed: keep by
default, or delete after their content is written to private/. Listing
fifteen attachments and stopping there meant composing an unlink() by
hand, mid-migration, from identifiers read off a screen.
--- FR ---
[FIX] addons : cesser d'appeler « erreur » un rapport de restes
« Command returned error code: 1 » suivait un thème correctement
retiré. 1 veut dire « il y a des constats » dans cet outillage, mais le
rapport était la dernière commande du désinstalleur, donc son code
devenait celui du script ; et la vérification COW passait encore par
l'exécuteur qui capture, lequel annonce tout code non nul comme une
erreur.
Les restes peuvent désormais être traités, pas seulement listés :
garder par défaut, ou effacer après écriture de leur contenu sous
private/. Lister quinze pièces jointes et s'arrêter là revenait à faire
composer un unlink() à la main, en pleine migration.
Assisted-by: Claude Opus 5
(cherry picked from commit 304ce32b2680e3d01e38c3224bb85c2798cd6f53)
The error prompt printed « --reset <key> --apply » and left the key to
be found in a thousand-line diff. Copying it by hand is where a
character goes missing, and a key matching no copy is not an error for
the tool: the command runs and does nothing, silently.
[3] now asks the tool for the keys, numbers them, and offers « all ».
An out-of-range or unreadable answer resets nothing — falling back to
« all » would act on what was never asked for.
--- FR ---
[ADD] migration : choisir la copie COW à réinitialiser dans une liste
L'invite d'erreur imprimait « --reset <key> --apply » et laissait
retrouver la clé dans un diff de mille lignes. La recopier à la main
est l'endroit où un caractère se perd, et une clé ne correspondant à
aucune copie n'est pas une erreur pour l'outil : la commande tourne et
ne fait rien, en silence.
[3] demande désormais les clés à l'outil, les numérote et offre
« toutes ». Une réponse hors liste ou illisible ne réinitialise rien —
retomber sur « toutes » agirait sur ce qui n'a pas été demandé.
Assisted-by: Claude Opus 5
(cherry picked from commit ae08e13fe5bba2b02b8661c67c4024fcd79f29bc)
The fix was offered while the checkout was still on the previous
version. Answering « a » ran reset_asset in an Odoo 12 shell, which has
no web_editor.assets: KeyError, nothing changed, and the migration went
on to break at the next bump — measured on a real run.
Predicting early is right; fixing early is not. The early call is now
--report-only, and a second call comes after the bump, on the upgraded
database, where the checkout can do it. The tool also refuses on its
own: it reads the checkout sources for reset_asset rather than trusting
a version number, and says when to come back.
--- FR ---
[FIX] migration : réinitialiser le SCSS périmé après le palier, pas avant
La correction était proposée alors que le checkout était encore sur la
version précédente. Répondre « a » lançait reset_asset dans un shell
Odoo 12, sans web_editor.assets : KeyError, rien de modifié, et la
migration continuait jusqu'à casser au palier suivant. Mesuré.
Prédire tôt est juste ; corriger tôt ne l'est pas. L'appel précoce est
désormais --report-only, et un second vient après le palier, sur la
base montée de version, là où le checkout sait le faire. L'outil refuse
aussi de lui-même : il cherche reset_asset dans les sources du checkout
plutôt que de se fier à un numéro, et dit quand revenir.
Assisted-by: Claude Opus 5
(cherry picked from commit 13d4d0a33c63efcbafb5fb29313a5377ba5f508e)
The report named the attachment and printed a command to paste. Deciding
« reset it » still meant accepting to lose one did not know what: the
diff against the module file is the only thing resetting gives up.
The tool now shows it and asks. --diff prints it, --tui browses it,
--apply resets without asking; with no flag and a terminal it asks, and
looking does not answer — the prompt comes back after each read.
--apply writes the copies under private/ first: reset_asset deletes the
attachment, so without that the customized lines would be nowhere.
The migration runs it on the real terminal, or none of this would be
reachable from there — the same pipe that was closing the TUI.
--- FR ---
[ADD] migration : lire le SCSS périmé, puis le corriger, sans sortir
Le rapport nommait la pièce jointe et imprimait une commande à coller.
Répondre « réinitialise » revenait encore à accepter de perdre on ne
sait quoi : l'écart avec le fichier du module est la seule chose que la
réinitialisation abandonne.
L'outil le montre et pose la question. --diff l'imprime, --tui le
parcourt, --apply réinitialise sans demander ; sans drapeau et devant
un terminal il demande, et regarder ne répond pas — l'invite revient
après chaque lecture. --apply écrit d'abord les copies sous private/ :
reset_asset supprime la pièce jointe, sans quoi les lignes
personnalisées ne seraient plus nulle part.
La migration le lance sur le vrai terminal, sinon rien de tout cela n'y
serait atteignable — le tube même qui fermait la TUI.
Assisted-by: Claude Opus 5
(cherry picked from commit 9e6c88622a74f7be408a8b1c523838eeadda1da3)
Customized SCSS lives in ir_attachment, frozen the day it is written,
still using the variables of that version. A bump can rename them:
website declared $o-theme-font-number in 12.0 and replaced the whole
mechanism in 13.0, so a 2020 customization stopped the frontend
bundle. Same shape as a stale COW view.
Reading the stored SCSS against the target sources answers before the
bump and names the attachment. Booting Odoo and opening a page answers
after, with « Style error » and no name — on a page a broken frontend
bundle is exactly what keeps you from reaching.
Measured: on the pre-bump database, targeting 13.0, it predicts the
failure; against its own 12.0 sources it reports nothing. That noise
floor is what makes it usable — the first version cried wolf on six
mixin parameters and named @include arguments.
--- FR ---
[ADD] migration : prédire quel SCSS personnalisé le palier va casser
Un SCSS personnalisé vit dans ir_attachment, figé le jour où il est
écrit, employant encore les variables de cette version-là. Un palier
peut les renommer : website déclarait $o-theme-font-number en 12.0 et a
remplacé le mécanisme en 13.0, arrêtant le bundle sur une
personnalisation de 2020. Même forme qu'une vue COW périmée.
Lire le SCSS stocké contre les sources cibles répond AVANT le palier et
nomme la pièce jointe. Démarrer Odoo et ouvrir une page répond après,
par « Style error » sans nom — et un bundle cassé est justement ce qui
empêche d'atteindre la page.
Mesuré : sur la base d'avant le palier, cible 13.0, il prédit la
panne ; contre ses propres sources 12.0 il ne signale rien. Ce bruit de
fond nul est ce qui le rend utilisable — la première version criait à
tort sur six paramètres de mixin et arguments nommés.
Assisted-by: Claude Opus 5
(cherry picked from commit c6611ee1431cfee94e321536d20052b8cca3ec10)
A theme carries view copies and SCSS through every version bump, and a
bump can rename what they rely on. Removing it first drops a whole
family of failures, and it can be put back afterwards.
Asked in step 1, before OpenUpgrade runs, and only when a theme is
actually installed. Default is no: removing a theme changes how a site
looks, and a migration does not decide that for its owner.
theme_default is not offered — it IS the absence of a theme.
--- FR ---
[ADD] migration : proposer de retirer les thèmes avant le premier palier
Un thème traîne des copies de vues et des SCSS à travers chaque palier
de version, et un palier peut renommer ce dont ils dépendent. Le
retirer d'abord enlève une famille entière de pannes, et se refait
ensuite.
Posée à l'étape 1, avant OpenUpgrade, et seulement s'il y a vraiment un
thème installé. Par défaut non : retirer un thème change l'apparence
d'un site, et ce n'est pas à une migration de trancher cela à la place
de son propriétaire. theme_default n'est pas proposé — il EST
l'absence de thème.
Assisted-by: Claude Opus 5
(cherry picked from commit dcbee87a6b920408c315f7354a096b0ecfabcf06)
There was no counterpart to install_addons_theme.sh, so themes were
removed with a plain --uninstall. That takes out the module, not the
theme: it skips _theme_remove(), whose first act is
_reset_default_config() — the call that writes font-number and its
three neighbours into user_values.scss.
Measured on a real 12 -> 13 migration: web.assets_frontend stopped on
« Undefined variable: $o-theme-font-number ». Odoo 12 defined it in
option_font_body_*, dropped in 13.0; only the theme still redefined
it, so removing the theme exposed a frozen 2020 customization.
theme_leftover.py then reports what unloading does not take — 15
attachments on the measured database. It deletes nothing: their
content may be the only trace of a customization.
--- FR ---
[ADD] addons : désinstaller un thème comme Odoo le retire
install_addons_theme.sh n'avait pas de symétrique : on retirait donc
les thèmes par un --uninstall nu. Cela enlève le module, pas le thème
— cela saute _theme_remove(), dont le premier geste est
_reset_default_config(), l'appel qui écrit font-number et ses trois
voisines dans user_values.scss.
Mesuré sur une vraie migration 12 → 13 : web.assets_frontend s'arrête
sur « Undefined variable: $o-theme-font-number ». Odoo 12 la
définissait dans option_font_body_*, supprimés en 13.0 ; seul le thème
la redéfinissait, et le retirer a mis à nu un SCSS figé en 2020.
theme_leftover.py signale ensuite ce que le déchargement ne prend pas
— 15 pièces jointes sur la base mesurée. Il ne supprime rien : leur
contenu peut être la seule trace d'une personnalisation.
Assisted-by: Claude Opus 5
(cherry picked from commit 16a7b1e1333752e2ef603d66f47374a22590d665)
The eleven migration commits sit at the end of the branch, apart from the
deployment work, so their changelog entries follow them rather than
announcing features the earlier commits do not carry.
Four entries: going back to a step and acting on the copy-on-write copies
at announcement time, the website copy analysis, the tools now speaking
the system language, and their executable bit.
Written in CHANGELOG.base.md, the only source; the two generated files
come from it.
--- FR ---
Les onze commits de migration sont en fin de branche, à l'écart du
travail de déploiement : leurs entrées de changelog les suivent donc,
plutôt que d'annoncer des fonctionnalités que les commits précédents ne
portent pas.
Quatre entrées : le retour à une étape et l'action sur les copies
copy-on-write dès leur annonce, l'analyse des copies de site, les outils
qui parlent désormais la langue du système, et leur bit d'exécution.
Écrit dans CHANGELOG.base.md, seule source ; les deux fichiers générés en
découlent.
Assisted-by: Claude Opus 5
Nine of the thirteen carried a shebang without the bit, so only four
could be run by their own path. Set to 755, not chmod +x: two were
664 under the 0002 umask and would have become 775 — executed by
others while a group member could still rewrite them. That pairing is
the only real risk here; the bit alone grants nothing, since reading
the file is enough to run python3 on it.
Being runnable opens a path without the venv: the shebang resolves to
the system python3, which has no Textual. --tui fell back to the text
report saying nothing. It now names the interpreter and the venv.
--- FR ---
[FIX] script : rendre exécutables les outils d'analyse et de migration
Neuf des treize portaient un shebang sans le bit ; quatre seulement
se lançaient par leur chemin. Mis à 755, pas chmod +x : deux étaient
en 664 sous l'umask 0002 et seraient passés à 775 — exécutés par
d'autres alors qu'un membre du groupe pouvait encore les réécrire.
C'est la seule vraie prise ici ; le bit seul n'accorde rien, lire le
fichier suffit déjà à lancer python3 dessus.
Devenir lançable ouvre un chemin sans le venv : le shebang résout le
python du système, sans Textual. --tui retombait sur le rapport texte
sans rien dire. Il nomme désormais l'interpréteur et le venv.
Assisted-by: Claude Opus 5
They run as subprocesses and had no i18n, so a French migration alternated
languages from one line to the next. The database upgrade itself had the
same gap.
The driver read English sentences out of their output to decide whether to
ask its question. Translating them would have made it mute -- no error, no
trace. The link is now the exit code, which no language touches: 0
nothing, 1 copies concerned, 2 the tool failed.
87 strings, five tools. A test rejects any displayed sentence that skips
t(), and proves itself on an untranslated one.
--- FR ---
Ils tournent en sous-processus et n'avaient aucun i18n : une migration en
français alternait les deux langues d'une ligne à l'autre. La mise à
niveau de la base elle-même souffrait du même manque.
Le pilote lisait des phrases anglaises dans leur sortie pour décider de
poser sa question. Les traduire l'aurait rendu muet — sans erreur, sans
trace. Le lien est désormais le code de sortie, qu'aucune langue ne
touche : 0 rien, 1 copies concernées, 2 l'outil a échoué.
87 chaînes, cinq outils. Un test refuse toute phrase affichée qui saute
t(), et fait sa preuve sur une chaîne non traduite.
Assisted-by: Claude Opus 5
Step 2 announced the copies the next bump will break, invited to
arbitrate, then moved on: the question came at the bump, tens of minutes
later. Yet looking writes nothing, and neutralizing here covers every bump
-- each bump database is a clone of this one.
The announcement is now a prompt: view what a copy holds, why it breaks,
full screen, or neutralize right away. Both prompts build their command in
one place, so they cannot drift apart.
Full screen means a real terminal: the viewer was started without one and
drew nothing, the pager exiting at once on a pipe.
--- FR ---
L'étape 2 annonçait les copies que le palier suivant casserait, invitait à
arbitrer, puis passait : la question venait au palier, des dizaines de
minutes plus tard. Or regarder n'écrit rien, et neutraliser ici vaut pour
tous les paliers — chaque base de palier est un clone de celle-ci.
L'annonce est désormais une invite : voir ce que porte une copie, pourquoi
elle casse, en plein écran, ou neutraliser tout de suite. Les deux invites
composent leur commande au même endroit, elles ne peuvent donc pas
diverger.
Le plein écran suppose un vrai terminal : la vue était lancée sans, et ne
dessinait rien, le pagineur sortant aussitôt sur un tube.
Assisted-by: Claude Opus 5
The screen could already replay from any step -- Enter on a row does it --
but that lived in a hint line under four named buttons. A capability you
have to guess is not offered, and it was reported as missing. It now has a
key, a button and a message, like the four others.
The b key added earlier went to the line-by-line prompts during the run,
not to this screen. Same letter on both, so going back is one key wherever
you are.
Two defects behind it. Replaying the chosen step actually SKIPPED it,
resuming at the next one. And a replayed step did not rewind the variables
it owns, so the second run started from the first one's leftovers.
Checked in a simulated terminal: b focuses the table, two arrows and Enter
return step 2, and the button focuses without choosing.
--- FR ---
L'écran savait déjà rejouer depuis n'importe quelle étape — Entrée sur une
rangée le fait — mais cela vivait dans une ligne d'indication sous quatre
boutons nommés. Une capacité qu'il faut deviner n'est pas offerte, et elle
a été signalée manquante. Elle a maintenant une touche, un bouton et un
message, comme les quatre autres.
La touche b ajoutée plus tôt s'adressait aux invites ligne à ligne pendant
l'exécution, pas à cet écran. Même lettre sur les deux : revenir en
arrière est une seule touche, où qu'on soit.
Deux défauts derrière cela. Rejouer l'étape choisie la SAUTAIT en fait,
reprenant à la suivante. Et une étape rejouée ne remettait pas à zéro les
variables qui lui appartiennent, si bien que la seconde exécution partait
des restes de la première.
Vérifié en terminal simulé : b donne le focus au tableau, deux flèches et
Entrée ramènent l'étape 2, et le bouton met le focus sans choisir.
Assisted-by: Claude Opus 5
Realising at a prompt that an earlier step deserved another answer had one
way out: Ctrl+C. That leaves the progression as it stands and makes you find
the resume screen again to rewind. « b » does it properly — it shows the
steps, rewinds the state, writes it, and says what to relaunch.
Cancelling that must not stop the migration, which is the trap: it returns to
the same prompt, exactly where you were. Removing that guard makes two tests
fail.
The COW warning printed « -d DB -t odooXX.0 » for commands meant to be pasted.
It knows both values, so it prints them, and offers --shape as well since that
is half the answer.
Checked on the four outcomes: a normal answer passes through, « b » then a
step rewinds and stops, cancelling and an unknown step both continue. 15 tests.
--- FR ---
S'apercevoir à une invite qu'une étape antérieure méritait un autre choix
n'avait qu'une issue : Ctrl+C. Cela laisse la progression telle quelle et
oblige à retrouver l'écran de reprise pour rembobiner. « b » le fait
proprement — il montre les étapes, rembobine l'état, l'écrit, et dit quoi
relancer.
Y renoncer ne doit pas arrêter la migration, et c'est le piège : on revient à
la même invite, exactement là où l'on était. Retirer ce garde-fou fait tomber
deux tests.
L'avertissement COW affichait « -d DB -t odooXX.0 » pour des commandes faites
pour être collées. Il connaît les deux valeurs, donc il les écrit, et propose
aussi --shape puisque c'est la moitié de la réponse.
Vérifié sur les quatre issues : une réponse normale passe, « b » puis une
étape rembobine et arrête, annuler et un choix inconnu continuent. 15 tests.
Assisted-by: Claude Opus 5
An early check warns, hours before the bump, that a copy will break it. It
then says « arbitrate BEFORE launching the migration » and hands over a raw
UPDATE — and no question follows. Read on a resumed run it looks like the
question already went by and was skipped, which is exactly how it was read.
It now says the migration asks at the bump itself, and shows what each copy
holds before the answer. The manual UPDATE stays, but after the two commands
that do it reversibly: telling someone to hand-write SQL when --restore exists
is offering the sharper tool first.
--- FR ---
Un contrôle précoce prévient, des heures avant le palier, qu'une copie va le
casser. Il dit ensuite « arbitrez AVANT de lancer la migration » et livre un
UPDATE brut — et aucune question ne suit. Lu au cours d'une reprise, on croit
que la question est passée et a été sautée, ce qui est exactement la lecture
qui en a été faite.
Il dit maintenant que la migration pose la question au palier lui-même, en
montrant ce que chaque copie contient avant qu'on réponde. L'UPDATE manuel
reste, mais après les deux commandes qui le font de façon réversible : dire à
quelqu'un d'écrire du SQL à la main quand --restore existe, c'est tendre
l'outil le plus coupant en premier.
Assisted-by: Claude Opus 5
The declarations view showed a 12.0 template becoming a 13.0 extension and
stopped there. Read alone it says « Odoo changed its code », and the obvious
reaction is to ask why that is anyone's problem — which is exactly what it
prompted.
It is not the problem. On a database without a copy the module upgrade
rewrites the view and nothing breaks. It breaks because a COPY exists and
froze the old shape. That sentence was missing, and so was the other half of
the answer: what the copy actually holds. A copy identical to the view it
shadows costs nothing to neutralize; one carrying five lines of theme hooks
costs those five lines. Both are now stated where the question arises.
Checked on the database mid-migration: the copy that raised the question
reports +5/-3, and the two other cases — identical to its twin, and a page
with no twin at all — each say so.
--- FR ---
La vue des déclarations montrait un gabarit 12.0 devenant une extension 13.0
et s'arrêtait là. Lue seule, elle dit « Odoo a changé son code », et la
réaction naturelle est de demander en quoi cela nous regarde — ce qu'elle a
justement provoqué.
Ce n'est pas le problème. Sur une base sans copie, la mise à jour du module
réécrit la vue et rien ne casse. Ça casse parce qu'une COPIE existe et a figé
l'ancienne forme. Cette phrase manquait, et l'autre moitié de la réponse
aussi : ce que la copie contient réellement. Une copie identique à la vue
qu'elle masque ne coûte rien à neutraliser ; une qui porte cinq lignes
d'ancres de thème coûte ces cinq lignes. Les deux sont dites là où la question
se pose.
Vérifié sur la base en cours de migration : la copie qui a soulevé la question
rapporte +5/-3, et les deux autres cas — identique à sa jumelle, et page sans
jumelle — le disent chacun.
Assisted-by: Claude Opus 5
A database coming from an old version is updated before the neutralization —
the tool offers it at the very start. That work IS step 2, done earlier, but
it was only recorded as state_1_update_all while the screen reads state_2_*.
So the step stayed « not started » right after running.
The costly half was invisible. Step 2 skipped the work through a local
variable, which is False again on a resume: with only the old flag written,
resuming a migration re-ran update_addons_all on an already-updated database.
Hours, for nothing. The check now reads the written trace, not the session.
The screen says when it happened rather than just « done », since the moment
is exactly what raised the doubt. Logs written before this fix read correctly
without being touched — the early flag alone is recognised.
Checked on the real log from the VM: step 2 goes from « not started » to
« done early, before the neutralization », the four other steps unchanged.
10 tests; removing the fix makes the resume one fail.
--- FR ---
Une base venant d'une vieille version se met à jour avant la neutralisation —
l'outil le propose au tout début. Ce travail EST l'étape 2, faite plus tôt,
mais il n'était enregistré que sous state_1_update_all quand l'écran lit
state_2_*. L'étape restait donc « non démarrée » juste après avoir tourné.
La moitié coûteuse était invisible. L'étape 2 sautait le travail grâce à une
variable locale, remise à False à la reprise : avec seulement l'ancien drapeau
écrit, reprendre une migration relançait update_addons_all sur une base déjà à
jour. Des heures, pour rien. Le contrôle lit maintenant la trace écrite, pas
la session.
L'écran dit quand cela a eu lieu plutôt que « terminée », le moment étant
justement la source du doute. Les journaux écrits avant ce correctif se lisent
correctement sans être modifiés — le drapeau précoce seul est reconnu.
Vérifié sur le vrai journal de la VM : l'étape 2 passe de « non démarrée » à
« faite plus tôt, avant la neutralisation », les quatre autres inchangées.
10 tests ; retirer le correctif fait tomber celui de la reprise.
Assisted-by: Claude Opus 5
The progression log lives at one path and the next migration writes over it.
Restarting therefore erased everything known about the run before — which
steps passed, which modules were missing, how long each took — and that is
exactly what someone looks for after having had to restart.
Both answers that discard the progression now copy it aside first, named after
the origin database and the moment of the copy, so two attempts on the same
database do not cover each other and a file moved out of its folder still says
what it is. Partial replays keep the log, so they archive nothing.
It lands under private/, not beside the original: reinstalling wipes
.venv.erplibre/ and would take the history with it.
Two copies in the same second overwrote each other in silence — undoing the
very loss this prevents. The second one is numbered now, and the test that
had skipped that case asserts it.
Checked on the real 51 KB log from the VM: 18 states copied unchanged, the
name carries the database and the timestamp, and a log with no state at all is
not archived. 12 tests.
--- FR ---
Le journal de progression vit à un seul endroit et la migration suivante écrit
par-dessus. Recommencer effaçait donc tout ce qu'on savait de la tentative
précédente — quels paliers étaient passés, quels modules manquaient, combien
de temps chacun avait pris — soit exactement ce qu'on cherche après avoir dû
recommencer.
Les deux réponses qui jettent la progression la copient désormais d'abord,
sous un nom portant la base d'origine et l'instant de la copie, pour que deux
tentatives sur la même base ne se recouvrent pas et qu'un fichier sorti de son
dossier se décrive encore. Une reprise partielle garde le journal, donc
n'archive rien.
La copie va sous private/, pas à côté de l'originale : une réinstallation
efface .venv.erplibre/ et emporterait l'historique avec elle.
Deux copies dans la même seconde s'écrasaient en silence — annulant la perte
même qu'on évite. La seconde est numérotée, et le test qui sautait ce cas
l'affirme.
Vérifié sur le vrai journal de 51 Ko de la VM : 18 états copiés à l'identique,
le nom porte la base et l'horodatage, et un journal sans aucun état n'est pas
archivé. 12 tests.
Assisted-by: Claude Opus 5
The prompt asked whether to neutralize copies without showing what they hold.
Answering meant giving up a customization sight unseen — often three lines, an
id and a container width, sometimes a whole page, and nothing told them apart.
« v » now shows both halves of the question. What the copy changed, diffed
against the module view it shadows: on the database at hand, 5 lines added and
3 removed, two CSS anchors and a container width. And why it breaks, by
showing the declaration in each version — portal.frontend_layout is a
standalone template in 12.0 and inheritance specs in 13.0, which is the whole
explanation. « w » is the same two, full screen, space to switch.
The current version comes from ir_module_module, not .odoo-version: the
checkout is switched to the target before this runs, so reading the file
compared the target with itself and printed the same declaration twice. That
is what it did until it was run against a real migration.
--list says which copies a past neutralization put aside. A renamed key is
invisible in the interface, so without it the only trace was remembering.
Checked on the VM mid-migration: both views on view 2670, the screen builds
headless and toggles, --list reports and reports nothing when there is
nothing. A missing database now exits 2 with a message instead of a traceback.
--- FR ---
L'invite demandait de neutraliser des copies sans montrer ce qu'elles
contiennent. Répondre revenait à renoncer à une personnalisation sans l'avoir
vue — souvent trois lignes, un id et une largeur de conteneur, parfois une
page entière, et rien ne les distinguait.
« v » montre désormais les deux moitiés de la question. Ce que la copie a
changé, comparé à la vue de module qu'elle masque : sur la base en cours, 5
lignes ajoutées et 3 retirées, deux ancres CSS et une largeur. Et pourquoi ça
casse, en affichant la déclaration dans chaque version —
portal.frontend_layout est un gabarit autonome en 12.0 et des consignes
d'héritage en 13.0, ce qui est toute l'explication. « w » donne les deux en
plein écran, espace pour basculer.
La version courante vient d'ir_module_module, pas de .odoo-version : le
checkout est basculé sur la cible avant cette étape, donc lire le fichier
comparait la cible avec elle-même et affichait deux fois la même déclaration.
C'est ce qu'il faisait jusqu'à l'essai sur une vraie migration.
--list dit quelles copies une neutralisation passée a mises de côté. Une clé
renommée est invisible dans l'interface ; sans cela, la seule trace était de
s'en souvenir.
Vérifié sur la VM en cours de migration : les deux vues sur la vue 2670,
l'écran se construit sans terminal et bascule, --list rapporte et ne rapporte
rien quand il n'y a rien. Une base absente sort en 2 avec un message plutôt
qu'une trace d'appel.
Assisted-by: Claude Opus 5
**Ubuntu 20.04 et 22.04 ne sont plus supportées**, sur toutes les architectures.
```
[UPD] release: deploy and run a fleet of VMs
The QEMU deployment form stops treating the fleet as one machine: vCPU,
RAM, disk, type, ERPLibre branch, Odoo version and timezone are set per
VM, a lock shields one from the global profile, an entry can be renamed
or duplicated. The install dashboard follows through -- update by parts,
restart Odoo or delete a machine without leaving it. A graphical VM picks
its desktop and its application store, and the SSH command to reach it is
composed from ~/.ssh/config.
Installation reaches four new grounds. openSUSE Leap and Tumbleweed,
AlmaLinux, Rocky and Fedora 43 join the catalogue, and the s390x build
chain works end to end on all of them: no wheel is published for that
architecture, so everything compiles against distribution headers. mise
lays down a precompiled CPython where pyenv built one, uv places the
Python packages, and both fall back to the old path on failure.
Ubuntu 20.04 and 22.04 are dropped -- pikepdf needs qpdf 12.2, built in
C++20, while focal ships GCC 9. That is the only breaking change here.
--- FR ---
Le formulaire de déploiement QEMU cesse de traiter le parc comme une
seule machine : vCPU, RAM, disque, type, branche ERPLibre, version d'Odoo
et fuseau horaire se règlent par VM, un verrou en soustrait une au profil
global, une entrée se renomme ou se duplique. Le tableau de bord suit —
mettre à jour par parties, redémarrer Odoo ou supprimer une machine sans
le quitter. Une VM graphique choisit son bureau et son magasin
d'applications, et la commande SSH pour la joindre est composée depuis
~/.ssh/config.
L'installation gagne quatre terrains. openSUSE Leap et Tumbleweed,
AlmaLinux, Rocky et Fedora 43 rejoignent le catalogue, et la chaîne de
compilation s390x y fonctionne de bout en bout : aucune roue n'est
publiée pour cette architecture, donc tout se compile contre les en-têtes
de la distribution. mise pose un CPython précompilé là où pyenv en
compilait un, uv pose les paquets Python, et les deux retombent sur
l'ancien chemin en cas d'échec.
Ubuntu 20.04 et 22.04 partent — pikepdf exige qpdf 12.2, bâti en C++20,
quand focal livre GCC 9. C'est le seul changement cassant du lot.
Assisted-by: Claude Opus 5
```
**Per-VM deployment.** vCPU, RAM, disk, VM type, ERPLibre branch, Odoo version
and timezone are each set on the VM, all the way down to the remote command
built per machine. A lock shields a VM from the global x1..x4 profile and shows
on the whole row; an entry can be renamed or deployed in several copies.
Presets are finer where development VMs actually live: every gigabyte and every
vCPU up to 16.
**Graphical VMs.** A server / desktop choice offering GNOME or Cinnamon, the
application store picked per VM (.deb only, Flatpak tooling, or snap), and a
composed SSH command to reach the remote desktop — read from `~/.ssh/config`
so a nested VM is reachable through its ProxyJump, with the hypervisor console
as a third route.
**Install dashboard.** Acts on a VM without leaving it: update by parts —
system packages, then git repositories, then Python dependencies, never chained
so one failure cannot take the rest down — restart Odoo, or delete after a
confirmation naming the disk. Architecture column, both-way scrolling and
resizable columns.
**Platforms.** openSUSE Leap 16.0 and Tumbleweed, AlmaLinux, Rocky, Fedora 43
and the CentOS-family fixes. The s390x build chain works end to end on Debian,
EL9, EL10, Fedora and openSUSE. Ubuntu 20.04 and 22.04 are removed.
**Toolchain.** `EL_PYTHON_PROVIDER` chooses mise or pyenv, `EL_PIP_PROVIDER`
chooses uv or pip; each lives in a single library file, and each falls back on
failure. Neither tool is ever installed on its own — `make install_mise` and
`make install_uv` carry that decision. A Poetry dependency can be declined per
architecture.
**Déploiement par VM.** vCPU, RAM, disque, type de VM, branche ERPLibre,
version d'Odoo et fuseau horaire se règlent chacun sur la VM, jusqu'à la
commande distante bâtie par machine. Un verrou soustrait une VM au profil
global x1..x4 et se voit à la ligne entière ; une entrée se renomme ou se
déploie en plusieurs exemplaires. Les préréglages sont plus fins là où vivent
les VM de développement : chaque gigaoctet et chaque vCPU jusqu'à 16.
**VM graphiques.** Un choix serveur / bureau proposant GNOME ou Cinnamon, le
magasin d'applications retenu par VM (.deb seul, outillage Flatpak, ou snap),
et une commande SSH composée pour joindre le bureau distant — lue depuis
`~/.ssh/config`, si bien qu'une VM imbriquée est atteignable par son
ProxyJump, avec la console de l'hyperviseur comme troisième voie.
**Tableau de bord d'installation.** Agit sur une VM sans la quitter : mise à
jour par parties — paquets système, puis dépôts git, puis dépendances Python,
jamais enchaînées pour qu'un échec n'emporte pas le reste — redémarrage
d'Odoo, ou suppression après une confirmation nommant le disque. Colonne
d'architecture, défilement dans les deux sens et colonnes ajustables.
**Plateformes.** openSUSE Leap 16.0 et Tumbleweed, AlmaLinux, Rocky, Fedora 43
et les correctifs de la famille CentOS. La chaîne de compilation s390x
fonctionne de bout en bout sur Debian, EL9, EL10, Fedora et openSUSE. Ubuntu
20.04 et 22.04 sont retirées.
**Outillage.** `EL_PYTHON_PROVIDER` choisit mise ou pyenv, `EL_PIP_PROVIDER`
choisit uv ou pip ; chacun vit dans un seul fichier de bibliothèque, et chacun
retombe sur l'autre en cas d'échec. Aucun des deux n'est jamais installé de
lui-même — `make install_mise` et `make install_uv` portent cette décision.
Une dépendance Poetry peut être déclinée par architecture.
The Unreleased section already covered the QEMU deployment, the graphical
VMs and the COW migration tools, but stopped at what existed a month ago.
It says nothing of the per-VM settings, of the mise and uv providers, or
of the s390x build chain -- and a reader deciding whether to upgrade has
only this file to go on.
Fourteen entries, spread over Added, Changed and Fixed. Nothing is
repeated: the platforms and tools already listed stay where they are, and
only what the entry does not already say is added. The migration work
follows on its own, at the end of the branch.
Entries are written on one line. Nothing wraps markdown here -- no
max_line_length in .editorconfig, prettier never runs on .md -- and a
sentence cut at column 80 reads worse in a diff and in a terminal. The
three entries this cycle had already folded are flattened with them.
Written in CHANGELOG.base.md, the only source; the two generated files
come from it. mmg was unavailable here, so the generation was reproduced
by a filter checked byte-for-byte against the committed output before
being trusted.
--- FR ---
La section Unreleased couvrait déjà le déploiement QEMU, les VM graphiques
et les outils de migration COW, mais s'arrêtait à l'état d'il y a un mois.
Elle ne dit rien des réglages par VM, des fournisseurs mise et uv, ni de
la chaîne de compilation s390x — et qui décide de mettre à jour n'a que ce
fichier pour se prononcer.
Quatorze entrées, réparties sur Ajouté, Modifié et Corrigé. Rien n'est
redit : les plateformes et outils déjà listés restent en place, et seul ce
que l'entrée ne dit pas encore est ajouté. Le travail de migration suit
à part, en fin de branche.
Les entrées tiennent sur une ligne. Rien n'impose de plier le markdown
ici — pas de max_line_length dans .editorconfig, prettier ne tourne
jamais sur du .md — et une phrase coupée à la colonne 80 se lit moins
bien, en diff comme au terminal. Les trois entrées déjà pliées de ce
cycle sont mises à plat avec elles.
Écrit dans CHANGELOG.base.md, seule source ; les deux fichiers générés en
découlent. mmg étant indisponible ici, la génération a été reproduite par
un filtre vérifié à l'octet près contre la sortie déjà versionnée avant
d'être employé.
Assisted-by: Claude Opus 5
The list named Ubuntu, Debian 12, AlmaLinux, Rocky and Arch. It has been
wrong for a while: install_dev.sh also dispatches Fedora, openSUSE and
Linux Mint, each with its own dependency script, and the Debian path
handles trixie as well as bookworm. Someone on Fedora reading this file
concludes ERPLibre is not for them.
Every line is now read from the code rather than remembered. Ubuntu is
checked strictly against 24.04, 25.10 and 26.04, and refuses anything
else; Mint against 22.3; the RHEL family arrives through ID_LIKE, hence
RHEL and CentOS Stream alongside Alma and Rocky; SUSE through zypper,
Leap 16.0 and Tumbleweed. Debian carries no version test, and its qpdf is
built from source when the distribution ships one below 12.2 -- the same
guard the three families share.
The second list, further down, repeated four platforms and forgot the
rest. It now says what make install_os does: detect the distribution and
pick its package manager.
--- FR ---
La liste nommait Ubuntu, Debian 12, AlmaLinux, Rocky et Arch. Elle est
fausse depuis un moment : install_dev.sh aiguille aussi Fedora, openSUSE
et Linux Mint, chacune vers son script de dépendances, et le chemin
Debian traite trixie autant que bookworm. Qui lit ce fichier sous Fedora
en conclut qu'ERPLibre n'est pas pour lui.
Chaque ligne est désormais lue dans le code plutôt que de mémoire. Ubuntu
est vérifiée strictement contre 24.04, 25.10 et 26.04, et refuse le
reste ; Mint contre 22.3 ; la famille RHEL arrive par ID_LIKE, d'où RHEL
et CentOS Stream aux côtés d'Alma et Rocky ; SUSE par zypper, Leap 16.0
et Tumbleweed. Debian ne porte aucun test de version, et son qpdf est
compilé depuis les sources quand la distribution en livre un sous 12.2 —
le même garde que partagent les trois familles.
La seconde liste, plus bas, répétait quatre plateformes et oubliait les
autres. Elle dit maintenant ce que fait make install_os : détecter la
distribution et choisir son gestionnaire de paquets.
Assisted-by: Claude Opus 5
The gap between 4 and 8 GB was the first one worth filling -- it is the
usual size of an ERPLibre development VM -- but every neighbouring gap
had the same fault: the lists jumped precisely where development VMs
live.
RAM now offers every gigabyte up to 16, and vCPU every count up to 16.
Disk gains 30, 50, 100 and 160 G, the steps missing between those already
there. Above 16 nothing changes: those jumps are deliberate, a machine
that large not being sized by picking from a list.
A typed value was already accepted in both interfaces, so these are a
convenience, never a constraint.
--- FR ---
L'écart entre 4 et 8 Go était le premier à combler — c'est la taille
courante d'une VM de développement ERPLibre — mais tous les écarts
voisins avaient le même défaut : les listes sautaient précisément là où
vivent les VM de développement.
La RAM offre désormais chaque gigaoctet jusqu'à 16, et les vCPU chaque
valeur jusqu'à 16. Le disque gagne 30, 50, 100 et 160 G, les paliers qui
manquaient entre ceux déjà présents. Au-delà de 16, rien ne change : ces
sauts sont voulus, une machine de cette taille ne se dimensionne pas en
piochant dans une liste.
Une valeur tapée était déjà acceptée dans les deux interfaces : ce sont
donc des commodités, jamais une contrainte.
Assisted-by: Claude Opus 5
A per-VM setting appears not to be taken into account, and nothing on
screen tells which link failed: the gap may be between the widget and
the model, or between the model and the spec. A screenshot shows
neither.
F9 writes both side by side into ~/.erplibre/deploy-form-dump.txt:
profile, shared values, overrides, locks, row generation, then VM by VM
what the list DISPLAYS against what the model HOLDS, and finally the
spec that would go to deployment.
The file can be pasted into a message, unlike an image, and it answers
the question on its own: if the list shows 16384 while the model says
1024, the defect is in the intake; if they agree and the created VM
differs, it is downstream, in deploy_qemu.
--- FR ---
Un réglage par VM ne semble pas pris en compte, et rien dans ce que
l'écran montre ne permet de trancher : l'écart peut être entre le widget
et le modèle, ou entre le modèle et la spec. Une capture d'écran ne dit
ni l'un ni l'autre.
F9 écrit les deux côte à côte dans ~/.erplibre/deploy-form-dump.txt :
profil, valeurs communes, surcharges, verrous, génération des rangées,
puis VM par VM ce que la liste AFFICHE contre ce que le modèle CONTIENT,
et enfin la spec qui partirait au déploiement.
Le fichier se recopie dans un message, contrairement à une image, et il
répond seul à la question : si la liste montre 16384 et que le modèle
dit 1024, le défaut est dans la prise en compte ; s'ils s'accordent et
que la VM créée diffère, il est en aval, dans deploy_qemu.
Assisted-by: Claude Opus 5
textual, urwid and lxml were already in the tooling requirements; the
earlier table read as if they were missing, when it only compared
against the system python. psycopg2 is the one absent, and stays so:
nothing under script/ imports it, the analysis tools query PostgreSQL
through psql, and the Odoo venvs declare it where Odoo needs it.
A test now answers this by reading the imports instead of the venv. It
bites both ways: a removed declaration, and a new undeclared import.
Also chmod +X -> +x in the Dockerfile: uppercase only adds the bit to
directories, or to files that already carry one. On what COPY had just
laid down in 644 it did nothing.
--- FR ---
[ADD] test : ce que l'outillage importe doit être déclaré
textual, urwid et lxml y étaient déjà ; le tableau précédent laissait
croire le contraire, alors qu'il comparait au python du système.
psycopg2 est le seul absent, et le reste : rien sous script/ ne
l'importe, les outils d'analyse passent par psql, et les venvs Odoo le
déclarent là où Odoo en a besoin.
Un test répond désormais à la question en lisant les imports plutôt
que le venv. Il mord des deux côtés : déclaration retirée, et import
non déclaré.
Aussi chmod +X -> +x dans le Dockerfile : la majuscule n'ajoute le bit
qu'aux répertoires, ou aux fichiers qui en portent déjà un. Sur ce que
COPY venait de déposer en 644, elle ne faisait rien.
Assisted-by: Claude Opus 5
A "Remote desktop tunnel" entry under SSH configuration. It lists the
targets, resolves them, and composes the full command -- nothing to fill
in.
todo.py runs on the libvirt HOST; the tunnel starts from the workstation.
It cannot open it, but it alone knows the VM's private IP, its port and
the address through which it was reached. That last one comes from
SSH_CONNECTION, whose third field is exactly the server address used --
far safer than a "hostname" that may resolve to nothing outside.
When ~/.ssh/config already carries the entry, the tunnel takes it:
"ssh -N -L 5902:localhost:5901 <vm>". ProxyJump makes the route and
"localhost" means the VM's OWN loopback, so the tunnel survives an IP
change. That config is also the right source of targets, not the local
libvirt: a graphical VM is often nested, and virsh would only ever list
the orchestrator.
Two details: the hypervisor console needs VNC bound to the loopback, as
"listen=none" opens no socket at all; and two menu entries had no icon.
--- FR ---
Une entrée « Tunnel bureau distant » sous Configuration SSH. Elle liste
les cibles, les résout, et compose la commande complète — rien à remplir.
todo.py tourne sur l'HÔTE libvirt ; le tunnel, lui, part du poste de
travail. Il ne peut donc pas l'ouvrir, mais il est le seul à connaître
l'IP privée de la VM, son port et l'adresse par laquelle on l'a joint.
Cette dernière vient de SSH_CONNECTION, dont le troisième champ est
exactement l'adresse serveur utilisée — bien plus sûr qu'un « hostname »
qui peut ne rien résoudre depuis l'extérieur.
Quand ~/.ssh/config porte déjà l'entrée, le tunnel l'emprunte :
« ssh -N -L 5902:localhost:5901 <vm> ». Le ProxyJump fait la route et
« localhost » désigne le bouclage DE LA VM, si bien que le tunnel survit à
un changement d'IP. Ce fichier est aussi la bonne source de cibles, pas le
libvirt local : une VM graphique est souvent imbriquée, et virsh ne
listerait jamais que l'orchestrateur.
Deux détails : la console de l'hyperviseur exige un VNC sur la boucle
locale, « listen=none » n'ouvrant aucun socket ; et deux entrées de menu
n'avaient pas d'icône.
Assisted-by: Claude Opus 5
The VM announced "Remote desktop: RDP 3389" without saying how to get
there. Its address is on libvirt's private network, which is not routed
from outside its host: the port alone helps nobody.
It now prints the tunnel to set up, address already filled in --
"ssh -L 3390:<ip>:3389 <user>@<libvirt-host>", then an RDP client on
localhost:3390. Likewise in VNC for Arch, on 5902.
This is the only workable route when the libvirt host is itself a VM
with no graphical interface: the SPICE console is on "listen=none" and
assumes virt-viewer ON that host.
--- FR ---
La VM annonçait « Bureau distant : RDP 3389 » sans dire par où passer.
Son adresse est sur le réseau privé de libvirt, qui n'est pas routé
depuis l'extérieur de son hôte : le port seul n'aide personne.
Elle imprime maintenant le tunnel à monter, adresse déjà remplie —
« ssh -L 3390:<ip>:3389 <user>@<hote-libvirt> », puis un client RDP sur
localhost:3390. Idem en VNC pour Arch, sur 5902.
C'est le seul chemin praticable quand l'hôte libvirt est lui-même une VM
sans interface graphique : la console SPICE est en « listen=none » et
suppose virt-viewer SUR cet hôte.
Assisted-by: Claude Opus 5
The timezone was typed by hand. A misspelt IANA name is not rejected by
cloud-init: it is IGNORED. The VM stays on UTC, and you only notice from
the timestamps, once deployed.
A list of twenty-five zones, Québec first, then the rest of Canada and
the places one actually meets. The host's zone goes to the top, without
duplication: a machine outside this list must still see its own at a
glance.
NAMES, not offsets: "UTC-5" says nothing about daylight saving and
cloud-init will not take it. A name carries its own switching rules.
"free value…" keeps the door open to the other six hundred zones in the
database. The choice is copied into the field, which stays the only
value the spec reads -- one place holds the answer.
--- FR ---
Le fuseau se tapait à la main. Un nom IANA mal orthographié n'est pas
refusé par cloud-init : il est IGNORÉ. La VM reste en UTC, et on ne s'en
aperçoit qu'aux horodatages, une fois déployée.
Une liste de vingt-cinq fuseaux, le Québec d'abord, puis le reste du
Canada et les places qu'on rencontre en pratique. Le fuseau de l'hôte
passe en tête, sans doublon : une machine hors de cette liste doit voir
le sien en un coup d'œil.
Des NOMS, pas des décalages : « UTC-5 » ne dit rien de l'heure d'été et
cloud-init n'en veut pas. Un nom porte ses propres règles de bascule.
« libre… » garde la porte ouverte aux six cents autres fuseaux de la
base. Le choix est recopié dans le champ, qui reste la seule valeur lue
par la spec — un seul endroit porte la réponse.
Assisted-by: Claude Opus 5
A profile list per row, beside the branch: "ERPLibre + Odoo 18",
"Odoo 17", "ERPLibre alone". The form's profile stays the default; picking
another for a VM creates an override, going back clears it.
It reaches down to execution, like the branch and the type before it.
"final_cmd" now takes either a string for the whole fleet or a
{name: command} map, and the remote command is built per machine as soon
as profiles differ. A VM can install Odoo 18 while another validates
Odoo 17, in the same deployment.
Both lists are widened -- branch to 24 columns, profile to 28. Truncated,
"develop" and "ERPLibre + Odoo 18" no longer showed what had been picked,
and that is precisely what one wants to re-read before deploying.
Two more defects: the global branch and Odoo choices reached nothing at
all, and the summary announced the global profile for every VM, then named
a version nothing would install.
--- FR ---
Une liste de profils par rangée, à côté de la branche : « ERPLibre +
Odoo 18 », « Odoo 17 », « ERPLibre seul ». Le profil du formulaire reste
le défaut ; en choisir un autre pour une VM crée une surcharge, y revenir
l'efface.
Il descend jusqu'à l'exécution, comme la branche et le type avant lui.
« final_cmd » accepte maintenant une chaîne pour tout le parc ou une carte
{nom: commande}, et la commande distante est bâtie par machine dès que les
profils diffèrent. Une VM peut donc installer Odoo 18 pendant qu'une autre
valide Odoo 17, dans le même déploiement.
Les deux listes sont élargies : la branche passe à 24 colonnes, le profil
à 28. Tronqués, « develop » et « ERPLibre + Odoo 18 » ne laissaient plus
voir ce qu'on avait choisi — et c'est précisément ce qu'on veut relire
avant de déployer.
Deux autres défauts : les choix globaux de branche et d'Odoo n'atteignaient
rien, et le sommaire annonçait le profil global pour toutes les VM, puis
nommait une version que rien n'installait.
Assisted-by: Claude Opus 5
A branch list per row. The form's branch stays the default; picking
another for a VM creates an override, going back clears it -- the VM then
follows the form again, which is what one expects when restoring the
common choice.
It reaches all the way down to execution, like VM type before it.
"branch" now takes either a string for the whole fleet or a {name: branch}
map, and the remote command is built per machine as soon as branches
differ. The ground was ready: launch_installs already knows how to take
one command per VM.
A VM can therefore carry develop while another validates 1.6.0, in the
same deployment and the same monitoring table.
One trap: a row's branch fell back to develop on remount, the list being
rebuilt from the form rather than from the override it already held.
--- FR ---
Une liste de branches par rangée. La branche du formulaire reste le
défaut ; en choisir une autre pour une VM crée une surcharge, y revenir
l'efface — la VM suit alors de nouveau le formulaire, ce qui est le plus
attendu quand on remet le choix commun.
Elle descend jusqu'à l'exécution, comme le type de VM avant elle.
« branch » accepte désormais une chaîne pour tout le parc ou une carte
{nom: branche}, et la commande distante est bâtie par machine dès que les
branches diffèrent. Le terrain était prêt : launch_installs sait déjà
prendre une commande par VM.
Une VM peut donc porter develop pendant qu'une autre valide 1.6.0, sur le
même déploiement et dans le même tableau de suivi.
Un piège : la branche d'une rangée retombait sur develop au remontage, la
liste étant rebâtie depuis le formulaire plutôt que depuis la surcharge
qu'elle portait déjà.
Assisted-by: Claude Opus 5
A "✎" per row opens an input prefilled with the current name. The given
name becomes an override like any other: it survives recomputation, and
F4 removes it along with the VM's other settings.
An explicit name makes automatic naming GIVE WAY. Switching the VM to
GNOME no longer appends "-gnome": adding a suffix would amount to
correcting the user. Clearing the field restores the automatic name,
copy and desktop suffixes included.
The name becomes the machine's HOSTNAME, so it is validated against
RFC 1123 before being accepted. One capital or one dot too many and
cloud-init silently ignores it -- the VM would stay "ubuntu", and you
would find out once deployed. Capitals are lowered, the rest is refused
with a message.
--- FR ---
Un « ✎ » par rangée ouvre une saisie préremplie du nom courant. Le nom
donné devient une surcharge comme les autres : il survit au recalcul, et
F4 le retire avec le reste des réglages de la VM.
Un nom explicite fait CÉDER le nommage automatique. Passer la VM en
GNOME n'y colle plus « -gnome » : y ajouter un suffixe reviendrait à
corriger l'utilisateur. Vider le champ rend le nom automatique, suffixes
de copie et de bureau compris.
Le nom devient le NOM D'HÔTE de la machine : il est donc validé en
RFC 1123 avant d'être retenu. Une majuscule ou un point de trop et
cloud-init l'ignore en silence — la VM resterait « ubuntu », et on le
découvrirait une fois déployée. Les majuscules sont abaissées, le reste
est refusé avec un message.
Assisted-by: Claude Opus 5
A "+" per row adds a copy of the entry, a "−" removes it. The "−" only
appears on a copy: the original cannot be deleted by mistake, it is
unticked in the catalogue.
The name adapts on its own -- erplibre-ubuntu-2404, then -2, then -3.
The first keeps the catalogue name, so existing deployments keep theirs.
The real work is in identity. entry_key was (distro, version, arch): two
copies shared it, so setting the first set the second and their locks
fought each other. It now carries the instance number, and overrides as
well as locks follow the right machine. Each instance is a COPY of the
dictionary, never a shared reference.
Removing a copy forgets its settings: keeping them would resurrect old
values on the next copy, with nothing to explain it.
--- FR ---
Un « + » par rangée ajoute une copie de l'entrée, un « − » la retire. Le
« − » n'apparaît que sur une copie : l'original ne se supprime pas par
mégarde, il se décoche au catalogue.
Le nom s'adapte seul — erplibre-ubuntu-2404, puis -2, puis -3. Le
premier garde le nom du catalogue, pour que les déploiements existants
gardent le leur.
Le vrai travail est dans l'identité. entry_key valait
(distro, version, arch) : deux copies la partageaient, donc régler la
première réglait la seconde et leurs verrous se marchaient dessus. Elle
porte maintenant le numéro d'exemplaire, et surcharges comme verrous
suivent la bonne machine. Chaque exemplaire est une COPIE du
dictionnaire, jamais une référence partagée.
Retirer une copie oublie ses réglages : les garder ferait resurgir
d'anciennes valeurs à la copie suivante, sans que rien ne l'explique.
Assisted-by: Claude Opus 5
A 🔒 box at the head of each row. Ticked, the VM's four current values --
vCPU, RAM, disk, type -- are copied into its overrides: the x1..x4 profile
no longer reaches it. Unticked, they are removed and the VM falls back
under the profile. The lock shows on the WHOLE ROW, not in a box lost at
the end: that is what lets you scan the plan and see at once what escapes
the profile.
It rests on the override mechanism already proven, indexed by catalog
identity, so it survives a remount. Locked state stays distinct from
overrides: a VM can be edited without being frozen, and the lock covers
all four fields at once.
Four traps came with it. "remove_children()" is ASYNCHRONOUS, so giving
the card an id broke the remount, the old one still being there. Lists
kept stale values across a remount, and a refresh took back the free
entry. A frozen VM changed version all the same. And switching profile
wiped the disk size that had been set.
--- FR ---
Une case 🔒 en tête de chaque rangée. Cochée, les quatre valeurs courantes
de la VM — vCPU, RAM, disque, type — sont recopiées dans ses surcharges :
le profil x1..x4 ne l'atteint plus. Décochée, elles sont retirées et la VM
retombe sous le profil. Le verrou se voit à la LIGNE ENTIÈRE, pas à une
case perdue au bout : c'est ce qui permet de balayer le plan et de savoir
d'un coup ce qui échappe au profil.
Il s'appuie sur le mécanisme de surcharge déjà éprouvé, indexé par
identité de catalogue : il survit donc à un remontage. L'état verrouillé
reste distinct des surcharges : une VM peut être modifiée sans être figée,
et le verrou couvre les quatre champs d'un coup.
Quatre pièges l'ont accompagné. « remove_children() » est ASYNCHRONE :
donner un id à la carte faisait échouer le remontage, l'ancienne étant
encore là. Les listes gardaient des valeurs périmées au remontage, et un
rafraîchissement reprenait la saisie libre. Une VM figée changeait quand
même de version. Et changer de profil effaçait la taille de disque réglée.
Assisted-by: Claude Opus 5
The architecture was missing, though it alone explains why an install
takes ten times longer: s390x and arm64 are EMULATED on an amd64 host.
Without it you look for the fault elsewhere. An "Arch" column, right after
the name.
The table was pinned at 74 columns: beyond that nothing was reachable and
no scrollbar showed, for want of reserved space. Automatic width capped at
60% of the screen, scrolling both ways, and VISIBLE bars rather than
guessable ones.
Columns can finally be adjusted: "+" widens the cursor's, "-" narrows it,
"0" returns them all to their original width -- the same keys as the mail
TUI. auto_width is turned off along the way, otherwise the setting did not
survive the table's first update, and the resize aimed at the "#" column
whatever the cursor was on.
--- FR ---
L'architecture manquait, alors qu'elle explique à elle seule pourquoi une
installation dure dix fois plus : s390x et arm64 sont ÉMULÉES sur un hôte
amd64. Sans elle, on cherche la faute ailleurs. Une colonne « Arch »,
juste après le nom.
Le tableau était figé à 74 colonnes : au-delà rien n'était atteignable et
aucune barre de défilement n'apparaissait, faute de place réservée.
Largeur automatique plafonnée à 60 % de l'écran, défilement dans les deux
sens, et barres VISIBLES plutôt que devinables.
Les colonnes s'ajustent enfin : « + » élargit celle du curseur, « - » la
rétrécit, « 0 » les ramène toutes à leur largeur d'origine — les mêmes
touches que la TUI courriel. auto_width est désactivé au passage, sans
quoi le réglage ne survivait pas à la première mise à jour du tableau, et
le redimensionnement visait la colonne « # » quel que soit le curseur.
Assisted-by: Claude Opus 5
The monitor could only watch. The "a" key now opens the selected VM's
actions: update, restart Odoo, delete.
The update is chosen by parts, and the order is not free: system packages,
then git repositories, then Python dependencies -- the latter compile
against the former. Nothing is chained with "&&": one failing part must
not take the others down. Deleting demands a second hand, a confirmation
screen naming the disk to be erased.
Two defects the dashboard revealed. Detached installs were stealing the
shell's keystrokes, the child inheriting a terminal it had no business
reading. And the elapsed time restarted from zero every time the dashboard
was reopened, since it was counted from the view rather than from the
run's own first write.
--- FR ---
Le suivi ne savait que regarder. La touche « a » ouvre désormais les
actions de la VM sélectionnée : mettre à jour, redémarrer Odoo, supprimer.
La mise à jour se choisit par parties, et l'ordre n'est pas libre :
paquets système, puis dépôts git, puis dépendances Python — ces dernières
compilent contre les premiers. Rien n'est enchaîné par « && » : une partie
en échec ne doit pas emporter les autres. Supprimer exige une seconde
main, un écran de confirmation nommant le disque à effacer.
Deux défauts que le tableau de bord a révélés. Les installations détachées
volaient les frappes du shell, l'enfant héritant d'un terminal qu'il
n'avait pas à lire. Et la durée repartait de zéro à chaque réouverture,
comptée depuis la vue plutôt que depuis la première écriture du run.
Assisted-by: Claude Opus 5
erplibre-ubuntu-2404-gnome, erplibre-ubuntu-2404-mint. A graphical VM is
recognisable from a "virsh list", and its hostname says so too --
deploy_qemu uses the name as hostname when --hostname is not given.
This is not only cosmetic. The name is the COLLISION KEY: a graphical VM
and its server twin carried the same one, so the second was reported as
"already exists" and silently skipped. They are now distinct.
The suffix is applied AFTER overrides, the only point where each
machine's type is known now that it is chosen VM by VM. In the form the
name therefore follows the choice live, both ways.
"mint" rather than "cinnamon": that is the name chosen for the fleet,
the installed package still being Cinnamon from the distribution's own
repositories. The suffix lives with the flavour, in _QEMU_DESKTOP, and
the CLI calls the same function as the TUI rather than writing a second.
--- FR ---
erplibre-ubuntu-2404-gnome, erplibre-ubuntu-2404-mint. Une VM graphique
se reconnaît d'un « virsh list », et son nom d'hôte le dit aussi —
deploy_qemu prend le nom pour hôte quand --hostname n'est pas donné.
Ce n'est pas que cosmétique. Le nom sert de CLÉ DE COLLISION : une VM
graphique et sa jumelle serveur portaient le même, donc la seconde était
signalée « existe déjà » et silencieusement ignorée. Elles se
distinguent maintenant.
Le suffixe est appliqué APRÈS les surcharges, seul moment où le type de
chaque machine est connu depuis qu'il se choisit VM par VM. Dans le
formulaire, le nom suit donc le choix en direct, dans les deux sens.
« mint » et non « cinnamon » : c'est le nom retenu pour le parc, le
paquet installé restant Cinnamon depuis les dépôts de la distribution.
Le suffixe vit avec la saveur, dans _QEMU_DESKTOP, et la CLI appelle la
même fonction que la TUI plutôt que d'en écrire une seconde.
Assisted-by: Claude Opus 5
snap was not a choice but a fate: we disabled snapd, then gnome-core
pulled a Firefox snap that froze the install for thirty minutes. The
previous fix imposed "deb". Three answers are now offered.
deb nothing but .deb, epiphany-browser as the browser. Default,
and lightest: nothing extra to download.
flatpak Flatpak tooling as well, WITHOUT the Flathub remote or any
install. The machine is ready, the admin picks its remotes.
snap Ubuntu's default, snapd left running and Firefox as a snap.
It is the only mode where snapd is not disabled -- disabling
it was precisely the cause of the freeze.
The question is only asked when it means something: at least one
graphical VM on a distro shipping snapd, Ubuntu alone here. A server
pulls no snap, and Debian ships none. The TUI greys the choice out and
says why; the CLI does not ask.
Verified on a 26.04 VM: snapd is indeed preinstalled (2.75.2), flatpak
and its GNOME Software plugin are packaged, and firefox-esr does not
exist on Ubuntu.
--- FR ---
snap n'était plus un choix mais une fatalité : on coupait snapd, puis
gnome-core tirait un Firefox-snap qui figeait l'installation trente
minutes. Le correctif précédent imposait « deb ». Trois réponses sont
maintenant offertes.
deb rien que des .deb, epiphany-browser comme navigateur. Défaut,
et le plus léger : rien de plus à télécharger.
flatpak l'outillage Flatpak en plus, SANS dépôt Flathub ni
installation. La machine est prête, l'administrateur choisit
ses dépôts.
snap le défaut d'Ubuntu, snapd laissé actif et Firefox en snap.
C'est le seul mode où snapd n'est pas coupé — l'y couper
était précisément la cause du blocage.
La question n'est posée que lorsqu'elle a un sens : au moins une VM
graphique sur une distribution qui livre snapd, Ubuntu seule ici. Un
serveur ne tire aucun snap, et Debian n'en livre pas. La TUI grise le
choix et dit pourquoi ; la CLI ne le demande pas.
Vérifié sur une VM 26.04 : snapd y est bien préinstallé (2.75.2),
flatpak et son greffon GNOME Software sont empaquetés, et firefox-esr
n'existe pas sur Ubuntu.
Assisted-by: Claude Opus 5
A graphical Ubuntu VM stopped making progress, with no error, on "Unable
to contact the store, trying every minute for the next 30 minutes".
Nothing in the log says why, and the install just looks stuck.
The cause is ours. We disable snapd a few lines earlier, to stop its
refreshes during the install. Then gnome-core recommends "firefox", which
on Ubuntu is only a transitional package whose postinst runs "snap
install" -- against a snapd we just stopped.
It is a RECOMMENDS, with alternatives. So we exclude the snap packages and
name epiphany-browser, a real .deb. Excluding firefox alone was not
enough: apt fell back to chromium-browser, a transitional package too, and
Cinnamon froze the same way on thunderbird. Measured on the VM: with this
list, GNOME (844 packages) and Cinnamon (1167) pull none, without an apt
error.
--- FR ---
Une VM Ubuntu graphique cessait d'avancer, sans erreur, sur « Unable to
contact the store, trying every minute for the next 30 minutes ». Rien
dans le log n'en dit la raison, et l'installation paraît simplement figée.
La cause est nôtre. On coupe snapd quelques lignes plus haut, pour
empêcher ses rafraîchissements pendant l'installation. Puis gnome-core
recommande « firefox », qui n'est plus sur Ubuntu qu'un paquet de
transition dont le postinst lance « snap install » — contre un snapd qu'on
vient d'arrêter.
C'est un RECOMMENDS, avec alternatives. On écarte donc les paquets snap et
on nomme epiphany-browser, un vrai .deb. Écarter le seul firefox ne
suffisait pas : apt retombait sur chromium-browser, paquet de transition
lui aussi, et Cinnamon figeait pareillement sur thunderbird. Mesuré sur la
VM : avec cette liste, GNOME (844 paquets) et Cinnamon (1167) n'en tirent
aucun, sans erreur apt.
Assisted-by: Claude Opus 5
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
VM type was global: the whole fleet as servers, or all of them GNOME. It
now lives on the VM, all the way down -- the creation flag, and one remote
command per machine at install time, where a single one served them all.
The right pane is no longer a table but a row of widgets per VM: vCPU,
RAM, disk and type, each with its usual values and a free entry. The
left-hand fields become the shared default, which the screen now says. The
scope selector and the F2 modal go away: given two ways to do the same
thing, keep the visible one.
Three traps came out of it, and the tests lock them. Widget ids carry a
RANK, and the rank shifts when an entry is ticked, so an event from an
already destroyed widget applied to the VM that took its place -- rows now
carry a generation, marked BEFORE mounting, since mount_all empties the
pending children and marking after it was a race. The x1..x4 profile no
longer reached any VM. And a total of zero never said it had counted
nothing.
--- FR ---
Le type de VM était global : tout le parc en serveur, ou tout en GNOME. Il
vit désormais sur la VM, jusqu'au bout — le drapeau de création, et une
commande distante par machine à l'installation, là où une seule les
servait toutes.
Le panneau de droite n'est plus un tableau mais une rangée de widgets par
VM : vCPU, RAM, disque et type, chacun avec ses valeurs usuelles et une
saisie libre. Les champs de gauche deviennent le défaut commun, ce que
l'écran dit maintenant. Le sélecteur de portée et la modale F2 partent :
entre deux façons de faire la même chose, on garde la visible.
Trois pièges en sont sortis, et les tests les verrouillent. Les
identifiants de widgets portent un RANG, et le rang se décale quand on
coche une entrée : un événement émis par un widget déjà détruit
s'appliquait à la VM qui avait pris sa place — les rangées portent
maintenant une génération, marquée AVANT le montage, car mount_all vide
les enfants en attente et marquer après était une course. Le profil x1..x4
n'atteignait plus aucune VM. Et un total à zéro ne disait pas qu'il
n'avait rien compté.
Assisted-by: Claude Opus 5
The three resource fields applied to the whole fleet. With a single
machine needing 16 G, the other eight got it too. A scope selector
settles it: all VMs, or the row targeted in the plan. The x1..x4 profile
stays global, multiplying what each image asks for; under "selected VM"
the fields are absolute, hence active even outside the custom profile.
The F2 modal already existed but was undiscoverable, and its cursor was
unusable: the table never held focus. It stays, the toggle now focuses
the table, F4 returns a VM to the shared profile, and the plan marks
customised rows with a ✎ -- without it, two rows with different
resources have no explanation on screen.
One defect found along the way: clear() reset the cursor to the top on
every redraw, and the plan recomputes on every keystroke. You picked
debian, typed the value, the table redrew, and the next entry landed on
ubuntu with nothing to show for it.
--- FR ---
Les trois champs de ressources s'appliquaient à tout le parc. Une seule
machine ayant besoin de 16 G, il fallait les donner aux huit autres. Un
sélecteur de portée tranche : toutes les VM, ou la ligne visée dans le
plan. Le profil x1..x4 reste global, il multiplie ce que demande chaque
image ; en portée « une seule » les champs valent en absolu, et sont donc
actifs même hors profil personnalisé.
La modale F2 existait déjà mais restait introuvable, et son curseur était
inutilisable : le tableau n'avait jamais le focus. Elle demeure, la
bascule lui donne le focus, F4 rend une VM au profil commun, et le plan
marque d'un ✎ ce qui a été personnalisé — sans marque, deux lignes aux
ressources différentes n'ont aucune explication à l'écran.
Un défaut au passage : « clear() » ramenait le curseur en tête à chaque
redessin, et le plan se recalcule à chaque frappe. On choisissait debian,
on tapait la valeur, le tableau se redessinait, et la saisie suivante
partait sur ubuntu sans que rien ne le montre.
Assisted-by: Claude Opus 5
The catalogue only offered openSUSE Tumbleweed, a rolling release with
no version number. Nearly every openSUSE incident in this series came
from that: the cloud image is a snapshot lagging behind its own repos,
hence the mandatory "zypper dup", and two VMs deployed the same day saw
git-daemon 2.54 on s390x against 2.55 on amd64. For an ERP platform,
that is not what should be offered by default.
Leap 16.0 is numbered, stable, and publishes the three architectures
that matter -- verified, x86_64, aarch64 and s390x all 200. It also
unifies its tree: no separate /ports/, unlike Tumbleweed, whose
equivalent paths 404 for Leap.
Tumbleweed stays on offer, as a bellwether for breakage to come. Two
things separate them in the scripts: the repository path, and "dup" --
which on Leap means CHANGING version, not updating.
--- FR ---
Le catalogue n'offrait qu'openSUSE Tumbleweed, une rolling sans numéro
de version. Presque tous les incidents openSUSE de la série venaient de
là : l'image cloud est un instantané en retard sur ses dépôts, d'où le
« zypper dup » obligatoire, et deux VM déployées le même jour ont vu
git-daemon 2.54 sur s390x contre 2.55 sur amd64. Pour une plateforme
ERP, ce n'est pas ce qu'on veut proposer par défaut.
Leap 16.0 est numérotée, stable, et publie les trois architectures qui
comptent — vérifié, x86_64, aarch64 et s390x en 200. Elle unifie de plus
son arbre : pas de /ports/ séparé, contrairement à Tumbleweed, dont les
chemins équivalents rendent 404 pour Leap.
Tumbleweed reste offerte, comme banc d'essai des ruptures à venir.
Deux points les séparent dans les scripts : le chemin des dépôts, et
« dup » — qui sur Leap sert à CHANGER de version, pas à mettre à jour.
Assisted-by: Claude Opus 5
uv replaces pip where it can: the tools venv and the Poetry bootstrap. The
choice lives in EL_PIP_PROVIDER -- auto, uv or pip -- and in a single
file, lib_pip_provider.sh, on the exact model of the mise/pyenv switch. A
uv failure falls back to pip: it is stricter on metadata and rejects
packages pip accepts.
Three guards. The target always goes through "--python" rather than being
inferred from the active venv: poetry.toml declares a "./.venv" uv would
also look for. Python 3.7, still used by Odoo 12 and 13, stays on pip. And
"uv pip sync" is never used: it would delete pip itself and everything
Poetry laid down.
One bug falls along the way: the idempotence guard aimed at
.venv.erplibre/bin/poetry while Poetry installs into the Odoo venv, so a
successful replay reported failure all the same.
--- FR ---
uv remplace pip là où il le peut : le venv d'outils et l'amorçage de
Poetry. Le choix vit dans EL_PIP_PROVIDER — auto, uv ou pip — et dans un
seul fichier, lib_pip_provider.sh, sur le modèle exact de l'aiguillage
mise/pyenv. Un échec d'uv retombe sur pip : il est plus strict sur les
métadonnées et refuse des paquets que pip accepte.
Trois gardes. La cible passe toujours par « --python » plutôt que d'être
déduite du venv actif : poetry.toml déclare un « ./.venv » qu'uv
chercherait aussi. Python 3.7, encore utilisé par Odoo 12 et 13, reste sur
pip. Et « uv pip sync » n'est jamais employé : il supprimerait pip
lui-même et tout ce que Poetry a posé.
Un défaut tombe au passage : le garde d'idempotence visait
.venv.erplibre/bin/poetry alors que Poetry s'installe dans le venv Odoo,
si bien qu'un rejeu réussi rapportait quand même un échec.
Assisted-by: Claude Opus 5
Measured from Montréal on extra.db: mirror.quantum5.ca 2.0 s,
mirror.xenyth.net 7.1 s, against 8.0 s for geo.mirror.pkgbuild.com. The
official "geographic" mirror is therefore not the best one here, and
reflector, which sorts by throughput from inside the VM, had not picked
them.
Both are PREPENDED, never substituted: whatever reflector chose stays
below, as fallback. The write therefore comes after it, since "--save"
overwrites the file. Guarded on x86_64, these mirrors serving that
architecture only. Host side, the addition is idempotent.
The desktop install went through neither step: it ran without the near
mirrors and without the full update a rolling release demands, so it
pulled from Europe and broke on partial upgrades.
--- FR ---
Mesuré depuis Montréal sur extra.db : mirror.quantum5.ca 2,0 s,
mirror.xenyth.net 7,1 s, contre 8,0 s pour geo.mirror.pkgbuild.com. Le
miroir « géographique » officiel n'est donc pas le meilleur ici, et
reflector, qui trie par débit depuis la VM, ne les avait pas retenus.
Les deux sont mis EN TÊTE, jamais substitués : ce que reflector a choisi
reste dessous, en repli. L'écriture vient donc après lui, puisque
« --save » écrase le fichier. Gardé sur x86_64, ces miroirs ne servant que
cette architecture. Côté hôte, l'ajout est idempotent.
L'installation du bureau ne passait par aucune des deux étapes : elle
s'exécutait sans les miroirs proches et sans la mise à jour complète
qu'exige une rolling release, tirant donc d'Europe et cassant sur des
mises à jour partielles.
Assisted-by: Claude Opus 5
The interpreter provider is now chosen when creating a VM, in both
interfaces. "mise" installs it in the VM and lays down a precompiled
CPython; "pyenv" keeps today's build-from-source.
The question is only asked where it means something: mise publishes
binaries for amd64 and arm64 only. An all-s390x fleet never sees it, a
mixed fleet sees it along with the architectures that will fall back to
pyenv -- said before deploying, not discovered in a log an hour later.
mise goes into /usr/local/bin rather than ~/.local/bin: the remote command
runs through "ssh host 'command'", where neither ~/.profile nor ~/.bashrc
is read. Choosing "mise" exports "auto", not "mise", so a failed install
can still fall back to pyenv.
The unavailability notice was translated as "pyenv required", which said
the opposite of what happens: pyenv is the fallback, not a demand.
--- FR ---
Le fournisseur d'interpréteur se choisit désormais à la création d'une VM,
dans les deux interfaces. « mise » l'installe dans la VM et pose un
CPython précompilé ; « pyenv » garde la compilation d'aujourd'hui.
La question n'est posée que là où elle a un sens : mise ne publie de
binaires que pour amd64 et arm64. Un parc tout s390x ne la voit jamais, un
parc mixte la voit avec les architectures qui retomberont sur pyenv — dit
avant de déployer, pas découvert dans un log une heure plus tard.
mise va dans /usr/local/bin plutôt que ~/.local/bin : la commande distante
passe par « ssh hôte 'commande' », où ni ~/.profile ni ~/.bashrc ne sont
lus. Choisir « mise » exporte « auto », pas « mise », pour qu'une
installation ratée puisse encore retomber sur pyenv.
L'avis d'indisponibilité était traduit par « pyenv exigé », qui disait
l'inverse de ce qui se passe : pyenv est le repli, pas une exigence.
Assisted-by: Claude Opus 5
mise lays down a precompiled CPython where pyenv builds one: seconds
against one to three minutes, with no -dev package at all. The choice
lives in EL_PYTHON_PROVIDER -- auto, mise or pyenv -- and in a single
file, lib_python_provider.sh. The rest of the repository only knows venv
paths and needs to know none of this.
In auto mode an ALREADY installed interpreter wins, whichever provider put
it there. mise is never installed on its own, "curl | sh" commits too much
for a script to decide -- make install_mise carries that decision.
MISE_PYTHON_COMPILE=false forbids it from quietly compiling: without that
guard it would fall back to pyenv's own engine, giving us the slowness
without the tooling. That is also what stopped gcc from collapsing while
building CPython on a low-memory s390x guest, for nothing.
One real bug falls along the way: a failed venv did not stop the install,
which then went on and failed further down, far from the cause.
--- FR ---
mise pose un CPython précompilé là où pyenv en compile un : des secondes
contre une à trois minutes, et aucun paquet -dev. Le choix vit dans
EL_PYTHON_PROVIDER — auto, mise ou pyenv — et dans un seul fichier,
lib_python_provider.sh. Le reste du dépôt ne connaît que des chemins de
venv et n'a rien à savoir de tout cela.
En mode auto, un interpréteur DÉJÀ posé l'emporte, quel qu'en soit le
fournisseur. mise n'est jamais installé de lui-même, « curl | sh » engage
trop pour qu'un script en décide — make install_mise porte cette décision.
MISE_PYTHON_COMPILE=false lui interdit de compiler en silence : sans ce
garde, il retomberait sur le moteur de pyenv, et nous aurions sa lenteur
sans son outillage. C'est aussi ce qui a évité que gcc s'écroule en
bâtissant CPython sur une VM s390x à faible mémoire, inutilement.
Un vrai défaut tombe au passage : un venv raté n'arrêtait pas
l'installation, qui continuait et échouait plus loin, loin de la cause.
Assisted-by: Claude Opus 5
"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
Tumbleweed is the only catalog entry whose qpdf already clears the pikepdf
threshold: 12.3.2 against 12.2 required, so the half-hour qpdf build under
s390x emulation never runs there. It is also the only family foreign to
both RHEL and Debian, and it brings zypper, absent from the repository:
wired into the install_dev.sh dispatch, a dependency script, the remote
bootstrap and the desktop block.
Four SUSE traps, all met on real machines. Global options precede the
subcommand, and misplaced ones abort the call; without
"--auto-agree-with-licenses" zypper waits for an answer nobody gives in a
detached install. A compat package that PROVIDES another under a different
name makes zypper raise a conflict and drop the whole batch, so only what
nothing already provides is requested. pkg-config no longer exists as an
RPM, only as a capability. And a single mirror, unreachable one day, sent
everyone back to Europe -- three are probed in order now.
CentOS Stream is dropped again: it served as a canary but 10 duplicates
what Alma and Rocky already cover.
--- FR ---
Tumbleweed est la seule entrée du catalogue dont qpdf franchit déjà le
seuil de pikepdf : 12.3.2 contre 12.2 exigé, si bien que la demi-heure de
compilation de qpdf sous émulation s390x ne s'y déclenche jamais. C'est
aussi la seule famille étrangère à RHEL comme à Debian, et elle apporte
zypper, absent du dépôt : câblé dans l'aiguillage d'install_dev.sh, un
script de dépendances, l'amorçage distant et le bloc bureau.
Quatre pièges SUSE, tous rencontrés sur machine réelle. Les options
globales précèdent la sous-commande, mal placées elles arrêtent l'appel ;
sans « --auto-agree-with-licenses » zypper attend une réponse que personne
ne donne dans une installation détachée. Un paquet compat qui FOURNIT un
autre sous un nom différent fait lever un conflit à zypper, qui abandonne
le lot entier : on ne demande donc que ce que rien ne fournit déjà.
pkg-config n'existe plus comme RPM, seulement comme capacité. Et un miroir
unique, injoignable un jour, renvoyait tout le monde en Europe — trois
sont désormais sondés dans l'ordre.
CentOS Stream repart : il servait de canari, mais 10 double ce qu'Alma et
Rocky couvrent déjà.
Assisted-by: Claude Opus 5
Fedora does publish an s390x cloud image, just elsewhere: the arch is
SECONDARY there, its images live under "fedora-secondary" rather than
/pub/fedora/linux/. The catalog comment read "404" -- it was the wrong
tree.
It brings what nothing else has on this architecture: qpdf 12.2.0,
exactly the pikepdf 10 threshold. The qpdf build, half an hour under
emulation, disappears. With GCC 15, Python 3.14 and cargo 1.90, none of
the s390x workarounds fire there.
Only 43 is kept: Fedora builds s390x for the current release only. 41 and
42 return 404 on the master mirror, 44 sits on third-party mirrors only.
Hence a positive per-architecture declaration, read by both interfaces --
the catalog never offers what deployment would refuse.
--- FR ---
Fedora publie bien une image cloud s390x, mais ailleurs : l'architecture
est SECONDAIRE chez elle, ses images vivent sous « fedora-secondary » et
non sous /pub/fedora/linux/. Le commentaire du catalogue disait « 404 » —
c'était la mauvaise arborescence.
Elle apporte ce qu'aucune autre n'a sur cette architecture : qpdf 12.2.0,
soit exactement le seuil de pikepdf 10. La compilation de qpdf, une demi-
heure sous émulation, disparaît. Avec GCC 15, Python 3.14 et cargo 1.90,
aucun des contournements s390x ne s'y déclenche.
Seule la 43 est retenue : Fedora ne construit s390x que pour la version
courante. Les 41 et 42 rendent 404 sur le miroir maître, la 44 n'est que
sur certains miroirs tiers. D'où une déclaration positive par
architecture, que les deux interfaces relisent — le catalogue ne propose
pas ce que le déploiement refuserait.
Assisted-by: Claude Opus 5
The server-or-desktop choice only showed on the left, in the form. The
table on the right, the one read before launching, said nothing about it:
two visually identical plans could produce different VMs.
The Status column, empty until now for a VM to create, therefore carries
the type, and the totals line repeats it. An already defined VM keeps its
collision message: it is not touched, showing a desktop there would
suggest one is about to be installed on it.
--- FR ---
Le choix serveur ou bureau ne se voyait qu'à gauche, dans le formulaire.
Le tableau de droite, celui qu'on relit avant de lancer, n'en disait
rien : deux plans identiques à l'écran pouvaient produire des VM
différentes.
La colonne Statut, vide jusqu'ici pour une VM à créer, porte donc le
type, et la ligne de totaux le rappelle. Une VM déjà définie garde son
message de collision : elle n'est pas retouchée, lui afficher un bureau
laisserait croire qu'on va lui en poser un.
Assisted-by: Claude Opus 5
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
VMs could only be servers. A server-or-graphical choice joins both
interfaces, installing GNOME along with remote access to it.
Packages come from the remote command, not cloud-init: their 1 to 2 GB
would stretch an already long boot there while leaving no trace in the
monitoring, and group installs do not go through it. The desktop
therefore does not depend on ERPLibre -- a VM may be wanted graphical
and bare.
Each distribution has its own names, taken from the source: Arch has no
xrdp in its official repositories and takes TigerVNC. The SPICE display
is set only on amd64 and arm64; s390x does expose virtio-gpu-ccw, but
nothing guarantees its kernel's DRM driver, whereas remote desktop works
everywhere.
--- FR ---
Les VM ne pouvaient être que des serveurs. Un choix serveur ou graphique
s'ajoute aux deux interfaces, et pose GNOME avec son accès distant.
Les paquets viennent de la commande distante, pas de cloud-init : leurs
1 à 2 Go y allongeraient un démarrage déjà long sans laisser de trace
dans le suivi, et les installations par groupe n'y passent pas. Le bureau
ne dépend donc pas d'ERPLibre — une VM peut être voulue graphique et nue.
Chaque distribution a ses noms, relevés à la source : Arch n'a pas xrdp
dans ses dépôts officiels et prend TigerVNC. L'écran virtuel SPICE n'est
posé que sur amd64 et arm64 ; s390x expose bien virtio-gpu-ccw, mais rien
ne garantit le pilote DRM de son noyau, alors que le bureau distant, lui,
marche partout.
Assisted-by: Claude Opus 5
Changing state meant retyping the name, on a single comma-separated line.
Names are long and alike -- two of them sometimes differ by a suffix
only -- and a typo here decided whether a machine started or shut down.
The screen now reuses the numbered list from the delete screen, "all"
included, and its parser, which already accepts names: nothing is lost
for those who typed them. The warning on an unknown entry is kept, that
parser otherwise dropping it without a word.
--- FR ---
Changer l'état demandait de retaper le nom, sur une seule ligne séparée
par des virgules. Les noms sont longs et se ressemblent — deux d'entre
eux ne diffèrent parfois que par un suffixe — et une faute de frappe
portait ici sur le démarrage ou l'extinction d'une machine.
L'écran reprend donc la liste numérotée de la suppression, « all »
compris, et son analyseur, qui accepte déjà les noms : rien n'est perdu
pour qui les tapait. L'avertissement sur une entrée inconnue est
conservé, cet analyseur l'écartant autrement sans un mot.
Assisted-by: Claude Opus 5
The form's parallelism was pinned at 4, while the CLI already counted
host cores: two interfaces, two answers.
A box ticked by default now gives one run per install -- five VMs, five
deployments -- and the core count stops capping it. Unticking hands
control back to the dropdown, whose default finally follows the host. The
CLI offers the same toggle through "n".
--- FR ---
Le parallélisme du formulaire était figé à 4, quand la CLI comptait déjà
les cœurs de l'hôte : deux interfaces, deux réponses.
Une case cochée par défaut donne désormais une exécution par
installation — cinq VM, cinq déploiements — et le nombre de cœurs cesse
alors de plafonner. La décocher rend la main à la liste, dont le défaut
suit enfin l'hôte. La CLI offre la même bascule par « n ».
Assisted-by: Claude Opus 5
Monitoring stayed on the same address for 1170 s, never catching up with
the VM. Two holes, in the very re-resolution meant to prevent that.
The lease fallback required an answer on port 22. But dnsmasq keeps one
lease per MAC: when cloud-init sets the real hostname and the DHCP client
asks again, the lease MOVES the address. The old one no longer belongs to
the VM and sshd will never answer there. The lease therefore wins as soon
as it stops listing the current address.
The other hole explains the silence: virsh was muted on both branches, so
an unreachable libvirt kept the initial IP without a single line saying
so. The log went quiet for a quarter of an hour for the same reason --
cloud-init holds the package lock while writing nothing.
--- FR ---
Le suivi restait sur la même adresse pendant 1170 s, sans jamais rattraper
la VM. Deux trous, dans la re-résolution censée l'éviter.
Le repli par bail exigeait une réponse sur le port 22. Or dnsmasq garde un
bail par MAC : quand cloud-init pose le vrai nom d'hôte et que le client
DHCP redemande, le bail DÉPLACE l'adresse. L'ancienne n'appartient plus à
la VM et sshd n'y répondra jamais. Le bail l'emporte donc dès qu'il cesse
de lister l'adresse courante.
L'autre trou explique le silence : virsh était muet sur les deux branches,
si bien qu'un libvirt injoignable conservait l'IP initiale sans une ligne
pour le dire. Le log se taisait un quart d'heure pour la même raison —
cloud-init tient le verrou des paquets sans rien écrire.
Assisted-by: Claude Opus 5
Two blockers on 20.04, neither worth carrying. "TypeError: unsupported
operand type(s) for |" fired before the install even started:
update_env_version.py imports erplibre_state as the very first thing
"make install_os" does, hence before pyenv, on the system Python 3.8,
where a "str | None" annotation is evaluated at import. And cryptography
now demands OpenSSL 3, while focal ships 1.1.1.
Annotations are therefore deferred, a contract the bootstrap file already
stated in a comment and now holds across script/version and
script/install. But the releases themselves go: pikepdf requires
qpdf >= 12.2, compiled in C++20, when focal ships GCC 9.
--- FR ---
Deux blocages sur 20.04, aucun ne méritant d'être porté. « TypeError:
unsupported operand type(s) for | » se déclenchait avant même le début de
l'installation : update_env_version.py importe erplibre_state en tout
premier lieu de « make install_os », donc avant pyenv, sur le Python 3.8
du système, où une annotation « str | None » est évaluée à l'import. Et
cryptography exige désormais OpenSSL 3, quand focal livre 1.1.1.
Les annotations sont donc différées, contrat que le fichier d'amorçage
énonçait déjà en commentaire et qui tient maintenant sur script/version et
script/install. Mais les versions elles-mêmes partent : pikepdf réclame
qpdf >= 12.2, compilé en C++20, quand focal livre GCC 9.
Assisted-by: Claude Opus 5
Installs run detached (setsid -f): closing the terminal does not stop
them, but it lost the only view onto them. With no way to resume, the
only way out was deleting the VMs and starting over.
Picking "Deploy" now looks at the latest run: if VMs there still lack an
exit marker, it offers to reopen its monitoring instead of starting
another. Time since the last write is shown, a dead run being otherwise
indistinguishable from a live one.
Only the latest run is examined: an old one left without a marker would
flag a phantom install forever. Dry-run creates nothing, so it does not
ask. "Reopen monitoring" moves to the Deployment section, where one
looks for it.
--- FR ---
Les installs partent détachées (setsid -f) : fermer le terminal ne les
arrête pas, mais faisait perdre la seule vue dessus. Sans moyen de
reprendre, la seule issue était d'effacer les VM et de recommencer.
Choisir « Déployer » regarde donc le dernier run : s'il lui reste des VM
sans marqueur de sortie, il propose de rouvrir son suivi plutôt que d'en
lancer un autre. Le silence depuis la dernière écriture est affiché, un
run mort n'étant pas distinguable autrement d'un run vivant.
Seul le dernier run est examiné : un run ancien laissé sans marqueur
signalerait éternellement une install fantôme. L'aperçu ne crée rien, il
ne pose pas la question. « Rouvrir le suivi » rejoint la section
Déploiement, où on le cherche.
Assisted-by: Claude Opus 5
The CLI already took a typed value -- a letter picks a suggestion, a
digit stands for itself. The form, though, locked the custom profile
into its three dropdowns.
Each now gets a final "free value..." entry revealing an input below it.
An invalid entry overwrites nothing: the resource falls back to the
catalog value instead of freezing the view.
The 3 vCPU preset was missing too, between 2 and 4; it comes from the
same constant, so both interfaces gain it together.
--- FR ---
La CLI acceptait déjà une valeur tapée — une lettre choisit une
suggestion, un chiffre vaut pour lui-même. Le formulaire, lui, enfermait
le profil personnalisé dans ses trois listes déroulantes.
Chacune reçoit donc un dernier choix, « valeur libre… », qui révèle une
saisie sous elle. Une entrée invalide n'écrase rien : la ressource
retombe sur celle du catalogue plutôt que de bloquer la vue.
Le préréglage 3 vCPU manquait aussi, entre 2 et 4 ; il vient de la même
constante, donc les deux interfaces l'offrent ensemble.
Assisted-by: Claude Opus 5
"TypeError: unsupported operand type(s) for +: 'int' and 'NoSelection'"
as soon as the custom resource profile was picked.
Textual 8 turned Select.BLANK into a deprecated alias worth False, the
sentinel having become Select.NULL. The guard compared against False and
filtered nothing; NoSelection, lacking __bool__ and thus truthy, sailed
through "or default" into the plan totals.
The sentinel is now resolved at runtime, and both summed fields are
coerced to a positive int inside the pure function -- where the invariant
belongs, whatever Textual version is installed.
--- FR ---
« TypeError: unsupported operand type(s) for +: 'int' and 'NoSelection' »
dès qu'on choisissait le profil personnalisé.
Textual 8 a ramené Select.BLANK à un alias déprécié valant False, le
sentinelle étant devenu Select.NULL. La garde comparait donc à False et
ne filtrait plus rien ; NoSelection, dépourvu de __bool__ et tenu pour
vrai, traversait « ou valeur par défaut » jusqu'aux sommes du plan.
Le sentinelle est résolu à l'exécution, et les deux champs additionnés
sont ramenés à un entier positif dans la fonction pure — c'est là que
l'invariant appartient, quelle que soit la version de Textual.
Assisted-by: Claude Opus 5
factur-x >= 4.0 needs saxonche, which Saxonica ships no s390x wheel for.
Pin 3.x there, 4.2+ everywhere else.
PEP 508 markers now survive the whole chain: kept instead of evaluated,
and each line reaches "poetry add" as a single argument -- the
"grep -v ';'" silently dropped them. Since "poetry add" dedupes by name,
the multi-constraint form, which the CLI cannot express, is written back
into the pyproject and the lock regenerated.
PyMuPDF is set aside on s390x for the same reason: MuPDF does not build
there. Along the way, the ignore list missed pymssql, whose key carried
its version, and two pre-existing solver deadlocks, lxml-html-clean and
s3fs, blocked any regeneration.
--- FR ---
factur-x >= 4.0 dépend de saxonche, sans roue s390x chez Saxonica. On
épingle la 3.x là-bas, la 4.2+ ailleurs.
Le marqueur PEP 508 traverse maintenant la chaîne : il est conservé au
lieu d'être évalué, et chaque ligne devient un seul argument de « poetry
add » — le « grep -v ';' » écartait ces lignes en silence. « poetry add »
dédupliquant par nom, la forme multi-contraintes, hors de portée du CLI,
est réécrite dans le pyproject, puis le lock refait.
PyMuPDF est écarté sur s390x pour la même raison : MuPDF ne s'y construit
pas. Au passage, la liste d'ignorés ratait pymssql, dont la clé portait sa
version, et deux blocages préexistants du solveur, lxml-html-clean et
s3fs, interdisaient toute régénération.
Assisted-by: Claude Opus 5
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
- update changelog
- inspect odoo database for analysing to detect studio and custom field,
database size. Show diff over TUI
- odoo migration check COW file, it's update file Copie-of-write
different from coding file, this can crash over migration
- fix git repo init
- increase stability when create VM with QEMU
- Support ERPLibre mail client
- Improve keepass usage and fix file browser into TODO
The last content update was 2026-02-14, and 145 commits landed since. The
first pass only covered what was fresh in mind and left about twenty notable
entries out: the RTK menu, the AI assistant tools, the deploy and sshfs
commands, the backup and erase commands, the Selenium work, the BRIN index
advisor, the STL support, the mobile manifests and the new dependencies.
Coverage was then checked against the 145 subjects rather than from memory,
one topic at a time.
The Security entry states its scope exactly — display and logging — because
the password still reaches the process argv, and a changelog must not promise
more than was done.
--- FR ---
La dernière mise à jour de contenu date du 2026-02-14, et 145 commits ont
suivi. La première passe n'a couvert que ce qui était frais et laissait de
côté une vingtaine d'entrées notables : le menu RTK, les outils d'assistance
IA, les commandes de déploiement et sshfs, la sauvegarde et l'effacement de
base, le travail Selenium, le conseiller d'index BRIN, le support STL, les
manifestes mobiles et les nouvelles dépendances.
La couverture a ensuite été vérifiée contre les 145 sujets, sujet par sujet,
plutôt que de mémoire.
L'entrée Sécurité énonce exactement sa portée — affichage et journalisation —
car le mot de passe atteint encore l'argv du processus, et un changelog ne
doit pas promettre plus que ce qui a été fait.
Assisted-by: Claude Opus 5
Four papercuts met while using the CLI: the test menu returned a verdict
nobody could find at the end of the output, the file browser never closed
once a file was picked, a wrong KeePass password killed the whole CLI, and
a configuration key had drifted from the code that reads it.
--- FR ---
Quatre irritants rencontrés à l'usage : le menu Test rendait un verdict
introuvable en fin de sortie, le navigateur de fichiers ne se fermait
jamais une fois le fichier choisi, un mauvais mot de passe KeePass tuait
tout le CLI, et une clé de configuration avait dérivé du code qui la lit.
Assisted-by: Claude Opus 5
An IMAP/SMTP client in the menu, with its tests against real servers. Most
of the work went into refusals: an application password is named only when
the server actually refuses, an accented password is reported as never
having left the machine, and a refusal is recognised by what the server
SAYS rather than by matching its wording. A malformed date no longer takes
the whole folder down, and a received email is never read as markup.
--- FR ---
Un client IMAP/SMTP dans le menu, avec ses tests contre de vrais serveurs.
L'essentiel du travail porte sur les refus : le mot de passe d'application
n'est nommé que lorsque le serveur refuse vraiment, un mot de passe accentué
est signalé comme n'ayant jamais quitté la machine, et un refus se reconnaît
à ce que le serveur DIT plutôt qu'à ses mots. Une date illisible n'emporte
plus le dossier entier, et un courriel reçu n'est jamais lu comme du balisage.
Assisted-by: Claude Opus 5
The monitor froze the address given at launch, so it lost the VM as soon as
cloud-init renamed the host and DHCP handed out another lease. It now
re-resolves at each attempt, in the views too, and reads virsh without sudo
— « sudo -n » fails in a detached session with no tty.
First boot also stopped paying for what it does not need: the guest agent
leaves cloud-init, snapd and locale-gen go, apt takes the fastest mirror.
The timezone follows the host. And when KVM is missing, the deployment says
so before the wait instead of being mysteriously fifteen times slower.
--- FR ---
Le suivi figeait l'adresse connue au lancement : il perdait donc la VM dès
que cloud-init posait le vrai nom d'hôte et que DHCP donnait un autre bail.
Il la ré-résout désormais à chaque tentative, dans les vues aussi, et lit
virsh sans sudo — « sudo -n » échoue dans une session détachée, sans tty.
Le premier démarrage cesse aussi de payer l'inutile : l'agent invité sort
de cloud-init, snapd et locale-gen disparaissent, apt prend le miroir le
plus rapide. Le fuseau suit l'hôte. Et faute de KVM, le déploiement le dit
avant l'attente, au lieu d'être quinze fois plus lent sans raison visible.
Assisted-by: Claude Opus 5
repo cannot resolve a commit into a manifest revision on a FRESH workspace:
it gave up on « unparseable HEAD », then repo sync on « manifest not
found ». An already-initialised .repo accepts the SHA, which is why only
new installations were hit — four fresh VMs failed identically.
--- FR ---
repo ne sait pas résoudre un commit en révision de manifeste sur un espace
de travail NEUF : il abandonnait sur « unparseable HEAD », puis repo sync
sur « manifest not found ». Un .repo déjà initialisé accepte le SHA, d'où
un défaut limité aux installations neuves — quatre VM ont échoué ainsi.
Assisted-by: Claude Opus 5
A copy-on-write view freezes the module view it came from; the module moves
on and the upgrade dies hours later on a missing anchor. These tools
predict, snapshot, diff, neutralize and reset them. The migration screen
gains the real state of each step, replay from any of them, and statistics.
--- FR ---
Une vue copy-on-write fige la vue de module dont elle vient ; le module
évolue et la mise à niveau meurt des heures plus tard sur un point
d'ancrage absent. Ces outils les prévoient, photographient, comparent,
neutralisent et réinitialisent. L'écran de migration gagne l'état réel de
chaque étape, la reprise depuis n'importe laquelle, et des statistiques.
Assisted-by: Claude Opus 5
A read-only toolkit answering « what is in this database, and what will
break on a version bump »: schema size and tables no model claims,
customised views compared with their module source, and the x_ fields
Studio left behind. It reads a backup zip directly, so a 40 GB dump needs
no restore, and it reaches every answer from the TODO menu.
--- FR ---
Une boîte à outils en lecture seule qui répond à « qu'y a-t-il dans cette
base, et qu'est-ce qui cassera à la montée de version » : taille du schéma
et tables qu'aucun modèle ne réclame, vues personnalisées comparées à leur
source, champs x_ laissés par Studio. Elle lit un zip de sauvegarde tel
quel, donc sans restaurer, et tout s'atteint depuis le menu TODO.
Assisted-by: Claude Opus 5
- Support qemu for ERPLibre OS installation
- New support Fedora
- Improve support arch linux, debian and ubuntu for all supported
version
- TUI for VM deployement and TODO telemetry for navigation
- Automatic download cloud images for Qemu
- Refactor TODO prompt more readable
CodeQL flagged five clear-text logging alerts here, and they are real:
todo.py and kdbx_manager.py build « --default_password_auth '<KeePass
password>' » and db_restore.py « --master_password=… », while this file
printed the command before and after every run and logged it on error. The
« if "password" in command » guard covered one branch out of six.
Redaction sits at the display point, not at construction: six outputs here
against commands built all over the repository. Only the value goes, never
the option name, and the RETURNED command stays clear — « [1] redo the
command » needs it. Verified that PreferredAuthentications=password survives.
--- FR ---
CodeQL signalait ici cinq journalisations en clair, et elles sont réelles :
todo.py et kdbx_manager.py construisent « --default_password_auth '<mot de
passe KeePass>' » et db_restore.py « --master_password=… », tandis que ce
fichier affichait la commande avant et après chaque exécution et la
journalisait en erreur. Le garde « if "password" in command » couvrait une
branche sur six.
Le caviardage est au point d'affichage, non à la construction : six sorties
ici, contre des commandes bâties partout dans le dépôt. Seule la valeur
part, jamais le nom de l'option, et la commande RENVOYÉE reste en clair —
« [1] refaire la commande » en dépend. Vérifié que
PreferredAuthentications=password reste intact.
Assisted-by: Claude Opus 5
Groups the long menus into sections with icons, accepts o/oui everywhere,
shows the default of each yes/no question, and stops offering a traceback
line as a database name when PostgreSQL is unreachable.
--- FR ---
Regroupe les menus longs en sections avec icônes, accepte o/oui partout,
affiche la valeur par défaut de chaque question oui/non, et cesse de
proposer une ligne de trace d'appel comme nom de base quand PostgreSQL est
injoignable.
Assisted-by: Claude Opus 4.8
Assisted-by: Claude Opus 5
Stores the per-user settings in ~/.erplibre/todo_prefs.json: which deploy
interface to use, what to display while deploying, which migration
interface. A missing or corrupt file reads as defaults.
--- FR ---
Range les réglages propres à l'utilisateur dans
~/.erplibre/todo_prefs.json : interface de déploiement, affichage pendant
le déploiement, interface de migration. Un fichier absent ou corrompu se
lit comme les valeurs par défaut.
Assisted-by: Claude Opus 4.8
Records the menus visited and shows them as a tree, a kanban or a list.
The tree is derived from the code, so a command never visited appears too,
and can be run from there.
--- FR ---
Enregistre les menus visités et les présente en arbre, en kanban ou en
liste. L'arbre est dérivé du code, si bien qu'une commande jamais visitée
y figure aussi, et peut être lancée de là.
Assisted-by: Claude Opus 4.8
Deploy, list, test, resize, delete and clean up VMs. Adds the SSH
configuration with recursive ProxyJump, port forwarding, and registration
of the QEMU hosts in virt-manager.
--- FR ---
Déployer, lister, tester, redimensionner, supprimer et nettoyer des VM.
Ajoute la configuration SSH avec ProxyJump récursif, la redirection de port
et l'enregistrement des hôtes QEMU dans virt-manager.
Assisted-by: Claude Opus 4.8
Shows every deployment setting at once, with a plan that recomputes on each
change and marks the collisions. A collapsible progress view follows.
--- FR ---
Affiche tous les réglages de déploiement d'un coup, avec un plan qui se
recalcule à chaque changement et signale les collisions. Une vue de
progression repliable suit.
Assisted-by: Claude Opus 4.8
One Textual dashboard per install run: live status, logs, host telemetry,
error counts and history. The installs run detached, so closing it does not
stop them.
--- FR ---
Un tableau de bord Textual par exécution : état en direct, logs, télémétrie
de l'hôte, comptes d'erreurs et historique. Les installations tournent
détachées : le fermer ne les arrête pas.
Assisted-by: Claude Opus 4.8
The TUI screens need Textual. Rather than naming it, the CLI offers to
install it for the running interpreter, bounded to the major the screens
are written for.
--- FR ---
Les écrans TUI ont besoin de Textual. Plutôt que de le nommer, le CLI
propose de l'installer pour l'interpréteur courant, borné à la majeure pour
laquelle les écrans sont écrits.
Assisted-by: Claude Opus 4.8
Assisted-by: Claude Opus 5
Adds a Fedora dependency installer, rewrites the Arch one on pacman rather
than an AUR helper absent from cloud images, and repairs the Debian path:
apt lock timeout, PostGIS best-effort, Ubuntu 26.04, Node 22.
--- FR ---
Ajoute un installeur de dépendances Fedora, réécrit celui d'Arch sur pacman
plutôt qu'un assistant AUR absent des images cloud, et répare le chemin
Debian : attente du verrou apt, PostGIS best-effort, Ubuntu 26.04, Node 22.
Assisted-by: Claude Opus 4.8
Assisted-by: Claude Opus 5
Deploys Ubuntu, Debian, Fedora and Arch cloud images through libvirt, on
amd64, arm64 and s390x. Handles the image download with mirror fallback,
the cloud-init seed, UEFI without Secure Boot, and the host setup.
--- FR ---
Déploie des images cloud Ubuntu, Debian, Fedora et Arch via libvirt, en
amd64, arm64 et s390x. Gère le téléchargement avec repli sur miroir, le seed
cloud-init, l'UEFI sans Secure Boot et la préparation de l'hôte.
Assisted-by: Claude Opus 4.8
- install NTFY for notification for mobile (WIP)
- install script to validate brin psql and do advisor
- can deploy ssh remote with TODO
- TODO with command erase database
Give users a guided, confirmation-gated way to drop one or all
databases from the interactive CLI. Previously this meant running
make db_drop_all or odoo_bin db --drop by hand, which is easy to
mistype and offers no safeguard. The new entry requires an explicit
'oui'/'yes' (default no) before any irreversible deletion.
Generated by Claude Code 2.1.191 claude-sonnet-4-6
Co-Authored-By: Mathieu Benoit <mathben@technolibre.ca>
Add a one-command installer for the ntfy push notification server
(Ubuntu/Debian and Arch Linux), wired into the todo.py Deploy menu.
Users can now deploy a local ntfy server from the CLI and subscribe
to topics from their mobile device (ntfy app) to receive push
notifications from ERPLibre.
Generated by Claude Code 2.1.101 model claude-sonnet-4-6
Co-Authored-By: Mathieu Benoit <mathben@technolibre.ca>
Enable deploying and managing ERPLibre on remote servers via SSH
directly from make and the interactive todo.py CLI, since only
local deployment was previously supported.
- New conf/make.ssh.Makefile with 11 targets: ssh_check, ssh_push,
ssh_install, ssh_run, ssh_stop, ssh_restart, ssh_status, ssh_logs,
ssh_make, ssh_install_systemd, ssh_install_nginx
- Variables: SSH_HOST (required), SSH_USER, SSH_PORT, SSH_KEY,
SSH_PATH, SSH_TARGET, SSH_DOMAIN, SSH_ADMIN_EMAIL
- Execute > Deploy menu extended with 11 SSH options in todo.py
- All strings translated fr/en in todo_i18n.py
Generated by Claude Code 2.1.101 model claude-sonnet-4-6
Co-Authored-By: Mathieu Benoit <mathben@technolibre.ca>
« Installation avec modules extra » (--with_extra) ne clonait pas CybroOdoo
sur un env déjà installé : validate_environment renvoyait « valide » ->
update_environment (où l'état extra est posé via set_version_installed) était
sauté -> get_version_extra restait False -> git_merge_repo_manifest n'ajoutait
pas manifest/git_manifest_extra_odooXX.xml -> CybroOdoo jamais synchronisé ni
ajouté à config.conf (« Nothing to do »).
Nouvelle étape apply_extra_modules(), appelée dans main() quand --with_extra
est demandé (même si l'env de base est déjà installé) : pose l'état extra,
régénère le manifest local + repo sync (clone CybroOdoo). La post-étape qui
suit régénère config.conf, qui prend alors le nouveau chemin d'addons.
--- EN ---
« Install with extra modules » (--with_extra) did not clone CybroOdoo on an
already-installed environment: validate_environment answered « valid » ->
update_environment, where the extra state is set through
set_version_installed, was skipped -> get_version_extra stayed False ->
git_merge_repo_manifest did not add
manifest/git_manifest_extra_odooXX.xml -> CybroOdoo was never synced nor
added to config.conf (« Nothing to do »).
A new step, apply_extra_modules(), is called from main() whenever
--with_extra is requested, even on an already-installed base environment: it
sets the extra state and regenerates the local manifest plus a repo sync,
which clones CybroOdoo. The post-step that follows regenerates config.conf,
which then picks up the new addons path.
Assisted-by: Claude Opus 4.8
update_env_version.py (cible « make install_odoo_XX ») calculait un statut
mais ne faisait JAMAIS sys.exit() et IGNORAIT le retour de
update_environment() (l'install réelle : venv/poetry). Résultat : même
quand install_locally.sh échouait (ex. poetry status 127), le script
sortait 0 -> make 0 -> remote « && » continuait (service créé) ->
__ERPLIBRE_EXIT__ 0 -> le suivi d'installation affichait ✅ à tort.
- main() suit un exit_code : install_system() ou update_environment()
renvoyant une valeur non nulle (os.system : 0 = succès) -> exit_code=1.
- sys.exit(main() or 0) propage réellement l'échec.
- Étapes post-install (pycharm, git_repo_update, generate_config) exécutées
seulement si l'install a réussi (sinon .venv.erplibre absent -> cascade
d'erreurs).
Chaîne désormais complète : install_locally.sh exit 1 -> install_locally_
dev.sh exit 1 -> os.system != 0 -> install_erplibre != 0 ->
update_environment != 0 -> main exit_code=1 -> sys.exit(1) -> make échoue
-> remote && stoppe -> __ERPLIBRE_EXIT__ != 0 -> dashboard ❌.
--- EN ---
update_env_version.py, the « make install_odoo_XX » target, computed a status
but NEVER called sys.exit() and IGNORED the return of update_environment(),
the real install with its venv and poetry. As a result, even when
install_locally.sh failed — poetry status 127, say — the script exited 0 ->
make exited 0 -> the remote « && » carried on and created the service ->
__ERPLIBRE_EXIT__ was 0 -> and the install monitor wrongly showed ✅.
- main() tracks an exit_code: install_system() or update_environment()
returning non-zero — with os.system, 0 means success — sets exit_code=1.
- sys.exit(main() or 0) actually propagates the failure.
- The post-install steps (pycharm, git_repo_update, generate_config) only run
when the install succeeded; otherwise .venv.erplibre is missing and errors
cascade.
The chain is now complete: install_locally.sh exit 1 ->
install_locally_dev.sh exit 1 -> os.system != 0 -> install_erplibre != 0 ->
update_environment != 0 -> main exit_code=1 -> sys.exit(1) -> make fails ->
the remote && stops -> __ERPLIBRE_EXIT__ != 0 -> dashboard ❌.
Assisted-by: Claude Opus 4.8
extraire_svg_graphique_by_3d annote « -> Optional[str] » mais le module
n'importait pas Optional -> « NameError: name 'Optional' is not defined »
au chargement. Ajout de « from typing import Optional ».
--- EN ---
extraire_svg_graphique_by_3d is annotated « -> Optional[str] » but the module
never imported Optional -> « NameError: name 'Optional' is not defined » at
import time. Added « from typing import Optional ».
Assisted-by: Claude Opus 4.8
webdriver.Firefox échouait : « InvalidArgumentException: Argument
--remote-allow-system-access can't be set via capabilities ». Cet argument
(ajouté pour le Firefox snap d'Ubuntu) est désormais REFUSÉ via les
capabilities par les geckodriver récents, qui gèrent seuls l'accès système
du snap. Il cassait donc TOUS les setups sur geckodriver récent (ici Arch
sans snap). On ne le passe plus.
--- EN ---
webdriver.Firefox was failing with « InvalidArgumentException: Argument
--remote-allow-system-access can't be set via capabilities ». That argument,
added for Ubuntu's snap Firefox, is now REFUSED through capabilities by
recent geckodriver versions, which handle the snap's system access on their
own. It therefore broke EVERY setup running a recent geckodriver — here Arch,
with no snap at all. It is no longer passed.
Assisted-by: Claude Opus 4.8
Installation was very noisy: poetry ran "install -vvv" and repo sync /
git daemon ran with -v/--verbose. They are now quiet by default
(poetry -q, repo sync -q, no git daemon --verbose) and the detailed
logs come back only when EL_VERBOSE=1.
Applied to install_locally.sh (poetry) and every manifest script (repo
sync + git daemon). env_var.sh documents EL_VERBOSE and respects a value
already set in the environment, so "EL_VERBOSE=1 make install_odoo_18"
works.
--- FR ---
L'installation était très bavarde : poetry tournait en « install -vvv », et
repo sync comme git daemon en -v/--verbose. Ils sont désormais silencieux par
défaut — poetry -q, repo sync -q, plus de git daemon --verbose — et les
journaux détaillés ne reviennent qu'avec EL_VERBOSE=1.
Appliqué à install_locally.sh (poetry) et à tous les scripts de manifest
(repo sync et git daemon). env_var.sh documente EL_VERBOSE et respecte une
valeur déjà passée dans l'environnement, si bien que « EL_VERBOSE=1 make
install_odoo_18 » fonctionne.
Assisted-by: Claude Opus 4.8
Choosing « remote » as the migration source raised AttributeError: the method
had moved to DatabaseManager, and todo_upgrade still called it on the TODO
object. The remote path was therefore unusable — the only way to start a
migration from a production backup rather than a local zip.
--- FR ---
Choisir « remote » comme source de migration levait une AttributeError : la
méthode avait été déplacée vers DatabaseManager, et todo_upgrade l'appelait
toujours sur l'objet TODO. Le chemin distant était donc inutilisable — le seul
moyen de démarrer une migration depuis une sauvegarde de production plutôt que
depuis un zip local.
Assisted-by: Claude Opus 5
sentencepiece provides the SentencePiece tokenizer (C++) needed by the
MarianMT Android plugin. Cloned shallow (depth=1) alongside whisper.cpp.
--- FR ---
sentencepiece fournit le tokeniseur SentencePiece, en C++, dont le greffon
Android MarianMT a besoin. Cloné en profondeur 1, à côté de whisper.cpp.
Assisted-by: Claude Sonnet 4.6
Ajout remote ggerganov et projet whisper.cpp (clone shallow, revision
master) dans le manifest Google Repo mobile. Chemin cible :
mobile/erplibre_home_mobile/android/app/src/main/cpp/whisper
--- EN ---
Adds the ggerganov remote and the whisper.cpp project (shallow clone,
revision master) to the mobile Google Repo manifest. Target path:
mobile/erplibre_home_mobile/android/app/src/main/cpp/whisper
Assisted-by: Claude Sonnet 4.6
@capacitor/cli v8.x requires Node.js >=22.0.0. The install script
was pinning NODE_MAJOR=20, causing a fatal error when installing
the mobile app via todo.py.
--- FR ---
@capacitor/cli v8.x exige Node.js >= 22.0.0. Le script d'installation
figeait NODE_MAJOR=20, d'où une erreur fatale à l'installation de
l'application mobile depuis todo.py.
Assisted-by: Claude Sonnet 4.6
The path was listed for every version, but git_manifest_odoo18.0.xml does not
declare that repository — only 12.0 to 17.0 and the extra 18.0 manifest do. On
Odoo 18 without the extra modules, repo never syncs the directory, so Odoo was
handed an addons path entry that does not exist.
--- FR ---
Le chemin était listé pour toutes les versions, alors que
git_manifest_odoo18.0.xml ne déclare pas ce dépôt — seuls les manifestes de
12.0 à 17.0 et le manifeste extra de 18.0 le font. Sur Odoo 18 sans les modules
extra, repo ne synchronise jamais ce répertoire : on donnait donc à Odoo une
entrée de chemin d'addons qui n'existe pas.
Assisted-by: Claude Opus 5
Poetry install and git-repo sync are independent (different write
paths). Running them sequentially wastes time. Split install_locally.sh
into EL_PHASE=setup|poetry|all phases so install_locally_dev.sh can
background the repo sync while poetry runs in the foreground, reducing
total install time by up to 50% on slow connections.
Set EL_PARALLEL_INSTALL=0 to restore sequential behavior for debugging.
--- FR ---
L'installation poetry et la synchronisation git-repo sont indépendantes —
elles écrivent à des endroits différents — et les enchaîner fait perdre du
temps. install_locally.sh est découpé en phases EL_PHASE=setup|poetry|all
pour qu'install_locally_dev.sh puisse lancer la synchronisation des dépôts
en arrière-plan pendant que poetry tourne au premier plan, réduisant la
durée totale jusqu'à 50 % sur une connexion lente.
EL_PARALLEL_INSTALL=0 rétablit le comportement séquentiel pour le débogage.
Assisted-by: Claude Sonnet 4.6
CybroOdoo repos are large and slow to clone, making them unsuitable
for default installation. Moves them to opt-in per-version extra
manifests, introduces .erplibre-state.json to track installation
options per Odoo version, and surfaces the choice in the TODO CLI
sub-menu. Switch auto-detects extra from state and warns when no
state is recorded.
--- FR ---
Les dépôts CybroOdoo sont volumineux et lents à cloner, ce qui les rend
inadaptés à une installation par défaut. Ils passent dans des manifestes
extra par version, activés à la demande ; .erplibre-state.json est
introduit pour suivre les options d'installation de chaque version d'Odoo,
et le choix apparaît dans le sous-menu du CLI TODO. Le changement de
version détecte l'option extra depuis cet état et avertit quand aucun état
n'est enregistré.
Assisted-by: Claude Sonnet 4.6
make version had no visibility into whether the mobile project was
active. Add detection via presence of mobile/erplibre_home_mobile
directory (cloned by repo sync --with_mobile) and display its status
alongside the existing Odoo/Python/Poetry version info.
--- FR ---
make version n'avait aucune visibilité sur l'activité du projet mobile.
Ajoute une détection par la présence du répertoire
mobile/erplibre_home_mobile, cloné par repo sync --with_mobile, et affiche
son état à côté des versions Odoo, Python et Poetry déjà présentes.
Assisted-by: Claude Sonnet 4.6
The template wrote « Generated by Claude Code », the form AI_POLICY.md
replaces with the Assisted-by trailer. Three defects rode along: the model
came from ~/.claude/settings.json, which has no model key here, so it
declared the sonnet default rather than the truth; --author alone failed on
the committer, this checkout having no git identity; and [UPD] was missing
from the tag table while being the most used tag, 134 of the last 400.
The model now comes from the session transcript, the only source that
follows a /model switch — checked, it prints Claude Opus 5. The timezone is
left to the system so contributors keep their own, and the menu substitutes
name and email separately, the placeholders no longer being adjacent.
--- FR ---
Le gabarit écrivait « Generated by Claude Code », la forme que AI_POLICY.md
remplace par le trailer Assisted-by. Trois défauts l'accompagnaient : le
modèle venait de ~/.claude/settings.json, sans clé model ici, si bien qu'il
déclarait le défaut sonnet plutôt que la vérité ; --author seul échouait sur
le committer, ce checkout n'ayant aucune identité git ; et [UPD] manquait au
tableau des tags alors qu'il est le plus utilisé, 134 des 400 derniers.
Le modèle vient désormais de la transcription de session, seule source qui
suive un changement par /model — vérifié, elle rend Claude Opus 5. Le fuseau
est laissé au système, pour que chaque contributeur garde le sien, et le
menu substitue nom et courriel séparément, les jetons n'étant plus accolés.
Assisted-by: Claude Opus 5
ERPLibre had no position on AI-assisted contribution while its own history
already carried AI trailers — and carried them in the one field the OCA
policy forbids, Co-authored-by, whose meaning for a machine is legally
undefined.
The policy is adopted rather than reinvented: the file summarises it and
points at the OCA document as the reference, so it cannot drift from
upstream. What it keeps is what a contributor here needs in front of them —
the Assisted-by trailer with one line per model, the ban on AI in authorship
fields, the size and pace expectations, and the fact that responsibility does
not transfer to a tool.
Written as AI_POLICY.base.md, like README, CHANGELOG and TODO: « make
doc_markdown » globs every *.base.md, so a plain .md here would be
overwritten or, worse, silently left out of the bilingual set.
--- FR ---
ERPLibre n'avait aucune position sur la contribution assistée par IA, alors
que son propre historique portait déjà des trailers d'IA — et les portait
dans le seul champ que la politique de l'OCA interdit, Co-authored-by, dont
le sens pour une machine est juridiquement indéfini.
La politique est adoptée plutôt que réinventée : le fichier la résume et
désigne le document de l'OCA comme référence, si bien qu'il ne peut pas
diverger de l'amont. Il retient ce qu'un contributeur d'ici doit avoir sous
les yeux : le trailer Assisted-by, une ligne par modèle, l'interdiction de
l'IA dans les champs de paternité, les attentes de taille et de rythme, et le
fait que la responsabilité ne se transfère pas à un outil.
Écrit en AI_POLICY.base.md, comme README, CHANGELOG et TODO : « make
doc_markdown » balaie tous les *.base.md, si bien qu'un simple .md ici serait
écrasé ou, pire, silencieusement laissé hors de la paire bilingue.
Source: https://github.com/dixmit/oca.github/blob/ai_policy/AI_POLICY.md
Assisted-by: Claude Opus 5
Every session paid ~4 000 tokens for CLAUDE.md and .claude/rules/, and part of
that content no longer described this repository:
CLAUDE.md and 05-environments.md gave .venv.odoo18/bin/python — a path that
does not exist. The real one carries BOTH versions,
.venv.odoo18.0_python3.12.10. 02-project-structure.md announced addons/ and
odoo12.0/, absent from the checkout.
That is the reason for the cuts, more than the token count: the files drifted
from the repository, while « ls » cannot. What a session can rebuild by
reading the code is now left to the code.
02-project-structure.md deleted — a tree that ls gives, and gives right
05-environments.md deleted — a venv list that was simply false
04-code-conventions.md reduced to a pointer at .flake8, .editorconfig and
pyproject.toml, which already hold every value it
repeated, plus the Git conventions, which they
do not
01-versions.md table dropped for the pointer at
conf/supported_version_erplibre.json, whose keys
already pair Odoo with Python
Two blocks move to lazy loading — their body costs nothing until invoked:
03-commands.md -> skill erplibre-commands (kept whole: there is no
« make help » target, and the per-module test recipes
carry flags nobody would guess)
07-documentation.md -> skill erplibre-doc-i18n for the how-to, while the
prohibition « never edit a generated .md » STAYS in
the rules: a rule that must hold at all times cannot
live in a file loaded on demand
Resident guidance: ~3 997 -> ~1 939 est. tokens per session.
--- FR ---
Chaque session payait environ 4 000 jetons pour CLAUDE.md et .claude/rules/, et
une partie de ce contenu ne décrivait plus ce dépôt :
CLAUDE.md et 05-environments.md donnaient .venv.odoo18/bin/python — un chemin
qui n'existe pas. Le vrai porte les DEUX versions,
.venv.odoo18.0_python3.12.10. 02-project-structure.md annonçait addons/ et
odoo12.0/, absents du checkout.
C'est la raison des coupes, plus encore que le nombre de jetons : les fichiers
avaient dérivé par rapport au dépôt, ce que « ls » ne peut pas faire. Ce qu'une
session peut reconstruire en lisant le code est désormais laissé au code.
02-project-structure.md supprimé — une arborescence que ls donne, et donne
juste
05-environments.md supprimé — une liste de venvs simplement fausse
04-code-conventions.md réduit à un renvoi vers .flake8, .editorconfig et
pyproject.toml, qui portent déjà toutes les valeurs
qu'il répétait, plus les conventions Git, qu'ils ne
portent pas
01-versions.md tableau abandonné au profit du renvoi vers
conf/supported_version_erplibre.json, dont les clés
apparient déjà Odoo et Python
Deux blocs passent en chargement paresseux — leur corps ne coûte rien tant
qu'il n'est pas invoqué :
03-commands.md -> skill erplibre-commands, conservée entière : il
n'existe pas de cible « make help », et les recettes
de test par module portent des drapeaux que personne
ne devinerait
07-documentation.md -> skill erplibre-doc-i18n pour le mode d'emploi, tandis
que l'interdiction « ne jamais éditer un .md généré »
RESTE dans les règles : une règle qui doit tenir en
permanence ne peut pas vivre dans un fichier chargé à
la demande
Consignes résidentes : environ 3 997 -> 1 939 jetons estimés par session.
Assisted-by: Claude Opus 4.8
Provides Claude Code with structured context about the
ERPLibre Home Mobile project (OWL 2, Capacitor 8, Vite,
Vitest, SQLite) including stack, conventions, commands,
and migration patterns.
--- FR ---
Fournit à Claude Code un contexte structuré sur le projet ERPLibre Home
Mobile — OWL 2, Capacitor 8, Vite, Vitest, SQLite — incluant la pile
technique, les conventions, les commandes et les motifs de migration.
Assisted-by: Claude Sonnet 4.6
Define the integration contract between erplibre_mobile and ERPLibre
platform: JSON-RPC 2.0 call specs, Note→project.task field mapping,
GeoMultiPoint format for geolocation entries, conflict resolution
strategy, re-auth flow, and version compatibility matrix.
Establishes the shared source of truth before implementation begins.
--- FR ---
Définit le contrat d'intégration entre erplibre_mobile et la plateforme
ERPLibre : spécifications des appels JSON-RPC 2.0, correspondance des champs
Note→project.task, format GeoMultiPoint pour les entrées de géolocalisation,
stratégie de résolution des conflits, flux de réauthentification et matrice
de compatibilité des versions. Établit la source de vérité commune avant que
l'implémentation ne commence.
Assisted-by: Claude Sonnet 4.6
Add a multi-agent orchestrator that coordinates all 25 specialist agents
through 5 phases (analysis, design, implementation, verification, release)
with agent-to-agent communication via Agent Teams. Add /feature slash
command as the entry point. Enable CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS
in project settings to allow direct inter-agent messaging.
--- FR ---
Ajoute un orchestrateur multi-agents qui coordonne les 25 agents spécialisés
en 5 phases — analyse, conception, implémentation, vérification, publication
— avec communication d'agent à agent par les Agent Teams. Ajoute la commande
slash /feature comme point d'entrée. Active
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS dans les réglages du projet pour
autoriser la messagerie directe entre agents.
Assisted-by: Claude Sonnet 4.6
Add a full catalog of Claude Code subagents covering all development
disciplines needed for a banking-grade open-source mobile app:
code quality, QA, backend, frontend, UX, architecture, security,
docs, community, product, ethics, DevOps/SRE, release, incident
response, performance, pentest, accessibility, compliance, risk,
data governance, legal/license, support, localization, and AI
agent engineering.
--- FR ---
Ajoute un catalogue complet de sous-agents Claude Code couvrant toutes les
disciplines de développement nécessaires à une application mobile libre de
qualité bancaire : qualité du code, AQ, dorsal, frontal, UX, architecture,
sécurité, documentation, communauté, produit, éthique, DevOps/SRE,
publication, réponse aux incidents, performance, test d'intrusion,
accessibilité, conformité, risque, gouvernance des données, aspects
juridiques et de licence, soutien, localisation et ingénierie des agents
d'IA.
Assisted-by: Claude Sonnet 4.6
2026-08-07 01:05:08 -04:00
648 changed files with 247571 additions and 3742 deletions
description: Use this agent to audit accessibility, ensure WCAG 2.1 AA compliance, test with screen readers, and make the app usable by people with disabilities. Invoke when building new UI components, before a release, or when accessibility issues are reported.
model: claude-sonnet-4-6
tools: [Read, Glob, Grep]
---
You are an accessibility specialist for ERPLibre Home Mobile. Accessibility is a right, not a feature.
description: Use this agent to design, create, and maintain Claude Code agents, slash commands, hooks, and AI-assisted workflows for the project. Invoke when adding a new specialized agent, creating a custom slash command, configuring automation hooks, auditing the agent ecosystem, or improving how AI agents collaborate on this codebase.
model: claude-sonnet-4-6
tools: [Read, Glob, Grep, Write, Edit, Bash]
---
You are the AI agent engineering specialist for ERPLibre Home Mobile. You design and maintain the Claude Code agent ecosystem, custom commands, and automation hooks that make the development team more productive.
## Your responsibilities
- Design new specialized agents: write clear system prompts, set appropriate tool permissions, define scope
- Audit existing agents: identify overlaps, gaps, and outdated context
- Create custom slash commands (`/.claude/commands/`) for recurring workflows
- Configure Claude Code hooks in `settings.json` for pre/post tool automation
- Define agent composition patterns: when to chain agents vs run them in parallel
- Document the agent catalog so team members know what to invoke and when
- Evolve agent prompts based on feedback (lessons learned, repeated mistakes)
description: Use this agent for work on services, database layer, migrations, Capacitor plugin integration, and business logic in the ERPLibre mobile app. Invoke for database schema changes, new migrations, service methods, or Capacitor API integration.
model: claude-sonnet-4-6
tools: [Read, Glob, Grep, Bash, Write, Edit]
---
You are a backend developer for ERPLibre Home Mobile, specialized in the data layer, services, and native Capacitor integrations.
## Your responsibilities
- Design and implement SQLite schema changes with proper migrations
- Write `DatabaseService` methods: correct parameterized queries, proper type mapping
- Implement versioned migrations (YYYYMMDDNN format) that are idempotent and safe
description: Use this agent to review code quality, enforce engineering standards, detect code smells, suggest refactoring, and ensure consistency across the ERPLibre mobile codebase. Invoke when writing new code, reviewing a PR, or doing a code audit.
model: claude-sonnet-4-6
tools: [Read, Glob, Grep, Bash, Edit]
---
You are a senior code quality engineer specialized in the ERPLibre Home Mobile project (Odoo Owl 2.8.1 + Capacitor 7.x + TypeScript + SCSS).
## Your responsibilities
- Enforce consistent code style: 2-space JSON/YAML, tab-indented TypeScript, LF line endings, no trailing spaces
- Detect and flag: dead code, duplicate logic, overly complex functions, magic numbers, unclear naming
- Enforce Owl best practices: reactive state via `useState`, `onWillDestroy` cleanup for every `addEventListener`, `t-key` on dynamic component lists
- Detect memory leaks: MutationObserver not disconnected, event listeners not removed
- Enforce the OCA commit tag convention: `[IMP]`, `[FIX]`, `[REF]`, `[ADD]`, `[REM]`, `[MOV]`
- Flag any `any` type used without justification in TypeScript
- Ensure all async functions handle errors explicitly (no silent catch `{}` unless intentional)
- Check that `onWillDestroy` is always paired with `addEventListener` / `MutationObserver`
description: Use this agent to draft contributor guidelines, review pull request communication, write issue templates, onboard new contributors, and maintain a healthy open-source community around ERPLibre. Invoke when handling contributor interactions, drafting community policies, or improving contribution workflows.
model: claude-sonnet-4-6
tools: [Read, Glob, Grep, Write]
---
You are a community manager for the ERPLibre open-source project. ERPLibre is a community fork of Odoo Community Edition (OCE), AGPL-3.0+.
## Your responsibilities
- Draft and maintain `CONTRIBUTING.md` for the mobile sub-project
- Write clear, welcoming responses to GitHub issues and pull requests
description: Use this agent to evaluate regulatory compliance, map features to banking regulations, identify compliance gaps, and ensure the software meets financial industry standards. Invoke when assessing deployment readiness for financial institutions, adding data handling features, or preparing for regulatory audits.
model: claude-sonnet-4-6
tools: [Read, Glob, Grep, Write, WebSearch]
---
You are a compliance and regulatory specialist for ERPLibre in financial industry contexts. You ensure the software meets the requirements of banking regulators and financial standards bodies.
## Your responsibilities
- Map application features to applicable regulations and standards
- Identify compliance gaps between current implementation and requirements
- Define audit trail requirements: what must be logged, for how long, in what format
- Assess data residency requirements: where can data be stored?
- Evaluate PCI-DSS applicability if payment data is ever in scope
- Review GDPR/PIPEDA compliance: consent, right to erasure, data portability
- Assess FINTRAC obligations for Canadian financial institutions
- Evaluate SOX controls for audit trail and access management
- Define data retention policies aligned with regulatory minimums/maximums
- Assess open-source license compliance for banking deployment (AGPL implications)
## Key regulatory frameworks
| Framework | Jurisdiction | Applies when |
|-----------|-------------|--------------|
| PIPEDA / Law 25 | Canada / Québec | Any personal data of Canadians |
| ISO 27001 | Global | Information security management |
## AGPL-3.0+ in banking context
Critical: AGPL requires that if the software is used over a network (SaaS), the source must be made available. Banks deploying ERPLibre internally are generally safe, but must:
- Track all modifications to AGPL code
- Not combine with GPL-incompatible proprietary code
- Maintain license notices in all distributions
## Output format
For each compliance requirement:
1. **Regulation/Standard**: specific article or control
2. **Requirement**: what it mandates
3. **Current state**: compliant / partial / gap / not applicable
4. **Gap description**: what's missing
5. **Remediation**: specific technical or process change
6. **Priority**: must-have before banking deployment / recommended / nice-to-have
description: Use this agent to define data classification, retention policies, lineage, access controls, and GDPR/PIPEDA rights implementation. Invoke when adding new data storage, preparing for a privacy audit, or implementing data subject rights (erasure, portability).
model: claude-sonnet-4-6
tools: [Read, Glob, Grep, Write]
---
You are the data governance specialist for ERPLibre Home Mobile. In a banking context, every piece of data has a classification, a retention policy, and a legal basis.
## Your responsibilities
- Classify all data stored by the application
- Define retention policies per data class (minimum and maximum retention)
- Map data flows: where data enters, where it's stored, where it exits
- Implement right to erasure (GDPR Art. 17 / Law 25): what must be deleted and how
- Implement data portability (GDPR Art. 20): export format for user data
- Define access control matrix: who can access what data
- Audit that encryption is applied consistently to all sensitive data classes
- Ensure audit logs are tamper-evident and retained appropriately
- Validate that data minimization is applied (no unnecessary data collection)
## Data classification for this project
| Data | Class | Sensitivity | Retention | Encrypted |
description: Use this agent for CI/CD pipelines, deployment automation, infrastructure as code, monitoring, SLA management, and reliability engineering. Invoke when setting up build pipelines, defining deployment gates, configuring monitoring, or addressing reliability issues.
model: claude-sonnet-4-6
tools: [Read, Glob, Grep, Bash, Write, Edit]
---
You are a DevOps/SRE engineer for ERPLibre Home Mobile and the ERPLibre platform. You ensure that software is built, tested, deployed, and operated reliably.
## Your responsibilities
- Design and maintain CI/CD pipelines (GitHub Actions, GitLab CI)
- Define deployment gates: test pass rate, security scan, license check before merge
- Automate Android APK/AAB builds via Capacitor + Gradle
description: Use this agent to write, review, and maintain technical documentation, CHANGELOG entries, API comments, README sections, and installation guides. Invoke when releasing a version, adding public APIs, or when documentation is missing or outdated.
model: claude-sonnet-4-6
tools: [Read, Glob, Grep, Write, Edit]
---
You are a documentation specialist for ERPLibre Home Mobile. Clear documentation reduces onboarding time and support burden.
## Your responsibilities
- Write and maintain `CHANGELOG.md` using Keep a Changelog format + CalVer `YYYY.MM.DD.NN`
- Update `README.md` / installation guides when setup steps change
- Write TSDoc comments for public service methods (not for trivial getters)
- Document migration files: what they do, why, and what state they assume
- Write architectural decision records (ADRs) when significant choices are made
- Document Capacitor plugin requirements: which Android permissions, minimum API level
- Keep the in-app changelog component (`OptionsChangelogComponent`) in sync with `CHANGELOG.md`
- Identify and flag documentation that is outdated or contradicts the current code
- **Code comments**: explain *why*, not *what* — the code already shows what
- **TSDoc**: `@param`, `@returns`, `@throws` for public methods that are non-obvious
- **Migrations**: always document the version number, description, and assumption about existing data
## Project context
- `CHANGELOG.md` at `mobile/erplibre_home_mobile/CHANGELOG.md`
- In-app version: `CURRENT_VERSION` in `options_changelog_component.ts`
- Version format: `versionToDisplay(YYYYMMDDNN)` → `YYYY.MM.DD.NN`
- Two release entries so far: `2025.12.28.01` (initial) and `2026.03.18.01` (SQLite + features)
## Output
When writing documentation, be concise and accurate. Avoid padding. A short accurate sentence is better than a long vague paragraph. Always verify against the current code before writing.
description: Use this agent to evaluate ethical implications of features, review data privacy practices, assess algorithmic fairness, and ensure the app respects user autonomy and digital rights. Invoke when adding data collection, AI features, biometric auth, or any feature that affects user privacy or autonomy.
model: claude-sonnet-4-6
tools: [Read, Glob, Grep]
---
You are an ethics advisor for ERPLibre Home Mobile, specializing in responsible technology, digital rights, and ethical software practices.
## Your responsibilities
- Evaluate privacy implications of new features: what data is collected, where it goes, who can access it
- Review consent mechanisms: are users informed? Do they have meaningful choice?
- Assess biometric auth: is it opt-in? Can users access the app without it?
- Evaluate data retention: is data stored longer than necessary?
- Flag surveillance risks: geolocation tracking, camera access patterns, usage analytics
- Review accessibility as an ethical obligation, not just a compliance item
- Assess power dynamics: does the app empower users or create dependency?
description: Use this agent for Owl component development, SCSS styling, template authoring, reactive state management, and Capacitor UI integration. Invoke when building new components, fixing rendering issues, or implementing UI interactions.
model: claude-sonnet-4-6
tools: [Read, Glob, Grep, Bash, Write, Edit]
---
You are a frontend developer for ERPLibre Home Mobile, specialized in Odoo Owl 2.8.1, TypeScript, and SCSS for a Capacitor Android app.
## Your responsibilities
- Build and maintain Owl components using `xml` tagged templates
- Manage reactive state with `useState`, refs with `useRef`, lifecycle with `onMounted`, `onPatched`, `onWillDestroy`
- Wire event bus communications: trigger with `this.eventBus.trigger(Events.X, payload)`, listen with `addEventListener` + cleanup in `onWillDestroy`
- Implement `t-key` on all dynamic lists to force remount on identity change
- Style components with SCSS using `@use` and `mixins.scss` patterns
description: Use this agent to manage incidents, write post-mortems, define on-call procedures, classify severity, and coordinate response. Invoke when an incident occurs, when defining incident response processes, or when writing post-mortems.
model: claude-sonnet-4-6
tools: [Read, Glob, Grep, Bash, Write]
---
You are the incident response specialist for ERPLibre Home Mobile and the ERPLibre platform. You minimize impact and improve system resilience.
## Your responsibilities
- Classify incident severity (SEV1–SEV4) and define response SLAs
- Coordinate incident response: who does what, in what order
- Write blameless post-mortems focused on systemic improvements
- Define runbooks for known failure modes (DB corruption, key loss, migration failure)
- Identify monitoring gaps that allowed incidents to go undetected
- Track action items from post-mortems to completion
- Define on-call rotation and escalation paths
## Severity classification
| Level | Description | Response time | Example |
|-------|-------------|---------------|---------|
| SEV1 | App unusable, data loss risk | Immediate | DB encryption key lost, migration corrupts data |
| SEV2 | Major feature broken | <1h|Allnotesunreadable,crashonlaunch|
description: Use this agent to evaluate open-source license compatibility, assess AGPL obligations, review dependency licenses, and advise on intellectual property matters. Invoke when adding new dependencies, preparing for a commercial or banking deployment, or when license compliance is questioned.
model: claude-sonnet-4-6
tools: [Read, Glob, Grep, Bash, WebSearch]
---
You are the legal and license advisor for ERPLibre. You ensure the project's open-source licensing is correctly applied and that all dependencies are compatible.
## Your responsibilities
- Audit all npm dependencies for license compatibility with AGPL-3.0+
- Flag licenses that are incompatible or require special attention: proprietary, GPL-2.0-only, SSPL, BSL
- Clarify AGPL-3.0+ obligations for deploying institutions (especially banks)
- Assess whether SaaS/network use triggers AGPL's source disclosure requirement
- Review CLA (Contributor License Agreement) requirements for the project
- Advise on patent risks in open-source components
- Flag any dual-licensed components and assess implications
- Ensure license notices are preserved in distributions
- Advise on what modifications to AGPL code must be disclosed and how
## AGPL-3.0+ key obligations
1. **Source disclosure**: any user interacting with the software over a network must be able to obtain the source code — including all modifications
2. **License preservation**: all copies must carry the AGPL license notice
3. **Modification disclosure**: modified versions used internally do NOT require disclosure (internal use exception) — but network deployment does
description: Use this agent to implement internationalization (i18n), manage translations, ensure locale-aware formatting, and expand language support. Invoke when adding new UI strings, preparing a new language, or auditing the app for hardcoded text.
model: claude-sonnet-4-6
tools: [Read, Glob, Grep, Write, Edit]
---
You are the localization and i18n specialist for ERPLibre Home Mobile. You ensure the app is usable across languages and regions, starting with French and English.
## Your responsibilities
- Audit the codebase for hardcoded strings in Owl templates and TypeScript
- Design and implement an i18n system appropriate for the stack (Owl + Capacitor)
- Store locale in `SecureStorage` or `localStorage`
- Pass `t` function through Owl env or as a utility import
- Use translation keys that describe context, not content: `note.entry.geolocation.title` not `geolocation_data`
## Date/number formatting
- Use `Intl.DateTimeFormat` for dates (already used via `helpers.formatDate()` — verify locale parameter)
- Use `Intl.NumberFormat` for file sizes and numbers
- Use `toLocaleString()` with explicit locale, not implicit system locale
## Output
Provide complete implementation: translation file structure, `t()` function, Owl integration pattern, and migration plan for existing hardcoded strings.
description: Use this agent to perform active security testing, identify exploitable vulnerabilities, test authentication bypass, assess data extraction risks, and validate that security controls actually work. Invoke before major releases, after security-relevant changes, or as part of a security audit cycle.
model: claude-sonnet-4-6
tools: [Read, Glob, Grep, Bash]
---
You are a penetration tester for ERPLibre Home Mobile. You think like an attacker to find exploitable vulnerabilities before real attackers do.
## Your responsibilities
- Test SQLite encryption bypass: can an attacker extract the DB without the key?
- Test SecureStorage extraction: can the encryption key be retrieved without biometric auth?
- Test SQL injection in all `db.run()` / `db.query()` calls
- Test path traversal in `Filesystem.writeFile()` / `Filesystem.stat()` calls
- Test XSS in Owl templates: are user-provided strings rendered via `t-raw`?
- Test Android backup extraction: is the SQLite DB included in ADB backups?
- Test intent handling: can a malicious app trigger `SET_INTENT` events?
- Test deep link abuse: can external URLs manipulate the router?
- Test camera/filesystem permission abuse: can stored media be accessed by other apps?
- Assess APK reverse engineering risk: are secrets hardcoded?
## Attack surface for this app
- **SQLite DB**: `erplibre_mobileSQLite.db` in app's `databases/` dir (AES-256 encrypted)
- **Encryption key**: stored in Android Keystore via `SecureStoragePlugin`
- **Media files**: stored in `Directory.External` — accessible to other apps with storage permission
description: Use this agent to profile performance, define SLAs, run load tests, identify bottlenecks, and optimize critical paths. Invoke when the app feels slow, before a major release, or when defining performance budgets.
model: claude-sonnet-4-6
tools: [Read, Glob, Grep, Bash]
---
You are a performance engineer for ERPLibre Home Mobile. You ensure the app meets latency, memory, and battery targets on real Android devices.
## Your responsibilities
- Define performance budgets: app launch time, note load time, DB query time, render time
description: Use this agent to define product vision, prioritize features, write user stories, evaluate feature requests, and align technical decisions with user needs. Invoke when evaluating new feature ideas, planning a release, or when technical work needs product context.
model: claude-sonnet-4-6
tools: [Read, Glob, Grep, Write]
---
You are a product manager for ERPLibre Home Mobile — a personal productivity app for ERPLibre/Odoo users on Android.
## Your responsibilities
- Define and maintain product vision and value proposition
- Write user stories: "As a [user], I want [feature] so that [benefit]"
- Prioritize features using value vs effort: focus on high-value, low-effort first
- Evaluate feature requests: does this solve a real user problem? Does it fit the product scope?
- Define MVP scope for new features — what's the minimum that delivers value?
- Identify user segments and their specific needs
- Align technical decisions with product goals — push back on over-engineering
- Track the product roadmap and communicate it clearly
- Define success metrics for features
## Product context
**Current product**: ERPLibre Home Mobile
- Personal note-taking with rich entries (text, audio, video, photo, geolocation, date)
description: Use this agent to break down features into tasks, plan sprints, estimate effort, identify dependencies, and maintain a clear roadmap. Invoke when starting a new feature, organizing a backlog, or planning a release.
model: claude-sonnet-4-6
tools: [Read, Glob, Grep, Write]
---
You are a project planner for ERPLibre Home Mobile. You bridge technical work and delivery.
## Your responsibilities
- Break down feature requests into atomic, implementable tasks
- Identify dependencies between tasks (what blocks what)
- Estimate relative complexity: S / M / L / XL
- Produce sprint-ready task lists with clear acceptance criteria
description: Use this agent to write tests, review test coverage, identify untested paths, design test scenarios, and validate that migrations and services behave correctly. Invoke when adding new features, fixing bugs, or auditing test coverage.
model: claude-sonnet-4-6
tools: [Read, Glob, Grep, Bash, Write, Edit]
---
You are a QA specialist for the ERPLibre Home Mobile project. Your framework is Vitest with mocked Capacitor plugins.
## Your responsibilities
- Write unit tests for services: `NoteService`, `AppService`, `DatabaseService`, `MigrationService`
- Write tests for `versionToDisplay()`, migration logic, and data transformation functions
description: Use this agent to coordinate releases, manage versioning, define release checklists, plan rollbacks, and communicate release notes. Invoke before any production release, when cutting a release branch, or when defining the release process.
model: claude-sonnet-4-6
tools: [Read, Glob, Grep, Bash, Write]
---
You are the release manager for ERPLibre Home Mobile. You ensure releases are predictable, safe, and well-communicated.
description: Use this agent to assess technical and operational risks, define mitigation strategies, build business continuity plans, and maintain a risk register. Invoke when evaluating new features for risk, preparing for a banking deployment, or after an incident.
model: claude-sonnet-4-6
tools: [Read, Glob, Grep, Write]
---
You are the risk manager for ERPLibre Home Mobile in a banking-grade deployment context. You identify, quantify, and mitigate risks before they become incidents.
## Your responsibilities
- Maintain a risk register: technical, operational, regulatory, reputational risks
- Assess risk likelihood × impact and prioritize mitigation
- Define Business Continuity Plan (BCP): how does the organization operate if the app is unavailable?
- Define Disaster Recovery Plan (DRP): how is the system restored after catastrophic failure?
description: Use this agent to audit security, review encryption implementation, check for data leaks, assess permissions, and validate that sensitive data is handled correctly. Invoke before releases, when adding new data storage, or when handling user credentials.
model: claude-sonnet-4-6
tools: [Read, Glob, Grep]
---
You are a software security specialist for ERPLibre Home Mobile — an app that stores Odoo credentials and personal notes on Android.
description: Use this agent to triage user issues, write support runbooks, create FAQ content, diagnose common failure modes, and define L1/L2 escalation paths. Invoke when responding to bug reports, building a knowledge base, or defining the support process.
model: claude-sonnet-4-6
tools: [Read, Glob, Grep, Write]
---
You are the L1/L2 support specialist for ERPLibre Home Mobile. You diagnose user problems efficiently and build knowledge that prevents repeat issues.
description: Use this agent for architectural decisions, design patterns, technical trade-offs, system integration design, and reviewing structural changes. Invoke before starting significant new features, when evaluating libraries, or when the current architecture needs to evolve.
model: claude-sonnet-4-6
tools: [Read, Glob, Grep, WebSearch]
---
You are a system architect for ERPLibre Home Mobile, responsible for technical direction and structural integrity.
## Your responsibilities
- Evaluate architectural trade-offs: native vs web, local vs remote, sync vs async
- Design service interfaces and data flow between layers
- Review new dependencies before adoption: bundle size, maintenance status, licensing, Capacitor compatibility
- Define patterns for recurring problems: event bus vs props, service injection, migration versioning
- Identify structural technical debt and propose remediation paths
- Design for testability: services must be injectable and mockable
- Evaluate Capacitor plugin APIs before integrating
- Define the boundary between Owl UI layer and Capacitor native layer
## Project architecture
```
app.ts (bootstrap)
└── DatabaseService (SQLite, encrypted)
└── MigrationService (versioned, YYYYMMDDNN)
└── NoteService / AppService / IntentService
└── Owl component tree
├── RootComponent
│ ├── ContentComponent (router, t-key remount)
│ ├── NavbarComponent
│ └── VideoCameraComponent
└── NoteComponent
├── NoteContentComponent (entries + Sortable)
└── NoteBottomControlsComponent
```
- **Event bus**: `EventBus` from `@odoo/owl` — used for cross-component communication
- **Router**: custom `SimpleRouter`, hash-based, remounts component on every URL change via `t-key`
- **State**: local `useState` per component — no global store
- **Data**: SQLite only (AES-256), no cloud sync currently
## Decision framework
For each architectural decision, provide:
1. **Options considered** (min 2)
2. **Trade-offs** for each
3. **Recommendation** with rationale
4. **Constraints** that informed the decision (bundle size, Android API level, Capacitor limitations)
5. **Migration path** if changing existing architecture
Be opinionated. One clear recommendation is more useful than a list of possibilities.
description: Use this agent to evaluate user experience, propose UX improvements, review interaction flows, assess accessibility, and validate that the mobile UI is intuitive and efficient. Invoke when designing new features, reviewing user-facing changes, or auditing the overall UX.
model: claude-sonnet-4-6
tools: [Read, Glob, Grep]
---
You are a UX specialist for ERPLibre Home Mobile — a personal note-taking and Odoo instance management app running on Android via Capacitor.
## Your responsibilities
- Evaluate interaction flows: how many taps to complete a task, where friction exists
- Identify missing affordances: buttons without visual feedback, actions without confirmation
- Review information hierarchy: is the most important content prominent?
- Assess mobile-specific UX: thumb reachability, touch target sizes (min 44×44px), safe area handling
- Flag accessibility gaps: missing ARIA labels, poor color contrast, no keyboard navigation
- Recommend auto-behaviors: auto-scroll to new entries, auto-open camera on new media entry, default read mode
- Evaluate error states: are errors surfaced clearly? Are dialogs copyable on mobile?
- Review navigation patterns: breadcrumbs, prev/next note, back button behavior
description: Commandes ERPLibre — changer de version Odoo, lancer/tester une instance, opérations base de données, tester un module précis avec couverture, formatage, Docker, Google Repo, installation. À charger dès qu'une commande make ou un script du dépôt est nécessaire.
---
## Changement de version Odoo
```bash
@ -30,7 +34,17 @@ make db_clone_test_to_test2 # Cloner test -> test2
```
## Tests
### Suite complète
### Unitaires python (rapides, sans base de données)
```bash
make test_unit # tout ce qui tourne sans DB ni Odoo
make test_unit_file F=test/test_qemu_motd.py # un seul fichier
```
Ils lisent le code et exécutent les fragments de shell générés par `todo.py`,
avec `sudo`, `pgrep` et `pkill` bouchonnés — quelques secondes. Le lanceur
annonce sa dépendance à `mobile/erplibre_home_mobile` : absent, les tests du
transfert mobile se déclarent ignorés au lieu de passer en silence.
description: Documentation bilingue ERPLibre (mmg, fichiers .base.md) et internationalisation du CLI TODO (todo_i18n.py, clés TRANSLATIONS). À charger pour rédiger ou régénérer de la documentation, ou pour ajouter une chaîne traduisible au CLI.
---
# Documentation multilingue
La documentation est bilingue (anglais/français) via **mmg** (Multilingual
Markdown Generator).
## Fonctionnement
- Les fichiers sources sont les `.base.md` (contiennent les deux langues)
- `mmg` génère : `FICHIER.md` (anglais) et `FICHIER.fr.md` (français)
@ -25,6 +25,526 @@ au [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
## [Unreleased]
<!-- [en] -->
## Added
<!-- [fr] -->
## Ajouté
<!-- [en] -->
- Site presets for the VPN: one `.json` carries a site's gateway, protocol and connection group, and neither a username nor a secret, so it can be handed around. Read from `conf/vpn_presets/`, then from a git-ignored `private/vpn/presets/`, then from any directory listed in `vpn_preset_paths`; on the same identifier the latest wins, so a site fixes a shipped template without touching a tracked file
- Import a Cisco AnyConnect `.xml` profile from the menu, browsing the client's own directories or typing the path, and get a preset from its `HostName`, `HostAddress` and `UserGroup`
- OpenConnect tells apart the two mechanisms that designate a service on one concentrator: the connection group in the URL and the value picked from a dropdown. Confusing them hands over another service's login form, so correct credentials are refused with nothing naming the group
- Reach a gateway that demands an embedded browser for SAML, which stops OpenConnect on « No SSO handler »: the web step is delegated to an `openconnect-sso` helper that the installer offers to set up, and the tunnel is then brought up by the driver itself, so the interface name, the state files and the diagnosis stay with the profile
- Declare a concentrator that compares only the first characters of a password: it is announced before the secret is stored, and nothing is ever truncated
- The VPN installer looks for `vpnc-script` — a file, not a binary on the `PATH` — and names the package to install per distribution family, instead of letting the tunnel fail on an interface that never appears
- A command launched by the VPN runner gets `/dev/null` on standard input, so a captured-output command can no longer be stopped by a SIGTTOU and freeze the machine's package manager
- The VPN profile list marks which profiles carry a live tunnel, so connecting one already up asks first and disconnecting one already down says so instead of looking like a mistake. A profile is judged on its interface, not on the state file a tunnel killed without `down` leaves behind — a state left over used to be reported as mounted on the same screen that declared the process gone
- `Assistant › LLM` — ask a model server over several turns, local or remote. The history lives in memory and dies with the menu, `/save` being the only way to keep a trace; every command carries a leading slash, so a question pasted over several lines stays one turn. A third-party destination has to be retyped before the first send
- Server recognition across eleven ports and twelve families, identity read from the response BODY and never from the port: one port hosts up to three products, and one family re-serves another's whole native API
- Finding a server from six sources — the loopback, this machine's QEMU domains, the hosts of `~/.ssh/config`, an address or a network typed by hand, and the networks read over SSH on another machine. Anything wider than a `/24` is refused before enumeration, and two preferences bound the sweep: `assistant_sweep_workers`, `assistant_sweep_timeout`
- A gpt catalogue in `script/todo/assistant/gpt/`: one Markdown file per tool, whose declared requirements are matched against what the server announces. An unknown never greys a tool out — only a requirement contradicted by a field actually read does, with the figure that refuses it
- A declared READ-ONLY context per tool, files and allowlisted commands, shown and confirmed before the first send, capped in size and duration, and scanned for identifying data. The scan's honest limit is stated: it sees addresses, e-mails and account paths, not names
- `Execute › GPT code › Claude Code` — list the machine's sessions, ask one a question with read-only tools, or resume one in its own terminal. A copy is branched by default, since two writers on one session lose a branch
- `check_comment_hygiene.py` signals a fully qualified machine name in a comment, as a re-read signal and never a finding: a BARE host name is mechanically indistinguishable from an ordinary word, so the absence of a signal proves nothing about names. The copyright header, the RFC 2606 domains and any address carried by a URL are left alone
- Transform data, a menu entry that opens an external file — Excel, Access, CSV, XML or JSON — reports what it holds, then draws an anonymised copy of it. The original is never touched. Numbers are drawn from the measured extent of their own column rather than a fixed 0-1000 range, which turns a tax rate into 743 and a year into 12; they are drawn without replacement, since a hundred distinct keys in a range of a hundred otherwise yield sixty-six outputs and a fixture that no longer reimports. Text takes a French word from a local dictionary of 1366, assigned by a counter rather than a draw, and a portable mapping table gives the same client the same word across a whole batch
- Eleven structural labels are left alone on their NAME — `id`, `create_uid`, `sequence`, `active` and the rest, plus anything ending in `/id` or `/.id` — since a test set has to keep working. Every OTHER column is judged on its measured CONTENT, never on the strength of its name. In an import-ready export, `partner_id` holds the relation's display name and `display_name` is the data itself, so deciding on the label copied the most identifying columns of the file verbatim while announcing them as protected
- The anonymiser rereads the bytes it has just written and refuses the copy when a value it announced as replaced survives in it. A workbook holds data in a dozen places that are not cells: a pivot cache and an external link each carry an entire copy of the source, a chart caches its categories and its axis titles, a custom number format carries a label, a comment carries its author, a cell hyperlink carries a path. The guard depends on no list of those, so a place nobody thought to clean produces a refusal instead of a silence — and what stays by decision, a header row or a column left alone, is named on screen before anything is written
- Transform data anonymises an Odoo database too, the entry asking for the SOURCE rather than the format: an external file, a live database, or a backup zip taken from `image_db/`. A zip is never modified — it is restored into a database, anonymised there, then dumped into a NEW zip by Odoo's own backup, so the dump, the filestore and the manifest are written by the software that will read them back. A live database is modified ITSELF, which is said before the work and not after, and nothing is drawn when the write did not happen: declining otherwise handed back a zip of the untouched database, announced as anonymised. A register records which databases the entry produced, since the server does not
- An anonymised number can keep its digit count, on the file anonymiser and on `anonymize.py` alike (`--keep-digits`): 8839 then draws in 1000..9999, so the copy keeps columns of the same width, which an export read by eye or imported into a bounded field asks for. Each value keeps ITS own width and not its column's — 7 stays at one digit where 12 keeps two — and below the unit the rule does not apply, 0.15 having no digit before the point. The option trades one guarantee for another: the measured extent no longer bounds anything, so a rate or a year can leave its range, and the preview SAYS so rather than letting it be found at reimport. Uniqueness is what yields when a band fills up, a duplicate of the same width beating a value of a different one, and the band never exceeds what the type RECEIVING the draw holds, which is not always the column's: an Odoo `integer` over a column PostgreSQL did not create as an integer — what an upgraded base carries — is poured into `numeric`, which has no ceiling, where `integer` stops at 2 147 483 647 and a draw past it aborts the whole write, that write being one transaction
- The anonymiser asks four questions instead of eleven, seven of the eleven having had an obvious default. Answering them one by one to arrive at the same place makes prompts be passed by reflex, and a prompt passed by reflex consents to nothing; they now live behind « Advanced options? ». The short path DECLARES what it takes, in sentences rather than in yes/no, since those are decisions taken and not questions whose answer was lost. Macros and charts are asked on both paths: they are not visible in the cells
- `markdown-it-py` is declared as a functional dependency: it renders the language model's markdown to HTML, before sanitising, on the assistant page. It reached the environment transitively through `bandit` → `rich`, a lint tool, so removing a lint dependency removed a portal page's rendering engine
- A download cache shared by the QEMU VMs of a host, installed from **Deployment › QEMU cache**. Two VMs of the same distribution stop pulling the same hundreds of megabytes twice: a package file is served from disk, while an index is always taken from upstream, so a withdrawn package can never turn into a « failed retrieving file … 404 ». An index is stored all the same and only comes back out when upstream is unreachable, which is what makes an offline deployment possible. The cache never shrinks by itself: `--status` says what it occupies
- Interception is transparent and covers the whole host bridge, so a VM cannot opt out from the inside. Every VM trusts the cache's authority as long as the service runs. To take ONE machine out, tick « keep this VM out of the download cache » when deploying: its MAC address is fixed before creation and an exception is posted on the host. To take them all out, stop the service — its rules leave with it. A Proxmox host that is itself a VM here is no exception: the machines it carries come out behind its address, so the deployment poses the authority in each of them, by ssh, before installing anything
- The measurement is not limited to Arch: any catalogue system whose package family is known, and either a batch of packages or the real install of ERPLibre and Odoo 18. Measured on Ubuntu 24.04 with that real install, the second VM pulled **zero byte** of package from the network and finished 19 % faster. Verified on the seven systems of the catalogue
- Git is MIRRORED rather than cached: its protocol is a negotiation, the server computing its answer from what the client already holds, so no answer is reusable. A bare mirror per upstream repository is kept on the host and served locally, and a mirror already held serves with no network at all — measured, a repository cloned inside a VM while the cache's upstream was cut. Measured on a full ERPLibre install: the second VM pulled **zero** git request from upstream, where git had been four fifths of the traffic. **Deployment › QEMU cache › Git mirrors** fills them ahead from the manifests, so the first VM does not pay every clone
- An offline deployment also covers the base suite of a cloud image. Its apt REVALIDATES the index it ships instead of downloading it, upstream answers 304, and the cache had no body to keep — so that one suite, and only it, was missing offline while its `-updates` and `-security` neighbours came off the disk. A conditional request for something the cache does not hold now goes upstream without its condition, once, and a client that holds its own copy gets 304 rather than 504 when upstream is mute.
- What an offline deployment covers, exactly: packages, repository indexes and git. NOT what the cache is forbidden to decrypt — a client carrying its own trust store, npm and poetry among them, is tunnelled opaquely, and a tunnel carries nothing once the network is gone. A full ERPLibre install therefore still needs the network, though everything the cache holds is served from disk
- A mirror is COMPLETE where `repo sync` clones at depth one, so it costs tens of gigabytes. Below ten gigabytes free, no new mirror is created and the request goes back upstream. The diagnosis says what the objects and the mirrors each occupy
- **Deployment › QEMU cache › Age and cleanup** groups the cache by age of last use (day, week or month; objects and git repositories apart) and gives back what has not served for a chosen delay, or everything. A served object has its date renewed, so « old » means « no longer used ». Both cleanups say what would go before erasing anything, and entry 5 lists the mirrors heaviest first to remove one
- `long_test/qemu_cache.py` measures whether the cache really serves the second VM, and `--hors-ligne` cuts the upstream of the cache service alone to prove a third VM still builds from the stored index
- Before cutting, the form says whether the cache holds the base suite of each system asked for: F5 warns « cache holds nothing for ubuntu 26.04 » and a second F5 goes ahead anyway. The verdict is given only where a release is named unambiguously in the URL — the apt families — rather than reassuring wrongly elsewhere. The verdict is given component by component — `main`, `universe`, `restricted`, `multiverse`, on the base suite and on its `-updates` and `-security` companions — because a single stored URL used to silence it while a whole component was missing, and apt only said so twenty minutes later, by « Unable to locate package »
- **Deployment › QEMU cache › Copy it to another machine** carries the store to another ERPLibre host in a single stream — `tar`, compressed, over ssh, no intermediate file for tens of gigabytes — and hands the files to the service account on arrival, the same account rarely bearing the same number on two machines. Only the STORE travels: an object is keyed by its URL and never by the machine that fetched it, and a git mirror is a repository. The settings stay behind — bridge, subnet and authority belong to the host, and entry 1 poses them there
- The deployment form carries a **Network** section with « No internet connection »: for the whole deployment, install included, the cache service loses its way out AND the VMs lose theirs — ping, other ports, UDP, IPv6 — so a step that takes any path but the cache fails instead of quietly succeeding online. Names no longer resolve through the internet either: the host answers every name itself with an address the cache intercepts, so only what the cache holds can be reached; dnsmasq must be installed on the host. A VM behind the cache pulls from one fixed apt mirror: cloud-init's mirror search discards every mirror behind a resolver that answers every name, and would fall back on another mirror than the one the previous VMs filled the cache from. The cut refuses rather than drops, so an address the cache does not hold answers 504 at once instead of after a connection timeout; a kernel that cannot load the reject module gets the dropping set instead. Offered only where the cache runs, and the deployment refuses rather than run with the upstream still up, a VM built that way succeeding for the wrong reason. **Proxmox VE** carries the same box, offered where its host is itself a VM of this bridge: its guests come out behind its address, so the local cut covers them and nothing is posted on the remote host. A Proxmox host that does not live here is never offered it — nothing here can cut its way out
- A Proxmox VE deployment can ask for **3D acceleration**. The VM is created with an accelerated screen (`--vga virtio-gl`) rather than the serial console as its display, and the account joins the GPU groups INSIDE the guest: the render node belongs to `root:render`, so without them every GL application falls back to software rendering while the VIRGL negotiation reports success, and nothing says so. The box is offered only where the remote host has a render node AND the three libraries Proxmox loads for that screen — VIRGL, GL and EGL. It names the missing ones and refuses to start the machine, once its disk is written and its configuration posted, so a host carrying GL without EGL would fail at the very last step. Where a piece is missing the form says which, and the package to install on the host: a box that vanishes without a word reads as a regression. A button installs them without leaving the screen — the form hands the terminal back so sudo can ask for a password and apt can be watched — then reads the host again rather than taking apt's word for it, and the box appears in place of the message. The serial port stays posted, so `qm terminal` keeps working
- Offline, the cache replays what an online pass saw, not only 200 bodies: redirects, definitive refusals (404/410) and HEAD answers of volatile URLs are kept without a body, under keys of their own, and served ONLY when upstream is mute. A TUF client probing the next version of its root gets the 404 it expects instead of a 504, so mise installs Python offline with its Sigstore verification intact; GNOME extensions, Claude Code's installer and rtk's version lookup follow their redirects offline
- The offline cut ends when the last installation ends, not when the monitor closes: a root unit, handed the lift at launch, waits for every installation's exit marker and survives the monitor closed early, todo.py killed or the terminal gone — 12 h at most. The monitor is therefore required while offline. A second offline deployment is refused while one runs, and an online deployment started meanwhile is told it would run offline
- F5 also reads the previous offline runs of the same VM and warns « at least N addresses were missing », minus what the store holds now (`erplibre_go_qemu_cache --detient`, read-only, no root). **Deployment › QEMU cache › Fill what offline runs lacked** replays them online, through the cache
- The install log names the commit the VM runs; offline, the recap says, branch by branch, which commit the cache's mirror will give
- `long_test/qemu_cache.py --distro tous` (or a comma list) chains one campaign per catalogue system, destroys each system's VMs before the next, and ends on a table of verdict, durations and upstream bytes. A failure does not stop the series
- The QEMU download cache can clean itself up every day: by age (`EL_PURGE_AGE`, e.g. `90j`) and by size ceiling (`EL_MAX_SIZE`, e.g. `50G`, the least recently served going first, objects and git mirrors alike). Both are off by default and set from **Deployment › QEMU cache › Automatic cleanup**, which previews what would go; `--purge-to-size` runs the ceiling by hand. A reinstall keeps the values chosen
- NixOS 25.11 as a deployable system, alongside the eight others. It is the only one no distribution publishes a cloud image for: the image is rebuilt by a third party, so its release is pinned, its sha256 verified at every download, and its origin printed before anything is created. cloud-init receives no network configuration there — its networkd renderer takes the key of a block as an interface NAME, where netplan honours a `match:` — and the account is created with `/bin/sh`, sshd refusing an account whose shell does not exist
- ERPLibre installed on NixOS, its dependencies DECLARED in `conf/nixos/erplibre.nix` and applied by `nixos-rebuild`, where the four other families install them one command at a time. `services.envfs` answers `/usr/bin/env` and `programs.nix-ld` gives manylinux wheels the dynamic loader they ask for; the headers of what has no wheel are linked into the system profile, and its libraries reach the loader too, a module compiled on the machine carrying no RPATH. The install reaches it from the menu like any other distribution: the bootstrap poses git, make and python3 — absent from that image — in the user profile for the clone, and « make install_os » redeclares them for the system. Checked on a VM: the 362-package lock installs and Odoo answers over HTTP
- A `nix + nixos-anywhere` option on the OTHER distributions, the reverse of picking NixOS: it leaves an ordinary VM able to install NixOS onto any machine reachable over SSH. Nix is called by absolute path, the remote shell's PATH being frozen before the installer drops the binary, and the flake features are repeated on the command line, writing `nix.conf` needing a sudo that may fail
- NixOS deploys on a **Proxmox** host as it does on QEMU/KVM, which took three fixes no code reading could have found. Its image has no BIOS boot sector: a VM created in SeaBIOS reports « running » with a silent console, so the catalogue now marks which images need UEFI — one marker per distribution, since Debian 13 boots in SeaBIOS on that same host. `--ciuser` and `--sshkeys` defer to the image's DEFAULT account, which NixOS declares as another name: the repository's own cloud-config now travels as a snippet for every distribution, carrying an explicit `users:` block. And the cloud-init drive moves to the SCSI bus — an image built for virtio alone has no ATA driver and never sees an IDE drive, so cloud-init hunted network datasources and the VM came up with no account at all. Checked end to end: NixOS answers with `/bin/sh`, Debian 13 with `/bin/bash`, sudo on both
- The third-party image is verified against the sum the repository pins for it on the Proxmox path too, where a bare `wget` used to be enough. One accessor carries that sum for both paths, and the check runs even on a cached image — the case aimed at is a file substituted or truncated between deployments, which a presence test cannot see
- One entry of the download cache can be removed, by URL. A checksum that does not match invalidated nothing: the store kept serving the same bytes, and re-downloading changed nothing since the store is what answers. Neither existing purge reaches it — `--purge` erases everything, and `--purge-older-than` skips what is recent while every service resets that date, so a poisoned object that keeps being served never ages. `--oublie` is symmetric to `--detient`: same input lines, same key functions, same refusals, and a present object that resists is reported as a refusal rather than a forget. Both checksum failures now name it, with the exact URL
- The install log carries what the host decided before launching: the download cache authority placed or refused, the bypass, the mirror. Those lines were said on a console that scrolls away, while the file reopened after a failure held only the symptom — on a guest with no trust store, a refused certificate, hundreds of derivations to build and six hundred lines of errors, without a word on the cause
- One entry of the download cache can be forgotten from the menu, under « Age and cleanup ». The binary could already do it; the menu offered only the two bulk purges, neither of which reaches a single object — « erase what has not served » never reaches one the service rejuvenates each time it serves it, and « erase everything » costs the whole cache for one file. `--detient` runs first and is the preview: same line, same key, nothing modified
- `erplibre_go_qemu_cache --recle` stores a cache's objects again under the current key, without downloading anything, and merges the copies a mirror carried under several paths. Objects written under the former key rule stay on disk but become UNREACHABLE, so the service asks upstream for them again and the space they hold serves no one: on a store of 12 764 objects, 5 419 were in that case — 9.11 GiB — and merging the duplicates returned about 3.37 GiB. The service must be stopped, the body being renamed before its meta, and `--dry-run` only counts what would move. A status-only entry is left alone, its key carrying the host rather than the path
- The `pre-commit` hook runs `check_python_version.py` on staged files: it reports source that does not parse under the Python of `conf/python-erplibre-version`, without blocking the commit, and says when no such interpreter was there to check. Neither black nor flake8 sees that fault — black's target bounds what it writes, never what it accepts
- `Deploy › Local › [4]` opens a SOCKS proxy over SSH — `ssh -D`, port 1080 by default — so the browser reaches, FROM the remote machine, an interface listening only on its loopback or a host of its network. The address comes from `~/.ssh/config` or by hand; an alias is passed to ssh as is, so its `ProxyJump` still applies and a nested VM stays reachable. The Firefox settings print before the tunnel opens, the command only returning on Ctrl+C
- `make format_test` formats `test/` and `long_test/`, which no target covered: 75 files out of 210 followed no standard, and only a file a diff reported was ever touched
- `script/reverse_proxy/main.py` — a development reverse proxy for Odoo 18 without nginx: one address sends pages to the web port and `/websocket` to the bus port, with the `X-Forwarded-*` headers of `proxy_mode` set by the proxy alone (`--trust-forwarded` extends a chain instead, behind another proxy). Only the request head is read, so an upgraded WebSocket stays open and a gzip or chunked response passes byte for byte. It serves HTTPS with `--tls-cert`/`--tls-key`, logs one line per request (route, status, duration; `--quiet` silences it), says at start which Odoo port does not answer, and names that port in a 502. A request head waits 30 s (408) and the connection to Odoo 10 s (504), never an open WebSocket. Listens on `127.0.0.1:8080` by default, `--listen 0.0.0.0` opens it to the network; one request per connection, production keeps nginx
- `script/reverse_proxy/local_cert.py` issues a local authority, imported once in the browser, and a server certificate it signs for localhost, the host name and its addresses, under `~/.erplibre/reverse_proxy_tls/` with keys in 0600; the authority is kept when the certificate is issued again
- `TODO › Execute › Network › Odoo reverse proxy` starts it with the web and bus ports read from `config.conf`, asks for this machine only or the whole network and for HTTP or HTTPS, issues the local certificate on first HTTPS use, and warns when `proxy_mode` is off or `workers` is 0 — without a worker no bus port listens and `/websocket` fails. `Network › Local TLS certificates` issues it again with extra names
<!-- [fr] -->
- Des préréglages de site pour le VPN : un `.json` porte la passerelle d'un site, son protocole et son groupe de connexion, et ni identifiant ni secret, si bien qu'il peut circuler. Lus depuis `conf/vpn_presets/`, puis depuis un `private/vpn/presets/` ignoré par git, puis depuis tout répertoire listé dans `vpn_preset_paths` ; sur un même identifiant le plus tardif gagne, et un site corrige un gabarit livré sans toucher de fichier suivi
- Importer un profil Cisco AnyConnect `.xml` depuis le menu, en parcourant les répertoires du client ou en tapant le chemin, et en tirer un préréglage de ses balises `HostName`, `HostAddress` et `UserGroup`
- OpenConnect distingue les deux mécanismes qui désignent un service sur un même concentrateur : le groupe de connexion dans l'URL et la valeur choisie dans un menu déroulant. Les confondre donne le formulaire d'un autre service, et des identifiants justes sont refusés sans que rien ne nomme le groupe
- Joindre une passerelle qui exige un navigateur intégré pour le SAML, ce qui arrête OpenConnect sur « No SSO handler » : l'étape web est déléguée à un greffon `openconnect-sso` que l'installateur propose de poser, et le tunnel est ensuite monté par le pilote lui-même, si bien que le nom d'interface, les fichiers d'état et le diagnostic restent au profil
- Déclarer un concentrateur qui ne compare que les premiers caractères d'un mot de passe : il est annoncé avant le dépôt du secret, et rien n'est jamais tronqué
- L'installateur VPN cherche `vpnc-script` — un fichier, et non un binaire du `PATH` — et nomme le paquet à poser par famille de distribution, au lieu de laisser le tunnel échouer sur une interface qui n'apparaît jamais
- Une commande lancée par l'exécuteur VPN reçoit `/dev/null` sur son entrée standard, si bien qu'une commande à sortie capturée ne peut plus être arrêtée par un SIGTTOU et figer le gestionnaire de paquets de la machine
- La liste des profils VPN marque ceux qui portent un tunnel vivant, si bien que connecter un profil déjà monté demande confirmation et que déconnecter un profil déjà tombé le dit au lieu de ressembler à une erreur. Un profil est jugé sur son interface et non sur le fichier d'état qu'un tunnel tué sans `down` laisse derrière lui — un état laissé était annoncé monté sur l'écran même qui déclarait le processus mort
- `Assistant › LLM` — interroger un serveur de modèle sur plusieurs tours, local ou distant. L'historique vit en mémoire et meurt avec le menu, `/save` étant le seul moyen d'en garder une trace ; toute commande porte une barre oblique initiale, donc une question collée sur plusieurs lignes reste un seul tour. Une destination tierce doit être retapée avant le premier envoi
- Reconnaissance du serveur sur onze ports et douze familles, l'identité étant lue dans le CORPS de la réponse et jamais dans le port : un port héberge jusqu'à trois produits, et une famille réémet l'API native d'une autre en entier
- Recherche d'un serveur depuis six sources — la boucle locale, les domaines QEMU de la machine, les hôtes de `~/.ssh/config`, une adresse ou un réseau saisi, et les réseaux lus en SSH sur une autre machine. Plus large qu'un `/24` est refusé avant énumération, et deux préférences bornent le balayage : `assistant_sweep_workers`, `assistant_sweep_timeout`
- Un catalogue d'outils gpt dans `script/todo/assistant/gpt/` : un fichier Markdown par outil, dont les exigences déclarées sont confrontées à ce que le serveur annonce. L'inconnu ne grise jamais un outil — seule une exigence contredite par un champ réellement lu le fait, avec le chiffre qui la refuse
- Un contexte LECTURE SEULE déclaré par outil, fichiers et commandes autorisées, montré et confirmé avant le premier envoi, borné en taille et en durée, et balayé à la recherche de données identifiantes. La limite du balayage est dite : il voit les adresses, les courriels et les chemins de compte, pas les noms
- `Exécution › GPT code › Claude Code` — lister les sessions de la machine, en interroger une avec des outils en lecture seule, ou la reprendre dans son propre terminal. Une copie est branchée par défaut, deux écritures sur une même session perdant une branche
- `check_comment_hygiene.py` signale un nom de machine pleinement qualifié dans un commentaire, en signal à relire et jamais en trouvaille : un nom d'hôte NU ne se distingue mécaniquement pas d'un mot ordinaire, donc l'absence de signal ne prouve rien sur les noms. L'en-tête de copyright, les domaines de la RFC 2606 et toute adresse portée par une URL sont laissés tranquilles
- Transform data, une entrée de menu qui ouvre un fichier externe — Excel, Access, CSV, XML ou JSON —, rapporte ce qu'il porte, puis en tire une copie anonymisée. L'original n'est jamais touché. Les nombres sont tirés dans l'étendue mesurée de leur propre colonne plutôt que dans un intervalle fixe de 0 à 1000, qui rend un taux de TVA à 743 et une année à 12 ; ils sont tirés sans remise, cent clés distinctes dans une étendue de cent ne rendant sinon que soixante-six sorties, et une fixture qui ne se réimporte plus. Le texte prend un mot français dans un dictionnaire local de 1366, attribué par un compteur et non par un tirage, et une table de correspondance portable donne au même client le même mot sur tout un lot
- Onze étiquettes structurelles sont laissées intactes sur leur NOM — `id`, `create_uid`, `sequence`, `active` et les autres, plus tout ce qui finit en `/id` ou `/.id` —, un jeu de test devant continuer de fonctionner. Toute AUTRE colonne est jugée sur son CONTENU mesuré, jamais sur la seule foi de son nom. Dans un export import-compatible, `partner_id` porte le nom affiché de la relation et `display_name` est la donnée elle-même : décider sur l'étiquette recopiait textuellement les colonnes les plus identifiantes du fichier en les annonçant comme protégées
- L'anonymiseur relit les octets qu'il vient d'écrire et refuse la copie dès qu'une valeur annoncée comme remplacée y subsiste. Un classeur porte de la donnée dans une douzaine d'endroits qui ne sont pas des cellules : un cache de tableau croisé et un lien externe en portent chacun une copie entière, un graphique met ses catégories et ses titres d'axes en cache, un format de nombre personnalisé porte un libellé, un commentaire porte son auteur, un hyperlien de cellule porte un chemin. Le filet ne dépend d'aucune liste de ces endroits, si bien qu'un endroit que personne n'a pensé à nettoyer produit un refus et non un silence — et ce qui reste par décision, une ligne d'en-tête ou une colonne laissée intacte, est nommé à l'écran avant que rien ne soit écrit
- Transform data anonymise aussi une base Odoo, l'entrée demandant la SOURCE plutôt que le format : un fichier externe, une base vivante, ou un zip de sauvegarde pris dans `image_db/`. Un zip n'est jamais modifié — il est restauré dans une base, anonymisé là, puis vidé dans un zip NEUF par la sauvegarde d'Odoo lui-même, si bien que le dump, le filestore et le manifeste sont écrits par le logiciel qui les relira. Une base vivante est modifiée ELLE-MÊME, ce qui est dit avant le travail et non après, et rien n'est tiré lorsque l'écriture n'a pas eu lieu : un renoncement rendait sinon un zip de la base intacte, annoncé comme anonymisé. Un registre inscrit les bases que l'entrée a produites, le serveur ne le disant pas
- Un nombre anonymisé peut garder son nombre de chiffres, sur l'anonymiseur de fichiers comme sur `anonymize.py` (`--keep-digits`) : 8839 tire alors dans 1000..9999, si bien que la copie garde des colonnes de la même largeur, ce qu'un export relu à l'œil ou importé dans un champ borné demande. Chaque valeur garde SA largeur et non celle de sa colonne — 7 reste à un chiffre là où 12 en garde deux — et sous l'unité la règle ne s'applique pas, 0,15 n'ayant pas de chiffre avant la virgule. L'option échange une garantie contre une autre : l'étendue mesurée ne borne plus rien, donc un taux ou une année peut sortir de sa plage, et l'aperçu le DIT au lieu de le laisser découvrir à la réimportation. C'est l'unicité qui cède quand une bande se remplit, un doublon de la même largeur valant mieux qu'une valeur d'une autre, et la bande ne dépasse jamais ce que tient le type qui ACCUEILLE le tirage, lequel n'est pas toujours celui de la colonne : un `integer` d'Odoo posé sur une colonne que PostgreSQL n'a pas créée entière — ce qu'une base montée de version porte — se coule en `numeric`, qui n'a pas de plafond, là où `integer` s'arrête à 2 147 483 647 et où un tirage au-delà fait retomber toute l'écriture, celle-ci tenant en une transaction
- L'anonymiseur pose quatre questions au lieu de onze, sept des onze ayant eu un défaut évident. Les répondre une par une pour arriver au même endroit fait passer les invites par réflexe, et une invite qu'on passe par réflexe ne consent à rien : elles vivent désormais derrière « Options avancées ? ». Le chemin court DIT ce qu'il prend, en phrases et non en oui/non, puisque ce sont des décisions prises et non des questions dont on aurait perdu la réponse. Macros et graphiques sont demandés dans les deux chemins : ils ne se voient pas dans les cellules
- `markdown-it-py` est déclaré en dépendance fonctionnelle : il rend en HTML le markdown du modèle de langage, avant assainissement, sur la page de l'assistant. Il arrivait dans l'environnement en transitif par `bandit` → `rich`, un outil de lint, si bien que retirer une dépendance de lint retirait le moteur de rendu d'une page portail
- Un cache de téléchargement partagé par les VM QEMU d'un hôte, installé depuis **Déploiement › Cache QEMU**. Deux VM de la même distribution cessent de tirer deux fois les mêmes centaines de mégaoctets : un fichier de paquet est servi du disque, tandis qu'un index est toujours repris à l'amont, si bien qu'un paquet retiré ne peut jamais devenir un « failed retrieving file … 404 ». L'index est stocké quand même et ne ressort que si l'amont est injoignable, ce qui rend un déploiement hors ligne possible. Le cache ne diminue jamais de lui-même : `--status` dit ce qu'il occupe
- L'interception est transparente et vaut pour tout le pont de l'hôte : une VM ne peut pas s'y soustraire de l'intérieur. Toutes approuvent l'autorité du cache tant que le service tourne. Pour en soustraire UNE, cocher « soustraire cette VM au cache » au déploiement : son adresse MAC est fixée avant la création et une exception est posée sur l'hôte. Pour les soustraire toutes, arrêter le service — ses règles partent avec lui. Un hôte Proxmox qui est lui-même une VM d'ici n'y échappe pas : les machines qu'il porte sortent derrière son adresse, et le déploiement pose donc l'autorité dans chacune, par ssh, avant d'installer quoi que ce soit
- La mesure ne se limite plus à Arch : tout système du catalogue dont la famille de paquets est connue, et au choix un lot de paquets ou l'installation réelle d'ERPLibre et d'Odoo 18. Mesuré sur Ubuntu 24.04 avec cette installation réelle, la seconde VM n'a tiré **aucun octet** de paquet du réseau et a fini 19 % plus vite. Vérifié sur les sept systèmes du catalogue
- Git est mis en MIROIR plutôt que caché : son protocole est une négociation, le serveur calculant sa réponse d'après ce que le client détient déjà, si bien qu'aucune réponse ne se réutilise. Un miroir nu par dépôt amont est tenu sur l'hôte et servi localement, et un miroir déjà détenu sert sans aucun réseau — mesuré, un dépôt cloné dans une VM alors que l'amont du cache était coupé. Mesuré sur une installation complète d'ERPLibre : la seconde VM n'a tiré **aucune** requête git de l'amont, là où git pesait quatre cinquièmes du trafic. **Déploiement › Cache QEMU › Miroirs git** les remplit d'avance depuis les manifestes, pour que la première VM ne paie pas tous les clonages
- Un déploiement hors ligne couvre aussi la suite de base d'une image cloud. Son apt REVALIDE l'index qu'elle livre au lieu de le télécharger, l'amont rend 304, et le cache n'avait donc aucun corps à garder — cette suite-là, et elle seule, manquait hors ligne pendant que ses voisines `-updates` et `-security` sortaient du disque. Une requête conditionnelle sur ce que le cache ne détient pas part désormais sans sa condition, une fois ; et un client qui détient sa propre copie reçoit 304 plutôt que 504 quand l'amont est muet.
- Ce qu'un déploiement hors ligne couvre, exactement : les paquets, les index de dépôts et git. PAS ce que le cache n'a pas le droit de déchiffrer — un client qui porte son propre magasin de confiance, npm et poetry en sont, passe en tunnel opaque, et un tunnel ne porte rien une fois le réseau coupé. Une installation complète d'ERPLibre demande donc toujours le réseau, même si tout ce que le cache détient est servi du disque
- Un miroir est COMPLET là où `repo sync` clone en profondeur un : il coûte donc des dizaines de gigaoctets. Sous dix gigaoctets libres, aucun miroir neuf n'est créé et la requête repart vers l'amont. Le diagnostic dit ce qu'occupent les objets et les miroirs, séparément
- **Déploiement › Cache QEMU › Âge et nettoyage** groupe le cache par âge du dernier usage (jour, semaine ou mois ; objets et dépôts git séparément) et rend ce qui n'a plus servi depuis un délai choisi, ou tout. Un objet servi voit sa date remise à jour : « vieux » veut donc dire « n'a plus servi ». Les deux nettoyages disent ce qui partirait avant d'effacer quoi que ce soit, et l'entrée 5 liste les miroirs du plus lourd au plus léger pour en effacer un
- `long_test/qemu_cache.py` mesure si le cache sert vraiment la seconde VM, et `--hors-ligne` coupe l'amont du seul service du cache pour prouver qu'une troisième se bâtit encore sur l'index stocké
- Avant de couper, le formulaire dit si le cache détient la suite de base de chaque système demandé : F5 prévient « le cache ne détient rien pour ubuntu 26.04 » et un second F5 passe outre. Le verdict n'est rendu que là où une version se nomme sans ambiguïté dans l'URL — les familles apt — plutôt que de rassurer à tort ailleurs. Le verdict est rendu composant par composant — `main`, `universe`, `restricted`, `multiverse`, sur la suite de base et sur ses compagnes `-updates` et `-security` —, car une seule URL en réserve le rendait muet quand un composant entier manquait, et apt ne le disait que vingt minutes plus tard, par « Unable to locate package »
- **Déploiement › Cache QEMU › L'emporter sur une autre machine** porte le magasin vers un autre hôte ERPLibre en un seul flux — `tar`, compressé, par ssh, sans fichier intermédiaire pour des dizaines de gigaoctets — et rend les fichiers au compte du service à l'arrivée, le même compte portant rarement le même numéro sur deux machines. Seul le MAGASIN voyage : un objet est rangé sous son URL et jamais sous la machine qui l'a pris, et un miroir git est un dépôt. Les réglages restent — pont, sous-réseau et autorité appartiennent à l'hôte, et l'entrée 1 les pose là-bas
- Le formulaire de déploiement porte une section **Réseau** avec « Sans connexion internet » : pour tout le déploiement, installation comprise, le service du cache perd sa sortie ET les VM perdent la leur — ping, autres ports, UDP, IPv6 —, si bien qu'un pas qui prendrait un autre chemin que le cache échoue au lieu de réussir en ligne sans rien dire. Les noms ne se résolvent plus par l'internet non plus : l'hôte répond lui-même à tout nom une adresse que le cache intercepte, si bien que seul ce que le cache détient est joignable ; dnsmasq doit être installé sur l'hôte. Une VM derrière le cache tire d'un seul miroir apt, fixe : la recherche de miroir de cloud-init écarte tout miroir derrière un résolveur qui répond à tout nom, et retomberait sur un autre miroir que celui dont les VM précédentes ont rempli le cache. La coupure refuse au lieu de jeter : une adresse que le cache ne détient pas répond 504 sur-le-champ, et non après un délai de connexion ; un noyau qui ne peut pas charger le module du refus reçoit le jeu qui jette. Offerte seulement là où le cache tourne, et le déploiement refuse plutôt que de partir avec l'amont debout, une VM bâtie ainsi réussissant pour la mauvaise raison. **Proxmox VE** porte la même case, offerte là où son hôte est lui-même une VM de ce pont : ses invités sortent derrière son adresse, si bien que la coupure locale les couvre et que rien n'est posé sur l'hôte distant. Un hôte Proxmox qui ne vit pas ici ne la reçoit jamais — rien ici ne sait couper sa sortie
- Un déploiement Proxmox VE peut demander l'**accélération 3D**. La VM est créée avec un écran accéléré (`--vga virtio-gl`) plutôt que la console série comme affichage, et le compte entre dans les groupes du GPU DANS l'invité : le nœud de rendu appartient à « root:render », si bien que sans eux toute application GL retombe en rendu logiciel alors que la négociation VIRGL a réussi, et rien ne le signale. La case n'est offerte que là où l'hôte distant a le nœud de rendu ET les trois bibliothèques que Proxmox charge pour cet écran — VIRGL, GL et EGL. Il nomme celles qui manquent et refuse de démarrer la machine, une fois son disque écrit et sa configuration posée : un hôte portant GL sans EGL échouerait donc à la toute dernière étape. Là où une pièce manque, le formulaire dit laquelle et quel paquet poser sur l'hôte — une case qui disparaît sans un mot se lit comme une régression. Un bouton les pose sans quitter l'écran — le formulaire rend le terminal pour que sudo puisse demander un mot de passe et qu'on voie apt travailler —, puis relit l'hôte au lieu de croire apt sur parole, et la case prend la place du message. Le port série reste posé, donc « qm terminal » fonctionne toujours
- Hors ligne, le cache rejoue ce qu'un passage en ligne a vu, et non plus les seuls corps en 200 : redirections, refus définitifs (404/410) et réponses HEAD des adresses volatiles sont gardés sans corps, sous des clés à eux, et servis SEULEMENT quand l'amont est muet. Un client TUF qui sonde la version suivante de sa racine reçoit le 404 qu'il attend au lieu d'un 504 : mise pose Python hors ligne, vérification Sigstore intacte ; les extensions GNOME, l'installateur de Claude Code et la version de rtk suivent leurs redirections hors ligne
- La coupure hors ligne tombe avec la dernière installation, et non à la fermeture du suivi : une unité root, qui reçoit la levée au lancement, attend le marqueur de fin de chaque installation et survit au suivi fermé tôt, à todo.py tué ou au terminal perdu — 12 h au plus. Le suivi est donc obligatoire hors ligne. Un second déploiement hors ligne est refusé pendant qu'un premier tourne, et un déploiement en ligne lancé entre-temps est prévenu qu'il tournerait hors ligne
- F5 lit aussi les essais hors ligne précédents de la même VM et prévient « au moins N adresses ont manqué », moins ce que le magasin détient désormais (`erplibre_go_qemu_cache --detient`, en lecture seule, sans root). **Déploiement › Cache QEMU › Combler ce qui a manqué hors ligne** les rejoue en ligne, à travers le cache
- Le journal d'installation nomme le commit que la VM exécute ; hors ligne, le récapitulatif dit, branche par branche, quel commit le miroir du cache donnera
- `long_test/qemu_cache.py --distro tous` (ou une liste séparée par des virgules) enchaîne une campagne par système du catalogue, défait les VM de chaque système avant le suivant, et finit sur un tableau des verdicts, durées et octets d'amont. Un échec n'arrête pas la série
- Le cache de téléchargement QEMU peut se nettoyer chaque jour : par âge (`EL_PURGE_AGE`, ex. `90j`) et par plafond de taille (`EL_MAX_SIZE`, ex. `50G`, le moins récemment servi partant d'abord, objets et miroirs git confondus). Les deux sont désactivés par défaut et se règlent depuis **Déploiement › Cache QEMU › Nettoyage automatique**, qui montre ce qui partirait ; `--purge-to-size` applique le plafond à la main. Une réinstallation garde les valeurs choisies
- NixOS 25.11 parmi les systèmes déployables, à côté des huit autres. C'est le seul dont aucune distribution ne publie d'image cloud : l'image est rebâtie par un tiers, donc sa version est épinglée, sa somme sha256 vérifiée à chaque téléchargement, et son origine dite avant que rien ne soit créé. cloud-init n'y reçoit aucune configuration réseau — son moteur networkd prend la clé d'un bloc pour un NOM d'interface, là où netplan honore un `match:` — et le compte y est créé avec `/bin/sh`, sshd refusant un compte dont le shell n'existe pas
- ERPLibre installé sur NixOS, ses dépendances DÉCLARÉES dans `conf/nixos/erplibre.nix` puis appliquées par `nixos-rebuild`, là où les quatre autres familles les installent commande par commande. `services.envfs` répond à `/usr/bin/env` et `programs.nix-ld` donne aux roues manylinux le chargeur dynamique qu'elles réclament ; les en-têtes de ce qui n'a pas de roue sont liés au profil du système, et leurs bibliothèques vont aussi au chargeur, un module compilé sur la machine ne portant pas de RPATH. L'installation l'atteint depuis le menu comme toute autre distribution : l'amorçage pose git, make et python3 — absents de cette image — dans le profil de l'utilisateur pour la durée du clone, et « make install_os » les redéclare pour le système. Vérifié sur une VM : le verrou de 362 paquets s'installe et Odoo répond en HTTP
- Une option `nix + nixos-anywhere` sur les AUTRES distributions, l'inverse de choisir NixOS : elle laisse une VM ordinaire capable d'installer NixOS sur toute machine joignable en SSH. Nix est appelé par son chemin absolu, le PATH du shell distant étant figé avant que l'installateur ne pose le binaire, et les fonctions des flakes sont redonnées sur la ligne de commande, l'écriture de `nix.conf` réclamant un sudo qui peut manquer
- NixOS se déploie sur un hôte **Proxmox** comme sur QEMU/KVM, ce qui a demandé trois correctifs qu'aucune lecture de code n'aurait trouvés. Son image n'a pas de secteur d'amorçage BIOS : une VM créée en SeaBIOS se déclare « running » avec une console muette, donc le catalogue marque désormais les images qui exigent l'UEFI — un marqueur par distribution, Debian 13 démarrant en SeaBIOS sur ce même hôte. `--ciuser` et `--sshkeys` s'en remettent au compte par DÉFAUT de l'image, que NixOS nomme autrement : le cloud-config du dépôt part maintenant comme extrait pour toutes les distributions, avec son bloc `users:` explicite. Et le lecteur cloud-init passe sur le bus SCSI — une image bâtie pour virtio seul n'a pas de pilote ATA et ne voit jamais un lecteur IDE, si bien que cloud-init cherchait des sources réseau et que la VM arrivait sans aucun compte. Vérifié de bout en bout : NixOS rend `/bin/sh`, Debian 13 `/bin/bash`, sudo aux deux
- L'image tierce est vérifiée contre la somme que le dépôt épingle pour elle sur le chemin Proxmox aussi, où un `wget` nu suffisait. Un seul accesseur porte cette somme pour les deux chemins, et le contrôle vaut même pour une image déjà en cache — le cas visé est un fichier substitué ou tronqué entre deux déploiements, qu'un test de présence ne voit pas
- Une entrée du cache de téléchargement peut être retirée, par son URL. Une somme qui ne correspond pas n'invalidait rien : le magasin continuait de servir les mêmes octets, et retélécharger ne changeait rien puisque c'est lui qui répond. Aucune des deux purges ne l'atteint — `--purge` efface tout, et `--purge-older-than` saute ce qui est récent alors que chaque service remet cette date, si bien qu'un objet empoisonné qui sert ne vieillit jamais. `--oublie` est le symétrique de `--detient` : mêmes lignes en entrée, mêmes fonctions de clé, mêmes refus, et un objet présent qui résiste est dit refusé plutôt qu'oublié. Les deux échecs de somme le nomment désormais, avec l'URL exacte
- Le journal d'installation porte ce que l'hôte a décidé avant de lancer : l'autorité du cache de téléchargement posée ou refusée, l'exception, le miroir. Ces lignes se disaient sur une console qui défile, pendant que le fichier qu'on rouvre après un échec ne portait que le symptôme — sur un invité sans magasin de confiance, un certificat refusé, des centaines de dérivations à construire et six cents lignes d'erreurs, sans un mot sur la cause
- Une entrée du cache de téléchargement s'oublie depuis le menu, sous « Âge et nettoyage ». Le binaire savait déjà le faire ; le menu n'offrait que les deux purges en gros, dont aucune ne vise un objet — « effacer ce qui n'a plus servi » n'atteint jamais celui que le service rajeunit chaque fois qu'il le rend, et « tout effacer » coûte le cache entier pour un fichier. `--detient` passe d'abord et fait l'aperçu : même ligne, même clé, sans rien modifier
- `erplibre_go_qemu_cache --recle` range à nouveau les objets d'un cache sous la clé courante, sans rien retélécharger, et fond les copies qu'un miroir portait sous plusieurs chemins. Les objets écrits sous l'ancienne règle de clé restent sur le disque mais deviennent INTROUVABLES, si bien que le service les redemande à l'amont et que la place qu'ils tiennent ne sert plus personne : sur un magasin de 12 764 objets, 5 419 étaient dans ce cas — 9,11 Gio — et la fusion des doublons a rendu environ 3,37 Gio. Le service doit être arrêté, le corps étant renommé avant son méta, et `--dry-run` ne fait que compter ce qui bougerait. Un statut seul n'est pas touché, sa clé portant l'hôte et non le chemin
- Le hook `pre-commit` lance `check_python_version.py` sur les fichiers indexés : il signale le source qui ne parse pas sous le Python de `conf/python-erplibre-version`, sans bloquer le commit, et dit quand aucun interpréteur de cette version n'était là pour vérifier. Ni black ni flake8 ne voient ce défaut — la cible de black borne ce qu'il écrit, jamais ce qu'il accepte
- `Déploiement › Local › [4]` ouvre un proxy SOCKS par SSH — `ssh -D`, port 1080 par défaut — pour que le navigateur atteigne, DEPUIS la machine distante, une interface qui n'écoute que sur sa boucle locale ou un hôte de son réseau. L'adresse vient de `~/.ssh/config` ou de la saisie ; un alias part tel quel à ssh, si bien que son `ProxyJump` s'applique encore et qu'une VM imbriquée reste joignable. Le réglage de Firefox s'affiche avant l'ouverture du tunnel, la commande ne rendant la main qu'au Ctrl+C
- `make format_test` formate `test/` et `long_test/`, qu'aucune cible ne couvrait : 75 fichiers sur 210 ne suivaient aucune norme, et seul un fichier signalé par un diff était touché
- `script/reverse_proxy/main.py` — un mandataire inverse de développement pour Odoo 18, sans nginx : une seule adresse envoie les pages au port web et `/websocket` au port du bus, les en-têtes `X-Forwarded-*` de `proxy_mode` n'étant posés que par le mandataire (`--trust-forwarded` prolonge plutôt une chaîne, derrière un autre mandataire). Seule la tête de la requête est lue : une WebSocket montée reste ouverte et une réponse gzip ou en morceaux passe octet pour octet. Il sert en HTTPS avec `--tls-cert`/`--tls-key`, écrit une ligne par requête (route, statut, durée ; `--quiet` la coupe), dit au démarrage quel port d'Odoo ne répond pas, et nomme ce port dans un 502. La tête d'une requête attend 30 s (408) et la connexion à Odoo 10 s (504), jamais une WebSocket ouverte. Écoute par défaut sur `127.0.0.1:8080`, `--listen 0.0.0.0` l'ouvre au réseau ; une requête par connexion, la production garde nginx
- `script/reverse_proxy/local_cert.py` émet une autorité locale, importée une fois dans le navigateur, et un certificat serveur qu'elle signe pour localhost, le nom d'hôte et ses adresses, sous `~/.erplibre/reverse_proxy_tls/` avec des clés en 0600 ; l'autorité est gardée quand le certificat est réémis
- `TODO › Execute › Network › Mandataire inverse Odoo` le lance avec les ports web et bus lus dans `config.conf`, demande cette machine seule ou tout le réseau et HTTP ou HTTPS, émet le certificat local au premier usage en HTTPS, et prévient quand `proxy_mode` est éteint ou que `workers` vaut 0 — sans worker, aucun port de bus n'écoute et `/websocket` échoue. `Network › Certificats TLS locaux` le réémet avec d'autres noms
<!-- [en] -->
## Changed
<!-- [fr] -->
## Modifié
<!-- [en] -->
- `Assistant › [1]` no longer sends every question to a single remote API on a fixed model: it asks whichever server is configured, and falls back to the remote one only when no local server answers
- The comment hygiene check reads Go comments, not only `#` ones: `//` outside a string, the raw string between backticks, and `/* … */` blocks
- Debian and Ubuntu `by-hash` index files are served from disk, their name being the digest of their content; `…/releases/latest/download/…` is no longer pinned to the first version seen
- An upstream that refuses or drops connections is remembered for 20 s: a request with a stored answer is served at once instead of waiting its connect timeout, which made up most of an offline install's time; a request with nothing stored still tries upstream. A git mirror skips its refresh while its forge is unreachable
- Mirror prefetch runs under the cache's service account, never as root
- The long-test menu asks before creating real machines, and asks again, in words of its own, before `--detruire` removes machines with their disks. The command is shown first, which is what makes the question answerable; a dry run or a performance report creates nothing and asks nothing
- Every entry of the Proxmox VE menu carries an icon, the same picture meaning the same action as in the other menus of the tool
- The QEMU cache binary speaks English or French: service journal, `--status`, `--age`, option help and the error served to a VM. The language comes from `--lang`, then `EL_LANG`, then French; the installer writes `EL_LANG` to the service settings and the TODO menu passes its own. Rules, verdict codes and JSON keys are never translated
- A repository index the cache already holds is revalidated with its ETag rather than downloaded again: upstream still judges every request, and a « 304 » serves the stored body from disk. On a full ERPLibre install the pip indexes, npm metadata and repo bundle had been about 110 MB per VM, taken whole each time. An index stored without its host — shared by every mirror of a rotating list — and an answer carrying no ETag are taken whole as before; the access log names the new outcome `revalidated`
- A registry page served under `Vary: Accept` keeps one copy per representation. npm asks for the same `/npm` page abridged, then complete, then abridged again; kept under one key they replaced each other and the 31 MB were fetched on every install. Each representation is now revalidated and, offline, served on its own; `--detient` still reads the page under its URL alone
- A VM deployed with the cache upstream cut — QEMU form, Proxmox VE, or `deploy_qemu.py --offline` — has npm's security audit turned off (`NPM_CONFIG_AUDIT=false`): it queries a remote service no cache can replay, and failed on every offline install. An online VM keeps its audit
- Verifying a downloaded image no longer needs `--verify`: it runs by default for every distribution that publishes a sum, and `--no-verify` is what skips it — to be kept for offline runs, where a substituted image would otherwise pass unremarked
- `--bios` is refused on an image with no BIOS boot sector, and says why. Forced there, it gave a VM reported « running » with a silent console — the very failure that flag exists to avoid elsewhere
- The tooling virtual environment `.venv.erplibre` runs Python 3.14.7, independently of the Odoo one (3.12.10 for Odoo 18.0). `install_erplibre.sh` builds it through `install_venv.sh` and `EL_PYTHON_PROVIDER` instead of the system `python3`
- `.venv.erplibre` on an incompatible Python is DELETED and rebuilt; whatever was installed in it by hand goes with it. Odoo's venv is kept when it merely differs in version, and rebuilt only when it is unusable: rebuilding it redoes a whole Poetry install. A directory without `pyvenv.cfg` is never deleted
- `make` and `make todo` run `./todo.sh`, a launcher whose name says a menu opens and not an installation; it hands every argument to `install.sh`, which picks an interpreter able to READ the code before running it: `.venv.erplibre` on the right version, else a recent enough system `python3`, else the install, which runs only on a yes typed in a terminal (`o`, `oui`, `y`, `yes`) since it can delete `.venv.erplibre`. A system older than `conf/python-erplibre-version` would otherwise stop on a syntax error raised before any guard could name the command to type. TODO then relaunches itself in `.venv.erplibre`, or offers to run `install_erplibre.sh` in a terminal
- The production Docker image builds `.venv.erplibre` on Odoo's Python and stops when that Python cannot parse `script/`
- Debian 11 is dropped from the deployment catalogue: its LTS ended, and its security suite is neither served nor archived — the index it still publishes names packages whose pool no longer holds the file, so apt stops before installing git. Debian 13 takes its place, its cloud image always being the latest point release
- Every container image is built on bookworm, whatever the Odoo version. The base is `python:<version>-slim-<suite>`: the interpreter comes from the official image, never from Debian, and the bookworm variants exist down to 3.7.17. The wkhtmltopdf build follows the suite — bullseye's requires libssl1.1, absent from bookworm
- The PATCH bounds only Odoo's venv, whose pyproject requires `>=3.12.10,<3.13`. For the tooling one, the major.minor is enough: requiring the patch turned away a distribution's Python one step behind — NixOS 25.11 ships 3.14.2 where conf asks 3.14.7 — and made pyenv COMPILE CPython for a difference nothing needs
- `make format` picks the formatter from each file's context: an Odoo module keeps isort and black on `py37`, the series still supported going down that far, while this repository's own tooling goes through ruff, configured once in `.ruff.toml`. ruff follows CPython's versions, where black 24.8.0 stops at `py313`, and its import sorting replaces isort; it is also what the OCA standard uses since it left black
- The repositories that Google Repo checks out under `script/` are excluded from that formatting, a named path included: reformatting them would write in someone else's history. `target-version` stays at `py310` there, because the git hooks carry `#!/usr/bin/env python3` and a distribution still ships 3.10 — from 3.14 on, ruff would write `except A, B:` without parentheses
- The list of Claude Code commands in `TODO › Execute › GPT code › Claude configs` compares each ERPLibre template in `conf/` with its copy in `~/.claude/commands/`: a command not installed is shown, an outdated copy is marked with its count of added and removed lines, and a command that comes from elsewhere is labelled as such. On a yes it prints the diff, then redeploys the outdated copies, keeping the git name and e-mail `/commit` carried
- A commit message opens on an English subject and an English body; `--- FR ---` then opens the French section, which starts with the subject translated under the same tag. The `commit-msg` hook refuses a `--- EN ---` marker and a French section without that title, and checks the title like a subject. `/commit` and `/git_prepare_merge` follow the same order
- TODO menus: the language is set only from Configuration, the duplicate entry in Execute is gone, and Fork moves from the main menu to Configuration. The main menu now numbers Telemetry 4 and Configuration 5. The language chooser shows a flag per language
- Odoo 18 dependencies refreshed. `openai` is pinned to 2.x, whose 3.x requires an `idna` that Odoo 18 forbids; `fsspec` is pinned beside `s3fs`, which demands it at its own exact version, so the two move together; `meteostat` returns to 1.x, every 2.x capping `pytz` below 2024. PyMuPDF stays excluded on s390x, now declared in the requirements so a regeneration keeps it. Major bumps of `ujson` 6, `plotly` 7, `python-slugify` 9 and `sqlalchemy` 2.1 are not yet tested
- Dependabot ignores the major versions of `meteostat`
- Odoo 18 moves to pandas 3.0.6, cryptography 50 with pyopenssl 26.4, Pillow 12.3 and botocore/boto3 1.43.75 with aiobotocore 3.9.1, the highest botocore its narrow range accepts. The seven modules that import pandas run their pandas calls unchanged; `freq='d'` in a Cybro attendance dashboard now warns and will break with pandas 4
- Dependabot groups `aiobotocore`, `botocore` and `boto3` into one pull request, since each aiobotocore accepts only a narrow botocore range; security fixes still arrive on their own
- `TODO › Transform data` reads Excel with openpyxl 3.1.5 and xlsxwriter 3.2.9; the leak test that guards openpyxl's exact pin passes on them
- factur-x requires 6.8 outside s390x, the version already locked, so a regeneration can no longer fall back to an untested 4.x or 5.x
- The interface chooser of the QEMU deployment and of the Odoo migration, and its preferences in `TODO › Configuration`, mark the TUI form with 📋 and the line by line questions with 💬
<!-- [fr] -->
- `Assistant › [1]` n'envoie plus chaque question à une seule API distante sur un modèle figé : elle interroge le serveur configuré, et ne retombe sur le distant que lorsqu'aucun serveur local ne répond
- Le contrôle d'hygiène des commentaires lit le Go, et non les seuls `#` : `//` hors d'une chaîne, la chaîne brute entre accents graves, et les blocs `/* … */`
- Les index `by-hash` de Debian et d'Ubuntu sont servis du disque, leur nom étant l'empreinte de leur contenu ; `…/releases/latest/download/…` n'est plus figé sur la première version vue
- Un amont qui refuse ou ignore les connexions est retenu 20 s : une requête qui a une réponse gardée est servie aussitôt au lieu d'attendre son délai d'établissement, qui faisait l'essentiel du temps d'une installation hors ligne ; une requête sans rien en réserve tente toujours l'amont. Un miroir git saute son rafraîchissement tant que sa forge est injoignable
- Le pré-remplissage des miroirs tourne sous le compte du service du cache, jamais en root
- Le menu des tests longs demande avant de créer de vraies machines, et redemande, avec des mots à lui, avant que `--detruire` efface des machines avec leurs disques. La commande est montrée d'abord, c'est elle qui rend la question répondable ; un plan à blanc ou un rapport de performance ne crée rien et ne demande rien
- Chaque entrée du menu Proxmox VE porte une icône, la même image voulant dire la même action que dans les autres menus de l'outil
- Le binaire du cache QEMU parle anglais ou français : journal du service, `--status`, `--age`, aide des options et erreur servie à une VM. La langue vient de `--lang`, puis d'`EL_LANG`, puis du français ; l'installateur écrit `EL_LANG` dans les réglages du service et le menu TODO passe la sienne. Règles, codes de verdict et clés JSON ne se traduisent jamais
- Un index de dépôt que le cache détient déjà est revalidé par son ETag au lieu d'être retéléchargé : l'amont juge toujours chaque requête, et un « 304 » sert le corps gardé depuis le disque. Sur une installation complète d'ERPLibre, les index pip, les métadonnées npm et le bundle de repo pesaient environ 110 Mo par VM, repris en entier à chaque fois. Un index rangé sans son hôte — partagé par tous les miroirs d'une liste qui tourne — et une réponse sans ETag sont repris en entier comme avant ; le journal d'accès nomme la nouvelle issue `revalidated`
- Une page de registre servie sous `Vary: Accept` garde une copie par représentation. npm demande la même page `/npm` abrégée, puis complète, puis de nouveau abrégée ; rangées sous une seule clé, elles se remplaçaient et les 31 Mo repartaient à chaque installation. Chaque représentation est désormais revalidée et, hors ligne, servie à part ; `--detient` lit toujours la page sous sa seule URL
- Une VM déployée l'amont du cache coupé — formulaire QEMU, Proxmox VE, ou `deploy_qemu.py --offline` — a l'audit de sécurité de npm désactivé (`NPM_CONFIG_AUDIT=false`) : il interroge un service qu'aucun cache ne rejoue, et échouait à chaque installation hors ligne. Une VM en ligne garde son audit
- Vérifier une image téléchargée ne demande plus `--verify` : c'est le défaut pour toute distribution qui publie une somme, et `--no-verify` est ce qui la saute — à réserver aux essais hors ligne, où une image substituée passerait autrement sans un mot
- `--bios` est refusé sur une image sans secteur d'amorçage BIOS, et dit pourquoi. Forcé là, il donnait une VM « running » à console muette — la panne même que ce drapeau évite ailleurs
- L'environnement virtuel d'outillage `.venv.erplibre` tourne en Python 3.14.7, indépendamment de celui d'Odoo (3.12.10 pour Odoo 18.0). `install_erplibre.sh` le bâtit par `install_venv.sh` et `EL_PYTHON_PROVIDER` plutôt qu'avec le `python3` du système
- `.venv.erplibre` sur un Python incompatible est SUPPRIMÉ puis rebâti ; ce qu'on y avait posé à la main part avec lui. Le venv d'Odoo est conservé quand seule sa version diffère, et rebâti seulement s'il est hors service : le rebâtir refait une installation Poetry entière. Un répertoire sans `pyvenv.cfg` n'est jamais effacé
- `make` et `make todo` lancent `./todo.sh`, dont le nom annonce un menu et non une installation ; il passe chaque argument à `install.sh`, qui choisit un interpréteur capable de LIRE le code avant de le lancer : `.venv.erplibre` s'il porte la bonne version, sinon le `python3` du système s'il est assez récent, sinon l'installation, qui ne part que sur un oui tapé au terminal (`o`, `oui`, `y`, `yes`) puisqu'elle peut supprimer `.venv.erplibre`. Un système plus ancien que `conf/python-erplibre-version` s'arrêterait autrement sur une erreur de syntaxe levée avant qu'aucun garde puisse nommer la commande à taper. TODO se relance ensuite dans `.venv.erplibre`, ou propose de lancer `install_erplibre.sh` en terminal
- L'image Docker de production bâtit `.venv.erplibre` sur le Python d'Odoo et s'arrête quand ce Python ne sait pas lire `script/`
- Debian 11 quitte le catalogue de déploiement : son LTS est terminé, et sa suite de sécurité n'est ni servie ni archivée — l'index qu'elle publie encore nomme des paquets dont le pool ne porte plus le fichier, et apt s'arrête avant d'installer git. Debian 13 la remplace, son image cloud étant toujours le dernier point de version
- Toutes les images de conteneur reposent sur bookworm, quelle que soit la version d'Odoo. La base est `python:<version>-slim-<version Debian>` : l'interpréteur vient de l'image officielle, jamais de Debian, et les variantes bookworm existent jusqu'à 3.7.17. Le build de wkhtmltopdf suit la version — celui de bullseye réclame libssl1.1, absente de bookworm
- Le PATCH ne borne que le venv d'Odoo, dont le pyproject exige `>=3.12.10,<3.13`. Pour celui de l'outillage, la majeure.mineure suffit : exiger le patch écartait le Python d'une distribution d'un cran en retard — NixOS 25.11 livre 3.14.2 quand conf demande 3.14.7 — et faisait COMPILER CPython à pyenv pour une différence que rien ne réclame
- `make format` choisit le formateur d'après le contexte de chaque fichier : un module Odoo garde isort et black en `py37`, la série la plus ancienne encore supportée, quand l'outillage de ce dépôt passe par ruff, réglé une fois dans `.ruff.toml`. ruff suit les versions de CPython, là où black 24.8.0 s'arrête à `py313`, et son tri d'imports remplace isort ; c'est aussi ce qu'emploie la norme OCA depuis qu'elle a quitté black
- Les dépôts que Google Repo rapatrie sous `script/` sont écartés de ce formatage, chemin nommé compris : les reformater écrirait dans l'historique d'autrui. `target-version` y reste à `py310`, parce que les hooks git portent `#!/usr/bin/env python3` et qu'une distribution livre encore 3.10 — à partir de 3.14, ruff écrirait `except A, B:` sans parenthèses
- La liste des commandes Claude Code de `TODO › Execute › GPT code › Claude configs` compare chaque gabarit d'ERPLibre de `conf/` à sa copie de `~/.claude/commands/` : une commande non installée est affichée, une copie périmée est marquée de son compte de lignes ajoutées et retirées, et une commande venue d'ailleurs est signalée comme telle. Sur un oui, elle affiche le diff, puis redéploie les copies périmées en gardant le nom et le courriel git que portait `/commit`
- Un message de commit s'ouvre sur un sujet et un corps en anglais ; `--- FR ---` ouvre ensuite la section française, qui commence par le sujet traduit sous le même tag. Le hook `commit-msg` refuse un marqueur `--- EN ---` et une section française sans ce titre, et juge ce titre comme un sujet. `/commit` et `/git_prepare_merge` suivent le même ordre
- Menus de TODO : la langue se règle seulement depuis Configuration, l'entrée en double dans Execute disparaît, et Fork quitte le menu principal pour Configuration. Le menu principal numérote désormais Télémétrie 4 et Configuration 5. Le choix de la langue montre un drapeau par langue
- Dépendances d'Odoo 18 rafraîchies. `openai` est épinglé en 2.x, dont la 3.x exige un `idna` qu'Odoo 18 interdit ; `fsspec` est épinglé à côté de `s3fs`, qui l'exige à sa propre version exacte, si bien que les deux se montent ensemble ; `meteostat` revient en 1.x, toute 2.x plafonnant `pytz` sous 2024. PyMuPDF reste écarté sur s390x, désormais déclaré dans les requirements pour qu'une régénération le garde. Les montées majeures de `ujson` 6, `plotly` 7, `python-slugify` 9 et `sqlalchemy` 2.1 ne sont pas encore testées
- Dependabot ignore les versions majeures de `meteostat`
- Odoo 18 passe à pandas 3.0.6, cryptography 50 avec pyopenssl 26.4, Pillow 12.3 et botocore/boto3 1.43.75 avec aiobotocore 3.9.1, le plus haut botocore que sa plage étroite accepte. Les sept modules qui importent pandas exécutent leurs appels pandas sans changement ; `freq='d'` dans un tableau de bord de présence Cybro avertit désormais et cassera avec pandas 4
- Dependabot réunit `aiobotocore`, `botocore` et `boto3` dans une seule demande de fusion, chaque aiobotocore n'acceptant qu'une plage étroite de botocore ; les correctifs de sécurité arrivent toujours seuls
- `TODO › Transform data` lit Excel avec openpyxl 3.1.5 et xlsxwriter 3.2.9 ; le test de fuite qui garde l'épingle exacte d'openpyxl passe sur eux
- factur-x exige 6.8 hors s390x, la version déjà verrouillée : une régénération ne peut plus retomber sur une 4.x ou 5.x non testée
- Le choix d'interface du déploiement QEMU et de la migration Odoo, et ses préférences dans `TODO › Configuration`, marquent le formulaire TUI d'un 📋 et les questions ligne par ligne d'un 💬
<!-- [en] -->
## Fixed
<!-- [fr] -->
## Corrigé
<!-- [en] -->
- Reading the dnsmasq leases no longer opens a root password prompt: the files are read directly, which suffices on a standard install where they are 0644, and only then is `sudo -n` tried, which fails instead of asking. Displaying a VM list called that path once per VM, and waiting on a VM called it every three seconds for ten minutes
- `--max_process` runs again on Python 3.10 and later: `loop=` left `asyncio.wait` in 3.10 and `asyncio.get_event_loop()` raises outside a running loop since 3.14, so the pool was not even constructible while the help still advertised the flag
- A prompt no longer writes its colon twice — the most-seen menu of the software asked « Command:: », and seven remote-deployment prompts showed a colon followed by another
- Eleven submenus now leave their segment in the breadcrumb, and navigation telemetry stops filing them as commands under their raw method name
- The three readers of `~/.ssh/config` agree on what a machine name is: an alias declared with a lowercase `host` is seen, a tab separates as legally as a space, and a negated `!name` pattern is no longer taken for a machine to connect to
- Three translation keys declared twice are gone, and a check refuses the next one: a repeated key silently overwrites the previous, which had already cost a menu label
- `anonymize.py` abstains from a unique numeric column and NAMES it in the report. A draw guarantees nothing on a unique column, and a number has no way out where text has one — appending the id carries uniqueness for text, but would change a number's magnitude. Two rows drawing the same number failed the UPDATE and, the whole run being one transaction, took the entire anonymisation with them. Without the report naming it, an identifying column stays in the clear with nothing saying so
- Restoring a backup no longer raises `AttributeError` before running the command: `_monitoring_restore` read `self._execute` where `TODO` sets `self.execute`, and both entries leading there — the local backup and the remote one — were broken. A check refuses the next one: every `self.X` that `TODO` READS must be set by TODO or by one of its bases. Searching the name across `script/todo/` did not see the fault, another object of the package setting `_execute`; it has to be searched in the classes TODO INHERITS from
- The Selenium scripts run on a Python built without `tkinter` — any server with no graphical toolkit package. That module is only needed by the vault's file picker, so it is now optional: with no `tkinter` and no configured KDBX path, opening the vault logs an error and returns, instead of breaking the import of every browser-automation script
- Dark mode works again in a private window on a current Firefox. The « Run in Private Windows » permission is granted when the addon is installed, through the `allowPrivateBrowsing` field, rather than clicked through the `about:addons` interface: Firefox refuses navigation to `about:addons` from the content context, and the chrome context demands `-remote-allow-system-access`, which geckodriver rejects through capabilities, so both routes to that checkbox are closed. A geckodriver that ignores the field installs without the permission instead of killing the session
- The « - Default » label appears again at the version and environment menus: both reads asked for a capitalised key the version file never writes, and a missing key returns nothing without a word
- The cache's « nothing in store » message is inert as a shell script, every line being a comment. Fed to an installer built on `curl … | bash`, it used to become a cascade of « command not found » that hid the real cause. Such a download now also asks curl to fail on an HTTP error rather than execute the error page
- The wait for a VM to be ready now covers the guest-agent install too. That one is launched as a DETACHED unit so cloud-init returns in seconds, and it runs an `apt-get update`: `cloud-init status --wait` said « done » while the package lock was still held, the next step burnt through its retries, and the install then ran on an index never refreshed — « Unable to locate package », a message that blames the repository rather than the lock. An update that never succeeds now says so on the spot
- A desktop install no longer waits minutes on the apt lock: the apt-daily SERVICE is stopped and not only its timer, a timer being disabled without interrupting the apt-get it already started; and the retry comes back every two seconds rather than every ten, `DPkg::Lock::Timeout` not covering the list lock at all
- Fedora VMs boot again: the firmware loads and starts their loader, then freezes without writing a byte — no console, no DHCP lease, a machine "running" that does nothing. Fedora is booted in legacy BIOS, where the same image starts its kernel; `--bios` still wins when asked
- A VM receives a hostname it can accept — an underscore, which a libvirt domain name tolerates, made it keep its image's generic name — and a timezone its own distribution knows, a legacy alias having left it in UTC
- starship installs in a VM: its installer runs as root, bounded by a root timeout, so it never reaches the `sudo -v` that sudo-rs refuses; its shell hook no longer prints « command not found », nor fails a sourced rc, when starship is absent
- Each optional tool says whether it was installed, and a GNOME extension whose download failed is no longer reported as unavailable for this GNOME
- mise, pyenv and GNOME extensions are downloaded, then run: without pipefail, `curl | sh` could neither report a failed download nor reach its fallback
- The guest-agent unit no longer ends in failure after a successful install
- The cache answers 508 to a request that targets the cache itself, instead of calling itself until it runs out of descriptors
- The cache diagnosis no longer reports a stopped service as running
- The wait for `apt-get update` is bounded by a deadline rather than by a number of attempts. An attempt fails in under a second on a held lock, but takes minutes when the cache answers 504 on every index it does not hold: sixty attempts were then worth hours of silence where five minutes were promised, and the install went on to fail on unmet dependencies
- A Proxmox guest is pinned to the same apt mirror as the rest of the fleet, written over ssh before anything downloads. The store keys its indexes by HOST, so a VM left on the default repositories of its image found none of what the cache had been filled with — offline, every one of those indexes was missing
- The cache installer accepts a bridge and a subnet given by hand. It probed libvirt first and died on « network default not found », so the workaround its own header advertised — `EL_BRIDGE` and `EL_SUBNET` — could never be reached. A machine whose libvirt network is not started, or which carries its bridge otherwise, can now lay the cache down by naming it; and when the probe does run and fails, it names both ways out
- **Deployment › QEMU cache › Install or reinstall** no longer announces « installed and started » when the installer failed. It caught exceptions only: a non-zero exit — a missing libvirt network, a build that gave way — printed the success line right under the error itself, along with the path of an authority that does not exist
- A Proxmox guest receives its guide, its timezone, its apt mirror and the cache authority again. All four go by ssh and used to start as soon as an address was known, while cloud-init was still creating accounts and keys: they failed together, and the VM was born in UTC, guideless, without the authority and on its image's repositories. The deployment now waits for the machine to answer ssh — five minutes at most — and says so when it never does, rather than failing four times in a row
- The cache no longer serves a repository index newer than the signature that announces it. Offline, each object came out with its own date: an index refreshed on Saturday under a Friday `InRelease` made apt fail on « File has unexpected size » or « Hash Sum mismatch », and the install stopped on unmet dependencies — a message that blames the repository, never the cache. The comparison is made on the upstream `Last-Modified`, never on the storage date, which is renewed on every hit
- The refusal to copy the cache to another machine names the gesture that lifts it, and that gesture is not entry 1 — entry 1 installs the cache HERE, so following it reinstalled the host that already had one while the target stayed empty. Three situations were reported as a single « no cache installed »: an ssh link that never ran the probe, a target carrying no cache, and a target whose cache lacks its service account. Each has its own message now, and the missing-cache one lists the steps to run ON the target, the two ways past an installer that reads the « default » libvirt network included — start libvirt, or name the bridge, a stopped libvirt making it die on a network that exists. The steps also name the branch to put the target on, read from this host: the installer is a file of the repository, so a machine left on another branch answers « no such file », which looks nothing like a missing cache. A fourth case is checked before a single byte leaves: sudo asking for a password on the target, which no terminal can answer since the store itself occupies ssh's standard input — the message gives the ticket to obtain there first. The arrival is asked for the privilege ONCE, `tar` and `chown` under a single invocation. Where sudo there wants a password, the entry offers two ways out instead of failing: the one-off sudoers line that allows it, or a two-step mode — the store is sent into the target's own account, which needs no privilege at all, and a printed command extracts it from a terminal there, where a password can be typed. That mode needs twice the store on the target, checked before a byte leaves, a cache holding only already-compressed packages and git archives. The guide carries the same section
- The Proxmox VE deployment form checks the cache before cutting the network, as the libvirt one already did: what the store lacks, no cut VM will read, and the failure used to land an hour later, at the desktop step — a message that blames the repository, never the cache. F5 again means going ahead anyway. Both forms now share a single verdict instead of two copies of it, which would have drifted apart at the first adjustment
- The cache keeps its repository indexes when a mirror list rotates. An index published under the hash of its content — `by-hash/SHA256/…` — was stored under a key carrying the host, so the same bytes served by a second mirror were fetched again; offline they were simply missing, and the install failed on files the store already held, with a message that blames the repository. Such an object is now keyed by its path alone, its name BEING the checksum of its content
- The cache diagnosis no longer reports « no redirection rule is posted » when it simply could not read them. On a host whose sudo asks for a password, `sudo -n nft` returns nothing, and that silence was read as an absence of rules — sending the operator to reinstall a cache that was redirecting correctly. The reading now carries a third state, « cannot tell », marked with a dot rather than a cross, exactly as the upstream-cut reading already did
- A lifted cut gives the upstreams their chance back at once. The service remembers, for a short while, which upstreams just failed to connect, so that an offline install does not pay the connection delay hundreds of times; nothing told it the cut was over, and the first requests after the lift fell back on the store while the network was already back. The lift now touches a witness file inside the store, which that memory consults — there is no channel at all to the running service
- Before cutting, the form also warns about what no index can reveal: a package the deployment lays down OUTSIDE the watched thread — the guest agent, installed by a detached unit whose failure surfaces nowhere — and the git repositories declared by the manifests that have no mirror yet. A held suite index was enough to call the cache complete while not one byte of that package had ever crossed it; and a git negotiation is never stored, so a repository without a mirror simply cannot be cloned once the network is gone
- The mirror warning counts only the repositories of the Odoo version being deployed. It used to add up every manifest in the repository — the deprecated one included — and announced 170 missing mirrors where a real Odoo 18 deployment meets four: an alarm that fires for nothing is one that stops being read. Filling the mirrors still takes every version ahead, which is its purpose
- A host banned from decryption on a burst of transport errors gets another chance. Three failed handshakes in a row put it in an opaque tunnel, and a tunnel never consults the store: a distribution mirror condemned by a few corrupted records sent all its traffic back upstream, including the hundreds of objects already held for it, until the service was restarted. A TLS alert still bans for good — the client looked at our certificate and refused it — but a repeated cut is only a suspicion, and it reopens after ten minutes
- **Deployment › QEMU cache › Git mirrors** fills the base of the active Odoo version, or its extra modules, on their own — beside the full fill of every manifest, which takes hours. Each list shows how many repositories it declares and how many still lack a mirror. What a deployment clones is now read with the manifest merge's own rule and lists, so the extra modules, installed only on request, and the mobile project no longer count: the offline warning announced four missing mirrors that a default Odoo 18 install never clones
- pip's PEP 658 metadata — the `.whl.metadata` file fetched before each wheel — is served from disk. The name ends in `.metadata`, which no rule knew, so each file was taken again on every install: 178 of them on a full ERPLibre install. Copies stored before this change are not reached again; the next online install refills them
- The timezone a deployed VM inherits from its host is translated to its canonical name. Ubuntu 24.04 cloud images no longer carry the legacy aliases — `Canada/*`, `US/*`, `Asia/Calcutta` — moved to a `tzdata-legacy` package they do not install: cloud-init refused the zone, the VM stayed on UTC, and the only sign was cloud-init reporting an error, the offset showing up in timestamps long afterwards. The alias table is the host's own `tzdata.zi`, not a copy kept in the code
- `make` looks for bash instead of assuming `/bin/bash`. That path does not exist on NixOS, where the shell lives in the store, and make stopped before running any recipe — including the one that installs what creates that path. Elsewhere the resolved shell is the same one as before
- The locale and the keyboard a deployed VM is given now apply on Debian, where both silently failed. A locale is generated from `/etc/locale.gen` and nowhere else, so `update-locale` refused one that was not there and the VM stayed on C.UTF-8; the keyboard module ends on a `console-setup` the genericcloud image does not carry, so `/etc/default/keyboard` — the file localed and X read — is written directly instead. Every Debian deployment used to print `cloud-init: status: error`, and a word that always shows warns of nothing
- A guest with no per-file trust anchor is taken out of the download cache instead of being intercepted without one. Interception is transparent and covers the whole bridge, so a VM given no authority still fails every HTTPS download on « self-signed certificate in certificate chain » — and on a declarative system placing the authority comes too late, the first rebuild being the first download. On a Proxmox host it is the HOST that is exempted: a nested guest leaves masqueraded behind it and the bridge never sees its own address. Measured from inside the guest: code 000 and SSL verification 19, then 200 and 0. Without it the package manager fell back to building 564 derivations, whose sources failed for the same reason
- NixOS learns the download cache's authority WITHOUT a rebuild, so it is no longer taken out of the cache — which used to close offline deployment to it, the store being the only source there and an exempted VM having none. It has no per-file trust anchor and /etc is generated read-only, while a declaration would come too late, the first rebuild being the first download. The authority is therefore POINTED AT, consumer by consumer, through the environment — and the environment is lost at three boundaries the four imperative families never meet. nix-daemon is socket-activated and sees no session: a drop-in under /run/systemd/system, a tmpfs writable where /etc is not, reaches it. sudo wipes it, and root's nix talks straight to the local store rather than the daemon, downloading on its own: `Defaults env_keep` carries the variables across, visudo being reached through the system profile since cloud-init's PATH there holds no sudo. And the ssh session opens one second before cloud-init writes the bundle, so the exports live inside the wait for it rather than at the head of the command. The bundle concatenates the system authorities with the cache's, giving the cache's alone would stop trusting everything else. Checked on a fresh VM with upstream CUT: nix-shell realises from the store; and with the cache intercepting, a complete install ends with no certificate refusal
- Odoo answers from outside a NixOS VM. It listened on 0.0.0.0:8069 and replied locally, but NixOS enables a firewall by default where none of the four other cloud images does: the host received nothing — not a refusal, silence until the timeout — and the monitor declared Odoo absent on a machine where it was running. Measured from the host: 000 after 12 s, then 303 in 9 ms
- ERPLibre runs as a service on NixOS. The install ended by writing a unit into `/etc/systemd/system`, generated from the store and mounted read-only: it returned 1 at its last step, after the clone, the venv and an Odoo start had all succeeded. The unit is now declared by the module; its interpreter comes from the store, `/bin` being an envfs FUSE mount that systemd does not see when it resolves the executable; and its PATH carries bash, whose absence stopped `run.sh` before Odoo
- What a declarative system must declare, and the four others receive free from their cloud image: xmlsec1, without which Odoo refuses to install auth_saml, a module of the addons path; parallel and shfmt, called by bare name; growpart, absent from the whole system while the disk grow is written « … || true » and returned 0 without growing anything; and the guest agent, which came from the image rather than the repository, its unit PATH lacking findmnt so that guest-exec died with 127 on its first line
- The connection guide is displayed on NixOS. Deployment writes `/etc/motd` everywhere and relies on pam_motd to show it — true of the four cloud images, false here, where sshd reports « printmotd no » and the PAM stack holds no pam_motd: the guide was written, complete, and nobody read it. It also gains a NixOS block naming the trap it exists for — `/etc/nixos/erplibre.nix` is rewritten by `make install_os`, and declarations added there vanish without a word
- « make db_drop_all » no longer announces databases as dropped that were not. It built a parallel command, discarded its exit status and printed the list; the case is reachable as soon as parallel is missing from the PATH, and the operator moves on believing their databases are gone
- A download cache mirror refused for lack of space names its threshold and its measurement. It echoed a field every ordinary caller leaves at zero — « less than 0 B free on disk » announces no threshold and does not say what was measured
- A downloaded image is checked against the sum its publisher ships, for every distribution that publishes one and WITHOUT asking. The check existed behind a flag and for Ubuntu only, so the other images arrived with nothing looking at them. Six now enter, read off the repositories rather than guessed: Debian publishes sha512 where everything else is sha256, the RHEL families name the file « CHECKSUM », Rocky writes the BSD form, and Arch and openSUSE ship a sum per image. An unreachable sums file no longer stops a deployment — that is an availability failure — while a mismatch still stops everything and removes the image
- The locale a deployed VM is given applies on NixOS. cloud-init applies it through locale-gen and update-locale, absent there, and the VM kept the distribution's default — « fr_CA.UTF-8 » asked for, « en_US.UTF-8 » obtained. Both it and the timezone are declared by the module now, and neither is imposed on a NixOS one already had
- The connection guide fits an 80-column terminal even on a VM carrying its tools and a desktop, where it rendered 103 columns wide: the frame overflowed, the terminal wrapped wherever it liked, and the two-column alignment — the only thing making the guide readable at a glance — was lost. A gloss now wraps under its column, and moves below its command when that command leaves no room. The layout carries the rule, not the length of the texts, which would have held only until the next tool
- A VM deployed offline gets its cache variables before its installation starts. « cloud-init status --wait » returns as soon as cloud-init declares itself in error — an accessory module suffices — while its final stage is still writing the authority, `/etc/environment` and the sudoers file; a session opened in that second lived without them, and an install run by sudo then rejected the cache certificate. The deployment now waits for the cloud-final unit, and only its « activating » state, that unit being a oneshot that stays active once finished
- Repository metadata an RPM distribution names after the hash of its content is served from disk like a package, and a range request on a file the cache does not hold fetches the whole file in the background, once per key. Such an index of tens of megabytes was taken whole on every install — about 110 MB per VM on a RHEL family system — and dnf, which fetches its zchunk metadata by ranges, got a « 504 » with upstream cut, no range being stored
- A VM deployed offline no longer waits for a time synchronisation that cannot come. An image that enables `systemd-time-wait-sync` holds `time-sync.target` until the first NTP answer, and cloud-init's final stage is ordered after it: with no reachable time server, that stage never ran, nor the ssh host keys it generates, and the VM reached its login prompt without ever answering ssh
- The download cache no longer re-fetches a package it already holds because a mirror files it under another path. A mirror prefixes the path as it pleases — « /rocky/10.2/… », « /mirror/rocky-linux/10.2/… », « /pub/archive/fedora/… » — and the whole path gave two keys for the same bytes: over a log of 7099 delivered names, 1124 lived under several paths and 3.18 GiB went back upstream for nothing. Only the last six segments count now, empty ones falling with them. Six is the smallest collision-free bound: a Debian path carries exactly six, so five would serve Ubuntu's package for Debian's, which bears the same name for other bytes. Pacman packages stop at four, their paths being shorter than the common bound, which drops the mirror's prefix and keeps the repository name. A store filled before this change is brought over by `--recle`
- A kept image that has gone stale is fetched once more instead of ending the deployment. A distribution's « latest » directory moves with each point release and the published sum stops describing the image on disk, with no byte corrupted: the check deleted it and exited, losing a whole campaign — three VMs — to a staleness one download repairs. A second mismatch is on freshly downloaded bytes, stops everything and deletes the image; called with no mirror list, and for unreachable sums, nothing changes
- `long_test/qemu_cache.py` no longer fails a campaign where the cache served everything. A URL counts as « already seen » only if the first VM obtained its bytes: one package lives under two paths depending on the mirror, and the first VM can get a « 504 » on one — upstream judged mute — then be served from disk by the other, so nothing was stored under the first path and the second VM's honest download was counted a fault. A missing status counts as delivered, older logs not always writing it, and the new-files line names both of its causes instead of blaming Arch whatever the system measured
- An interrupted image download resumes on the same mirror, three attempts, by a `Range` asking for the rest, instead of throwing away what it received: a VM image weighs half a gigabyte, and a truncated `.part` used to send the reader back to a hand-typed `curl -C -`. A server ignoring the Range returns the whole file, and the transfer restarts from zero rather than doubling the bytes already there
- The cache's certificate variables name a bundle only when the file exists. A recent Fedora lacks `/etc/pki/tls/certs/ca-bundle.crt`, and pointing pip at a missing path made it refuse EVERY download, including what has nothing to do with the cache. None found writes no variable, and pip keeps its own certificate set
- `make version` names both Pythons, Odoo's and the tooling's. A bare label suggested the repository had one, and the figure shown was not that of the venv the reader works in
- `make` no longer launches a `.venv.erplibre` built on another machine, such as a checkout mounted over the network, which died on « No module named 'encodings' ». `install.sh` reads the interpreter's version by running code: `python -V` answers before the standard library loads, so it vouched for an interpreter that could not start. Such a venv is now reported as built elsewhere, with the command that rebuilds it
- Dependabot no longer opens pull requests against the frozen requirements of Odoo 12 to 17: its security updates scan `requirement/` as its own directory, which the exclusions did not cover
- `poetry_update.py` stops on a missing `pyproject.toml` with the command that creates it, `make switch_odoo_XX` for the active version, and offers to run it then restart when launched from a terminal
- `poetry_update.py` runs Poetry in the Odoo venv even from a shell under `.venv.erplibre`, whose Python made it fail on « InvalidCurrentPythonVersionError »
- `poetry_update.py` skips requirements and manifests under a `doc`, `docs`, `example` or `examples` directory: an example file declaring a loose `>=` no longer moves a dependency for the whole environment
<!-- [fr] -->
- La lecture des baux dnsmasq n'ouvre plus d'invite de mot de passe root : les fichiers sont lus en direct, ce qui suffit sur une installation standard où ils sont en 0644, et `sudo -n` n'est tenté qu'ensuite, qui échoue au lieu de demander. L'affichage d'une liste de VM appelait ce chemin une fois par VM, et l'attente d'une VM toutes les trois secondes pendant dix minutes
- `--max_process` repart sur Python 3.10 et plus : `loop=` a quitté `asyncio.wait` en 3.10 et `asyncio.get_event_loop()` lève hors d'une loop en marche depuis 3.14, si bien que le pool n'était même plus instanciable alors que l'aide annonçait toujours l'option
- Une invite n'écrit plus son deux-points deux fois — le menu le plus vu du logiciel demandait « Commande :: », et sept invites de déploiement à distance affichaient un deux-points suivi d'un autre
- Onze sous-menus laissent désormais leur segment dans le fil d'Ariane, et la télémétrie de navigation cesse de les classer comme des commandes sous leur nom de méthode brut
- Les trois lecteurs de `~/.ssh/config` s'accordent sur ce qu'est un nom de machine : un alias déclaré par un `host` en minuscules est vu, une tabulation sépare aussi légalement qu'un espace, et un motif nié `!nom` n'est plus pris pour une machine à joindre
- Trois clés de traduction déclarées deux fois ont disparu, et un contrôle refuse la suivante : une clé répétée écrase la précédente en silence, ce qui avait déjà coûté une étiquette de menu
- `anonymize.py` s'abstient sur une colonne numérique unique et la NOMME dans le rapport. Un tirage ne garantit rien sur une colonne unique, et un nombre n'a pas l'issue qu'a le texte — coller l'id porte l'unicité pour du texte, mais changerait la grandeur d'un nombre. Deux lignes tirant le même nombre faisaient échouer l'UPDATE et, transaction unique oblige, emportaient TOUTE l'anonymisation. Sans que le rapport la nomme, une colonne identifiante reste en clair sans que rien ne le dise
- Restaurer une sauvegarde ne lève plus `AttributeError` avant de lancer la commande : `_monitoring_restore` lisait `self._execute` là où `TODO` pose `self.execute`, et les deux entrées qui y mènent — la sauvegarde locale et la distante — étaient cassées. Un contrôle refuse le suivant : tout `self.X` que `TODO` LIT doit être posé par TODO ou par une de ses bases. Chercher le nom dans tout `script/todo/` ne voyait pas la faute, un autre objet du paquet posant bien `_execute` ; il faut le chercher dans les classes dont TODO HÉRITE
- Les scripts Selenium tournent sur un Python bâti sans `tkinter` — tout serveur dépourvu de paquet d'interface graphique. Ce module ne sert qu'au sélecteur de fichier du coffre, il est donc désormais optionnel : sans `tkinter` et sans chemin KDBX configuré, l'ouverture du coffre journalise une erreur et rend la main, au lieu de casser l'import de tous les scripts de pilotage de navigateur
- Le mode sombre repart en fenêtre privée sur un Firefox récent. La permission « Exécuter dans les fenêtres privées » est accordée à l'installation de l'extension, par le champ `allowPrivateBrowsing`, au lieu d'être cochée dans l'interface `about:addons` : Firefox refuse la navigation vers `about:addons` depuis le contexte contenu, et le contexte chrome exige `-remote-allow-system-access`, que geckodriver refuse via les capabilities, si bien que les deux voies vers cette case sont fermées. Un geckodriver qui ignore le champ installe sans la permission au lieu d'interrompre la session
- L'étiquette « - Default » reparaît aux menus des versions et des environnements : les deux lectures demandaient une clé à majuscule que le fichier des versions n'écrit pas, et une clé absente ne rend rien sans rien dire
- Le message « rien en réserve » du cache est inerte pour un interpréteur de commandes, chaque ligne étant un commentaire. Livré à un installateur bâti sur `curl … | bash`, il devenait une cascade de « command not found » qui masquait la cause. Un tel téléchargement demande en outre à curl d'échouer sur une erreur HTTP plutôt que d'exécuter la page d'erreur
- L'attente qu'une VM soit prête couvre aussi la pose de l'agent invité. Celle-ci part en unité DÉTACHÉE pour que cloud-init rende la main en quelques secondes, et elle fait un `apt-get update` : « cloud-init status --wait » disait « done » alors que le verrou des paquets était encore tenu, l'étape suivante épuisait ses reprises, puis installait sur un index jamais rafraîchi — « Impossible de trouver le paquet », un message qui accuse le dépôt et non le verrou. Un update qui n'aboutit pas le dit désormais sur le champ
- Une installation de bureau n'attend plus des minutes sur le verrou apt : le SERVICE apt-daily est arrêté et non son seul minuteur, un minuteur désactivé n'interrompant pas l'apt-get qu'il a déjà lancé ; et la reprise repasse toutes les deux secondes au lieu de dix, « DPkg::Lock::Timeout » ne couvrant pas ce verrou-là
- Les VM Fedora démarrent de nouveau : le micrologiciel charge et démarre leur chargeur, puis se fige sans écrire un octet — pas de console, pas de bail DHCP, une machine « en cours d'exécution » qui ne fait rien. Fedora est amorcée en BIOS hérité, où la même image démarre son noyau ; `--bios` garde le dernier mot
- Une VM reçoit un nom d'hôte qu'elle accepte — un souligné, que le nom de domaine libvirt tolère, lui faisait garder le nom générique de son image — et un fuseau que sa distribution connaît, un alias hérité la laissant en UTC
- starship s'installe dans une VM : son installateur tourne en root, borné par un délai root, et n'atteint jamais le `sudo -v` que sudo-rs refuse ; son crochet de shell n'écrit plus « command not found », ni ne fait échouer un rc sourcé, quand starship est absent
- Chaque outil optionnel dit s'il a été posé, et une extension GNOME dont le téléchargement a échoué n'est plus déclarée indisponible pour ce GNOME
- mise, pyenv et les extensions GNOME sont téléchargés, puis exécutés : sans pipefail, `curl | sh` ne pouvait ni signaler un téléchargement raté ni atteindre son repli
- L'unité de l'agent invité ne finit plus en échec après une pose réussie
- Le cache répond 508 à une requête qui le vise lui-même, au lieu de s'appeler jusqu'à épuiser ses descripteurs
- Le diagnostic du cache ne donne plus un service arrêté pour actif
- L'attente d'`apt-get update` est bornée par une échéance et non par un nombre d'essais. Un essai échoue en moins d'une seconde sur un verrou tenu, mais dure des minutes quand le cache rend 504 sur chaque index qu'il ne détient pas : soixante essais valaient alors des heures de silence là où cinq minutes étaient promises, et l'installation échouait ensuite sur des dépendances introuvables
- Un invité Proxmox est fixé sur le même miroir apt que le reste du parc, écrit par ssh avant tout téléchargement. Le magasin range ses index par HÔTE : une VM restée sur les dépôts par défaut de son image ne retrouvait rien de ce dont le cache avait été rempli — hors ligne, chacun de ces index manquait
- L'installateur du cache accepte un pont et un sous-réseau donnés à la main. Il sondait libvirt d'abord et mourait sur « réseau default introuvable » : le contournement annoncé dans son propre en-tête — `EL_BRIDGE` et `EL_SUBNET` — était donc hors d'atteinte. Une machine dont le réseau libvirt n'est pas démarré, ou qui porte son pont autrement, peut désormais poser le cache en le nommant ; et quand la sonde tourne et échoue, elle nomme les deux issues
- **Déploiement › Cache QEMU › Installer ou réinstaller** n'annonce plus « installé et démarré » quand l'installateur a échoué. Il n'attrapait que les exceptions : un code de sortie non nul — réseau libvirt absent, compilation qui cède — imprimait la ligne de réussite juste sous l'erreur elle-même, avec le chemin d'une autorité qui n'existe pas
- Un invité Proxmox reçoit de nouveau son guide, son fuseau, son miroir apt et l'autorité du cache. Ces quatre gestes passent par ssh et partaient dès qu'une adresse était connue, pendant que cloud-init posait encore les comptes et les clés : ils échouaient ensemble, et la VM naissait en UTC, sans guide, sans autorité et sur les dépôts de son image. Le déploiement attend désormais que la machine réponde en ssh — cinq minutes au plus — et le dit quand elle ne répond jamais, au lieu d'échouer quatre fois de suite
- Le cache ne sert plus un index de dépôt plus récent que la signature qui l'annonce. Hors ligne, chaque objet sortait avec sa propre date : un index rafraîchi samedi sous un `InRelease` de vendredi faisait échouer apt sur « File has unexpected size » ou « Hash Sum mismatch », et l'installation s'arrêtait sur des dépendances introuvables — un message qui accuse le dépôt, jamais le cache. La comparaison porte sur le `Last-Modified` de l'amont, jamais sur la date de stockage, renouvelée à chaque service
- Le refus d'emporter le cache sur une autre machine nomme le geste qui le lève, et ce geste n'est pas l'entrée 1 — elle pose le cache ICI, si bien que la suivre faisait réinstaller l'hôte qui en avait déjà un pendant que l'arrivée restait sans rien. Trois situations étaient rendues par un seul « pas de cache » : un lien ssh qui n'a jamais exécuté la sonde, une arrivée sans cache, une arrivée dont le cache n'a pas son compte de service. Chacune a désormais son message, et celle du cache absent énumère les gestes à faire SUR l'arrivée, avec les deux issues d'un installateur qui lit le réseau libvirt « default » — lever libvirt, ou nommer le pont, un libvirt arrêté le faisant mourir sur un réseau qui existe. Les gestes nomment aussi la branche à donner à l'arrivée, lue sur cet hôte : l'installateur est un fichier du dépôt, si bien qu'une machine restée sur une autre branche répond « fichier introuvable », ce qui ne ressemble en rien à un cache absent. Un quatrième cas est éprouvé avant qu'un seul octet ne parte : un sudo qui réclame un mot de passe à l'arrivée, auquel aucun terminal ne peut répondre puisque le magasin occupe lui-même l'entrée standard de ssh — le message donne le ticket à y obtenir d'abord. Le privilège n'est demandé qu'UNE fois à l'arrivée, « tar » et « chown » sous une seule invocation. Quand le sudo de là-bas réclame un mot de passe, l'entrée offre deux issues au lieu d'échouer : la ligne sudoers à poser une fois, ou un mode en deux temps — le magasin part dans le compte de l'arrivée, qui n'exige aucun privilège, et une commande affichée l'extrait depuis un terminal de là-bas, où un mot de passe se tape. Ce mode réclame deux fois le magasin à l'arrivée, vérifié avant qu'un octet ne parte, un cache ne contenant que des paquets et des archives git déjà comprimés. Le guide porte la même section
- Le formulaire de déploiement Proxmox VE éprouve le cache avant de couper le réseau, comme celui de libvirt le faisait déjà : ce que le magasin n'a pas, aucune VM coupée ne le lira, et l'échec tombait une heure plus tard, à la pose du bureau — un message qui accuse le dépôt, jamais le cache. F5 à nouveau vaut passage outre. Les deux formulaires partagent désormais un seul verdict au lieu de deux copies, qui auraient divergé au premier ajustement
- Le cache garde ses index de dépôt quand une liste de miroirs tourne. Un index publié sous l'empreinte de son contenu — « by-hash/SHA256/… » — était rangé sous une clé portant l'hôte : les mêmes octets servis par un second miroir étaient repris à l'amont, et hors ligne ils manquaient tout simplement — l'installation échouait sur des fichiers que le magasin détenait, avec un message qui accuse le dépôt. Un tel objet est désormais rangé sous son seul chemin, son nom ÉTANT la somme de son contenu
- Le diagnostic du cache n'annonce plus « aucune règle de détournement n'est posée » quand il n'a simplement pas pu les lire. Sur un hôte dont le sudo réclame un mot de passe, « sudo -n nft » ne rend rien, et ce silence était lu comme une absence de règle — ce qui envoyait réinstaller un cache qui détournait correctement. La lecture porte désormais un troisième état, « impossible de savoir », marqué d'un point et non d'une croix, comme le faisait déjà la lecture de la coupure d'amont
- Une coupure levée rend aussitôt leur chance aux amonts. Le service retient un court moment ceux dont la connexion vient d'échouer, pour qu'une installation hors ligne ne paie pas le délai d'établissement des centaines de fois ; rien ne lui disait que la coupure était finie, et les premières requêtes d'après la levée se rabattaient sur le magasin alors que le réseau était déjà revenu. La levée touche désormais un témoin dans le magasin, que cette mémoire consulte — il n'existe aucun canal vers le service en marche
- Avant de couper, le formulaire avertit aussi de ce qu'aucun index ne peut révéler : un paquet que le déploiement pose HORS du fil observé — l'agent invité, posé par une unité détachée dont l'échec ne remonte nulle part — et les dépôts git déclarés par les manifestes qui n'ont pas encore de miroir. Un index de suite en réserve suffisait à faire passer le cache pour complet alors qu'aucun octet de ce paquet ne l'avait jamais traversé ; et une négociation git ne se garde jamais, si bien qu'un dépôt sans miroir ne peut tout simplement pas être cloné une fois le réseau coupé
- L'avertissement sur les miroirs ne compte que les dépôts de la version d'Odoo déployée. Il additionnait tous les manifestes du dépôt — le déprécié compris — et annonçait 170 miroirs manquants là où un vrai déploiement Odoo 18 en rencontre quatre : une alarme qui sonne pour rien est une alarme qu'on cesse de lire. Le remplissage des miroirs, lui, prend toujours de l'avance pour toutes les versions, ce qui est son rôle
- Un hôte banni du déchiffrement sur une rafale d'erreurs de transport retrouve sa chance. Trois poignées de main manquées d'affilée le passaient en tunnel opaque, et un tunnel ne consulte jamais le magasin : un miroir de distribution condamné par quelques enregistrements corrompus renvoyait tout son trafic à l'amont — y compris les centaines d'objets déjà détenus pour lui — jusqu'au redémarrage du service. Une alerte TLS bannit toujours définitivement, le client ayant regardé notre certificat et l'ayant refusé ; mais une coupure répétée n'est qu'un soupçon, et elle se rouvre au bout de dix minutes
- **Déploiement › Cache QEMU › Miroirs git** remplit à part la base de la version d'Odoo active, ou ses modules extra — à côté du remplissage de tous les manifestes, qui prend des heures. Chaque liste dit combien de dépôts elle déclare et combien n'ont pas encore de miroir. Ce qu'un déploiement clone se lit désormais avec la règle et les listes de la fusion des manifestes elle-même : les modules extra, installés seulement sur demande, et le projet mobile ne comptent plus, là où l'avertissement hors ligne annonçait quatre miroirs manquants qu'une installation Odoo 18 par défaut ne clone jamais
- Les métadonnées PEP 658 de pip — le fichier `.whl.metadata` récupéré avant chaque roue — sont servies du disque. Le nom finit par `.metadata`, qu'aucune règle ne connaissait : chaque fichier repartait à chaque installation, 178 sur une installation complète d'ERPLibre. Les copies gardées avant ce changement ne sont plus atteintes ; la prochaine installation en ligne les remplit
- Le fuseau horaire qu'une VM déployée hérite de son hôte est traduit en son nom canonique. Les images cloud d'Ubuntu 24.04 ne portent plus les alias historiques — `Canada/*`, `US/*`, `Asia/Calcutta` — déplacés dans un paquet `tzdata-legacy` qu'elles n'installent pas : cloud-init refusait le fuseau, la VM restait en UTC, et le seul signe était un cloud-init en erreur, le décalage n'apparaissant qu'aux horodatages longtemps après. La table des alias est le `tzdata.zi` de l'hôte, et non une copie figée dans le code
- `make` cherche bash au lieu de présumer `/bin/bash`. Ce chemin n'existe pas sur NixOS, où le shell vit dans le store, et make s'arrêtait avant d'exécuter la moindre recette — y compris celle qui installe de quoi créer ce chemin. Ailleurs, le shell résolu est celui d'avant
- Le locale et le clavier qu'une VM déployée reçoit s'appliquent désormais sur Debian, où les deux échouaient en silence. Un locale se génère à partir de `/etc/locale.gen` et de nulle part ailleurs : `update-locale` refusait celui qui n'y était pas et la VM restait en C.UTF-8 ; le module clavier finit par un `console-setup` que l'image genericcloud ne porte pas, alors `/etc/default/keyboard` — le fichier que localed et X relisent — est écrit directement. Chaque déploiement Debian imprimait `cloud-init: status: error`, et un mot qui s'affiche toujours n'avertit plus de rien
- Un invité sans ancre de confiance par fichier est soustrait au cache de téléchargement plutôt qu'intercepté sans elle. Le détournement est transparent et vaut pour tout le pont : une VM à qui l'on ne donne pas l'autorité échoue quand même sur « self-signed certificate in certificate chain » — et sur un système déclaratif, poser l'autorité arrive trop tard, la première reconstruction étant le premier téléchargement. Sur un hôte Proxmox, c'est l'HÔTE qui est excepté : un invité imbriqué sort masqué derrière lui et le pont ne voit jamais sa propre adresse. Mesuré depuis l'invité : code 000 et vérification SSL 19, puis 200 et 0. Sans cela le gestionnaire de paquets se rabattait sur 564 dérivations à construire, dont les sources échouaient pour la même raison
- NixOS apprend l'autorité du cache de téléchargement SANS reconstruire, et n'en est donc plus soustrait — ce qui lui fermait le déploiement hors ligne, le magasin étant alors la seule source et une VM exceptée n'ayant plus rien. Il n'a pas d'ancre de confiance par fichier et /etc est généré en lecture seule, quand une déclaration arriverait trop tard, la première reconstruction étant le premier téléchargement. L'autorité y est donc POINTÉE, consommateur par consommateur, par l'environnement — et l'environnement se perd à trois frontières que les quatre familles impératives ne rencontrent jamais. nix-daemon est activé par socket et ne voit aucune session : un fragment sous /run/systemd/system, un tmpfs inscriptible là où /etc ne l'est pas, l'atteint. sudo l'efface, et le nix de root parle droit au magasin local plutôt qu'au démon, téléchargeant lui-même : « Defaults env_keep » fait traverser les variables, visudo étant atteint par le profil du système, le PATH qu'y donne cloud-init ne portant aucun sudo. Et la session ssh s'ouvre une seconde avant que cloud-init n'écrive le faisceau, si bien que les exports vivent DANS l'attente de celui-ci plutôt qu'en tête de commande. Le faisceau concatène les autorités du système et celle du cache, donner la seconde seule ferait cesser d'approuver tout le reste. Vérifié amont COUPÉ sur une VM neuve : nix-shell réalise depuis le magasin ; et cache interceptant, une installation complète se termine sans un refus de certificat
- Odoo répond depuis l'extérieur d'une VM NixOS. Il écoutait sur 0.0.0.0:8069 et répondait en local, mais NixOS active un pare-feu par défaut là où aucune des quatre autres images cloud n'en active : l'hôte ne recevait rien — pas un refus, un silence jusqu'au délai — et le suivi déclarait Odoo absent sur une machine où il tournait. Mesuré depuis l'hôte : 000 après 12 s, puis 303 en 9 ms
- ERPLibre tourne comme service sur NixOS. L'installation finissait par écrire une unité dans `/etc/systemd/system`, généré depuis le store et monté en lecture seule : elle rendait 1 à sa dernière étape, après que le clone, le venv et un démarrage d'Odoo avaient tous réussi. L'unité est désormais déclarée par le module ; son interpréteur vient du store, `/bin` étant un montage FUSE d'envfs que systemd ne voit pas quand il résout l'exécutable ; et son PATH porte bash, dont l'absence arrêtait `run.sh` avant Odoo
- Ce qu'un système déclaratif doit déclarer, et que les quatre autres reçoivent gratuitement de leur image cloud : xmlsec1, sans lequel Odoo refuse d'installer auth_saml, module du chemin des addons ; parallel et shfmt, appelés par leur nom nu ; growpart, absent de tout le système alors que l'agrandissement du disque s'écrit « … || true » et rendait 0 sans rien agrandir ; et l'agent invité, qui venait de l'image et non du dépôt, le PATH de son unité manquant findmnt si bien que guest-exec mourait en 127 dès sa première ligne
- Le guide de connexion s'affiche sur NixOS. Le déploiement écrit `/etc/motd` partout et compte sur pam_motd pour le montrer — vrai des quatre images cloud, faux ici, où sshd rend « printmotd no » et où la pile PAM ne contient aucun pam_motd : le guide était écrit, complet, et personne ne le lisait. Il gagne aussi un bloc propre à NixOS, qui nomme le piège pour lequel il existe — `/etc/nixos/erplibre.nix` est réécrit par `make install_os`, et les déclarations qu'on y ajoute disparaissent sans un mot
- « make db_drop_all » n'annonce plus détruites des bases qui ne le sont pas. Il composait une commande parallel, jetait son code de retour et imprimait la liste ; le cas s'atteint dès que parallel manque du PATH, et l'opérateur passe à la suite en croyant ses bases parties
- Un miroir du cache de téléchargement refusé faute de place nomme son seuil et sa mesure. Il reprenait un champ que tout appelant ordinaire laisse à zéro — « moins de 0 o libres sur le disque » n'annonce aucun seuil et ne dit pas ce qui a été mesuré
- Une image téléchargée est vérifiée contre la somme que son éditeur publie, pour toute distribution qui en publie une et SANS le demander. La vérification existait sous un drapeau et pour Ubuntu seulement, si bien que les autres images arrivaient sans que rien ne les regarde. Six y entrent, relevées sur les dépôts plutôt que devinées : Debian publie du sha512 quand tout le reste est en sha256, les familles RHEL nomment le fichier « CHECKSUM », Rocky l'écrit en forme BSD, et Arch comme openSUSE posent une somme par image. Un fichier de sommes injoignable n'arrête plus un déploiement — c'est une panne de disponibilité — quand un écart arrête toujours tout et supprime l'image
- La locale qu'une VM déployée reçoit s'applique sur NixOS. cloud-init l'applique par locale-gen et update-locale, absents là-bas, et la VM gardait le défaut de la distribution — « fr_CA.UTF-8 » demandé, « en_US.UTF-8 » obtenu. Elle et le fuseau sont désormais déclarés par le module, et ni l'un ni l'autre n'est imposé à une NixOS qu'on avait déjà
- Le guide de connexion tient dans un terminal de 80 colonnes même sur une VM qui porte ses outils et un bureau, là où il en rendait 103 : le cadre débordait, le terminal repliait où il voulait, et l'alignement en deux colonnes — seule chose qui rend le guide lisible d'un coup d'œil — se perdait. La glose se replie désormais sous sa colonne, et passe sous sa commande quand celle-ci ne laisse plus de quoi écrire. C'est la mise en page qui porte la règle, non la longueur des textes, qui n'aurait tenu que jusqu'au prochain outil
- Une VM déployée hors ligne reçoit les variables du cache avant que son installation ne commence. « cloud-init status --wait » rend la main dès que cloud-init se déclare en erreur — un module accessoire y suffit — alors que son étape finale écrit encore l'autorité, `/etc/environment` et le fichier sudoers ; une session ouverte dans cette seconde-là vivait sans elles, et une installation lancée par sudo rejetait alors le certificat du cache. Le déploiement attend désormais l'unité cloud-final, et son seul état « activating », ce service étant un oneshot qui reste actif une fois fini
- Une métadonnée de dépôt qu'une distribution RPM nomme d'après l'empreinte de son contenu est servie du disque comme un paquet, et une demande de plage sur un fichier que le cache ne détient pas fait prendre le fichier entier en arrière-plan, une fois par clé. Un tel index de dizaines de mégaoctets était repris en entier à chaque installation — environ 110 Mo par VM sur un système de la famille RHEL — et dnf, qui prend ses métadonnées zchunk par plages, recevait un « 504 » l'amont coupé, aucune plage ne se gardant
- Une VM déployée hors ligne n'attend plus une synchronisation de l'heure qui ne peut pas venir. Une image qui active `systemd-time-wait-sync` retient `time-sync.target` jusqu'à la première réponse NTP, et l'étape finale de cloud-init est ordonnée après elle : sans serveur de temps joignable, cette étape ne démarrait jamais, ni les clés d'hôte ssh qu'elle génère, et la VM atteignait son invite de connexion sans jamais répondre en ssh
- Le cache de téléchargement ne reprend plus à l'amont un paquet qu'il détient déjà parce qu'un miroir le range sous un autre chemin. Un miroir préfixe le chemin à sa guise — « /rocky/10.2/… », « /mirror/rocky-linux/10.2/… », « /pub/archive/fedora/… » — et le chemin entier donnait deux clés pour les mêmes octets : sur un journal de 7099 noms livrés, 1124 vivaient sous plusieurs chemins et 3,18 Gio repartaient à l'amont pour rien. Seuls les six derniers segments comptent désormais, les segments vides tombant avec eux. Six est la plus petite borne sans collision : un chemin Debian en porte exactement six, si bien que cinq servirait le paquet d'Ubuntu pour celui de Debian, qui porte le même nom pour d'autres octets. Les paquets pacman s'arrêtent à quatre, leurs chemins étant plus courts que la borne commune, ce qui retire le préfixe du miroir et garde le nom du dépôt. Un magasin rempli avant ce changement se rattrape par `--recle`
- Une image gardée devenue périmée est reprise une fois au lieu d'arrêter le déploiement. Le répertoire « latest » d'une distribution avance à chaque version mineure et la somme publiée cesse de décrire l'image du disque, sans qu'un octet soit corrompu : la vérification la supprimait puis sortait, perdant une campagne entière — trois VM — pour une péremption qu'un seul téléchargement répare. Un second écart porte sur des octets fraîchement téléchargés, arrête tout et supprime l'image ; appelée sans liste de miroirs, et pour des sommes injoignables, rien ne change
- `long_test/qemu_cache.py` ne fait plus échouer une campagne où le cache a tout servi. Une URL n'est « déjà vue » que si la première VM en a obtenu les octets : un même paquet vit sous deux chemins selon le miroir, et la première VM peut recevoir « 504 » sur l'un — amont jugé muet — puis être servie du disque par l'autre, si bien que rien n'était rangé sous le premier chemin et que le téléchargement honnête de la seconde y était compté en faute. Un statut absent vaut livré, les journaux d'avant ne l'écrivant pas toujours, et la ligne des fichiers neufs nomme ses deux causes au lieu d'imputer à Arch quelle que soit la distribution mesurée
- Un téléchargement d'image coupé se reprend sur le même miroir, trois essais, par un `Range` qui demande la suite, au lieu de jeter ce qu'il a reçu : une image de VM pèse un demi-gigaoctet, et un `.part` tronqué renvoyait le lecteur à un `curl -C -` tapé à la main. Un serveur qui ignore le Range rend le fichier entier, et le transfert repart alors de zéro plutôt que de doubler les octets déjà là
- Les variables de certificat du cache ne désignent un faisceau que s'il existe. Une Fedora récente n'a pas `/etc/pki/tls/certs/ca-bundle.crt`, et viser un chemin absent faisait refuser à pip TOUT téléchargement, y compris ce qui n'a rien à voir avec le cache. Aucun trouvé n'écrit aucune variable, et pip garde son propre jeu de certificats
- `make version` nomme les deux Python, celui d'Odoo et celui de l'outillage. Un libellé nu laissait croire que le dépôt n'en a qu'un, et le chiffre affiché n'était pas celui du venv dans lequel on travaille
- `make` ne lance plus un `.venv.erplibre` bâti sur une autre machine, comme un checkout monté par le réseau, qui mourait sur « No module named 'encodings' ». `install.sh` lit la version de l'interpréteur en exécutant du code : `python -V` répond avant le chargement de la bibliothèque standard, et se portait donc garant d'un interpréteur incapable de démarrer. Un tel venv est désormais signalé comme bâti ailleurs, avec la commande qui le rebâtit
- Dependabot n'ouvre plus de demandes de fusion sur les requirements figés d'Odoo 12 à 17 : ses mises à jour de sécurité lisent `requirement/` comme un répertoire à part, que les exclusions ne couvraient pas
- `poetry_update.py` s'arrête sur un `pyproject.toml` absent en nommant la commande qui le crée, `make switch_odoo_XX` pour la version active, et propose de la lancer puis de se relancer quand il tourne dans un terminal
- `poetry_update.py` fait tourner Poetry dans le venv Odoo même depuis un shell sous `.venv.erplibre`, dont le Python le faisait échouer sur « InvalidCurrentPythonVersionError »
- `poetry_update.py` écarte les requirements et manifestes sous un répertoire `doc`, `docs`, `example` ou `examples` : un fichier d'exemple déclarant un `>=` lâche ne déplace plus une dépendance pour tout l'environnement
<!-- [en] -->
## Removed
<!-- [fr] -->
## Retiré
<!-- [en] -->
- The `sshconf` dependency, declared and installed everywhere and imported nowhere
<!-- [fr] -->
- La dépendance `sshconf`, déclarée et installée partout et importée nulle part
<!-- [en] -->
## Security
<!-- [fr] -->
## Sécurité
<!-- [en] -->
- An API key and a bearer token are redacted too before a command is displayed, logged or reprinted: `OPENAI_API_KEY=` went out in the clear, and a header token escaped by construction, carrying neither an option name nor a variable name
- Following a redirect, the cache no longer forwards the client's credentials (Authorization, Cookie, Proxy-Authorization) to another host
- Odoo 18 installs `idna` 3.20 instead of the 3.6 its own requirements pin, which is affected by CVE-2024-3651
- Odoo 18 installs `requests` 2.32.4 instead of the 2.31.0 its own requirements pin, which is affected by CVE-2024-35195 and CVE-2024-47081
- The git mirror of the QEMU cache clones only over `http` and `https`: a client could name an `ssh://` or `git://` repository in its request and make the cache connect, with its service account keys, to a host of its choosing. Repositories fetched over HTTPS are mirrored as before; the binary reports 0.2.17
<!-- [fr] -->
- Une clé d'API et un jeton Bearer sont caviardés eux aussi avant qu'une commande soit affichée, journalisée ou réimprimée : `OPENAI_API_KEY=` partait en clair, et un jeton d'en-tête échappait par construction, ne portant ni nom d'option ni nom de variable
- En suivant une redirection, le cache ne transmet plus les identifiants du client (Authorization, Cookie, Proxy-Authorization) à un autre hôte
- Odoo 18 installe `idna` 3.20 au lieu de la 3.6 qu'épinglent ses propres requirements, touchée par CVE-2024-3651
- Odoo 18 installe `requests` 2.32.4 au lieu du 2.31.0 qu'épinglent ses propres requirements, touché par CVE-2024-35195 et CVE-2024-47081
- Le miroir git du cache QEMU ne clone plus qu'en `http` et `https` : un client pouvait nommer un dépôt `ssh://` ou `git://` dans sa requête et faire se connecter le cache, avec les clés de son compte de service, à un hôte de son choix. Les dépôts servis en HTTPS sont mis en miroir comme avant ; le binaire annonce 0.2.17
<!-- [common] -->
## [1.8.0] - 2026-09-04
<!-- [en] -->
**Migration notes**
Recreating the virtual environment, the Python interpreter and the package
installer being chosen now. Use the installation guide from tool `make`.
Ubuntu 20.04 and 22.04 are no longer supported.
<!-- [fr] -->
**Notes de migration**
Recréer l'environnement virtuel, l'interpréteur Python et l'installateur de
paquets se choisissant désormais. Utiliser le guide d'installation depuis
l'outil `make`. Ubuntu 20.04 et 22.04 ne sont plus supportés.
<!-- [en] -->
## Added
<!-- [fr] -->
## Ajouté
<!-- [en] -->
- Deploy ERPLibre VMs with QEMU/KVM from cloud images: Ubuntu, Debian, Fedora, AlmaLinux, Rocky, openSUSE, Arch, Linux Mint, and Debian on s390x. Hardware, branch and Odoo version are set per machine
- Proxmox VE as a deployment target, its installation including the reboot it needs
- A QEMU menu: network status and repair, 3D acceleration, a diagnostic report, file recovery from a VM that no longer boots, virt-viewer and a remote desktop tunnel
- An install dashboard and Textual forms: deploy, follow, update, restart or delete a VM without leaving the screen
- A mobile development VM: PyCharm, Android Studio, an Android emulator and an adb tunnel
- A VPN tool, five free technologies from the menu, the secrets in a KeePassXC vault and a diagnosis that names the failing stage
- Automated Odoo migration: the tool drives the whole run, goes back to a step, and repairs what a version bump leaves behind
- Migration review: a verdict per step, smoke tests on every public URL, and a filestore check
- A read-only analysis toolkit for an Odoo database, a backup zip included, with PostgreSQL index advice
- Anonymising a production copy without AI, and duplicating a database neutralised for good
- Development assistants installed inside a VM, and a Git and Shell menu that installs what a checkout needs
- A writing convention for what stays in git, held by a `pre-commit` and a `commit-msg` hook
- `long_test/` — tests that create real machines, nested QEMU and Proxmox included, kept out of the unit runner
- NTFY, Forgejo, a local git server, e-mail from the CLI, and SSH configuration with recursive ProxyJump
- The Python interpreter and the package installer are chosen, through EL_PYTHON_PROVIDER and EL_PIP_PROVIDER
- The OCA generative AI policy, Claude Code agents and commands, and the context an assistant is given, shown from the menu
- Unit tests with a bilingual test plan, navigation telemetry for TODO, and Odoo 18 reading STL files
<!-- [fr] -->
- Déployer des VM ERPLibre en QEMU/KVM depuis des images cloud : Ubuntu, Debian, Fedora, AlmaLinux, Rocky, openSUSE, Arch, Linux Mint, et Debian sur s390x. Matériel, branche et version d'Odoo se règlent par machine
- Proxmox VE comme cible de déploiement, son installation comprenant le redémarrage qu'elle exige
- Un menu QEMU : état et réparation du réseau, accélération 3D, un rapport de diagnostic, récupération de fichiers sur une VM qui ne démarre plus, virt-viewer et un tunnel de bureau distant
- Un tableau de bord d'installation et des formulaires Textual : déployer, suivre, mettre à jour, redémarrer ou effacer une VM sans quitter l'écran
- Une VM de développement mobile : PyCharm, Android Studio, un émulateur Android et un tunnel adb
- Un outil VPN, cinq technologies libres au menu, les secrets dans un coffre KeePassXC et un diagnostic qui nomme l'étage fautif
- La migration Odoo automatisée : l'outil mène toute l'exécution, revient à une étape, et répare ce qu'un changement de version laisse derrière lui
- La revue de migration : un verdict par étape, des tests de fumée sur chaque URL publique, et un contrôle du filestore
- Une trousse d'analyse en lecture seule d'une base Odoo, archive de sauvegarde comprise, avec conseil d'index PostgreSQL
- L'anonymisation d'une copie de production sans IA, et la duplication d'une base neutralisée pour de bon
- Des assistants de développement posés dans une VM, et un menu Git et Shell qui installe ce qu'un checkout réclame
- Une convention d'écriture pour ce qui reste dans git, tenue par un hook `pre-commit` et un hook `commit-msg`
- `long_test/` — des tests qui créent de vraies machines, QEMU et Proxmox imbriqués compris, hors du lanceur unitaire
- NTFY, Forgejo, un serveur git local, le courriel depuis le CLI, et la configuration SSH avec ProxyJump récursif
- L'interpréteur Python et l'installateur de paquets se choisissent, par EL_PYTHON_PROVIDER et EL_PIP_PROVIDER
- La politique d'IA générative de l'OCA, les agents et commandes Claude Code, et le contexte donné à un assistant, montré depuis le menu
- Des tests unitaires avec un plan de test bilingue, la télémétrie de navigation de TODO, et Odoo 18 qui lit les fichiers STL
<!-- [en] -->
## Changed
<!-- [fr] -->
## Modifié
<!-- [en] -->
- todo.py split into nine files, one per subject, with a shared base per form
- Every menu entry carries an icon, the menus are grouped into sections, and a countdown prompt gives 15 seconds to decide
- Branch, profile, type and timezone are chosen per VM rather than globally
- Installation covers Fedora, Debian, Ubuntu, Arch and openSUSE; repository sync and Poetry run in parallel, quiet unless EL_VERBOSE asks
- Node.js 22 for Capacitor 8, flanker for Odoo 18, CybroOdoo extras opt-in, and a Poetry dependency declinable per architecture
- A VM boots faster and picks the fastest reachable mirror, Canadian pacman mirrors coming first on Arch
- Staging names the files, never `git add -A`
- Enter targets the highest supported Odoo version, and a VM name drops the `latest` segment
<!-- [fr] -->
- todo.py éclaté en neuf fichiers, un par sujet, avec un socle commun par formulaire
- Chaque entrée de menu porte une icône, les menus sont regroupés en sections, et une invite à compte à rebours laisse 15 secondes pour décider
- La branche, le profil, le type et le fuseau se choisissent par VM plutôt que globalement
- L'installation couvre Fedora, Debian, Ubuntu, Arch et openSUSE ; la synchronisation des dépôts et Poetry tournent en parallèle, silencieux sauf si EL_VERBOSE le demande
- Node.js 22 pour Capacitor 8, flanker pour Odoo 18, les extras CybroOdoo optionnels, et une dépendance Poetry déclinable par architecture
- Une VM démarre plus vite et prend le miroir joignable le plus rapide, les miroirs pacman canadiens passant en tête sur Arch
- L'indexation nomme les fichiers, jamais `git add -A`
- Entrée cible la version d'Odoo la plus élevée supportée, et un nom de VM perd le segment `latest`
<!-- [en] -->
## Fixed
<!-- [fr] -->
## Corrigé
<!-- [en] -->
- The libvirt network no longer counts as its own collision, no longer leaves a host without network at the next boot, and its state is read in English whatever the locale
- QEMU deployment: sudo says why it needs a password, the `libvirt` group replaces it where it suffices, no host reboots unasked, and an orphan disk no longer blocks a creation
- Migration: the database drop, the account.root view Odoo 17 leaves behind, the pricelists a repair invented, and the assumptions the 13-to-18 run rested on
- Anonymisation respects what a value means, and no longer breaks past the 131 072-byte limit of a single argument
- Installation on Debian 13, Fedora, Ubuntu 26.04 and s390x: apt locks, missing compilers and headers, too little memory, and what a recent SWIG or PROJ needs
- Secrets: the KeePassXC vault opens on a server without tkinter, the forgejo installer stops echoing the password it set, and db_restore validates the master one
- A question is seen before it is answered, and one faulty repository no longer takes a whole batch down
- Three screens that fell over, a shrink that would have filled the disk, and a monitor that binned a VM before being sure
- The unit runner globs the whole directory, where it ran 1131 tests of 3703
- Proxmox no longer aims at the host instead of the VM
<!-- [fr] -->
- Le réseau libvirt ne compte plus comme sa propre collision, ne laisse plus un hôte sans réseau au démarrage suivant, et son état est lu en anglais quelle que soit la locale
- Le déploiement QEMU : sudo dit pourquoi il faut un mot de passe, le groupe `libvirt` le remplace là où il suffit, aucun hôte ne redémarre sans qu'on le demande, et un disque orphelin ne bloque plus
- La migration : l'effacement de base, la vue account.root que laisse Odoo 17, les listes de prix qu'une réparation inventait, et les suppositions sur lesquelles tenait le passage de 13 à 18
- L'anonymisation respecte ce qu'une valeur signifie, et ne casse plus au-delà de la limite de 131 072 octets d'un seul argument
- L'installation sur Debian 13, Fedora, Ubuntu 26.04 et s390x : verrous apt, compilateurs et en-têtes manquants, mémoire trop courte, et ce qu'exigent un SWIG ou un PROJ récents
- Les secrets : le coffre KeePassXC s'ouvre sur un serveur sans tkinter, l'installateur forgejo cesse de réafficher le mot de passe qu'il a posé, et db_restore valide celui du maître
- Une question se voit avant qu'on y réponde, et un dépôt fautif n'emporte plus tout un lot
- Trois écrans qui tombaient, une réduction qui aurait rempli le disque, et un suivi qui mettait une VM à la poubelle avant d'en être sûr
- Le lanceur unitaire balaie tout le répertoire, là où il exécutait 1131 tests sur 3703
- Proxmox ne vise plus l'hôte au lieu de la VM
<!-- [en] -->
## Removed
<!-- [fr] -->
## Retiré
<!-- [en] -->
- Ubuntu 20.04 and 22.04 support, on every architecture
- The residue check that called a language broken when its `active` is NULL
<!-- [fr] -->
- Le support d'Ubuntu 20.04 et 22.04, sur toutes les architectures
- Le contrôle de résidus qui jugeait cassée une langue dont `active` est NULL
<!-- [en] -->
## Security
<!-- [fr] -->
## Sécurité
<!-- [en] -->
- Passwords and tokens are redacted before a command is displayed, logged or reprinted
- The Odoo master password and the KeePass one leave the command line, an environment variable carrying them instead
<!-- [fr] -->
- Les mots de passe et jetons sont caviardés avant l'affichage, la journalisation ou le réaffichage d'une commande
- Le mot de passe maître d'Odoo et celui de KeePass quittent la ligne de commande, une variable d'environnement les portant à la place
<!-- [common] -->
## [1.7.0] - 2026-03-11
<!-- [en] -->
**Migration notes**
@ -41,41 +561,47 @@ Recréer l'environnement virtuel, utiliser le guide d'installation depuis l'outi
## Ajouté
<!-- [en] -->
- Support Odoo migration database and module with TODO
- Support multi version odoo switch on same workspace
- Script for hardening the installation
- Support Odoo versions 12.0 to 18.0
- Separate ERPLibre python installation from Odoo python with .venv.erplibre and .venv.odoo18
- Implement auto-installation with TODO.py
- TODO show documentation, download database, help with code formatting
- Performance script to mesure request per second
- Support Mainframe architecture 390x
- Deployment with Cloudflare and Nginx
- Support Apache configuration like Nginx
- Support RobotLibre code generator
- Support ERPLibre DevOps, automation procedure about DevOps
- ERPLibre Home Mobile Application, use TODO to compile, deploy it and personalize it
- Support Selenium grid from selenium_lib.py
- Add addons OnlyOffice, Cetmix, OCA automation, OCA shopfloor
- Odoo 12.0 to 18.0 in a single workspace, switched without reinstalling: the manifests, the configuration and the addons paths follow the version named in `.odoo-version`
- ERPLibre's Python separated from Odoo's — `.venv.erplibre` carries the repository's own tools, `.venv.odoo<version>` the server — so a tool of the repository no longer depends on the interpreter a given Odoo version imposes
- Auto-installation driven from TODO: the menu lays down the environment it needs, Poetry, the Google Repo manifests and the addons included, rather than printing a command to retype
- Migration of an Odoo database and its modules from TODO, `--neutralize` included, with the repair of the mail module that a move from PostgreSQL 17 to 18 leaves behind
- A hardening script for the installation
- The ERPLibre Home mobile application: TODO compiles it, deploys it, renames the software and changes its menu image
- The RobotLibre code generator, with the queue_job channels its configuration needs
- ERPLibre DevOps, and the automation procedure it describes
- The Selenium grid from `selenium_lib.py`: a KeePass vault opened for the run, file downloads, dark mode, video recording and a scenario library
- A performance script measuring the requests per second a website answers
- Deployment: Cloudflare DNS, nginx with a non-interactive certbot, Apache templates matching the nginx ones, and a systemd unit whose working directory is configurable
- The s390x mainframe architecture
- Addons OnlyOffice, Cetmix, OCA automation, OCA shopfloor, and the design-themes repository
- Database backup and erase commands, and a clearer restore naming
- A security check of the Python environment, from the menu
- TODO shows the documentation, downloads a database and helps with code formatting
- Killing an Odoo process by the port it holds, from the menu
- CLAUDE.md and the agent information document, so an assistant reads the repository's conventions instead of guessing them
- A FAQ entry on wkhtmltopdf for recent distributions
<!-- [fr] -->
- Support de la migration de base de données et de modules Odoo avec TODO
- Support du changement multi-version Odoo sur le même espace de travail
- Script pour le renforcement de la sécurité de l'installation
- Support des versions Odoo 12.0 à 18.0
- Séparation de l'installation Python ERPLibre de celle d'Odoo avec .venv.erplibre et .venv.odoo18
- Implémentation de l'auto-installation avec TODO.py
- TODO affiche la documentation, télécharge la base de données, aide au formatage du code
- Script de performance pour mesurer les requêtes par seconde
- Support de l'architecture Mainframe 390x
- Déploiement avec Cloudflare et Nginx
- Support de la configuration Apache comme Nginx
- Support du générateur de code RobotLibre
- Support d'ERPLibre DevOps, procédure d'automatisation DevOps
- Application mobile ERPLibre Home, utiliser TODO pour compiler, déployer et personnaliser
- Support de la grille Selenium depuis selenium_lib.py
- Ajout des addons OnlyOffice, Cetmix, OCA automation, OCA shopfloor
- Odoo 12.0 à 18.0 dans un même espace de travail, changés sans réinstaller : les manifestes, la configuration et les chemins d'addons suivent la version nommée dans `.odoo-version`
- Le Python d'ERPLibre séparé de celui d'Odoo — `.venv.erplibre` porte les outils du dépôt, `.venv.odoo<version>` le serveur — si bien qu'un outil du dépôt ne dépend plus de l'interpréteur qu'impose une version d'Odoo
- L'auto-installation pilotée depuis TODO : le menu pose l'environnement dont il a besoin, Poetry, les manifestes Google Repo et les addons compris, au lieu d'afficher une commande à retaper
- La migration d'une base Odoo et de ses modules depuis TODO, `--neutralize` compris, avec la réparation du module mail que laisse un passage de PostgreSQL 17 à 18
- Un script de renforcement de la sécurité de l'installation
- L'application mobile ERPLibre Home : TODO la compile, la déploie, renomme le logiciel et change son image de menu
- Le générateur de code RobotLibre, avec les canaux queue_job que sa configuration réclame
- ERPLibre DevOps, et la procédure d'automatisation qu'il décrit
- La grille Selenium depuis `selenium_lib.py` : un coffre KeePass ouvert pour l'exécution, le téléchargement de fichiers, le mode sombre, l'enregistrement vidéo et une bibliothèque de scénarios
- Un script de performance qui mesure les requêtes par seconde qu'un site répond
- Le déploiement : DNS Cloudflare, nginx avec un certbot non interactif, gabarits Apache alignés sur ceux de nginx, et une unité systemd dont le répertoire de travail se configure
- L'architecture mainframe s390x
- Les addons OnlyOffice, Cetmix, OCA automation, OCA shopfloor, et le dépôt design-themes
- Des commandes de sauvegarde et d'effacement de base, et un nommage plus clair à la restauration
- Une vérification de sécurité de l'environnement Python, depuis le menu
- TODO affiche la documentation, télécharge une base et aide au formatage du code
- Tuer un processus Odoo par le port qu'il occupe, depuis le menu
- CLAUDE.md et le document d'information des agents, pour qu'un assistant lise les conventions du dépôt au lieu de les deviner
- Une entrée de FAQ sur wkhtmltopdf pour les distributions récentes
<!-- [en] -->
## Changed
@ -83,15 +609,65 @@ Recréer l'environnement virtuel, utiliser le guide d'installation depuis l'outi
## Modifié
<!-- [en] -->
- Docker support postgresql 18
- Format script search diff file into each repository
- Support neutralize database from Odoo
- Odoo 18.0 becomes the default version of a checkout
- Docker moves to PostgreSQL 18, with the matching client
- The documentation is bilingual, generated by mmg from the `.base.md` sources: a `.md` or `.fr.md` edited directly is lost at the next generation
- The TODO menus are grouped into sections, and the English text serves as the i18n key rather than a code of its own
- The formatting script looks for the changed files in every repository, hidden addons included, and skips a repository that is not installed
- Odoo runs on a custom database, and the menu configures queue_job as well as the SSH forwarding a remote instance needs
- Killing a process by port asks before acting, through an interactive menu
- Neutralising a database goes through Odoo's own `--neutralize`
- LinuxMint 22.3, Ubuntu 25.10, and macOS without Python 3.7
- Odoo 18 dependencies: tldextract, PyYAML, pdfminer.six, and cryptography at its latest version
- A make target runs the unit tests
- The Makefile is split: its commands live in `conf/`, and `Common.Makefile` extends it for a project of one's own
<!-- [fr] -->
- Support Docker postgresql 18
- Script de formatage recherche les fichiers diff dans chaque dépôt
- Support de la neutralisation de base de données depuis Odoo
- Odoo 18.0 devient la version par défaut d'un checkout
- Docker passe à PostgreSQL 18, avec le client correspondant
- La documentation est bilingue, générée par mmg depuis les sources `.base.md` : un `.md` ou `.fr.md` modifié directement est perdu à la prochaine génération
- Les menus TODO sont regroupés en sections, et le texte anglais sert de clé i18n plutôt qu'un code à part
- Le script de formatage cherche les fichiers modifiés dans chaque dépôt, addons cachés compris, et saute un dépôt qui n'est pas installé
- Odoo tourne sur une base personnalisée, et le menu configure queue_job comme la redirection SSH qu'une instance distante réclame
- Tuer un processus par son port demande confirmation, par un menu interactif
- La neutralisation d'une base passe par le `--neutralize` d'Odoo
- LinuxMint 22.3, Ubuntu 25.10, et macOS sans Python 3.7
- Dépendances Odoo 18 : tldextract, PyYAML, pdfminer.six, et cryptography à sa dernière version
- Une cible make lance les tests unitaires
- Le Makefile est éclaté : ses commandes vivent dans `conf/`, et `Common.Makefile` l'étend pour un projet à soi
<!-- [en] -->
## Fixed
<!-- [fr] -->
## Corrigé
<!-- [en] -->
- The documentation accents, and the markdown generation running in parallel
- `git_tool` returns nothing instead of raising where `.git` is absent
- `poetry iscompatible` no longer crashes on a version carrying a letter, an alpha or a release candidate
- pymssql compiles again, and the Odoo 18 requirements leave pyssql out of a production install
- wkhtmltopdf is no longer offered where it does not exist: no package is published for s390x on Ubuntu 25.10
- Selenium: the snap Firefox path, a 60-second timeout when reaching for an element, execution in a private window, and a login that waits for Odoo 18
- The formatting script ignores the files and directories it must not touch
- `db_drop_all` runs its shell command, and the backup processing keeps the permissions of what it writes
- TODO: the first import, the regeneration of `.repo/local_manifests`, the database open dialog, and a missing Odoo version reported instead of a crash
- The code generator: creating a project, extracting a class carrying a selection, and reading a model through the Python 3.11 `ast` module rather than astor
- Docker: the duplicated Odoo 18 build target, and the compose file pinned to an image that works
<!-- [fr] -->
- Les accents de la documentation, et la génération markdown qui tourne en parallèle
- `git_tool` rend vide au lieu de lever là où `.git` est absent
- `poetry iscompatible` ne casse plus sur une version portant une lettre, une alpha ou une candidate
- pymssql se compile de nouveau, et les dépendances Odoo 18 laissent pyssql hors d'une installation de production
- wkhtmltopdf n'est plus proposé là où il n'existe pas : aucun paquet n'est publié pour s390x sur Ubuntu 25.10
- Selenium : le chemin du Firefox snap, un délai de 60 secondes pour atteindre un élément, l'exécution en fenêtre privée, et une connexion qui attend Odoo 18
- Le script de formatage ignore les fichiers et répertoires qu'il ne doit pas toucher
- `db_drop_all` exécute sa commande shell, et le traitement des sauvegardes garde les permissions de ce qu'il écrit
- TODO : le premier import, la régénération de `.repo/local_manifests`, le dialogue d'ouverture de base, et une version d'Odoo manquante signalée au lieu d'un plantage
- Le générateur de code : la création d'un projet, l'extraction d'une classe portant une sélection, et la lecture d'un modèle par le module `ast` de Python 3.11 plutôt que par astor
- Docker : la cible de compilation Odoo 18 en double, et le fichier compose épinglé sur une image qui fonctionne
<!-- [common] -->
@ -1116,7 +1692,11 @@ Parce que le dépôt d'addons a changé, le fichier de configuration doit être
@ -9,34 +9,301 @@ au [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
## [Unreleased]
## Ajouté
- Des préréglages de site pour le VPN : un `.json` porte la passerelle d'un site, son protocole et son groupe de connexion, et ni identifiant ni secret, si bien qu'il peut circuler. Lus depuis `conf/vpn_presets/`, puis depuis un `private/vpn/presets/` ignoré par git, puis depuis tout répertoire listé dans `vpn_preset_paths` ; sur un même identifiant le plus tardif gagne, et un site corrige un gabarit livré sans toucher de fichier suivi
- Importer un profil Cisco AnyConnect `.xml` depuis le menu, en parcourant les répertoires du client ou en tapant le chemin, et en tirer un préréglage de ses balises `HostName`, `HostAddress` et `UserGroup`
- OpenConnect distingue les deux mécanismes qui désignent un service sur un même concentrateur : le groupe de connexion dans l'URL et la valeur choisie dans un menu déroulant. Les confondre donne le formulaire d'un autre service, et des identifiants justes sont refusés sans que rien ne nomme le groupe
- Joindre une passerelle qui exige un navigateur intégré pour le SAML, ce qui arrête OpenConnect sur « No SSO handler » : l'étape web est déléguée à un greffon `openconnect-sso` que l'installateur propose de poser, et le tunnel est ensuite monté par le pilote lui-même, si bien que le nom d'interface, les fichiers d'état et le diagnostic restent au profil
- Déclarer un concentrateur qui ne compare que les premiers caractères d'un mot de passe : il est annoncé avant le dépôt du secret, et rien n'est jamais tronqué
- L'installateur VPN cherche `vpnc-script` — un fichier, et non un binaire du `PATH` — et nomme le paquet à poser par famille de distribution, au lieu de laisser le tunnel échouer sur une interface qui n'apparaît jamais
- Une commande lancée par l'exécuteur VPN reçoit `/dev/null` sur son entrée standard, si bien qu'une commande à sortie capturée ne peut plus être arrêtée par un SIGTTOU et figer le gestionnaire de paquets de la machine
- La liste des profils VPN marque ceux qui portent un tunnel vivant, si bien que connecter un profil déjà monté demande confirmation et que déconnecter un profil déjà tombé le dit au lieu de ressembler à une erreur. Un profil est jugé sur son interface et non sur le fichier d'état qu'un tunnel tué sans `down` laisse derrière lui — un état laissé était annoncé monté sur l'écran même qui déclarait le processus mort
- `Assistant › LLM` — interroger un serveur de modèle sur plusieurs tours, local ou distant. L'historique vit en mémoire et meurt avec le menu, `/save` étant le seul moyen d'en garder une trace ; toute commande porte une barre oblique initiale, donc une question collée sur plusieurs lignes reste un seul tour. Une destination tierce doit être retapée avant le premier envoi
- Reconnaissance du serveur sur onze ports et douze familles, l'identité étant lue dans le CORPS de la réponse et jamais dans le port : un port héberge jusqu'à trois produits, et une famille réémet l'API native d'une autre en entier
- Recherche d'un serveur depuis six sources — la boucle locale, les domaines QEMU de la machine, les hôtes de `~/.ssh/config`, une adresse ou un réseau saisi, et les réseaux lus en SSH sur une autre machine. Plus large qu'un `/24` est refusé avant énumération, et deux préférences bornent le balayage : `assistant_sweep_workers`, `assistant_sweep_timeout`
- Un catalogue d'outils gpt dans `script/todo/assistant/gpt/` : un fichier Markdown par outil, dont les exigences déclarées sont confrontées à ce que le serveur annonce. L'inconnu ne grise jamais un outil — seule une exigence contredite par un champ réellement lu le fait, avec le chiffre qui la refuse
- Un contexte LECTURE SEULE déclaré par outil, fichiers et commandes autorisées, montré et confirmé avant le premier envoi, borné en taille et en durée, et balayé à la recherche de données identifiantes. La limite du balayage est dite : il voit les adresses, les courriels et les chemins de compte, pas les noms
- `Exécution › GPT code › Claude Code` — lister les sessions de la machine, en interroger une avec des outils en lecture seule, ou la reprendre dans son propre terminal. Une copie est branchée par défaut, deux écritures sur une même session perdant une branche
- `check_comment_hygiene.py` signale un nom de machine pleinement qualifié dans un commentaire, en signal à relire et jamais en trouvaille : un nom d'hôte NU ne se distingue mécaniquement pas d'un mot ordinaire, donc l'absence de signal ne prouve rien sur les noms. L'en-tête de copyright, les domaines de la RFC 2606 et toute adresse portée par une URL sont laissés tranquilles
- Transform data, une entrée de menu qui ouvre un fichier externe — Excel, Access, CSV, XML ou JSON —, rapporte ce qu'il porte, puis en tire une copie anonymisée. L'original n'est jamais touché. Les nombres sont tirés dans l'étendue mesurée de leur propre colonne plutôt que dans un intervalle fixe de 0 à 1000, qui rend un taux de TVA à 743 et une année à 12 ; ils sont tirés sans remise, cent clés distinctes dans une étendue de cent ne rendant sinon que soixante-six sorties, et une fixture qui ne se réimporte plus. Le texte prend un mot français dans un dictionnaire local de 1366, attribué par un compteur et non par un tirage, et une table de correspondance portable donne au même client le même mot sur tout un lot
- Onze étiquettes structurelles sont laissées intactes sur leur NOM — `id`, `create_uid`, `sequence`, `active` et les autres, plus tout ce qui finit en `/id` ou `/.id` —, un jeu de test devant continuer de fonctionner. Toute AUTRE colonne est jugée sur son CONTENU mesuré, jamais sur la seule foi de son nom. Dans un export import-compatible, `partner_id` porte le nom affiché de la relation et `display_name` est la donnée elle-même : décider sur l'étiquette recopiait textuellement les colonnes les plus identifiantes du fichier en les annonçant comme protégées
- L'anonymiseur relit les octets qu'il vient d'écrire et refuse la copie dès qu'une valeur annoncée comme remplacée y subsiste. Un classeur porte de la donnée dans une douzaine d'endroits qui ne sont pas des cellules : un cache de tableau croisé et un lien externe en portent chacun une copie entière, un graphique met ses catégories et ses titres d'axes en cache, un format de nombre personnalisé porte un libellé, un commentaire porte son auteur, un hyperlien de cellule porte un chemin. Le filet ne dépend d'aucune liste de ces endroits, si bien qu'un endroit que personne n'a pensé à nettoyer produit un refus et non un silence — et ce qui reste par décision, une ligne d'en-tête ou une colonne laissée intacte, est nommé à l'écran avant que rien ne soit écrit
- Transform data anonymise aussi une base Odoo, l'entrée demandant la SOURCE plutôt que le format : un fichier externe, une base vivante, ou un zip de sauvegarde pris dans `image_db/`. Un zip n'est jamais modifié — il est restauré dans une base, anonymisé là, puis vidé dans un zip NEUF par la sauvegarde d'Odoo lui-même, si bien que le dump, le filestore et le manifeste sont écrits par le logiciel qui les relira. Une base vivante est modifiée ELLE-MÊME, ce qui est dit avant le travail et non après, et rien n'est tiré lorsque l'écriture n'a pas eu lieu : un renoncement rendait sinon un zip de la base intacte, annoncé comme anonymisé. Un registre inscrit les bases que l'entrée a produites, le serveur ne le disant pas
- Un nombre anonymisé peut garder son nombre de chiffres, sur l'anonymiseur de fichiers comme sur `anonymize.py` (`--keep-digits`) : 8839 tire alors dans 1000..9999, si bien que la copie garde des colonnes de la même largeur, ce qu'un export relu à l'œil ou importé dans un champ borné demande. Chaque valeur garde SA largeur et non celle de sa colonne — 7 reste à un chiffre là où 12 en garde deux — et sous l'unité la règle ne s'applique pas, 0,15 n'ayant pas de chiffre avant la virgule. L'option échange une garantie contre une autre : l'étendue mesurée ne borne plus rien, donc un taux ou une année peut sortir de sa plage, et l'aperçu le DIT au lieu de le laisser découvrir à la réimportation. C'est l'unicité qui cède quand une bande se remplit, un doublon de la même largeur valant mieux qu'une valeur d'une autre, et la bande ne dépasse jamais ce que tient le type qui ACCUEILLE le tirage, lequel n'est pas toujours celui de la colonne : un `integer` d'Odoo posé sur une colonne que PostgreSQL n'a pas créée entière — ce qu'une base montée de version porte — se coule en `numeric`, qui n'a pas de plafond, là où `integer` s'arrête à 2 147 483 647 et où un tirage au-delà fait retomber toute l'écriture, celle-ci tenant en une transaction
- L'anonymiseur pose quatre questions au lieu de onze, sept des onze ayant eu un défaut évident. Les répondre une par une pour arriver au même endroit fait passer les invites par réflexe, et une invite qu'on passe par réflexe ne consent à rien : elles vivent désormais derrière « Options avancées ? ». Le chemin court DIT ce qu'il prend, en phrases et non en oui/non, puisque ce sont des décisions prises et non des questions dont on aurait perdu la réponse. Macros et graphiques sont demandés dans les deux chemins : ils ne se voient pas dans les cellules
- `markdown-it-py` est déclaré en dépendance fonctionnelle : il rend en HTML le markdown du modèle de langage, avant assainissement, sur la page de l'assistant. Il arrivait dans l'environnement en transitif par `bandit` → `rich`, un outil de lint, si bien que retirer une dépendance de lint retirait le moteur de rendu d'une page portail
- Un cache de téléchargement partagé par les VM QEMU d'un hôte, installé depuis **Déploiement › Cache QEMU**. Deux VM de la même distribution cessent de tirer deux fois les mêmes centaines de mégaoctets : un fichier de paquet est servi du disque, tandis qu'un index est toujours repris à l'amont, si bien qu'un paquet retiré ne peut jamais devenir un « failed retrieving file … 404 ». L'index est stocké quand même et ne ressort que si l'amont est injoignable, ce qui rend un déploiement hors ligne possible. Le cache ne diminue jamais de lui-même : `--status` dit ce qu'il occupe
- L'interception est transparente et vaut pour tout le pont de l'hôte : une VM ne peut pas s'y soustraire de l'intérieur. Toutes approuvent l'autorité du cache tant que le service tourne. Pour en soustraire UNE, cocher « soustraire cette VM au cache » au déploiement : son adresse MAC est fixée avant la création et une exception est posée sur l'hôte. Pour les soustraire toutes, arrêter le service — ses règles partent avec lui. Un hôte Proxmox qui est lui-même une VM d'ici n'y échappe pas : les machines qu'il porte sortent derrière son adresse, et le déploiement pose donc l'autorité dans chacune, par ssh, avant d'installer quoi que ce soit
- La mesure ne se limite plus à Arch : tout système du catalogue dont la famille de paquets est connue, et au choix un lot de paquets ou l'installation réelle d'ERPLibre et d'Odoo 18. Mesuré sur Ubuntu 24.04 avec cette installation réelle, la seconde VM n'a tiré **aucun octet** de paquet du réseau et a fini 19 % plus vite. Vérifié sur les sept systèmes du catalogue
- Git est mis en MIROIR plutôt que caché : son protocole est une négociation, le serveur calculant sa réponse d'après ce que le client détient déjà, si bien qu'aucune réponse ne se réutilise. Un miroir nu par dépôt amont est tenu sur l'hôte et servi localement, et un miroir déjà détenu sert sans aucun réseau — mesuré, un dépôt cloné dans une VM alors que l'amont du cache était coupé. Mesuré sur une installation complète d'ERPLibre : la seconde VM n'a tiré **aucune** requête git de l'amont, là où git pesait quatre cinquièmes du trafic. **Déploiement › Cache QEMU › Miroirs git** les remplit d'avance depuis les manifestes, pour que la première VM ne paie pas tous les clonages
- Un déploiement hors ligne couvre aussi la suite de base d'une image cloud. Son apt REVALIDE l'index qu'elle livre au lieu de le télécharger, l'amont rend 304, et le cache n'avait donc aucun corps à garder — cette suite-là, et elle seule, manquait hors ligne pendant que ses voisines `-updates` et `-security` sortaient du disque. Une requête conditionnelle sur ce que le cache ne détient pas part désormais sans sa condition, une fois ; et un client qui détient sa propre copie reçoit 304 plutôt que 504 quand l'amont est muet.
- Ce qu'un déploiement hors ligne couvre, exactement : les paquets, les index de dépôts et git. PAS ce que le cache n'a pas le droit de déchiffrer — un client qui porte son propre magasin de confiance, npm et poetry en sont, passe en tunnel opaque, et un tunnel ne porte rien une fois le réseau coupé. Une installation complète d'ERPLibre demande donc toujours le réseau, même si tout ce que le cache détient est servi du disque
- Un miroir est COMPLET là où `repo sync` clone en profondeur un : il coûte donc des dizaines de gigaoctets. Sous dix gigaoctets libres, aucun miroir neuf n'est créé et la requête repart vers l'amont. Le diagnostic dit ce qu'occupent les objets et les miroirs, séparément
- **Déploiement › Cache QEMU › Âge et nettoyage** groupe le cache par âge du dernier usage (jour, semaine ou mois ; objets et dépôts git séparément) et rend ce qui n'a plus servi depuis un délai choisi, ou tout. Un objet servi voit sa date remise à jour : « vieux » veut donc dire « n'a plus servi ». Les deux nettoyages disent ce qui partirait avant d'effacer quoi que ce soit, et l'entrée 5 liste les miroirs du plus lourd au plus léger pour en effacer un
- `long_test/qemu_cache.py` mesure si le cache sert vraiment la seconde VM, et `--hors-ligne` coupe l'amont du seul service du cache pour prouver qu'une troisième se bâtit encore sur l'index stocké
- Avant de couper, le formulaire dit si le cache détient la suite de base de chaque système demandé : F5 prévient « le cache ne détient rien pour ubuntu 26.04 » et un second F5 passe outre. Le verdict n'est rendu que là où une version se nomme sans ambiguïté dans l'URL — les familles apt — plutôt que de rassurer à tort ailleurs. Le verdict est rendu composant par composant — `main`, `universe`, `restricted`, `multiverse`, sur la suite de base et sur ses compagnes `-updates` et `-security` —, car une seule URL en réserve le rendait muet quand un composant entier manquait, et apt ne le disait que vingt minutes plus tard, par « Unable to locate package »
- **Déploiement › Cache QEMU › L'emporter sur une autre machine** porte le magasin vers un autre hôte ERPLibre en un seul flux — `tar`, compressé, par ssh, sans fichier intermédiaire pour des dizaines de gigaoctets — et rend les fichiers au compte du service à l'arrivée, le même compte portant rarement le même numéro sur deux machines. Seul le MAGASIN voyage : un objet est rangé sous son URL et jamais sous la machine qui l'a pris, et un miroir git est un dépôt. Les réglages restent — pont, sous-réseau et autorité appartiennent à l'hôte, et l'entrée 1 les pose là-bas
- Le formulaire de déploiement porte une section **Réseau** avec « Sans connexion internet » : pour tout le déploiement, installation comprise, le service du cache perd sa sortie ET les VM perdent la leur — ping, autres ports, UDP, IPv6 —, si bien qu'un pas qui prendrait un autre chemin que le cache échoue au lieu de réussir en ligne sans rien dire. Les noms ne se résolvent plus par l'internet non plus : l'hôte répond lui-même à tout nom une adresse que le cache intercepte, si bien que seul ce que le cache détient est joignable ; dnsmasq doit être installé sur l'hôte. Une VM derrière le cache tire d'un seul miroir apt, fixe : la recherche de miroir de cloud-init écarte tout miroir derrière un résolveur qui répond à tout nom, et retomberait sur un autre miroir que celui dont les VM précédentes ont rempli le cache. La coupure refuse au lieu de jeter : une adresse que le cache ne détient pas répond 504 sur-le-champ, et non après un délai de connexion ; un noyau qui ne peut pas charger le module du refus reçoit le jeu qui jette. Offerte seulement là où le cache tourne, et le déploiement refuse plutôt que de partir avec l'amont debout, une VM bâtie ainsi réussissant pour la mauvaise raison. **Proxmox VE** porte la même case, offerte là où son hôte est lui-même une VM de ce pont : ses invités sortent derrière son adresse, si bien que la coupure locale les couvre et que rien n'est posé sur l'hôte distant. Un hôte Proxmox qui ne vit pas ici ne la reçoit jamais — rien ici ne sait couper sa sortie
- Un déploiement Proxmox VE peut demander l'**accélération 3D**. La VM est créée avec un écran accéléré (`--vga virtio-gl`) plutôt que la console série comme affichage, et le compte entre dans les groupes du GPU DANS l'invité : le nœud de rendu appartient à « root:render », si bien que sans eux toute application GL retombe en rendu logiciel alors que la négociation VIRGL a réussi, et rien ne le signale. La case n'est offerte que là où l'hôte distant a le nœud de rendu ET les trois bibliothèques que Proxmox charge pour cet écran — VIRGL, GL et EGL. Il nomme celles qui manquent et refuse de démarrer la machine, une fois son disque écrit et sa configuration posée : un hôte portant GL sans EGL échouerait donc à la toute dernière étape. Là où une pièce manque, le formulaire dit laquelle et quel paquet poser sur l'hôte — une case qui disparaît sans un mot se lit comme une régression. Un bouton les pose sans quitter l'écran — le formulaire rend le terminal pour que sudo puisse demander un mot de passe et qu'on voie apt travailler —, puis relit l'hôte au lieu de croire apt sur parole, et la case prend la place du message. Le port série reste posé, donc « qm terminal » fonctionne toujours
- Hors ligne, le cache rejoue ce qu'un passage en ligne a vu, et non plus les seuls corps en 200 : redirections, refus définitifs (404/410) et réponses HEAD des adresses volatiles sont gardés sans corps, sous des clés à eux, et servis SEULEMENT quand l'amont est muet. Un client TUF qui sonde la version suivante de sa racine reçoit le 404 qu'il attend au lieu d'un 504 : mise pose Python hors ligne, vérification Sigstore intacte ; les extensions GNOME, l'installateur de Claude Code et la version de rtk suivent leurs redirections hors ligne
- La coupure hors ligne tombe avec la dernière installation, et non à la fermeture du suivi : une unité root, qui reçoit la levée au lancement, attend le marqueur de fin de chaque installation et survit au suivi fermé tôt, à todo.py tué ou au terminal perdu — 12 h au plus. Le suivi est donc obligatoire hors ligne. Un second déploiement hors ligne est refusé pendant qu'un premier tourne, et un déploiement en ligne lancé entre-temps est prévenu qu'il tournerait hors ligne
- F5 lit aussi les essais hors ligne précédents de la même VM et prévient « au moins N adresses ont manqué », moins ce que le magasin détient désormais (`erplibre_go_qemu_cache --detient`, en lecture seule, sans root). **Déploiement › Cache QEMU › Combler ce qui a manqué hors ligne** les rejoue en ligne, à travers le cache
- Le journal d'installation nomme le commit que la VM exécute ; hors ligne, le récapitulatif dit, branche par branche, quel commit le miroir du cache donnera
- `long_test/qemu_cache.py --distro tous` (ou une liste séparée par des virgules) enchaîne une campagne par système du catalogue, défait les VM de chaque système avant le suivant, et finit sur un tableau des verdicts, durées et octets d'amont. Un échec n'arrête pas la série
- Le cache de téléchargement QEMU peut se nettoyer chaque jour : par âge (`EL_PURGE_AGE`, ex. `90j`) et par plafond de taille (`EL_MAX_SIZE`, ex. `50G`, le moins récemment servi partant d'abord, objets et miroirs git confondus). Les deux sont désactivés par défaut et se règlent depuis **Déploiement › Cache QEMU › Nettoyage automatique**, qui montre ce qui partirait ; `--purge-to-size` applique le plafond à la main. Une réinstallation garde les valeurs choisies
- NixOS 25.11 parmi les systèmes déployables, à côté des huit autres. C'est le seul dont aucune distribution ne publie d'image cloud : l'image est rebâtie par un tiers, donc sa version est épinglée, sa somme sha256 vérifiée à chaque téléchargement, et son origine dite avant que rien ne soit créé. cloud-init n'y reçoit aucune configuration réseau — son moteur networkd prend la clé d'un bloc pour un NOM d'interface, là où netplan honore un `match:` — et le compte y est créé avec `/bin/sh`, sshd refusant un compte dont le shell n'existe pas
- ERPLibre installé sur NixOS, ses dépendances DÉCLARÉES dans `conf/nixos/erplibre.nix` puis appliquées par `nixos-rebuild`, là où les quatre autres familles les installent commande par commande. `services.envfs` répond à `/usr/bin/env` et `programs.nix-ld` donne aux roues manylinux le chargeur dynamique qu'elles réclament ; les en-têtes de ce qui n'a pas de roue sont liés au profil du système, et leurs bibliothèques vont aussi au chargeur, un module compilé sur la machine ne portant pas de RPATH. L'installation l'atteint depuis le menu comme toute autre distribution : l'amorçage pose git, make et python3 — absents de cette image — dans le profil de l'utilisateur pour la durée du clone, et « make install_os » les redéclare pour le système. Vérifié sur une VM : le verrou de 362 paquets s'installe et Odoo répond en HTTP
- Une option `nix + nixos-anywhere` sur les AUTRES distributions, l'inverse de choisir NixOS : elle laisse une VM ordinaire capable d'installer NixOS sur toute machine joignable en SSH. Nix est appelé par son chemin absolu, le PATH du shell distant étant figé avant que l'installateur ne pose le binaire, et les fonctions des flakes sont redonnées sur la ligne de commande, l'écriture de `nix.conf` réclamant un sudo qui peut manquer
- NixOS se déploie sur un hôte **Proxmox** comme sur QEMU/KVM, ce qui a demandé trois correctifs qu'aucune lecture de code n'aurait trouvés. Son image n'a pas de secteur d'amorçage BIOS : une VM créée en SeaBIOS se déclare « running » avec une console muette, donc le catalogue marque désormais les images qui exigent l'UEFI — un marqueur par distribution, Debian 13 démarrant en SeaBIOS sur ce même hôte. `--ciuser` et `--sshkeys` s'en remettent au compte par DÉFAUT de l'image, que NixOS nomme autrement : le cloud-config du dépôt part maintenant comme extrait pour toutes les distributions, avec son bloc `users:` explicite. Et le lecteur cloud-init passe sur le bus SCSI — une image bâtie pour virtio seul n'a pas de pilote ATA et ne voit jamais un lecteur IDE, si bien que cloud-init cherchait des sources réseau et que la VM arrivait sans aucun compte. Vérifié de bout en bout : NixOS rend `/bin/sh`, Debian 13 `/bin/bash`, sudo aux deux
- L'image tierce est vérifiée contre la somme que le dépôt épingle pour elle sur le chemin Proxmox aussi, où un `wget` nu suffisait. Un seul accesseur porte cette somme pour les deux chemins, et le contrôle vaut même pour une image déjà en cache — le cas visé est un fichier substitué ou tronqué entre deux déploiements, qu'un test de présence ne voit pas
- Une entrée du cache de téléchargement peut être retirée, par son URL. Une somme qui ne correspond pas n'invalidait rien : le magasin continuait de servir les mêmes octets, et retélécharger ne changeait rien puisque c'est lui qui répond. Aucune des deux purges ne l'atteint — `--purge` efface tout, et `--purge-older-than` saute ce qui est récent alors que chaque service remet cette date, si bien qu'un objet empoisonné qui sert ne vieillit jamais. `--oublie` est le symétrique de `--detient` : mêmes lignes en entrée, mêmes fonctions de clé, mêmes refus, et un objet présent qui résiste est dit refusé plutôt qu'oublié. Les deux échecs de somme le nomment désormais, avec l'URL exacte
- Le journal d'installation porte ce que l'hôte a décidé avant de lancer : l'autorité du cache de téléchargement posée ou refusée, l'exception, le miroir. Ces lignes se disaient sur une console qui défile, pendant que le fichier qu'on rouvre après un échec ne portait que le symptôme — sur un invité sans magasin de confiance, un certificat refusé, des centaines de dérivations à construire et six cents lignes d'erreurs, sans un mot sur la cause
- Une entrée du cache de téléchargement s'oublie depuis le menu, sous « Âge et nettoyage ». Le binaire savait déjà le faire ; le menu n'offrait que les deux purges en gros, dont aucune ne vise un objet — « effacer ce qui n'a plus servi » n'atteint jamais celui que le service rajeunit chaque fois qu'il le rend, et « tout effacer » coûte le cache entier pour un fichier. `--detient` passe d'abord et fait l'aperçu : même ligne, même clé, sans rien modifier
- `erplibre_go_qemu_cache --recle` range à nouveau les objets d'un cache sous la clé courante, sans rien retélécharger, et fond les copies qu'un miroir portait sous plusieurs chemins. Les objets écrits sous l'ancienne règle de clé restent sur le disque mais deviennent INTROUVABLES, si bien que le service les redemande à l'amont et que la place qu'ils tiennent ne sert plus personne : sur un magasin de 12 764 objets, 5 419 étaient dans ce cas — 9,11 Gio — et la fusion des doublons a rendu environ 3,37 Gio. Le service doit être arrêté, le corps étant renommé avant son méta, et `--dry-run` ne fait que compter ce qui bougerait. Un statut seul n'est pas touché, sa clé portant l'hôte et non le chemin
- Le hook `pre-commit` lance `check_python_version.py` sur les fichiers indexés : il signale le source qui ne parse pas sous le Python de `conf/python-erplibre-version`, sans bloquer le commit, et dit quand aucun interpréteur de cette version n'était là pour vérifier. Ni black ni flake8 ne voient ce défaut — la cible de black borne ce qu'il écrit, jamais ce qu'il accepte
- `Déploiement › Local › [4]` ouvre un proxy SOCKS par SSH — `ssh -D`, port 1080 par défaut — pour que le navigateur atteigne, DEPUIS la machine distante, une interface qui n'écoute que sur sa boucle locale ou un hôte de son réseau. L'adresse vient de `~/.ssh/config` ou de la saisie ; un alias part tel quel à ssh, si bien que son `ProxyJump` s'applique encore et qu'une VM imbriquée reste joignable. Le réglage de Firefox s'affiche avant l'ouverture du tunnel, la commande ne rendant la main qu'au Ctrl+C
- `make format_test` formate `test/` et `long_test/`, qu'aucune cible ne couvrait : 75 fichiers sur 210 ne suivaient aucune norme, et seul un fichier signalé par un diff était touché
- `script/reverse_proxy/main.py` — un mandataire inverse de développement pour Odoo 18, sans nginx : une seule adresse envoie les pages au port web et `/websocket` au port du bus, les en-têtes `X-Forwarded-*` de `proxy_mode` n'étant posés que par le mandataire (`--trust-forwarded` prolonge plutôt une chaîne, derrière un autre mandataire). Seule la tête de la requête est lue : une WebSocket montée reste ouverte et une réponse gzip ou en morceaux passe octet pour octet. Il sert en HTTPS avec `--tls-cert`/`--tls-key`, écrit une ligne par requête (route, statut, durée ; `--quiet` la coupe), dit au démarrage quel port d'Odoo ne répond pas, et nomme ce port dans un 502. La tête d'une requête attend 30 s (408) et la connexion à Odoo 10 s (504), jamais une WebSocket ouverte. Écoute par défaut sur `127.0.0.1:8080`, `--listen 0.0.0.0` l'ouvre au réseau ; une requête par connexion, la production garde nginx
- `script/reverse_proxy/local_cert.py` émet une autorité locale, importée une fois dans le navigateur, et un certificat serveur qu'elle signe pour localhost, le nom d'hôte et ses adresses, sous `~/.erplibre/reverse_proxy_tls/` avec des clés en 0600 ; l'autorité est gardée quand le certificat est réémis
- `TODO › Execute › Network › Mandataire inverse Odoo` le lance avec les ports web et bus lus dans `config.conf`, demande cette machine seule ou tout le réseau et HTTP ou HTTPS, émet le certificat local au premier usage en HTTPS, et prévient quand `proxy_mode` est éteint ou que `workers` vaut 0 — sans worker, aucun port de bus n'écoute et `/websocket` échoue. `Network › Certificats TLS locaux` le réémet avec d'autres noms
## Modifié
- `Assistant › [1]` n'envoie plus chaque question à une seule API distante sur un modèle figé : elle interroge le serveur configuré, et ne retombe sur le distant que lorsqu'aucun serveur local ne répond
- Le contrôle d'hygiène des commentaires lit le Go, et non les seuls `#` : `//` hors d'une chaîne, la chaîne brute entre accents graves, et les blocs `/* … */`
- Les index `by-hash` de Debian et d'Ubuntu sont servis du disque, leur nom étant l'empreinte de leur contenu ; `…/releases/latest/download/…` n'est plus figé sur la première version vue
- Un amont qui refuse ou ignore les connexions est retenu 20 s : une requête qui a une réponse gardée est servie aussitôt au lieu d'attendre son délai d'établissement, qui faisait l'essentiel du temps d'une installation hors ligne ; une requête sans rien en réserve tente toujours l'amont. Un miroir git saute son rafraîchissement tant que sa forge est injoignable
- Le pré-remplissage des miroirs tourne sous le compte du service du cache, jamais en root
- Le menu des tests longs demande avant de créer de vraies machines, et redemande, avec des mots à lui, avant que `--detruire` efface des machines avec leurs disques. La commande est montrée d'abord, c'est elle qui rend la question répondable ; un plan à blanc ou un rapport de performance ne crée rien et ne demande rien
- Chaque entrée du menu Proxmox VE porte une icône, la même image voulant dire la même action que dans les autres menus de l'outil
- Le binaire du cache QEMU parle anglais ou français : journal du service, `--status`, `--age`, aide des options et erreur servie à une VM. La langue vient de `--lang`, puis d'`EL_LANG`, puis du français ; l'installateur écrit `EL_LANG` dans les réglages du service et le menu TODO passe la sienne. Règles, codes de verdict et clés JSON ne se traduisent jamais
- Un index de dépôt que le cache détient déjà est revalidé par son ETag au lieu d'être retéléchargé : l'amont juge toujours chaque requête, et un « 304 » sert le corps gardé depuis le disque. Sur une installation complète d'ERPLibre, les index pip, les métadonnées npm et le bundle de repo pesaient environ 110 Mo par VM, repris en entier à chaque fois. Un index rangé sans son hôte — partagé par tous les miroirs d'une liste qui tourne — et une réponse sans ETag sont repris en entier comme avant ; le journal d'accès nomme la nouvelle issue `revalidated`
- Une page de registre servie sous `Vary: Accept` garde une copie par représentation. npm demande la même page `/npm` abrégée, puis complète, puis de nouveau abrégée ; rangées sous une seule clé, elles se remplaçaient et les 31 Mo repartaient à chaque installation. Chaque représentation est désormais revalidée et, hors ligne, servie à part ; `--detient` lit toujours la page sous sa seule URL
- Une VM déployée l'amont du cache coupé — formulaire QEMU, Proxmox VE, ou `deploy_qemu.py --offline` — a l'audit de sécurité de npm désactivé (`NPM_CONFIG_AUDIT=false`) : il interroge un service qu'aucun cache ne rejoue, et échouait à chaque installation hors ligne. Une VM en ligne garde son audit
- Vérifier une image téléchargée ne demande plus `--verify` : c'est le défaut pour toute distribution qui publie une somme, et `--no-verify` est ce qui la saute — à réserver aux essais hors ligne, où une image substituée passerait autrement sans un mot
- `--bios` est refusé sur une image sans secteur d'amorçage BIOS, et dit pourquoi. Forcé là, il donnait une VM « running » à console muette — la panne même que ce drapeau évite ailleurs
- L'environnement virtuel d'outillage `.venv.erplibre` tourne en Python 3.14.7, indépendamment de celui d'Odoo (3.12.10 pour Odoo 18.0). `install_erplibre.sh` le bâtit par `install_venv.sh` et `EL_PYTHON_PROVIDER` plutôt qu'avec le `python3` du système
- `.venv.erplibre` sur un Python incompatible est SUPPRIMÉ puis rebâti ; ce qu'on y avait posé à la main part avec lui. Le venv d'Odoo est conservé quand seule sa version diffère, et rebâti seulement s'il est hors service : le rebâtir refait une installation Poetry entière. Un répertoire sans `pyvenv.cfg` n'est jamais effacé
- `make` et `make todo` lancent `./todo.sh`, dont le nom annonce un menu et non une installation ; il passe chaque argument à `install.sh`, qui choisit un interpréteur capable de LIRE le code avant de le lancer : `.venv.erplibre` s'il porte la bonne version, sinon le `python3` du système s'il est assez récent, sinon l'installation, qui ne part que sur un oui tapé au terminal (`o`, `oui`, `y`, `yes`) puisqu'elle peut supprimer `.venv.erplibre`. Un système plus ancien que `conf/python-erplibre-version` s'arrêterait autrement sur une erreur de syntaxe levée avant qu'aucun garde puisse nommer la commande à taper. TODO se relance ensuite dans `.venv.erplibre`, ou propose de lancer `install_erplibre.sh` en terminal
- L'image Docker de production bâtit `.venv.erplibre` sur le Python d'Odoo et s'arrête quand ce Python ne sait pas lire `script/`
- Debian 11 quitte le catalogue de déploiement : son LTS est terminé, et sa suite de sécurité n'est ni servie ni archivée — l'index qu'elle publie encore nomme des paquets dont le pool ne porte plus le fichier, et apt s'arrête avant d'installer git. Debian 13 la remplace, son image cloud étant toujours le dernier point de version
- Toutes les images de conteneur reposent sur bookworm, quelle que soit la version d'Odoo. La base est `python:<version>-slim-<version Debian>` : l'interpréteur vient de l'image officielle, jamais de Debian, et les variantes bookworm existent jusqu'à 3.7.17. Le build de wkhtmltopdf suit la version — celui de bullseye réclame libssl1.1, absente de bookworm
- Le PATCH ne borne que le venv d'Odoo, dont le pyproject exige `>=3.12.10,<3.13`. Pour celui de l'outillage, la majeure.mineure suffit : exiger le patch écartait le Python d'une distribution d'un cran en retard — NixOS 25.11 livre 3.14.2 quand conf demande 3.14.7 — et faisait COMPILER CPython à pyenv pour une différence que rien ne réclame
- `make format` choisit le formateur d'après le contexte de chaque fichier : un module Odoo garde isort et black en `py37`, la série la plus ancienne encore supportée, quand l'outillage de ce dépôt passe par ruff, réglé une fois dans `.ruff.toml`. ruff suit les versions de CPython, là où black 24.8.0 s'arrête à `py313`, et son tri d'imports remplace isort ; c'est aussi ce qu'emploie la norme OCA depuis qu'elle a quitté black
- Les dépôts que Google Repo rapatrie sous `script/` sont écartés de ce formatage, chemin nommé compris : les reformater écrirait dans l'historique d'autrui. `target-version` y reste à `py310`, parce que les hooks git portent `#!/usr/bin/env python3` et qu'une distribution livre encore 3.10 — à partir de 3.14, ruff écrirait `except A, B:` sans parenthèses
- La liste des commandes Claude Code de `TODO › Execute › GPT code › Claude configs` compare chaque gabarit d'ERPLibre de `conf/` à sa copie de `~/.claude/commands/` : une commande non installée est affichée, une copie périmée est marquée de son compte de lignes ajoutées et retirées, et une commande venue d'ailleurs est signalée comme telle. Sur un oui, elle affiche le diff, puis redéploie les copies périmées en gardant le nom et le courriel git que portait `/commit`
- Un message de commit s'ouvre sur un sujet et un corps en anglais ; `--- FR ---` ouvre ensuite la section française, qui commence par le sujet traduit sous le même tag. Le hook `commit-msg` refuse un marqueur `--- EN ---` et une section française sans ce titre, et juge ce titre comme un sujet. `/commit` et `/git_prepare_merge` suivent le même ordre
- Menus de TODO : la langue se règle seulement depuis Configuration, l'entrée en double dans Execute disparaît, et Fork quitte le menu principal pour Configuration. Le menu principal numérote désormais Télémétrie 4 et Configuration 5. Le choix de la langue montre un drapeau par langue
- Dépendances d'Odoo 18 rafraîchies. `openai` est épinglé en 2.x, dont la 3.x exige un `idna` qu'Odoo 18 interdit ; `fsspec` est épinglé à côté de `s3fs`, qui l'exige à sa propre version exacte, si bien que les deux se montent ensemble ; `meteostat` revient en 1.x, toute 2.x plafonnant `pytz` sous 2024. PyMuPDF reste écarté sur s390x, désormais déclaré dans les requirements pour qu'une régénération le garde. Les montées majeures de `ujson` 6, `plotly` 7, `python-slugify` 9 et `sqlalchemy` 2.1 ne sont pas encore testées
- Dependabot ignore les versions majeures de `meteostat`
- Odoo 18 passe à pandas 3.0.6, cryptography 50 avec pyopenssl 26.4, Pillow 12.3 et botocore/boto3 1.43.75 avec aiobotocore 3.9.1, le plus haut botocore que sa plage étroite accepte. Les sept modules qui importent pandas exécutent leurs appels pandas sans changement ; `freq='d'` dans un tableau de bord de présence Cybro avertit désormais et cassera avec pandas 4
- Dependabot réunit `aiobotocore`, `botocore` et `boto3` dans une seule demande de fusion, chaque aiobotocore n'acceptant qu'une plage étroite de botocore ; les correctifs de sécurité arrivent toujours seuls
- `TODO › Transform data` lit Excel avec openpyxl 3.1.5 et xlsxwriter 3.2.9 ; le test de fuite qui garde l'épingle exacte d'openpyxl passe sur eux
- factur-x exige 6.8 hors s390x, la version déjà verrouillée : une régénération ne peut plus retomber sur une 4.x ou 5.x non testée
- Le choix d'interface du déploiement QEMU et de la migration Odoo, et ses préférences dans `TODO › Configuration`, marquent le formulaire TUI d'un 📋 et les questions ligne par ligne d'un 💬
## Corrigé
- La lecture des baux dnsmasq n'ouvre plus d'invite de mot de passe root : les fichiers sont lus en direct, ce qui suffit sur une installation standard où ils sont en 0644, et `sudo -n` n'est tenté qu'ensuite, qui échoue au lieu de demander. L'affichage d'une liste de VM appelait ce chemin une fois par VM, et l'attente d'une VM toutes les trois secondes pendant dix minutes
- `--max_process` repart sur Python 3.10 et plus : `loop=` a quitté `asyncio.wait` en 3.10 et `asyncio.get_event_loop()` lève hors d'une loop en marche depuis 3.14, si bien que le pool n'était même plus instanciable alors que l'aide annonçait toujours l'option
- Une invite n'écrit plus son deux-points deux fois — le menu le plus vu du logiciel demandait « Commande :: », et sept invites de déploiement à distance affichaient un deux-points suivi d'un autre
- Onze sous-menus laissent désormais leur segment dans le fil d'Ariane, et la télémétrie de navigation cesse de les classer comme des commandes sous leur nom de méthode brut
- Les trois lecteurs de `~/.ssh/config` s'accordent sur ce qu'est un nom de machine : un alias déclaré par un `host` en minuscules est vu, une tabulation sépare aussi légalement qu'un espace, et un motif nié `!nom` n'est plus pris pour une machine à joindre
- Trois clés de traduction déclarées deux fois ont disparu, et un contrôle refuse la suivante : une clé répétée écrase la précédente en silence, ce qui avait déjà coûté une étiquette de menu
- `anonymize.py` s'abstient sur une colonne numérique unique et la NOMME dans le rapport. Un tirage ne garantit rien sur une colonne unique, et un nombre n'a pas l'issue qu'a le texte — coller l'id porte l'unicité pour du texte, mais changerait la grandeur d'un nombre. Deux lignes tirant le même nombre faisaient échouer l'UPDATE et, transaction unique oblige, emportaient TOUTE l'anonymisation. Sans que le rapport la nomme, une colonne identifiante reste en clair sans que rien ne le dise
- Restaurer une sauvegarde ne lève plus `AttributeError` avant de lancer la commande : `_monitoring_restore` lisait `self._execute` là où `TODO` pose `self.execute`, et les deux entrées qui y mènent — la sauvegarde locale et la distante — étaient cassées. Un contrôle refuse le suivant : tout `self.X` que `TODO` LIT doit être posé par TODO ou par une de ses bases. Chercher le nom dans tout `script/todo/` ne voyait pas la faute, un autre objet du paquet posant bien `_execute` ; il faut le chercher dans les classes dont TODO HÉRITE
- Les scripts Selenium tournent sur un Python bâti sans `tkinter` — tout serveur dépourvu de paquet d'interface graphique. Ce module ne sert qu'au sélecteur de fichier du coffre, il est donc désormais optionnel : sans `tkinter` et sans chemin KDBX configuré, l'ouverture du coffre journalise une erreur et rend la main, au lieu de casser l'import de tous les scripts de pilotage de navigateur
- Le mode sombre repart en fenêtre privée sur un Firefox récent. La permission « Exécuter dans les fenêtres privées » est accordée à l'installation de l'extension, par le champ `allowPrivateBrowsing`, au lieu d'être cochée dans l'interface `about:addons` : Firefox refuse la navigation vers `about:addons` depuis le contexte contenu, et le contexte chrome exige `-remote-allow-system-access`, que geckodriver refuse via les capabilities, si bien que les deux voies vers cette case sont fermées. Un geckodriver qui ignore le champ installe sans la permission au lieu d'interrompre la session
- L'étiquette « - Default » reparaît aux menus des versions et des environnements : les deux lectures demandaient une clé à majuscule que le fichier des versions n'écrit pas, et une clé absente ne rend rien sans rien dire
- Le message « rien en réserve » du cache est inerte pour un interpréteur de commandes, chaque ligne étant un commentaire. Livré à un installateur bâti sur `curl … | bash`, il devenait une cascade de « command not found » qui masquait la cause. Un tel téléchargement demande en outre à curl d'échouer sur une erreur HTTP plutôt que d'exécuter la page d'erreur
- L'attente qu'une VM soit prête couvre aussi la pose de l'agent invité. Celle-ci part en unité DÉTACHÉE pour que cloud-init rende la main en quelques secondes, et elle fait un `apt-get update` : « cloud-init status --wait » disait « done » alors que le verrou des paquets était encore tenu, l'étape suivante épuisait ses reprises, puis installait sur un index jamais rafraîchi — « Impossible de trouver le paquet », un message qui accuse le dépôt et non le verrou. Un update qui n'aboutit pas le dit désormais sur le champ
- Une installation de bureau n'attend plus des minutes sur le verrou apt : le SERVICE apt-daily est arrêté et non son seul minuteur, un minuteur désactivé n'interrompant pas l'apt-get qu'il a déjà lancé ; et la reprise repasse toutes les deux secondes au lieu de dix, « DPkg::Lock::Timeout » ne couvrant pas ce verrou-là
- Les VM Fedora démarrent de nouveau : le micrologiciel charge et démarre leur chargeur, puis se fige sans écrire un octet — pas de console, pas de bail DHCP, une machine « en cours d'exécution » qui ne fait rien. Fedora est amorcée en BIOS hérité, où la même image démarre son noyau ; `--bios` garde le dernier mot
- Une VM reçoit un nom d'hôte qu'elle accepte — un souligné, que le nom de domaine libvirt tolère, lui faisait garder le nom générique de son image — et un fuseau que sa distribution connaît, un alias hérité la laissant en UTC
- starship s'installe dans une VM : son installateur tourne en root, borné par un délai root, et n'atteint jamais le `sudo -v` que sudo-rs refuse ; son crochet de shell n'écrit plus « command not found », ni ne fait échouer un rc sourcé, quand starship est absent
- Chaque outil optionnel dit s'il a été posé, et une extension GNOME dont le téléchargement a échoué n'est plus déclarée indisponible pour ce GNOME
- mise, pyenv et les extensions GNOME sont téléchargés, puis exécutés : sans pipefail, `curl | sh` ne pouvait ni signaler un téléchargement raté ni atteindre son repli
- L'unité de l'agent invité ne finit plus en échec après une pose réussie
- Le cache répond 508 à une requête qui le vise lui-même, au lieu de s'appeler jusqu'à épuiser ses descripteurs
- Le diagnostic du cache ne donne plus un service arrêté pour actif
- L'attente d'`apt-get update` est bornée par une échéance et non par un nombre d'essais. Un essai échoue en moins d'une seconde sur un verrou tenu, mais dure des minutes quand le cache rend 504 sur chaque index qu'il ne détient pas : soixante essais valaient alors des heures de silence là où cinq minutes étaient promises, et l'installation échouait ensuite sur des dépendances introuvables
- Un invité Proxmox est fixé sur le même miroir apt que le reste du parc, écrit par ssh avant tout téléchargement. Le magasin range ses index par HÔTE : une VM restée sur les dépôts par défaut de son image ne retrouvait rien de ce dont le cache avait été rempli — hors ligne, chacun de ces index manquait
- L'installateur du cache accepte un pont et un sous-réseau donnés à la main. Il sondait libvirt d'abord et mourait sur « réseau default introuvable » : le contournement annoncé dans son propre en-tête — `EL_BRIDGE` et `EL_SUBNET` — était donc hors d'atteinte. Une machine dont le réseau libvirt n'est pas démarré, ou qui porte son pont autrement, peut désormais poser le cache en le nommant ; et quand la sonde tourne et échoue, elle nomme les deux issues
- **Déploiement › Cache QEMU › Installer ou réinstaller** n'annonce plus « installé et démarré » quand l'installateur a échoué. Il n'attrapait que les exceptions : un code de sortie non nul — réseau libvirt absent, compilation qui cède — imprimait la ligne de réussite juste sous l'erreur elle-même, avec le chemin d'une autorité qui n'existe pas
- Un invité Proxmox reçoit de nouveau son guide, son fuseau, son miroir apt et l'autorité du cache. Ces quatre gestes passent par ssh et partaient dès qu'une adresse était connue, pendant que cloud-init posait encore les comptes et les clés : ils échouaient ensemble, et la VM naissait en UTC, sans guide, sans autorité et sur les dépôts de son image. Le déploiement attend désormais que la machine réponde en ssh — cinq minutes au plus — et le dit quand elle ne répond jamais, au lieu d'échouer quatre fois de suite
- Le cache ne sert plus un index de dépôt plus récent que la signature qui l'annonce. Hors ligne, chaque objet sortait avec sa propre date : un index rafraîchi samedi sous un `InRelease` de vendredi faisait échouer apt sur « File has unexpected size » ou « Hash Sum mismatch », et l'installation s'arrêtait sur des dépendances introuvables — un message qui accuse le dépôt, jamais le cache. La comparaison porte sur le `Last-Modified` de l'amont, jamais sur la date de stockage, renouvelée à chaque service
- Le refus d'emporter le cache sur une autre machine nomme le geste qui le lève, et ce geste n'est pas l'entrée 1 — elle pose le cache ICI, si bien que la suivre faisait réinstaller l'hôte qui en avait déjà un pendant que l'arrivée restait sans rien. Trois situations étaient rendues par un seul « pas de cache » : un lien ssh qui n'a jamais exécuté la sonde, une arrivée sans cache, une arrivée dont le cache n'a pas son compte de service. Chacune a désormais son message, et celle du cache absent énumère les gestes à faire SUR l'arrivée, avec les deux issues d'un installateur qui lit le réseau libvirt « default » — lever libvirt, ou nommer le pont, un libvirt arrêté le faisant mourir sur un réseau qui existe. Les gestes nomment aussi la branche à donner à l'arrivée, lue sur cet hôte : l'installateur est un fichier du dépôt, si bien qu'une machine restée sur une autre branche répond « fichier introuvable », ce qui ne ressemble en rien à un cache absent. Un quatrième cas est éprouvé avant qu'un seul octet ne parte : un sudo qui réclame un mot de passe à l'arrivée, auquel aucun terminal ne peut répondre puisque le magasin occupe lui-même l'entrée standard de ssh — le message donne le ticket à y obtenir d'abord. Le privilège n'est demandé qu'UNE fois à l'arrivée, « tar » et « chown » sous une seule invocation. Quand le sudo de là-bas réclame un mot de passe, l'entrée offre deux issues au lieu d'échouer : la ligne sudoers à poser une fois, ou un mode en deux temps — le magasin part dans le compte de l'arrivée, qui n'exige aucun privilège, et une commande affichée l'extrait depuis un terminal de là-bas, où un mot de passe se tape. Ce mode réclame deux fois le magasin à l'arrivée, vérifié avant qu'un octet ne parte, un cache ne contenant que des paquets et des archives git déjà comprimés. Le guide porte la même section
- Le formulaire de déploiement Proxmox VE éprouve le cache avant de couper le réseau, comme celui de libvirt le faisait déjà : ce que le magasin n'a pas, aucune VM coupée ne le lira, et l'échec tombait une heure plus tard, à la pose du bureau — un message qui accuse le dépôt, jamais le cache. F5 à nouveau vaut passage outre. Les deux formulaires partagent désormais un seul verdict au lieu de deux copies, qui auraient divergé au premier ajustement
- Le cache garde ses index de dépôt quand une liste de miroirs tourne. Un index publié sous l'empreinte de son contenu — « by-hash/SHA256/… » — était rangé sous une clé portant l'hôte : les mêmes octets servis par un second miroir étaient repris à l'amont, et hors ligne ils manquaient tout simplement — l'installation échouait sur des fichiers que le magasin détenait, avec un message qui accuse le dépôt. Un tel objet est désormais rangé sous son seul chemin, son nom ÉTANT la somme de son contenu
- Le diagnostic du cache n'annonce plus « aucune règle de détournement n'est posée » quand il n'a simplement pas pu les lire. Sur un hôte dont le sudo réclame un mot de passe, « sudo -n nft » ne rend rien, et ce silence était lu comme une absence de règle — ce qui envoyait réinstaller un cache qui détournait correctement. La lecture porte désormais un troisième état, « impossible de savoir », marqué d'un point et non d'une croix, comme le faisait déjà la lecture de la coupure d'amont
- Une coupure levée rend aussitôt leur chance aux amonts. Le service retient un court moment ceux dont la connexion vient d'échouer, pour qu'une installation hors ligne ne paie pas le délai d'établissement des centaines de fois ; rien ne lui disait que la coupure était finie, et les premières requêtes d'après la levée se rabattaient sur le magasin alors que le réseau était déjà revenu. La levée touche désormais un témoin dans le magasin, que cette mémoire consulte — il n'existe aucun canal vers le service en marche
- Avant de couper, le formulaire avertit aussi de ce qu'aucun index ne peut révéler : un paquet que le déploiement pose HORS du fil observé — l'agent invité, posé par une unité détachée dont l'échec ne remonte nulle part — et les dépôts git déclarés par les manifestes qui n'ont pas encore de miroir. Un index de suite en réserve suffisait à faire passer le cache pour complet alors qu'aucun octet de ce paquet ne l'avait jamais traversé ; et une négociation git ne se garde jamais, si bien qu'un dépôt sans miroir ne peut tout simplement pas être cloné une fois le réseau coupé
- L'avertissement sur les miroirs ne compte que les dépôts de la version d'Odoo déployée. Il additionnait tous les manifestes du dépôt — le déprécié compris — et annonçait 170 miroirs manquants là où un vrai déploiement Odoo 18 en rencontre quatre : une alarme qui sonne pour rien est une alarme qu'on cesse de lire. Le remplissage des miroirs, lui, prend toujours de l'avance pour toutes les versions, ce qui est son rôle
- Un hôte banni du déchiffrement sur une rafale d'erreurs de transport retrouve sa chance. Trois poignées de main manquées d'affilée le passaient en tunnel opaque, et un tunnel ne consulte jamais le magasin : un miroir de distribution condamné par quelques enregistrements corrompus renvoyait tout son trafic à l'amont — y compris les centaines d'objets déjà détenus pour lui — jusqu'au redémarrage du service. Une alerte TLS bannit toujours définitivement, le client ayant regardé notre certificat et l'ayant refusé ; mais une coupure répétée n'est qu'un soupçon, et elle se rouvre au bout de dix minutes
- **Déploiement › Cache QEMU › Miroirs git** remplit à part la base de la version d'Odoo active, ou ses modules extra — à côté du remplissage de tous les manifestes, qui prend des heures. Chaque liste dit combien de dépôts elle déclare et combien n'ont pas encore de miroir. Ce qu'un déploiement clone se lit désormais avec la règle et les listes de la fusion des manifestes elle-même : les modules extra, installés seulement sur demande, et le projet mobile ne comptent plus, là où l'avertissement hors ligne annonçait quatre miroirs manquants qu'une installation Odoo 18 par défaut ne clone jamais
- Les métadonnées PEP 658 de pip — le fichier `.whl.metadata` récupéré avant chaque roue — sont servies du disque. Le nom finit par `.metadata`, qu'aucune règle ne connaissait : chaque fichier repartait à chaque installation, 178 sur une installation complète d'ERPLibre. Les copies gardées avant ce changement ne sont plus atteintes ; la prochaine installation en ligne les remplit
- Le fuseau horaire qu'une VM déployée hérite de son hôte est traduit en son nom canonique. Les images cloud d'Ubuntu 24.04 ne portent plus les alias historiques — `Canada/*`, `US/*`, `Asia/Calcutta` — déplacés dans un paquet `tzdata-legacy` qu'elles n'installent pas : cloud-init refusait le fuseau, la VM restait en UTC, et le seul signe était un cloud-init en erreur, le décalage n'apparaissant qu'aux horodatages longtemps après. La table des alias est le `tzdata.zi` de l'hôte, et non une copie figée dans le code
- `make` cherche bash au lieu de présumer `/bin/bash`. Ce chemin n'existe pas sur NixOS, où le shell vit dans le store, et make s'arrêtait avant d'exécuter la moindre recette — y compris celle qui installe de quoi créer ce chemin. Ailleurs, le shell résolu est celui d'avant
- Le locale et le clavier qu'une VM déployée reçoit s'appliquent désormais sur Debian, où les deux échouaient en silence. Un locale se génère à partir de `/etc/locale.gen` et de nulle part ailleurs : `update-locale` refusait celui qui n'y était pas et la VM restait en C.UTF-8 ; le module clavier finit par un `console-setup` que l'image genericcloud ne porte pas, alors `/etc/default/keyboard` — le fichier que localed et X relisent — est écrit directement. Chaque déploiement Debian imprimait `cloud-init: status: error`, et un mot qui s'affiche toujours n'avertit plus de rien
- Un invité sans ancre de confiance par fichier est soustrait au cache de téléchargement plutôt qu'intercepté sans elle. Le détournement est transparent et vaut pour tout le pont : une VM à qui l'on ne donne pas l'autorité échoue quand même sur « self-signed certificate in certificate chain » — et sur un système déclaratif, poser l'autorité arrive trop tard, la première reconstruction étant le premier téléchargement. Sur un hôte Proxmox, c'est l'HÔTE qui est excepté : un invité imbriqué sort masqué derrière lui et le pont ne voit jamais sa propre adresse. Mesuré depuis l'invité : code 000 et vérification SSL 19, puis 200 et 0. Sans cela le gestionnaire de paquets se rabattait sur 564 dérivations à construire, dont les sources échouaient pour la même raison
- NixOS apprend l'autorité du cache de téléchargement SANS reconstruire, et n'en est donc plus soustrait — ce qui lui fermait le déploiement hors ligne, le magasin étant alors la seule source et une VM exceptée n'ayant plus rien. Il n'a pas d'ancre de confiance par fichier et /etc est généré en lecture seule, quand une déclaration arriverait trop tard, la première reconstruction étant le premier téléchargement. L'autorité y est donc POINTÉE, consommateur par consommateur, par l'environnement — et l'environnement se perd à trois frontières que les quatre familles impératives ne rencontrent jamais. nix-daemon est activé par socket et ne voit aucune session : un fragment sous /run/systemd/system, un tmpfs inscriptible là où /etc ne l'est pas, l'atteint. sudo l'efface, et le nix de root parle droit au magasin local plutôt qu'au démon, téléchargeant lui-même : « Defaults env_keep » fait traverser les variables, visudo étant atteint par le profil du système, le PATH qu'y donne cloud-init ne portant aucun sudo. Et la session ssh s'ouvre une seconde avant que cloud-init n'écrive le faisceau, si bien que les exports vivent DANS l'attente de celui-ci plutôt qu'en tête de commande. Le faisceau concatène les autorités du système et celle du cache, donner la seconde seule ferait cesser d'approuver tout le reste. Vérifié amont COUPÉ sur une VM neuve : nix-shell réalise depuis le magasin ; et cache interceptant, une installation complète se termine sans un refus de certificat
- Odoo répond depuis l'extérieur d'une VM NixOS. Il écoutait sur 0.0.0.0:8069 et répondait en local, mais NixOS active un pare-feu par défaut là où aucune des quatre autres images cloud n'en active : l'hôte ne recevait rien — pas un refus, un silence jusqu'au délai — et le suivi déclarait Odoo absent sur une machine où il tournait. Mesuré depuis l'hôte : 000 après 12 s, puis 303 en 9 ms
- ERPLibre tourne comme service sur NixOS. L'installation finissait par écrire une unité dans `/etc/systemd/system`, généré depuis le store et monté en lecture seule : elle rendait 1 à sa dernière étape, après que le clone, le venv et un démarrage d'Odoo avaient tous réussi. L'unité est désormais déclarée par le module ; son interpréteur vient du store, `/bin` étant un montage FUSE d'envfs que systemd ne voit pas quand il résout l'exécutable ; et son PATH porte bash, dont l'absence arrêtait `run.sh` avant Odoo
- Ce qu'un système déclaratif doit déclarer, et que les quatre autres reçoivent gratuitement de leur image cloud : xmlsec1, sans lequel Odoo refuse d'installer auth_saml, module du chemin des addons ; parallel et shfmt, appelés par leur nom nu ; growpart, absent de tout le système alors que l'agrandissement du disque s'écrit « … || true » et rendait 0 sans rien agrandir ; et l'agent invité, qui venait de l'image et non du dépôt, le PATH de son unité manquant findmnt si bien que guest-exec mourait en 127 dès sa première ligne
- Le guide de connexion s'affiche sur NixOS. Le déploiement écrit `/etc/motd` partout et compte sur pam_motd pour le montrer — vrai des quatre images cloud, faux ici, où sshd rend « printmotd no » et où la pile PAM ne contient aucun pam_motd : le guide était écrit, complet, et personne ne le lisait. Il gagne aussi un bloc propre à NixOS, qui nomme le piège pour lequel il existe — `/etc/nixos/erplibre.nix` est réécrit par `make install_os`, et les déclarations qu'on y ajoute disparaissent sans un mot
- « make db_drop_all » n'annonce plus détruites des bases qui ne le sont pas. Il composait une commande parallel, jetait son code de retour et imprimait la liste ; le cas s'atteint dès que parallel manque du PATH, et l'opérateur passe à la suite en croyant ses bases parties
- Un miroir du cache de téléchargement refusé faute de place nomme son seuil et sa mesure. Il reprenait un champ que tout appelant ordinaire laisse à zéro — « moins de 0 o libres sur le disque » n'annonce aucun seuil et ne dit pas ce qui a été mesuré
- Une image téléchargée est vérifiée contre la somme que son éditeur publie, pour toute distribution qui en publie une et SANS le demander. La vérification existait sous un drapeau et pour Ubuntu seulement, si bien que les autres images arrivaient sans que rien ne les regarde. Six y entrent, relevées sur les dépôts plutôt que devinées : Debian publie du sha512 quand tout le reste est en sha256, les familles RHEL nomment le fichier « CHECKSUM », Rocky l'écrit en forme BSD, et Arch comme openSUSE posent une somme par image. Un fichier de sommes injoignable n'arrête plus un déploiement — c'est une panne de disponibilité — quand un écart arrête toujours tout et supprime l'image
- La locale qu'une VM déployée reçoit s'applique sur NixOS. cloud-init l'applique par locale-gen et update-locale, absents là-bas, et la VM gardait le défaut de la distribution — « fr_CA.UTF-8 » demandé, « en_US.UTF-8 » obtenu. Elle et le fuseau sont désormais déclarés par le module, et ni l'un ni l'autre n'est imposé à une NixOS qu'on avait déjà
- Le guide de connexion tient dans un terminal de 80 colonnes même sur une VM qui porte ses outils et un bureau, là où il en rendait 103 : le cadre débordait, le terminal repliait où il voulait, et l'alignement en deux colonnes — seule chose qui rend le guide lisible d'un coup d'œil — se perdait. La glose se replie désormais sous sa colonne, et passe sous sa commande quand celle-ci ne laisse plus de quoi écrire. C'est la mise en page qui porte la règle, non la longueur des textes, qui n'aurait tenu que jusqu'au prochain outil
- Une VM déployée hors ligne reçoit les variables du cache avant que son installation ne commence. « cloud-init status --wait » rend la main dès que cloud-init se déclare en erreur — un module accessoire y suffit — alors que son étape finale écrit encore l'autorité, `/etc/environment` et le fichier sudoers ; une session ouverte dans cette seconde-là vivait sans elles, et une installation lancée par sudo rejetait alors le certificat du cache. Le déploiement attend désormais l'unité cloud-final, et son seul état « activating », ce service étant un oneshot qui reste actif une fois fini
- Une métadonnée de dépôt qu'une distribution RPM nomme d'après l'empreinte de son contenu est servie du disque comme un paquet, et une demande de plage sur un fichier que le cache ne détient pas fait prendre le fichier entier en arrière-plan, une fois par clé. Un tel index de dizaines de mégaoctets était repris en entier à chaque installation — environ 110 Mo par VM sur un système de la famille RHEL — et dnf, qui prend ses métadonnées zchunk par plages, recevait un « 504 » l'amont coupé, aucune plage ne se gardant
- Une VM déployée hors ligne n'attend plus une synchronisation de l'heure qui ne peut pas venir. Une image qui active `systemd-time-wait-sync` retient `time-sync.target` jusqu'à la première réponse NTP, et l'étape finale de cloud-init est ordonnée après elle : sans serveur de temps joignable, cette étape ne démarrait jamais, ni les clés d'hôte ssh qu'elle génère, et la VM atteignait son invite de connexion sans jamais répondre en ssh
- Le cache de téléchargement ne reprend plus à l'amont un paquet qu'il détient déjà parce qu'un miroir le range sous un autre chemin. Un miroir préfixe le chemin à sa guise — « /rocky/10.2/… », « /mirror/rocky-linux/10.2/… », « /pub/archive/fedora/… » — et le chemin entier donnait deux clés pour les mêmes octets : sur un journal de 7099 noms livrés, 1124 vivaient sous plusieurs chemins et 3,18 Gio repartaient à l'amont pour rien. Seuls les six derniers segments comptent désormais, les segments vides tombant avec eux. Six est la plus petite borne sans collision : un chemin Debian en porte exactement six, si bien que cinq servirait le paquet d'Ubuntu pour celui de Debian, qui porte le même nom pour d'autres octets. Les paquets pacman s'arrêtent à quatre, leurs chemins étant plus courts que la borne commune, ce qui retire le préfixe du miroir et garde le nom du dépôt. Un magasin rempli avant ce changement se rattrape par `--recle`
- Une image gardée devenue périmée est reprise une fois au lieu d'arrêter le déploiement. Le répertoire « latest » d'une distribution avance à chaque version mineure et la somme publiée cesse de décrire l'image du disque, sans qu'un octet soit corrompu : la vérification la supprimait puis sortait, perdant une campagne entière — trois VM — pour une péremption qu'un seul téléchargement répare. Un second écart porte sur des octets fraîchement téléchargés, arrête tout et supprime l'image ; appelée sans liste de miroirs, et pour des sommes injoignables, rien ne change
- `long_test/qemu_cache.py` ne fait plus échouer une campagne où le cache a tout servi. Une URL n'est « déjà vue » que si la première VM en a obtenu les octets : un même paquet vit sous deux chemins selon le miroir, et la première VM peut recevoir « 504 » sur l'un — amont jugé muet — puis être servie du disque par l'autre, si bien que rien n'était rangé sous le premier chemin et que le téléchargement honnête de la seconde y était compté en faute. Un statut absent vaut livré, les journaux d'avant ne l'écrivant pas toujours, et la ligne des fichiers neufs nomme ses deux causes au lieu d'imputer à Arch quelle que soit la distribution mesurée
- Un téléchargement d'image coupé se reprend sur le même miroir, trois essais, par un `Range` qui demande la suite, au lieu de jeter ce qu'il a reçu : une image de VM pèse un demi-gigaoctet, et un `.part` tronqué renvoyait le lecteur à un `curl -C -` tapé à la main. Un serveur qui ignore le Range rend le fichier entier, et le transfert repart alors de zéro plutôt que de doubler les octets déjà là
- Les variables de certificat du cache ne désignent un faisceau que s'il existe. Une Fedora récente n'a pas `/etc/pki/tls/certs/ca-bundle.crt`, et viser un chemin absent faisait refuser à pip TOUT téléchargement, y compris ce qui n'a rien à voir avec le cache. Aucun trouvé n'écrit aucune variable, et pip garde son propre jeu de certificats
- `make version` nomme les deux Python, celui d'Odoo et celui de l'outillage. Un libellé nu laissait croire que le dépôt n'en a qu'un, et le chiffre affiché n'était pas celui du venv dans lequel on travaille
- `make` ne lance plus un `.venv.erplibre` bâti sur une autre machine, comme un checkout monté par le réseau, qui mourait sur « No module named 'encodings' ». `install.sh` lit la version de l'interpréteur en exécutant du code : `python -V` répond avant le chargement de la bibliothèque standard, et se portait donc garant d'un interpréteur incapable de démarrer. Un tel venv est désormais signalé comme bâti ailleurs, avec la commande qui le rebâtit
- Dependabot n'ouvre plus de demandes de fusion sur les requirements figés d'Odoo 12 à 17 : ses mises à jour de sécurité lisent `requirement/` comme un répertoire à part, que les exclusions ne couvraient pas
- `poetry_update.py` s'arrête sur un `pyproject.toml` absent en nommant la commande qui le crée, `make switch_odoo_XX` pour la version active, et propose de la lancer puis de se relancer quand il tourne dans un terminal
- `poetry_update.py` fait tourner Poetry dans le venv Odoo même depuis un shell sous `.venv.erplibre`, dont le Python le faisait échouer sur « InvalidCurrentPythonVersionError »
- `poetry_update.py` écarte les requirements et manifestes sous un répertoire `doc`, `docs`, `example` ou `examples` : un fichier d'exemple déclarant un `>=` lâche ne déplace plus une dépendance pour tout l'environnement
## Retiré
- La dépendance `sshconf`, déclarée et installée partout et importée nulle part
## Sécurité
- Une clé d'API et un jeton Bearer sont caviardés eux aussi avant qu'une commande soit affichée, journalisée ou réimprimée : `OPENAI_API_KEY=` partait en clair, et un jeton d'en-tête échappait par construction, ne portant ni nom d'option ni nom de variable
- En suivant une redirection, le cache ne transmet plus les identifiants du client (Authorization, Cookie, Proxy-Authorization) à un autre hôte
- Odoo 18 installe `idna` 3.20 au lieu de la 3.6 qu'épinglent ses propres requirements, touchée par CVE-2024-3651
- Odoo 18 installe `requests` 2.32.4 au lieu du 2.31.0 qu'épinglent ses propres requirements, touché par CVE-2024-35195 et CVE-2024-47081
- Le miroir git du cache QEMU ne clone plus qu'en `http` et `https` : un client pouvait nommer un dépôt `ssh://` ou `git://` dans sa requête et faire se connecter le cache, avec les clés de son compte de service, à un hôte de son choix. Les dépôts servis en HTTPS sont mis en miroir comme avant ; le binaire annonce 0.2.17
## [1.8.0] - 2026-09-04
**Notes de migration**
Recréer l'environnement virtuel, l'interpréteur Python et l'installateur de
paquets se choisissant désormais. Utiliser le guide d'installation depuis
l'outil `make`. Ubuntu 20.04 et 22.04 ne sont plus supportés.
## Ajouté
- Déployer des VM ERPLibre en QEMU/KVM depuis des images cloud : Ubuntu, Debian, Fedora, AlmaLinux, Rocky, openSUSE, Arch, Linux Mint, et Debian sur s390x. Matériel, branche et version d'Odoo se règlent par machine
- Proxmox VE comme cible de déploiement, son installation comprenant le redémarrage qu'elle exige
- Un menu QEMU : état et réparation du réseau, accélération 3D, un rapport de diagnostic, récupération de fichiers sur une VM qui ne démarre plus, virt-viewer et un tunnel de bureau distant
- Un tableau de bord d'installation et des formulaires Textual : déployer, suivre, mettre à jour, redémarrer ou effacer une VM sans quitter l'écran
- Une VM de développement mobile : PyCharm, Android Studio, un émulateur Android et un tunnel adb
- Un outil VPN, cinq technologies libres au menu, les secrets dans un coffre KeePassXC et un diagnostic qui nomme l'étage fautif
- La migration Odoo automatisée : l'outil mène toute l'exécution, revient à une étape, et répare ce qu'un changement de version laisse derrière lui
- La revue de migration : un verdict par étape, des tests de fumée sur chaque URL publique, et un contrôle du filestore
- Une trousse d'analyse en lecture seule d'une base Odoo, archive de sauvegarde comprise, avec conseil d'index PostgreSQL
- L'anonymisation d'une copie de production sans IA, et la duplication d'une base neutralisée pour de bon
- Des assistants de développement posés dans une VM, et un menu Git et Shell qui installe ce qu'un checkout réclame
- Une convention d'écriture pour ce qui reste dans git, tenue par un hook `pre-commit` et un hook `commit-msg`
- `long_test/` — des tests qui créent de vraies machines, QEMU et Proxmox imbriqués compris, hors du lanceur unitaire
- NTFY, Forgejo, un serveur git local, le courriel depuis le CLI, et la configuration SSH avec ProxyJump récursif
- L'interpréteur Python et l'installateur de paquets se choisissent, par EL_PYTHON_PROVIDER et EL_PIP_PROVIDER
- La politique d'IA générative de l'OCA, les agents et commandes Claude Code, et le contexte donné à un assistant, montré depuis le menu
- Des tests unitaires avec un plan de test bilingue, la télémétrie de navigation de TODO, et Odoo 18 qui lit les fichiers STL
## Modifié
- todo.py éclaté en neuf fichiers, un par sujet, avec un socle commun par formulaire
- Chaque entrée de menu porte une icône, les menus sont regroupés en sections, et une invite à compte à rebours laisse 15 secondes pour décider
- La branche, le profil, le type et le fuseau se choisissent par VM plutôt que globalement
- L'installation couvre Fedora, Debian, Ubuntu, Arch et openSUSE ; la synchronisation des dépôts et Poetry tournent en parallèle, silencieux sauf si EL_VERBOSE le demande
- Node.js 22 pour Capacitor 8, flanker pour Odoo 18, les extras CybroOdoo optionnels, et une dépendance Poetry déclinable par architecture
- Une VM démarre plus vite et prend le miroir joignable le plus rapide, les miroirs pacman canadiens passant en tête sur Arch
- L'indexation nomme les fichiers, jamais `git add -A`
- Entrée cible la version d'Odoo la plus élevée supportée, et un nom de VM perd le segment `latest`
## Corrigé
- Le réseau libvirt ne compte plus comme sa propre collision, ne laisse plus un hôte sans réseau au démarrage suivant, et son état est lu en anglais quelle que soit la locale
- Le déploiement QEMU : sudo dit pourquoi il faut un mot de passe, le groupe `libvirt` le remplace là où il suffit, aucun hôte ne redémarre sans qu'on le demande, et un disque orphelin ne bloque plus
- La migration : l'effacement de base, la vue account.root que laisse Odoo 17, les listes de prix qu'une réparation inventait, et les suppositions sur lesquelles tenait le passage de 13 à 18
- L'anonymisation respecte ce qu'une valeur signifie, et ne casse plus au-delà de la limite de 131 072 octets d'un seul argument
- L'installation sur Debian 13, Fedora, Ubuntu 26.04 et s390x : verrous apt, compilateurs et en-têtes manquants, mémoire trop courte, et ce qu'exigent un SWIG ou un PROJ récents
- Les secrets : le coffre KeePassXC s'ouvre sur un serveur sans tkinter, l'installateur forgejo cesse de réafficher le mot de passe qu'il a posé, et db_restore valide celui du maître
- Une question se voit avant qu'on y réponde, et un dépôt fautif n'emporte plus tout un lot
- Trois écrans qui tombaient, une réduction qui aurait rempli le disque, et un suivi qui mettait une VM à la poubelle avant d'en être sûr
- Le lanceur unitaire balaie tout le répertoire, là où il exécutait 1131 tests sur 3703
- Proxmox ne vise plus l'hôte au lieu de la VM
## Retiré
- Le support d'Ubuntu 20.04 et 22.04, sur toutes les architectures
- Le contrôle de résidus qui jugeait cassée une langue dont `active` est NULL
## Sécurité
- Les mots de passe et jetons sont caviardés avant l'affichage, la journalisation ou le réaffichage d'une commande
- Le mot de passe maître d'Odoo et celui de KeePass quittent la ligne de commande, une variable d'environnement les portant à la place
## [1.7.0] - 2026-03-11
**Notes de migration**
Recréer l'environnement virtuel, utiliser le guide d'installation depuis l'outil `make`.
## Ajouté
- Support de la migration de base de données et de modules Odoo avec TODO
- Support du changement multi-version Odoo sur le même espace de travail
- Script pour le renforcement de la sécurité de l'installation
- Support des versions Odoo 12.0 à 18.0
- Séparation de l'installation Python ERPLibre de celle d'Odoo avec .venv.erplibre et .venv.odoo18
- Implémentation de l'auto-installation avec TODO.py
- TODO affiche la documentation, télécharge la base de données, aide au formatage du code
- Script de performance pour mesurer les requêtes par seconde
- Support de l'architecture Mainframe 390x
- Déploiement avec Cloudflare et Nginx
- Support de la configuration Apache comme Nginx
- Support du générateur de code RobotLibre
- Support d'ERPLibre DevOps, procédure d'automatisation DevOps
- Application mobile ERPLibre Home, utiliser TODO pour compiler, déployer et personnaliser
- Support de la grille Selenium depuis selenium_lib.py
- Ajout des addons OnlyOffice, Cetmix, OCA automation, OCA shopfloor
- Odoo 12.0 à 18.0 dans un même espace de travail, changés sans réinstaller : les manifestes, la configuration et les chemins d'addons suivent la version nommée dans `.odoo-version`
- Le Python d'ERPLibre séparé de celui d'Odoo — `.venv.erplibre` porte les outils du dépôt, `.venv.odoo<version>` le serveur — si bien qu'un outil du dépôt ne dépend plus de l'interpréteur qu'impose une version d'Odoo
- L'auto-installation pilotée depuis TODO : le menu pose l'environnement dont il a besoin, Poetry, les manifestes Google Repo et les addons compris, au lieu d'afficher une commande à retaper
- La migration d'une base Odoo et de ses modules depuis TODO, `--neutralize` compris, avec la réparation du module mail que laisse un passage de PostgreSQL 17 à 18
- Un script de renforcement de la sécurité de l'installation
- L'application mobile ERPLibre Home : TODO la compile, la déploie, renomme le logiciel et change son image de menu
- Le générateur de code RobotLibre, avec les canaux queue_job que sa configuration réclame
- ERPLibre DevOps, et la procédure d'automatisation qu'il décrit
- La grille Selenium depuis `selenium_lib.py` : un coffre KeePass ouvert pour l'exécution, le téléchargement de fichiers, le mode sombre, l'enregistrement vidéo et une bibliothèque de scénarios
- Un script de performance qui mesure les requêtes par seconde qu'un site répond
- Le déploiement : DNS Cloudflare, nginx avec un certbot non interactif, gabarits Apache alignés sur ceux de nginx, et une unité systemd dont le répertoire de travail se configure
- L'architecture mainframe s390x
- Les addons OnlyOffice, Cetmix, OCA automation, OCA shopfloor, et le dépôt design-themes
- Des commandes de sauvegarde et d'effacement de base, et un nommage plus clair à la restauration
- Une vérification de sécurité de l'environnement Python, depuis le menu
- TODO affiche la documentation, télécharge une base et aide au formatage du code
- Tuer un processus Odoo par le port qu'il occupe, depuis le menu
- CLAUDE.md et le document d'information des agents, pour qu'un assistant lise les conventions du dépôt au lieu de les deviner
- Une entrée de FAQ sur wkhtmltopdf pour les distributions récentes
## Modifié
- Support Docker postgresql 18
- Script de formatage recherche les fichiers diff dans chaque dépôt
- Support de la neutralisation de base de données depuis Odoo
- Odoo 18.0 devient la version par défaut d'un checkout
- Docker passe à PostgreSQL 18, avec le client correspondant
- La documentation est bilingue, générée par mmg depuis les sources `.base.md` : un `.md` ou `.fr.md` modifié directement est perdu à la prochaine génération
- Les menus TODO sont regroupés en sections, et le texte anglais sert de clé i18n plutôt qu'un code à part
- Le script de formatage cherche les fichiers modifiés dans chaque dépôt, addons cachés compris, et saute un dépôt qui n'est pas installé
- Odoo tourne sur une base personnalisée, et le menu configure queue_job comme la redirection SSH qu'une instance distante réclame
- Tuer un processus par son port demande confirmation, par un menu interactif
- La neutralisation d'une base passe par le `--neutralize` d'Odoo
- LinuxMint 22.3, Ubuntu 25.10, et macOS sans Python 3.7
- Dépendances Odoo 18 : tldextract, PyYAML, pdfminer.six, et cryptography à sa dernière version
- Une cible make lance les tests unitaires
- Le Makefile est éclaté : ses commandes vivent dans `conf/`, et `Common.Makefile` l'étend pour un projet à soi
## Corrigé
- Les accents de la documentation, et la génération markdown qui tourne en parallèle
- `git_tool` rend vide au lieu de lever là où `.git` est absent
- `poetry iscompatible` ne casse plus sur une version portant une lettre, une alpha ou une candidate
- pymssql se compile de nouveau, et les dépendances Odoo 18 laissent pyssql hors d'une installation de production
- wkhtmltopdf n'est plus proposé là où il n'existe pas : aucun paquet n'est publié pour s390x sur Ubuntu 25.10
- Selenium : le chemin du Firefox snap, un délai de 60 secondes pour atteindre un élément, l'exécution en fenêtre privée, et une connexion qui attend Odoo 18
- Le script de formatage ignore les fichiers et répertoires qu'il ne doit pas toucher
- `db_drop_all` exécute sa commande shell, et le traitement des sauvegardes garde les permissions de ce qu'il écrit
- TODO : le premier import, la régénération de `.repo/local_manifests`, le dialogue d'ouverture de base, et une version d'Odoo manquante signalée au lieu d'un plantage
- Le générateur de code : la création d'un projet, l'extraction d'une classe portant une sélection, et la lecture d'un modèle par le module `ast` de Python 3.11 plutôt que par astor
- Docker : la cible de compilation Odoo 18 en double, et le fichier compose épinglé sur une image qui fonctionne
## [1.6.0] - 2025-04-25
@ -491,7 +758,11 @@ Parce que le dépôt d'addons a changé, le fichier de configuration doit être
- Support uniquement de python3.6 et python3.7, python3.8 cause des erreurs à l'exécution.
@ -9,34 +9,301 @@ to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
## [Unreleased]
## Added
- Site presets for the VPN: one `.json` carries a site's gateway, protocol and connection group, and neither a username nor a secret, so it can be handed around. Read from `conf/vpn_presets/`, then from a git-ignored `private/vpn/presets/`, then from any directory listed in `vpn_preset_paths`; on the same identifier the latest wins, so a site fixes a shipped template without touching a tracked file
- Import a Cisco AnyConnect `.xml` profile from the menu, browsing the client's own directories or typing the path, and get a preset from its `HostName`, `HostAddress` and `UserGroup`
- OpenConnect tells apart the two mechanisms that designate a service on one concentrator: the connection group in the URL and the value picked from a dropdown. Confusing them hands over another service's login form, so correct credentials are refused with nothing naming the group
- Reach a gateway that demands an embedded browser for SAML, which stops OpenConnect on « No SSO handler »: the web step is delegated to an `openconnect-sso` helper that the installer offers to set up, and the tunnel is then brought up by the driver itself, so the interface name, the state files and the diagnosis stay with the profile
- Declare a concentrator that compares only the first characters of a password: it is announced before the secret is stored, and nothing is ever truncated
- The VPN installer looks for `vpnc-script` — a file, not a binary on the `PATH` — and names the package to install per distribution family, instead of letting the tunnel fail on an interface that never appears
- A command launched by the VPN runner gets `/dev/null` on standard input, so a captured-output command can no longer be stopped by a SIGTTOU and freeze the machine's package manager
- The VPN profile list marks which profiles carry a live tunnel, so connecting one already up asks first and disconnecting one already down says so instead of looking like a mistake. A profile is judged on its interface, not on the state file a tunnel killed without `down` leaves behind — a state left over used to be reported as mounted on the same screen that declared the process gone
- `Assistant › LLM` — ask a model server over several turns, local or remote. The history lives in memory and dies with the menu, `/save` being the only way to keep a trace; every command carries a leading slash, so a question pasted over several lines stays one turn. A third-party destination has to be retyped before the first send
- Server recognition across eleven ports and twelve families, identity read from the response BODY and never from the port: one port hosts up to three products, and one family re-serves another's whole native API
- Finding a server from six sources — the loopback, this machine's QEMU domains, the hosts of `~/.ssh/config`, an address or a network typed by hand, and the networks read over SSH on another machine. Anything wider than a `/24` is refused before enumeration, and two preferences bound the sweep: `assistant_sweep_workers`, `assistant_sweep_timeout`
- A gpt catalogue in `script/todo/assistant/gpt/`: one Markdown file per tool, whose declared requirements are matched against what the server announces. An unknown never greys a tool out — only a requirement contradicted by a field actually read does, with the figure that refuses it
- A declared READ-ONLY context per tool, files and allowlisted commands, shown and confirmed before the first send, capped in size and duration, and scanned for identifying data. The scan's honest limit is stated: it sees addresses, e-mails and account paths, not names
- `Execute › GPT code › Claude Code` — list the machine's sessions, ask one a question with read-only tools, or resume one in its own terminal. A copy is branched by default, since two writers on one session lose a branch
- `check_comment_hygiene.py` signals a fully qualified machine name in a comment, as a re-read signal and never a finding: a BARE host name is mechanically indistinguishable from an ordinary word, so the absence of a signal proves nothing about names. The copyright header, the RFC 2606 domains and any address carried by a URL are left alone
- Transform data, a menu entry that opens an external file — Excel, Access, CSV, XML or JSON — reports what it holds, then draws an anonymised copy of it. The original is never touched. Numbers are drawn from the measured extent of their own column rather than a fixed 0-1000 range, which turns a tax rate into 743 and a year into 12; they are drawn without replacement, since a hundred distinct keys in a range of a hundred otherwise yield sixty-six outputs and a fixture that no longer reimports. Text takes a French word from a local dictionary of 1366, assigned by a counter rather than a draw, and a portable mapping table gives the same client the same word across a whole batch
- Eleven structural labels are left alone on their NAME — `id`, `create_uid`, `sequence`, `active` and the rest, plus anything ending in `/id` or `/.id` — since a test set has to keep working. Every OTHER column is judged on its measured CONTENT, never on the strength of its name. In an import-ready export, `partner_id` holds the relation's display name and `display_name` is the data itself, so deciding on the label copied the most identifying columns of the file verbatim while announcing them as protected
- The anonymiser rereads the bytes it has just written and refuses the copy when a value it announced as replaced survives in it. A workbook holds data in a dozen places that are not cells: a pivot cache and an external link each carry an entire copy of the source, a chart caches its categories and its axis titles, a custom number format carries a label, a comment carries its author, a cell hyperlink carries a path. The guard depends on no list of those, so a place nobody thought to clean produces a refusal instead of a silence — and what stays by decision, a header row or a column left alone, is named on screen before anything is written
- Transform data anonymises an Odoo database too, the entry asking for the SOURCE rather than the format: an external file, a live database, or a backup zip taken from `image_db/`. A zip is never modified — it is restored into a database, anonymised there, then dumped into a NEW zip by Odoo's own backup, so the dump, the filestore and the manifest are written by the software that will read them back. A live database is modified ITSELF, which is said before the work and not after, and nothing is drawn when the write did not happen: declining otherwise handed back a zip of the untouched database, announced as anonymised. A register records which databases the entry produced, since the server does not
- An anonymised number can keep its digit count, on the file anonymiser and on `anonymize.py` alike (`--keep-digits`): 8839 then draws in 1000..9999, so the copy keeps columns of the same width, which an export read by eye or imported into a bounded field asks for. Each value keeps ITS own width and not its column's — 7 stays at one digit where 12 keeps two — and below the unit the rule does not apply, 0.15 having no digit before the point. The option trades one guarantee for another: the measured extent no longer bounds anything, so a rate or a year can leave its range, and the preview SAYS so rather than letting it be found at reimport. Uniqueness is what yields when a band fills up, a duplicate of the same width beating a value of a different one, and the band never exceeds what the type RECEIVING the draw holds, which is not always the column's: an Odoo `integer` over a column PostgreSQL did not create as an integer — what an upgraded base carries — is poured into `numeric`, which has no ceiling, where `integer` stops at 2 147 483 647 and a draw past it aborts the whole write, that write being one transaction
- The anonymiser asks four questions instead of eleven, seven of the eleven having had an obvious default. Answering them one by one to arrive at the same place makes prompts be passed by reflex, and a prompt passed by reflex consents to nothing; they now live behind « Advanced options? ». The short path DECLARES what it takes, in sentences rather than in yes/no, since those are decisions taken and not questions whose answer was lost. Macros and charts are asked on both paths: they are not visible in the cells
- `markdown-it-py` is declared as a functional dependency: it renders the language model's markdown to HTML, before sanitising, on the assistant page. It reached the environment transitively through `bandit` → `rich`, a lint tool, so removing a lint dependency removed a portal page's rendering engine
- A download cache shared by the QEMU VMs of a host, installed from **Deployment › QEMU cache**. Two VMs of the same distribution stop pulling the same hundreds of megabytes twice: a package file is served from disk, while an index is always taken from upstream, so a withdrawn package can never turn into a « failed retrieving file … 404 ». An index is stored all the same and only comes back out when upstream is unreachable, which is what makes an offline deployment possible. The cache never shrinks by itself: `--status` says what it occupies
- Interception is transparent and covers the whole host bridge, so a VM cannot opt out from the inside. Every VM trusts the cache's authority as long as the service runs. To take ONE machine out, tick « keep this VM out of the download cache » when deploying: its MAC address is fixed before creation and an exception is posted on the host. To take them all out, stop the service — its rules leave with it. A Proxmox host that is itself a VM here is no exception: the machines it carries come out behind its address, so the deployment poses the authority in each of them, by ssh, before installing anything
- The measurement is not limited to Arch: any catalogue system whose package family is known, and either a batch of packages or the real install of ERPLibre and Odoo 18. Measured on Ubuntu 24.04 with that real install, the second VM pulled **zero byte** of package from the network and finished 19 % faster. Verified on the seven systems of the catalogue
- Git is MIRRORED rather than cached: its protocol is a negotiation, the server computing its answer from what the client already holds, so no answer is reusable. A bare mirror per upstream repository is kept on the host and served locally, and a mirror already held serves with no network at all — measured, a repository cloned inside a VM while the cache's upstream was cut. Measured on a full ERPLibre install: the second VM pulled **zero** git request from upstream, where git had been four fifths of the traffic. **Deployment › QEMU cache › Git mirrors** fills them ahead from the manifests, so the first VM does not pay every clone
- An offline deployment also covers the base suite of a cloud image. Its apt REVALIDATES the index it ships instead of downloading it, upstream answers 304, and the cache had no body to keep — so that one suite, and only it, was missing offline while its `-updates` and `-security` neighbours came off the disk. A conditional request for something the cache does not hold now goes upstream without its condition, once, and a client that holds its own copy gets 304 rather than 504 when upstream is mute.
- What an offline deployment covers, exactly: packages, repository indexes and git. NOT what the cache is forbidden to decrypt — a client carrying its own trust store, npm and poetry among them, is tunnelled opaquely, and a tunnel carries nothing once the network is gone. A full ERPLibre install therefore still needs the network, though everything the cache holds is served from disk
- A mirror is COMPLETE where `repo sync` clones at depth one, so it costs tens of gigabytes. Below ten gigabytes free, no new mirror is created and the request goes back upstream. The diagnosis says what the objects and the mirrors each occupy
- **Deployment › QEMU cache › Age and cleanup** groups the cache by age of last use (day, week or month; objects and git repositories apart) and gives back what has not served for a chosen delay, or everything. A served object has its date renewed, so « old » means « no longer used ». Both cleanups say what would go before erasing anything, and entry 5 lists the mirrors heaviest first to remove one
- `long_test/qemu_cache.py` measures whether the cache really serves the second VM, and `--hors-ligne` cuts the upstream of the cache service alone to prove a third VM still builds from the stored index
- Before cutting, the form says whether the cache holds the base suite of each system asked for: F5 warns « cache holds nothing for ubuntu 26.04 » and a second F5 goes ahead anyway. The verdict is given only where a release is named unambiguously in the URL — the apt families — rather than reassuring wrongly elsewhere. The verdict is given component by component — `main`, `universe`, `restricted`, `multiverse`, on the base suite and on its `-updates` and `-security` companions — because a single stored URL used to silence it while a whole component was missing, and apt only said so twenty minutes later, by « Unable to locate package »
- **Deployment › QEMU cache › Copy it to another machine** carries the store to another ERPLibre host in a single stream — `tar`, compressed, over ssh, no intermediate file for tens of gigabytes — and hands the files to the service account on arrival, the same account rarely bearing the same number on two machines. Only the STORE travels: an object is keyed by its URL and never by the machine that fetched it, and a git mirror is a repository. The settings stay behind — bridge, subnet and authority belong to the host, and entry 1 poses them there
- The deployment form carries a **Network** section with « No internet connection »: for the whole deployment, install included, the cache service loses its way out AND the VMs lose theirs — ping, other ports, UDP, IPv6 — so a step that takes any path but the cache fails instead of quietly succeeding online. Names no longer resolve through the internet either: the host answers every name itself with an address the cache intercepts, so only what the cache holds can be reached; dnsmasq must be installed on the host. A VM behind the cache pulls from one fixed apt mirror: cloud-init's mirror search discards every mirror behind a resolver that answers every name, and would fall back on another mirror than the one the previous VMs filled the cache from. The cut refuses rather than drops, so an address the cache does not hold answers 504 at once instead of after a connection timeout; a kernel that cannot load the reject module gets the dropping set instead. Offered only where the cache runs, and the deployment refuses rather than run with the upstream still up, a VM built that way succeeding for the wrong reason. **Proxmox VE** carries the same box, offered where its host is itself a VM of this bridge: its guests come out behind its address, so the local cut covers them and nothing is posted on the remote host. A Proxmox host that does not live here is never offered it — nothing here can cut its way out
- A Proxmox VE deployment can ask for **3D acceleration**. The VM is created with an accelerated screen (`--vga virtio-gl`) rather than the serial console as its display, and the account joins the GPU groups INSIDE the guest: the render node belongs to `root:render`, so without them every GL application falls back to software rendering while the VIRGL negotiation reports success, and nothing says so. The box is offered only where the remote host has a render node AND the three libraries Proxmox loads for that screen — VIRGL, GL and EGL. It names the missing ones and refuses to start the machine, once its disk is written and its configuration posted, so a host carrying GL without EGL would fail at the very last step. Where a piece is missing the form says which, and the package to install on the host: a box that vanishes without a word reads as a regression. A button installs them without leaving the screen — the form hands the terminal back so sudo can ask for a password and apt can be watched — then reads the host again rather than taking apt's word for it, and the box appears in place of the message. The serial port stays posted, so `qm terminal` keeps working
- Offline, the cache replays what an online pass saw, not only 200 bodies: redirects, definitive refusals (404/410) and HEAD answers of volatile URLs are kept without a body, under keys of their own, and served ONLY when upstream is mute. A TUF client probing the next version of its root gets the 404 it expects instead of a 504, so mise installs Python offline with its Sigstore verification intact; GNOME extensions, Claude Code's installer and rtk's version lookup follow their redirects offline
- The offline cut ends when the last installation ends, not when the monitor closes: a root unit, handed the lift at launch, waits for every installation's exit marker and survives the monitor closed early, todo.py killed or the terminal gone — 12 h at most. The monitor is therefore required while offline. A second offline deployment is refused while one runs, and an online deployment started meanwhile is told it would run offline
- F5 also reads the previous offline runs of the same VM and warns « at least N addresses were missing », minus what the store holds now (`erplibre_go_qemu_cache --detient`, read-only, no root). **Deployment › QEMU cache › Fill what offline runs lacked** replays them online, through the cache
- The install log names the commit the VM runs; offline, the recap says, branch by branch, which commit the cache's mirror will give
- `long_test/qemu_cache.py --distro tous` (or a comma list) chains one campaign per catalogue system, destroys each system's VMs before the next, and ends on a table of verdict, durations and upstream bytes. A failure does not stop the series
- The QEMU download cache can clean itself up every day: by age (`EL_PURGE_AGE`, e.g. `90j`) and by size ceiling (`EL_MAX_SIZE`, e.g. `50G`, the least recently served going first, objects and git mirrors alike). Both are off by default and set from **Deployment › QEMU cache › Automatic cleanup**, which previews what would go; `--purge-to-size` runs the ceiling by hand. A reinstall keeps the values chosen
- NixOS 25.11 as a deployable system, alongside the eight others. It is the only one no distribution publishes a cloud image for: the image is rebuilt by a third party, so its release is pinned, its sha256 verified at every download, and its origin printed before anything is created. cloud-init receives no network configuration there — its networkd renderer takes the key of a block as an interface NAME, where netplan honours a `match:` — and the account is created with `/bin/sh`, sshd refusing an account whose shell does not exist
- ERPLibre installed on NixOS, its dependencies DECLARED in `conf/nixos/erplibre.nix` and applied by `nixos-rebuild`, where the four other families install them one command at a time. `services.envfs` answers `/usr/bin/env` and `programs.nix-ld` gives manylinux wheels the dynamic loader they ask for; the headers of what has no wheel are linked into the system profile, and its libraries reach the loader too, a module compiled on the machine carrying no RPATH. The install reaches it from the menu like any other distribution: the bootstrap poses git, make and python3 — absent from that image — in the user profile for the clone, and « make install_os » redeclares them for the system. Checked on a VM: the 362-package lock installs and Odoo answers over HTTP
- A `nix + nixos-anywhere` option on the OTHER distributions, the reverse of picking NixOS: it leaves an ordinary VM able to install NixOS onto any machine reachable over SSH. Nix is called by absolute path, the remote shell's PATH being frozen before the installer drops the binary, and the flake features are repeated on the command line, writing `nix.conf` needing a sudo that may fail
- NixOS deploys on a **Proxmox** host as it does on QEMU/KVM, which took three fixes no code reading could have found. Its image has no BIOS boot sector: a VM created in SeaBIOS reports « running » with a silent console, so the catalogue now marks which images need UEFI — one marker per distribution, since Debian 13 boots in SeaBIOS on that same host. `--ciuser` and `--sshkeys` defer to the image's DEFAULT account, which NixOS declares as another name: the repository's own cloud-config now travels as a snippet for every distribution, carrying an explicit `users:` block. And the cloud-init drive moves to the SCSI bus — an image built for virtio alone has no ATA driver and never sees an IDE drive, so cloud-init hunted network datasources and the VM came up with no account at all. Checked end to end: NixOS answers with `/bin/sh`, Debian 13 with `/bin/bash`, sudo on both
- The third-party image is verified against the sum the repository pins for it on the Proxmox path too, where a bare `wget` used to be enough. One accessor carries that sum for both paths, and the check runs even on a cached image — the case aimed at is a file substituted or truncated between deployments, which a presence test cannot see
- One entry of the download cache can be removed, by URL. A checksum that does not match invalidated nothing: the store kept serving the same bytes, and re-downloading changed nothing since the store is what answers. Neither existing purge reaches it — `--purge` erases everything, and `--purge-older-than` skips what is recent while every service resets that date, so a poisoned object that keeps being served never ages. `--oublie` is symmetric to `--detient`: same input lines, same key functions, same refusals, and a present object that resists is reported as a refusal rather than a forget. Both checksum failures now name it, with the exact URL
- The install log carries what the host decided before launching: the download cache authority placed or refused, the bypass, the mirror. Those lines were said on a console that scrolls away, while the file reopened after a failure held only the symptom — on a guest with no trust store, a refused certificate, hundreds of derivations to build and six hundred lines of errors, without a word on the cause
- One entry of the download cache can be forgotten from the menu, under « Age and cleanup ». The binary could already do it; the menu offered only the two bulk purges, neither of which reaches a single object — « erase what has not served » never reaches one the service rejuvenates each time it serves it, and « erase everything » costs the whole cache for one file. `--detient` runs first and is the preview: same line, same key, nothing modified
- `erplibre_go_qemu_cache --recle` stores a cache's objects again under the current key, without downloading anything, and merges the copies a mirror carried under several paths. Objects written under the former key rule stay on disk but become UNREACHABLE, so the service asks upstream for them again and the space they hold serves no one: on a store of 12 764 objects, 5 419 were in that case — 9.11 GiB — and merging the duplicates returned about 3.37 GiB. The service must be stopped, the body being renamed before its meta, and `--dry-run` only counts what would move. A status-only entry is left alone, its key carrying the host rather than the path
- The `pre-commit` hook runs `check_python_version.py` on staged files: it reports source that does not parse under the Python of `conf/python-erplibre-version`, without blocking the commit, and says when no such interpreter was there to check. Neither black nor flake8 sees that fault — black's target bounds what it writes, never what it accepts
- `Deploy › Local › [4]` opens a SOCKS proxy over SSH — `ssh -D`, port 1080 by default — so the browser reaches, FROM the remote machine, an interface listening only on its loopback or a host of its network. The address comes from `~/.ssh/config` or by hand; an alias is passed to ssh as is, so its `ProxyJump` still applies and a nested VM stays reachable. The Firefox settings print before the tunnel opens, the command only returning on Ctrl+C
- `make format_test` formats `test/` and `long_test/`, which no target covered: 75 files out of 210 followed no standard, and only a file a diff reported was ever touched
- `script/reverse_proxy/main.py` — a development reverse proxy for Odoo 18 without nginx: one address sends pages to the web port and `/websocket` to the bus port, with the `X-Forwarded-*` headers of `proxy_mode` set by the proxy alone (`--trust-forwarded` extends a chain instead, behind another proxy). Only the request head is read, so an upgraded WebSocket stays open and a gzip or chunked response passes byte for byte. It serves HTTPS with `--tls-cert`/`--tls-key`, logs one line per request (route, status, duration; `--quiet` silences it), says at start which Odoo port does not answer, and names that port in a 502. A request head waits 30 s (408) and the connection to Odoo 10 s (504), never an open WebSocket. Listens on `127.0.0.1:8080` by default, `--listen 0.0.0.0` opens it to the network; one request per connection, production keeps nginx
- `script/reverse_proxy/local_cert.py` issues a local authority, imported once in the browser, and a server certificate it signs for localhost, the host name and its addresses, under `~/.erplibre/reverse_proxy_tls/` with keys in 0600; the authority is kept when the certificate is issued again
- `TODO › Execute › Network › Odoo reverse proxy` starts it with the web and bus ports read from `config.conf`, asks for this machine only or the whole network and for HTTP or HTTPS, issues the local certificate on first HTTPS use, and warns when `proxy_mode` is off or `workers` is 0 — without a worker no bus port listens and `/websocket` fails. `Network › Local TLS certificates` issues it again with extra names
## Changed
- `Assistant › [1]` no longer sends every question to a single remote API on a fixed model: it asks whichever server is configured, and falls back to the remote one only when no local server answers
- The comment hygiene check reads Go comments, not only `#` ones: `//` outside a string, the raw string between backticks, and `/* … */` blocks
- Debian and Ubuntu `by-hash` index files are served from disk, their name being the digest of their content; `…/releases/latest/download/…` is no longer pinned to the first version seen
- An upstream that refuses or drops connections is remembered for 20 s: a request with a stored answer is served at once instead of waiting its connect timeout, which made up most of an offline install's time; a request with nothing stored still tries upstream. A git mirror skips its refresh while its forge is unreachable
- Mirror prefetch runs under the cache's service account, never as root
- The long-test menu asks before creating real machines, and asks again, in words of its own, before `--detruire` removes machines with their disks. The command is shown first, which is what makes the question answerable; a dry run or a performance report creates nothing and asks nothing
- Every entry of the Proxmox VE menu carries an icon, the same picture meaning the same action as in the other menus of the tool
- The QEMU cache binary speaks English or French: service journal, `--status`, `--age`, option help and the error served to a VM. The language comes from `--lang`, then `EL_LANG`, then French; the installer writes `EL_LANG` to the service settings and the TODO menu passes its own. Rules, verdict codes and JSON keys are never translated
- A repository index the cache already holds is revalidated with its ETag rather than downloaded again: upstream still judges every request, and a « 304 » serves the stored body from disk. On a full ERPLibre install the pip indexes, npm metadata and repo bundle had been about 110 MB per VM, taken whole each time. An index stored without its host — shared by every mirror of a rotating list — and an answer carrying no ETag are taken whole as before; the access log names the new outcome `revalidated`
- A registry page served under `Vary: Accept` keeps one copy per representation. npm asks for the same `/npm` page abridged, then complete, then abridged again; kept under one key they replaced each other and the 31 MB were fetched on every install. Each representation is now revalidated and, offline, served on its own; `--detient` still reads the page under its URL alone
- A VM deployed with the cache upstream cut — QEMU form, Proxmox VE, or `deploy_qemu.py --offline` — has npm's security audit turned off (`NPM_CONFIG_AUDIT=false`): it queries a remote service no cache can replay, and failed on every offline install. An online VM keeps its audit
- Verifying a downloaded image no longer needs `--verify`: it runs by default for every distribution that publishes a sum, and `--no-verify` is what skips it — to be kept for offline runs, where a substituted image would otherwise pass unremarked
- `--bios` is refused on an image with no BIOS boot sector, and says why. Forced there, it gave a VM reported « running » with a silent console — the very failure that flag exists to avoid elsewhere
- The tooling virtual environment `.venv.erplibre` runs Python 3.14.7, independently of the Odoo one (3.12.10 for Odoo 18.0). `install_erplibre.sh` builds it through `install_venv.sh` and `EL_PYTHON_PROVIDER` instead of the system `python3`
- `.venv.erplibre` on an incompatible Python is DELETED and rebuilt; whatever was installed in it by hand goes with it. Odoo's venv is kept when it merely differs in version, and rebuilt only when it is unusable: rebuilding it redoes a whole Poetry install. A directory without `pyvenv.cfg` is never deleted
- `make` and `make todo` run `./todo.sh`, a launcher whose name says a menu opens and not an installation; it hands every argument to `install.sh`, which picks an interpreter able to READ the code before running it: `.venv.erplibre` on the right version, else a recent enough system `python3`, else the install, which runs only on a yes typed in a terminal (`o`, `oui`, `y`, `yes`) since it can delete `.venv.erplibre`. A system older than `conf/python-erplibre-version` would otherwise stop on a syntax error raised before any guard could name the command to type. TODO then relaunches itself in `.venv.erplibre`, or offers to run `install_erplibre.sh` in a terminal
- The production Docker image builds `.venv.erplibre` on Odoo's Python and stops when that Python cannot parse `script/`
- Debian 11 is dropped from the deployment catalogue: its LTS ended, and its security suite is neither served nor archived — the index it still publishes names packages whose pool no longer holds the file, so apt stops before installing git. Debian 13 takes its place, its cloud image always being the latest point release
- Every container image is built on bookworm, whatever the Odoo version. The base is `python:<version>-slim-<suite>`: the interpreter comes from the official image, never from Debian, and the bookworm variants exist down to 3.7.17. The wkhtmltopdf build follows the suite — bullseye's requires libssl1.1, absent from bookworm
- The PATCH bounds only Odoo's venv, whose pyproject requires `>=3.12.10,<3.13`. For the tooling one, the major.minor is enough: requiring the patch turned away a distribution's Python one step behind — NixOS 25.11 ships 3.14.2 where conf asks 3.14.7 — and made pyenv COMPILE CPython for a difference nothing needs
- `make format` picks the formatter from each file's context: an Odoo module keeps isort and black on `py37`, the series still supported going down that far, while this repository's own tooling goes through ruff, configured once in `.ruff.toml`. ruff follows CPython's versions, where black 24.8.0 stops at `py313`, and its import sorting replaces isort; it is also what the OCA standard uses since it left black
- The repositories that Google Repo checks out under `script/` are excluded from that formatting, a named path included: reformatting them would write in someone else's history. `target-version` stays at `py310` there, because the git hooks carry `#!/usr/bin/env python3` and a distribution still ships 3.10 — from 3.14 on, ruff would write `except A, B:` without parentheses
- The list of Claude Code commands in `TODO › Execute › GPT code › Claude configs` compares each ERPLibre template in `conf/` with its copy in `~/.claude/commands/`: a command not installed is shown, an outdated copy is marked with its count of added and removed lines, and a command that comes from elsewhere is labelled as such. On a yes it prints the diff, then redeploys the outdated copies, keeping the git name and e-mail `/commit` carried
- A commit message opens on an English subject and an English body; `--- FR ---` then opens the French section, which starts with the subject translated under the same tag. The `commit-msg` hook refuses a `--- EN ---` marker and a French section without that title, and checks the title like a subject. `/commit` and `/git_prepare_merge` follow the same order
- TODO menus: the language is set only from Configuration, the duplicate entry in Execute is gone, and Fork moves from the main menu to Configuration. The main menu now numbers Telemetry 4 and Configuration 5. The language chooser shows a flag per language
- Odoo 18 dependencies refreshed. `openai` is pinned to 2.x, whose 3.x requires an `idna` that Odoo 18 forbids; `fsspec` is pinned beside `s3fs`, which demands it at its own exact version, so the two move together; `meteostat` returns to 1.x, every 2.x capping `pytz` below 2024. PyMuPDF stays excluded on s390x, now declared in the requirements so a regeneration keeps it. Major bumps of `ujson` 6, `plotly` 7, `python-slugify` 9 and `sqlalchemy` 2.1 are not yet tested
- Dependabot ignores the major versions of `meteostat`
- Odoo 18 moves to pandas 3.0.6, cryptography 50 with pyopenssl 26.4, Pillow 12.3 and botocore/boto3 1.43.75 with aiobotocore 3.9.1, the highest botocore its narrow range accepts. The seven modules that import pandas run their pandas calls unchanged; `freq='d'` in a Cybro attendance dashboard now warns and will break with pandas 4
- Dependabot groups `aiobotocore`, `botocore` and `boto3` into one pull request, since each aiobotocore accepts only a narrow botocore range; security fixes still arrive on their own
- `TODO › Transform data` reads Excel with openpyxl 3.1.5 and xlsxwriter 3.2.9; the leak test that guards openpyxl's exact pin passes on them
- factur-x requires 6.8 outside s390x, the version already locked, so a regeneration can no longer fall back to an untested 4.x or 5.x
- The interface chooser of the QEMU deployment and of the Odoo migration, and its preferences in `TODO › Configuration`, mark the TUI form with 📋 and the line by line questions with 💬
## Fixed
- Reading the dnsmasq leases no longer opens a root password prompt: the files are read directly, which suffices on a standard install where they are 0644, and only then is `sudo -n` tried, which fails instead of asking. Displaying a VM list called that path once per VM, and waiting on a VM called it every three seconds for ten minutes
- `--max_process` runs again on Python 3.10 and later: `loop=` left `asyncio.wait` in 3.10 and `asyncio.get_event_loop()` raises outside a running loop since 3.14, so the pool was not even constructible while the help still advertised the flag
- A prompt no longer writes its colon twice — the most-seen menu of the software asked « Command:: », and seven remote-deployment prompts showed a colon followed by another
- Eleven submenus now leave their segment in the breadcrumb, and navigation telemetry stops filing them as commands under their raw method name
- The three readers of `~/.ssh/config` agree on what a machine name is: an alias declared with a lowercase `host` is seen, a tab separates as legally as a space, and a negated `!name` pattern is no longer taken for a machine to connect to
- Three translation keys declared twice are gone, and a check refuses the next one: a repeated key silently overwrites the previous, which had already cost a menu label
- `anonymize.py` abstains from a unique numeric column and NAMES it in the report. A draw guarantees nothing on a unique column, and a number has no way out where text has one — appending the id carries uniqueness for text, but would change a number's magnitude. Two rows drawing the same number failed the UPDATE and, the whole run being one transaction, took the entire anonymisation with them. Without the report naming it, an identifying column stays in the clear with nothing saying so
- Restoring a backup no longer raises `AttributeError` before running the command: `_monitoring_restore` read `self._execute` where `TODO` sets `self.execute`, and both entries leading there — the local backup and the remote one — were broken. A check refuses the next one: every `self.X` that `TODO` READS must be set by TODO or by one of its bases. Searching the name across `script/todo/` did not see the fault, another object of the package setting `_execute`; it has to be searched in the classes TODO INHERITS from
- The Selenium scripts run on a Python built without `tkinter` — any server with no graphical toolkit package. That module is only needed by the vault's file picker, so it is now optional: with no `tkinter` and no configured KDBX path, opening the vault logs an error and returns, instead of breaking the import of every browser-automation script
- Dark mode works again in a private window on a current Firefox. The « Run in Private Windows » permission is granted when the addon is installed, through the `allowPrivateBrowsing` field, rather than clicked through the `about:addons` interface: Firefox refuses navigation to `about:addons` from the content context, and the chrome context demands `-remote-allow-system-access`, which geckodriver rejects through capabilities, so both routes to that checkbox are closed. A geckodriver that ignores the field installs without the permission instead of killing the session
- The « - Default » label appears again at the version and environment menus: both reads asked for a capitalised key the version file never writes, and a missing key returns nothing without a word
- The cache's « nothing in store » message is inert as a shell script, every line being a comment. Fed to an installer built on `curl … | bash`, it used to become a cascade of « command not found » that hid the real cause. Such a download now also asks curl to fail on an HTTP error rather than execute the error page
- The wait for a VM to be ready now covers the guest-agent install too. That one is launched as a DETACHED unit so cloud-init returns in seconds, and it runs an `apt-get update`: `cloud-init status --wait` said « done » while the package lock was still held, the next step burnt through its retries, and the install then ran on an index never refreshed — « Unable to locate package », a message that blames the repository rather than the lock. An update that never succeeds now says so on the spot
- A desktop install no longer waits minutes on the apt lock: the apt-daily SERVICE is stopped and not only its timer, a timer being disabled without interrupting the apt-get it already started; and the retry comes back every two seconds rather than every ten, `DPkg::Lock::Timeout` not covering the list lock at all
- Fedora VMs boot again: the firmware loads and starts their loader, then freezes without writing a byte — no console, no DHCP lease, a machine "running" that does nothing. Fedora is booted in legacy BIOS, where the same image starts its kernel; `--bios` still wins when asked
- A VM receives a hostname it can accept — an underscore, which a libvirt domain name tolerates, made it keep its image's generic name — and a timezone its own distribution knows, a legacy alias having left it in UTC
- starship installs in a VM: its installer runs as root, bounded by a root timeout, so it never reaches the `sudo -v` that sudo-rs refuses; its shell hook no longer prints « command not found », nor fails a sourced rc, when starship is absent
- Each optional tool says whether it was installed, and a GNOME extension whose download failed is no longer reported as unavailable for this GNOME
- mise, pyenv and GNOME extensions are downloaded, then run: without pipefail, `curl | sh` could neither report a failed download nor reach its fallback
- The guest-agent unit no longer ends in failure after a successful install
- The cache answers 508 to a request that targets the cache itself, instead of calling itself until it runs out of descriptors
- The cache diagnosis no longer reports a stopped service as running
- The wait for `apt-get update` is bounded by a deadline rather than by a number of attempts. An attempt fails in under a second on a held lock, but takes minutes when the cache answers 504 on every index it does not hold: sixty attempts were then worth hours of silence where five minutes were promised, and the install went on to fail on unmet dependencies
- A Proxmox guest is pinned to the same apt mirror as the rest of the fleet, written over ssh before anything downloads. The store keys its indexes by HOST, so a VM left on the default repositories of its image found none of what the cache had been filled with — offline, every one of those indexes was missing
- The cache installer accepts a bridge and a subnet given by hand. It probed libvirt first and died on « network default not found », so the workaround its own header advertised — `EL_BRIDGE` and `EL_SUBNET` — could never be reached. A machine whose libvirt network is not started, or which carries its bridge otherwise, can now lay the cache down by naming it; and when the probe does run and fails, it names both ways out
- **Deployment › QEMU cache › Install or reinstall** no longer announces « installed and started » when the installer failed. It caught exceptions only: a non-zero exit — a missing libvirt network, a build that gave way — printed the success line right under the error itself, along with the path of an authority that does not exist
- A Proxmox guest receives its guide, its timezone, its apt mirror and the cache authority again. All four go by ssh and used to start as soon as an address was known, while cloud-init was still creating accounts and keys: they failed together, and the VM was born in UTC, guideless, without the authority and on its image's repositories. The deployment now waits for the machine to answer ssh — five minutes at most — and says so when it never does, rather than failing four times in a row
- The cache no longer serves a repository index newer than the signature that announces it. Offline, each object came out with its own date: an index refreshed on Saturday under a Friday `InRelease` made apt fail on « File has unexpected size » or « Hash Sum mismatch », and the install stopped on unmet dependencies — a message that blames the repository, never the cache. The comparison is made on the upstream `Last-Modified`, never on the storage date, which is renewed on every hit
- The refusal to copy the cache to another machine names the gesture that lifts it, and that gesture is not entry 1 — entry 1 installs the cache HERE, so following it reinstalled the host that already had one while the target stayed empty. Three situations were reported as a single « no cache installed »: an ssh link that never ran the probe, a target carrying no cache, and a target whose cache lacks its service account. Each has its own message now, and the missing-cache one lists the steps to run ON the target, the two ways past an installer that reads the « default » libvirt network included — start libvirt, or name the bridge, a stopped libvirt making it die on a network that exists. The steps also name the branch to put the target on, read from this host: the installer is a file of the repository, so a machine left on another branch answers « no such file », which looks nothing like a missing cache. A fourth case is checked before a single byte leaves: sudo asking for a password on the target, which no terminal can answer since the store itself occupies ssh's standard input — the message gives the ticket to obtain there first. The arrival is asked for the privilege ONCE, `tar` and `chown` under a single invocation. Where sudo there wants a password, the entry offers two ways out instead of failing: the one-off sudoers line that allows it, or a two-step mode — the store is sent into the target's own account, which needs no privilege at all, and a printed command extracts it from a terminal there, where a password can be typed. That mode needs twice the store on the target, checked before a byte leaves, a cache holding only already-compressed packages and git archives. The guide carries the same section
- The Proxmox VE deployment form checks the cache before cutting the network, as the libvirt one already did: what the store lacks, no cut VM will read, and the failure used to land an hour later, at the desktop step — a message that blames the repository, never the cache. F5 again means going ahead anyway. Both forms now share a single verdict instead of two copies of it, which would have drifted apart at the first adjustment
- The cache keeps its repository indexes when a mirror list rotates. An index published under the hash of its content — `by-hash/SHA256/…` — was stored under a key carrying the host, so the same bytes served by a second mirror were fetched again; offline they were simply missing, and the install failed on files the store already held, with a message that blames the repository. Such an object is now keyed by its path alone, its name BEING the checksum of its content
- The cache diagnosis no longer reports « no redirection rule is posted » when it simply could not read them. On a host whose sudo asks for a password, `sudo -n nft` returns nothing, and that silence was read as an absence of rules — sending the operator to reinstall a cache that was redirecting correctly. The reading now carries a third state, « cannot tell », marked with a dot rather than a cross, exactly as the upstream-cut reading already did
- A lifted cut gives the upstreams their chance back at once. The service remembers, for a short while, which upstreams just failed to connect, so that an offline install does not pay the connection delay hundreds of times; nothing told it the cut was over, and the first requests after the lift fell back on the store while the network was already back. The lift now touches a witness file inside the store, which that memory consults — there is no channel at all to the running service
- Before cutting, the form also warns about what no index can reveal: a package the deployment lays down OUTSIDE the watched thread — the guest agent, installed by a detached unit whose failure surfaces nowhere — and the git repositories declared by the manifests that have no mirror yet. A held suite index was enough to call the cache complete while not one byte of that package had ever crossed it; and a git negotiation is never stored, so a repository without a mirror simply cannot be cloned once the network is gone
- The mirror warning counts only the repositories of the Odoo version being deployed. It used to add up every manifest in the repository — the deprecated one included — and announced 170 missing mirrors where a real Odoo 18 deployment meets four: an alarm that fires for nothing is one that stops being read. Filling the mirrors still takes every version ahead, which is its purpose
- A host banned from decryption on a burst of transport errors gets another chance. Three failed handshakes in a row put it in an opaque tunnel, and a tunnel never consults the store: a distribution mirror condemned by a few corrupted records sent all its traffic back upstream, including the hundreds of objects already held for it, until the service was restarted. A TLS alert still bans for good — the client looked at our certificate and refused it — but a repeated cut is only a suspicion, and it reopens after ten minutes
- **Deployment › QEMU cache › Git mirrors** fills the base of the active Odoo version, or its extra modules, on their own — beside the full fill of every manifest, which takes hours. Each list shows how many repositories it declares and how many still lack a mirror. What a deployment clones is now read with the manifest merge's own rule and lists, so the extra modules, installed only on request, and the mobile project no longer count: the offline warning announced four missing mirrors that a default Odoo 18 install never clones
- pip's PEP 658 metadata — the `.whl.metadata` file fetched before each wheel — is served from disk. The name ends in `.metadata`, which no rule knew, so each file was taken again on every install: 178 of them on a full ERPLibre install. Copies stored before this change are not reached again; the next online install refills them
- The timezone a deployed VM inherits from its host is translated to its canonical name. Ubuntu 24.04 cloud images no longer carry the legacy aliases — `Canada/*`, `US/*`, `Asia/Calcutta` — moved to a `tzdata-legacy` package they do not install: cloud-init refused the zone, the VM stayed on UTC, and the only sign was cloud-init reporting an error, the offset showing up in timestamps long afterwards. The alias table is the host's own `tzdata.zi`, not a copy kept in the code
- `make` looks for bash instead of assuming `/bin/bash`. That path does not exist on NixOS, where the shell lives in the store, and make stopped before running any recipe — including the one that installs what creates that path. Elsewhere the resolved shell is the same one as before
- The locale and the keyboard a deployed VM is given now apply on Debian, where both silently failed. A locale is generated from `/etc/locale.gen` and nowhere else, so `update-locale` refused one that was not there and the VM stayed on C.UTF-8; the keyboard module ends on a `console-setup` the genericcloud image does not carry, so `/etc/default/keyboard` — the file localed and X read — is written directly instead. Every Debian deployment used to print `cloud-init: status: error`, and a word that always shows warns of nothing
- A guest with no per-file trust anchor is taken out of the download cache instead of being intercepted without one. Interception is transparent and covers the whole bridge, so a VM given no authority still fails every HTTPS download on « self-signed certificate in certificate chain » — and on a declarative system placing the authority comes too late, the first rebuild being the first download. On a Proxmox host it is the HOST that is exempted: a nested guest leaves masqueraded behind it and the bridge never sees its own address. Measured from inside the guest: code 000 and SSL verification 19, then 200 and 0. Without it the package manager fell back to building 564 derivations, whose sources failed for the same reason
- NixOS learns the download cache's authority WITHOUT a rebuild, so it is no longer taken out of the cache — which used to close offline deployment to it, the store being the only source there and an exempted VM having none. It has no per-file trust anchor and /etc is generated read-only, while a declaration would come too late, the first rebuild being the first download. The authority is therefore POINTED AT, consumer by consumer, through the environment — and the environment is lost at three boundaries the four imperative families never meet. nix-daemon is socket-activated and sees no session: a drop-in under /run/systemd/system, a tmpfs writable where /etc is not, reaches it. sudo wipes it, and root's nix talks straight to the local store rather than the daemon, downloading on its own: `Defaults env_keep` carries the variables across, visudo being reached through the system profile since cloud-init's PATH there holds no sudo. And the ssh session opens one second before cloud-init writes the bundle, so the exports live inside the wait for it rather than at the head of the command. The bundle concatenates the system authorities with the cache's, giving the cache's alone would stop trusting everything else. Checked on a fresh VM with upstream CUT: nix-shell realises from the store; and with the cache intercepting, a complete install ends with no certificate refusal
- Odoo answers from outside a NixOS VM. It listened on 0.0.0.0:8069 and replied locally, but NixOS enables a firewall by default where none of the four other cloud images does: the host received nothing — not a refusal, silence until the timeout — and the monitor declared Odoo absent on a machine where it was running. Measured from the host: 000 after 12 s, then 303 in 9 ms
- ERPLibre runs as a service on NixOS. The install ended by writing a unit into `/etc/systemd/system`, generated from the store and mounted read-only: it returned 1 at its last step, after the clone, the venv and an Odoo start had all succeeded. The unit is now declared by the module; its interpreter comes from the store, `/bin` being an envfs FUSE mount that systemd does not see when it resolves the executable; and its PATH carries bash, whose absence stopped `run.sh` before Odoo
- What a declarative system must declare, and the four others receive free from their cloud image: xmlsec1, without which Odoo refuses to install auth_saml, a module of the addons path; parallel and shfmt, called by bare name; growpart, absent from the whole system while the disk grow is written « … || true » and returned 0 without growing anything; and the guest agent, which came from the image rather than the repository, its unit PATH lacking findmnt so that guest-exec died with 127 on its first line
- The connection guide is displayed on NixOS. Deployment writes `/etc/motd` everywhere and relies on pam_motd to show it — true of the four cloud images, false here, where sshd reports « printmotd no » and the PAM stack holds no pam_motd: the guide was written, complete, and nobody read it. It also gains a NixOS block naming the trap it exists for — `/etc/nixos/erplibre.nix` is rewritten by `make install_os`, and declarations added there vanish without a word
- « make db_drop_all » no longer announces databases as dropped that were not. It built a parallel command, discarded its exit status and printed the list; the case is reachable as soon as parallel is missing from the PATH, and the operator moves on believing their databases are gone
- A download cache mirror refused for lack of space names its threshold and its measurement. It echoed a field every ordinary caller leaves at zero — « less than 0 B free on disk » announces no threshold and does not say what was measured
- A downloaded image is checked against the sum its publisher ships, for every distribution that publishes one and WITHOUT asking. The check existed behind a flag and for Ubuntu only, so the other images arrived with nothing looking at them. Six now enter, read off the repositories rather than guessed: Debian publishes sha512 where everything else is sha256, the RHEL families name the file « CHECKSUM », Rocky writes the BSD form, and Arch and openSUSE ship a sum per image. An unreachable sums file no longer stops a deployment — that is an availability failure — while a mismatch still stops everything and removes the image
- The locale a deployed VM is given applies on NixOS. cloud-init applies it through locale-gen and update-locale, absent there, and the VM kept the distribution's default — « fr_CA.UTF-8 » asked for, « en_US.UTF-8 » obtained. Both it and the timezone are declared by the module now, and neither is imposed on a NixOS one already had
- The connection guide fits an 80-column terminal even on a VM carrying its tools and a desktop, where it rendered 103 columns wide: the frame overflowed, the terminal wrapped wherever it liked, and the two-column alignment — the only thing making the guide readable at a glance — was lost. A gloss now wraps under its column, and moves below its command when that command leaves no room. The layout carries the rule, not the length of the texts, which would have held only until the next tool
- A VM deployed offline gets its cache variables before its installation starts. « cloud-init status --wait » returns as soon as cloud-init declares itself in error — an accessory module suffices — while its final stage is still writing the authority, `/etc/environment` and the sudoers file; a session opened in that second lived without them, and an install run by sudo then rejected the cache certificate. The deployment now waits for the cloud-final unit, and only its « activating » state, that unit being a oneshot that stays active once finished
- Repository metadata an RPM distribution names after the hash of its content is served from disk like a package, and a range request on a file the cache does not hold fetches the whole file in the background, once per key. Such an index of tens of megabytes was taken whole on every install — about 110 MB per VM on a RHEL family system — and dnf, which fetches its zchunk metadata by ranges, got a « 504 » with upstream cut, no range being stored
- A VM deployed offline no longer waits for a time synchronisation that cannot come. An image that enables `systemd-time-wait-sync` holds `time-sync.target` until the first NTP answer, and cloud-init's final stage is ordered after it: with no reachable time server, that stage never ran, nor the ssh host keys it generates, and the VM reached its login prompt without ever answering ssh
- The download cache no longer re-fetches a package it already holds because a mirror files it under another path. A mirror prefixes the path as it pleases — « /rocky/10.2/… », « /mirror/rocky-linux/10.2/… », « /pub/archive/fedora/… » — and the whole path gave two keys for the same bytes: over a log of 7099 delivered names, 1124 lived under several paths and 3.18 GiB went back upstream for nothing. Only the last six segments count now, empty ones falling with them. Six is the smallest collision-free bound: a Debian path carries exactly six, so five would serve Ubuntu's package for Debian's, which bears the same name for other bytes. Pacman packages stop at four, their paths being shorter than the common bound, which drops the mirror's prefix and keeps the repository name. A store filled before this change is brought over by `--recle`
- A kept image that has gone stale is fetched once more instead of ending the deployment. A distribution's « latest » directory moves with each point release and the published sum stops describing the image on disk, with no byte corrupted: the check deleted it and exited, losing a whole campaign — three VMs — to a staleness one download repairs. A second mismatch is on freshly downloaded bytes, stops everything and deletes the image; called with no mirror list, and for unreachable sums, nothing changes
- `long_test/qemu_cache.py` no longer fails a campaign where the cache served everything. A URL counts as « already seen » only if the first VM obtained its bytes: one package lives under two paths depending on the mirror, and the first VM can get a « 504 » on one — upstream judged mute — then be served from disk by the other, so nothing was stored under the first path and the second VM's honest download was counted a fault. A missing status counts as delivered, older logs not always writing it, and the new-files line names both of its causes instead of blaming Arch whatever the system measured
- An interrupted image download resumes on the same mirror, three attempts, by a `Range` asking for the rest, instead of throwing away what it received: a VM image weighs half a gigabyte, and a truncated `.part` used to send the reader back to a hand-typed `curl -C -`. A server ignoring the Range returns the whole file, and the transfer restarts from zero rather than doubling the bytes already there
- The cache's certificate variables name a bundle only when the file exists. A recent Fedora lacks `/etc/pki/tls/certs/ca-bundle.crt`, and pointing pip at a missing path made it refuse EVERY download, including what has nothing to do with the cache. None found writes no variable, and pip keeps its own certificate set
- `make version` names both Pythons, Odoo's and the tooling's. A bare label suggested the repository had one, and the figure shown was not that of the venv the reader works in
- `make` no longer launches a `.venv.erplibre` built on another machine, such as a checkout mounted over the network, which died on « No module named 'encodings' ». `install.sh` reads the interpreter's version by running code: `python -V` answers before the standard library loads, so it vouched for an interpreter that could not start. Such a venv is now reported as built elsewhere, with the command that rebuilds it
- Dependabot no longer opens pull requests against the frozen requirements of Odoo 12 to 17: its security updates scan `requirement/` as its own directory, which the exclusions did not cover
- `poetry_update.py` stops on a missing `pyproject.toml` with the command that creates it, `make switch_odoo_XX` for the active version, and offers to run it then restart when launched from a terminal
- `poetry_update.py` runs Poetry in the Odoo venv even from a shell under `.venv.erplibre`, whose Python made it fail on « InvalidCurrentPythonVersionError »
- `poetry_update.py` skips requirements and manifests under a `doc`, `docs`, `example` or `examples` directory: an example file declaring a loose `>=` no longer moves a dependency for the whole environment
## Removed
- The `sshconf` dependency, declared and installed everywhere and imported nowhere
## Security
- An API key and a bearer token are redacted too before a command is displayed, logged or reprinted: `OPENAI_API_KEY=` went out in the clear, and a header token escaped by construction, carrying neither an option name nor a variable name
- Following a redirect, the cache no longer forwards the client's credentials (Authorization, Cookie, Proxy-Authorization) to another host
- Odoo 18 installs `idna` 3.20 instead of the 3.6 its own requirements pin, which is affected by CVE-2024-3651
- Odoo 18 installs `requests` 2.32.4 instead of the 2.31.0 its own requirements pin, which is affected by CVE-2024-35195 and CVE-2024-47081
- The git mirror of the QEMU cache clones only over `http` and `https`: a client could name an `ssh://` or `git://` repository in its request and make the cache connect, with its service account keys, to a host of its choosing. Repositories fetched over HTTPS are mirrored as before; the binary reports 0.2.17
## [1.8.0] - 2026-09-04
**Migration notes**
Recreating the virtual environment, the Python interpreter and the package
installer being chosen now. Use the installation guide from tool `make`.
Ubuntu 20.04 and 22.04 are no longer supported.
## Added
- Deploy ERPLibre VMs with QEMU/KVM from cloud images: Ubuntu, Debian, Fedora, AlmaLinux, Rocky, openSUSE, Arch, Linux Mint, and Debian on s390x. Hardware, branch and Odoo version are set per machine
- Proxmox VE as a deployment target, its installation including the reboot it needs
- A QEMU menu: network status and repair, 3D acceleration, a diagnostic report, file recovery from a VM that no longer boots, virt-viewer and a remote desktop tunnel
- An install dashboard and Textual forms: deploy, follow, update, restart or delete a VM without leaving the screen
- A mobile development VM: PyCharm, Android Studio, an Android emulator and an adb tunnel
- A VPN tool, five free technologies from the menu, the secrets in a KeePassXC vault and a diagnosis that names the failing stage
- Automated Odoo migration: the tool drives the whole run, goes back to a step, and repairs what a version bump leaves behind
- Migration review: a verdict per step, smoke tests on every public URL, and a filestore check
- A read-only analysis toolkit for an Odoo database, a backup zip included, with PostgreSQL index advice
- Anonymising a production copy without AI, and duplicating a database neutralised for good
- Development assistants installed inside a VM, and a Git and Shell menu that installs what a checkout needs
- A writing convention for what stays in git, held by a `pre-commit` and a `commit-msg` hook
- `long_test/` — tests that create real machines, nested QEMU and Proxmox included, kept out of the unit runner
- NTFY, Forgejo, a local git server, e-mail from the CLI, and SSH configuration with recursive ProxyJump
- The Python interpreter and the package installer are chosen, through EL_PYTHON_PROVIDER and EL_PIP_PROVIDER
- The OCA generative AI policy, Claude Code agents and commands, and the context an assistant is given, shown from the menu
- Unit tests with a bilingual test plan, navigation telemetry for TODO, and Odoo 18 reading STL files
## Changed
- todo.py split into nine files, one per subject, with a shared base per form
- Every menu entry carries an icon, the menus are grouped into sections, and a countdown prompt gives 15 seconds to decide
- Branch, profile, type and timezone are chosen per VM rather than globally
- Installation covers Fedora, Debian, Ubuntu, Arch and openSUSE; repository sync and Poetry run in parallel, quiet unless EL_VERBOSE asks
- Node.js 22 for Capacitor 8, flanker for Odoo 18, CybroOdoo extras opt-in, and a Poetry dependency declinable per architecture
- A VM boots faster and picks the fastest reachable mirror, Canadian pacman mirrors coming first on Arch
- Staging names the files, never `git add -A`
- Enter targets the highest supported Odoo version, and a VM name drops the `latest` segment
## Fixed
- The libvirt network no longer counts as its own collision, no longer leaves a host without network at the next boot, and its state is read in English whatever the locale
- QEMU deployment: sudo says why it needs a password, the `libvirt` group replaces it where it suffices, no host reboots unasked, and an orphan disk no longer blocks a creation
- Migration: the database drop, the account.root view Odoo 17 leaves behind, the pricelists a repair invented, and the assumptions the 13-to-18 run rested on
- Anonymisation respects what a value means, and no longer breaks past the 131 072-byte limit of a single argument
- Installation on Debian 13, Fedora, Ubuntu 26.04 and s390x: apt locks, missing compilers and headers, too little memory, and what a recent SWIG or PROJ needs
- Secrets: the KeePassXC vault opens on a server without tkinter, the forgejo installer stops echoing the password it set, and db_restore validates the master one
- A question is seen before it is answered, and one faulty repository no longer takes a whole batch down
- Three screens that fell over, a shrink that would have filled the disk, and a monitor that binned a VM before being sure
- The unit runner globs the whole directory, where it ran 1131 tests of 3703
- Proxmox no longer aims at the host instead of the VM
## Removed
- Ubuntu 20.04 and 22.04 support, on every architecture
- The residue check that called a language broken when its `active` is NULL
## Security
- Passwords and tokens are redacted before a command is displayed, logged or reprinted
- The Odoo master password and the KeePass one leave the command line, an environment variable carrying them instead
## [1.7.0] - 2026-03-11
**Migration notes**
Recreating the virtual environment, use installation guide from tool `make`.
## Added
- Support Odoo migration database and module with TODO
- Support multi version odoo switch on same workspace
- Script for hardening the installation
- Support Odoo versions 12.0 to 18.0
- Separate ERPLibre python installation from Odoo python with .venv.erplibre and .venv.odoo18
- Implement auto-installation with TODO.py
- TODO show documentation, download database, help with code formatting
- Performance script to mesure request per second
- Support Mainframe architecture 390x
- Deployment with Cloudflare and Nginx
- Support Apache configuration like Nginx
- Support RobotLibre code generator
- Support ERPLibre DevOps, automation procedure about DevOps
- ERPLibre Home Mobile Application, use TODO to compile, deploy it and personalize it
- Support Selenium grid from selenium_lib.py
- Add addons OnlyOffice, Cetmix, OCA automation, OCA shopfloor
- Odoo 12.0 to 18.0 in a single workspace, switched without reinstalling: the manifests, the configuration and the addons paths follow the version named in `.odoo-version`
- ERPLibre's Python separated from Odoo's — `.venv.erplibre` carries the repository's own tools, `.venv.odoo<version>` the server — so a tool of the repository no longer depends on the interpreter a given Odoo version imposes
- Auto-installation driven from TODO: the menu lays down the environment it needs, Poetry, the Google Repo manifests and the addons included, rather than printing a command to retype
- Migration of an Odoo database and its modules from TODO, `--neutralize` included, with the repair of the mail module that a move from PostgreSQL 17 to 18 leaves behind
- A hardening script for the installation
- The ERPLibre Home mobile application: TODO compiles it, deploys it, renames the software and changes its menu image
- The RobotLibre code generator, with the queue_job channels its configuration needs
- ERPLibre DevOps, and the automation procedure it describes
- The Selenium grid from `selenium_lib.py`: a KeePass vault opened for the run, file downloads, dark mode, video recording and a scenario library
- A performance script measuring the requests per second a website answers
- Deployment: Cloudflare DNS, nginx with a non-interactive certbot, Apache templates matching the nginx ones, and a systemd unit whose working directory is configurable
- The s390x mainframe architecture
- Addons OnlyOffice, Cetmix, OCA automation, OCA shopfloor, and the design-themes repository
- Database backup and erase commands, and a clearer restore naming
- A security check of the Python environment, from the menu
- TODO shows the documentation, downloads a database and helps with code formatting
- Killing an Odoo process by the port it holds, from the menu
- CLAUDE.md and the agent information document, so an assistant reads the repository's conventions instead of guessing them
- A FAQ entry on wkhtmltopdf for recent distributions
## Changed
- Docker support postgresql 18
- Format script search diff file into each repository
- Support neutralize database from Odoo
- Odoo 18.0 becomes the default version of a checkout
- Docker moves to PostgreSQL 18, with the matching client
- The documentation is bilingual, generated by mmg from the `.base.md` sources: a `.md` or `.fr.md` edited directly is lost at the next generation
- The TODO menus are grouped into sections, and the English text serves as the i18n key rather than a code of its own
- The formatting script looks for the changed files in every repository, hidden addons included, and skips a repository that is not installed
- Odoo runs on a custom database, and the menu configures queue_job as well as the SSH forwarding a remote instance needs
- Killing a process by port asks before acting, through an interactive menu
- Neutralising a database goes through Odoo's own `--neutralize`
- LinuxMint 22.3, Ubuntu 25.10, and macOS without Python 3.7
- Odoo 18 dependencies: tldextract, PyYAML, pdfminer.six, and cryptography at its latest version
- A make target runs the unit tests
- The Makefile is split: its commands live in `conf/`, and `Common.Makefile` extends it for a project of one's own
## Fixed
- The documentation accents, and the markdown generation running in parallel
- `git_tool` returns nothing instead of raising where `.git` is absent
- `poetry iscompatible` no longer crashes on a version carrying a letter, an alpha or a release candidate
- pymssql compiles again, and the Odoo 18 requirements leave pyssql out of a production install
- wkhtmltopdf is no longer offered where it does not exist: no package is published for s390x on Ubuntu 25.10
- Selenium: the snap Firefox path, a 60-second timeout when reaching for an element, execution in a private window, and a login that waits for Odoo 18
- The formatting script ignores the files and directories it must not touch
- `db_drop_all` runs its shell command, and the backup processing keeps the permissions of what it writes
- TODO: the first import, the regeneration of `.repo/local_manifests`, the database open dialog, and a missing Odoo version reported instead of a crash
- The code generator: creating a project, extracting a class carrying a selection, and reading a model through the Python 3.11 `ast` module rather than astor
- Docker: the duplicated Odoo 18 build target, and the compose file pinned to an image that works
## [1.6.0] - 2025-04-25
@ -491,7 +758,11 @@ Because addons repository has change, config file need to be updated.
- Support only python3.6 and python3.7, python3.8 causes error in runtime.
- **Ubuntu** : 24.04, 25.10, 26.04 — 20.04 and 22.04 are dropped, pikepdf requiring a qpdf 12.2 built in C++20
- **Linux Mint** : 22.3
- **Debian** : 12 (bookworm) and 13 (trixie)
- **Fedora** : 41 and later
- **AlmaLinux, Rocky Linux** : 9 and 10 — RHEL and CentOS Stream take the same path
- **openSUSE** : Leap 16.0 and Tumbleweed
- **Arch Linux** : rolling release
- **NixOS** : 25.11 — the dependencies are DECLARED in `conf/nixos/erplibre.nix` and applied by `nixos-rebuild`, where the four other families install them one command at a time
- **macOS** : through mise or pyenv
- **Windows** : through WSL or Docker
- **Architectures** : amd64, arm64 and s390x (IBM Z mainframe)
- **Ubuntu** : 24.04, 25.10, 26.04 — 20.04 et 22.04 sont retirées, pikepdf réclamant un qpdf 12.2 bâti en C++20
- **Linux Mint** : 22.3
- **Debian** : 12 (bookworm) et 13 (trixie)
- **Fedora** : 41 et suivantes
- **AlmaLinux, Rocky Linux** : 9 et 10 — RHEL et CentOS Stream empruntent le même chemin
- **openSUSE** : Leap 16.0 et Tumbleweed
- **Arch Linux** : rolling release
- **NixOS** : 25.11 — les dépendances y sont DÉCLARÉES dans `conf/nixos/erplibre.nix` puis appliquées par `nixos-rebuild`, là où les quatre autres familles les installent commande par commande
- **macOS** : par mise ou pyenv
- **Windows** : par WSL ou Docker
- **Architectures** : amd64, arm64 et s390x (mainframe IBM Z)
<!-- [en] -->
@ -229,6 +254,37 @@ make
<!-- [en] -->
`make` and `./install.sh` start TODO through the interpreter that can read it:
`.venv.erplibre` when it carries the right version, otherwise the system
`python3` when it is recent enough, otherwise the install itself — a system
older than `conf/python-erplibre-version` cannot parse the code, so it offers
the install rather than stopping on a syntax error. The install runs only on a
yes typed in a terminal (`o`, `oui`, `y` or `yes`); Enter alone, or no
terminal, means no. When the
environment is missing but the system Python suffices, TODO offers to run
`./script/install/install_erplibre.sh` (in a terminal) or prints that command. The install builds the environment
through `EL_PYTHON_PROVIDER` (mise or pyenv); an existing `.venv.erplibre` on
another Python version is DELETED and rebuilt, and whatever was installed in it
by hand goes with it.
<!-- [fr] -->
`make` et `./install.sh` lancent TODO par l'interpréteur capable de le lire :
`.venv.erplibre` quand il porte la bonne version, sinon le `python3` du système
s'il est assez récent, sinon l'installation elle-même — un système plus ancien
que `conf/python-erplibre-version` ne sait pas analyser le code, donc
l'installation est proposée plutôt que de s'arrêter sur une erreur de syntaxe.
Elle ne part que sur un oui tapé au terminal (`o`, `oui`, `y` ou `yes`) ;
Entrée seule, ou l'absence de terminal, vaut non. Quand
l'environnement manque mais que le Python du système suffit, TODO propose de
lancer `./script/install/install_erplibre.sh` (dans un terminal) ou affiche
cette commande. L'installation bâtit l'environnement par
`EL_PYTHON_PROVIDER` (mise ou pyenv) ; un `.venv.erplibre` existant sur une
autre version de Python est SUPPRIMÉ puis rebâti, et ce qu'on y avait posé à la
main part avec lui.
<!-- [en] -->
### Manually
Into Ubuntu, minimal dependency:
@ -276,11 +332,11 @@ cd ERPLibre
<!-- [en] -->
Support Ubuntu 20.04, 22.04, 24.04, 25.04 and OSX.
`make install_os` detects the distribution and picks the right dependency script: apt for Ubuntu, Linux Mint and Debian, dnf for Fedora and the RHEL family, zypper for openSUSE, pacman for Arch, and a declarative module for NixOS. See the supported platforms above.
<!-- [fr] -->
Support Ubuntu 20.04, 22.04, 24.04, 25.04 et OSX.
`make install_os` détecte la distribution et choisit le bon script de dépendances : apt pour Ubuntu, Linux Mint et Debian, dnf pour Fedora et la famille RHEL, zypper pour openSUSE, pacman pour Arch, et un module déclaratif pour NixOS. Voir les plateformes supportées ci-dessus.
- **Ubuntu** : 24.04, 25.10, 26.04 — 20.04 et 22.04 sont retirées, pikepdf réclamant un qpdf 12.2 bâti en C++20
- **Linux Mint** : 22.3
- **Debian** : 12 (bookworm) et 13 (trixie)
- **Fedora** : 41 et suivantes
- **AlmaLinux, Rocky Linux** : 9 et 10 — RHEL et CentOS Stream empruntent le même chemin
- **openSUSE** : Leap 16.0 et Tumbleweed
- **Arch Linux** : rolling release
- **NixOS** : 25.11 — les dépendances y sont DÉCLARÉES dans `conf/nixos/erplibre.nix` puis appliquées par `nixos-rebuild`, là où les quatre autres familles les installent commande par commande
- **macOS** : par mise ou pyenv
- **Windows** : par WSL ou Docker
- **Architectures** : amd64, arm64 et s390x (mainframe IBM Z)
# Installation en production
@ -113,6 +126,21 @@ make
```
`make` et `./install.sh` lancent TODO par l'interpréteur capable de le lire :
`.venv.erplibre` quand il porte la bonne version, sinon le `python3` du système
s'il est assez récent, sinon l'installation elle-même — un système plus ancien
que `conf/python-erplibre-version` ne sait pas analyser le code, donc
l'installation est proposée plutôt que de s'arrêter sur une erreur de syntaxe.
Elle ne part que sur un oui tapé au terminal (`o`, `oui`, `y` ou `yes`) ;
Entrée seule, ou l'absence de terminal, vaut non. Quand
l'environnement manque mais que le Python du système suffit, TODO propose de
lancer `./script/install/install_erplibre.sh` (dans un terminal) ou affiche
cette commande. L'installation bâtit l'environnement par
`EL_PYTHON_PROVIDER` (mise ou pyenv) ; un `.venv.erplibre` existant sur une
autre version de Python est SUPPRIMÉ puis rebâti, et ce qu'on y avait posé à la
main part avec lui.
### Manuellement
Sous Ubuntu, dépendance minimale :
@ -140,7 +168,7 @@ cd ERPLibre
```
Support Ubuntu 20.04, 22.04, 24.04, 25.04 et OSX.
`make install_os` détecte la distribution et choisit le bon script de dépendances : apt pour Ubuntu, Linux Mint et Debian, dnf pour Fedora et la famille RHEL, zypper pour openSUSE, pacman pour Arch, et un module déclaratif pour NixOS. Voir les plateformes supportées ci-dessus.
- **Ubuntu** : 24.04, 25.10, 26.04 — 20.04 and 22.04 are dropped, pikepdf requiring a qpdf 12.2 built in C++20
- **Linux Mint** : 22.3
- **Debian** : 12 (bookworm) and 13 (trixie)
- **Fedora** : 41 and later
- **AlmaLinux, Rocky Linux** : 9 and 10 — RHEL and CentOS Stream take the same path
- **openSUSE** : Leap 16.0 and Tumbleweed
- **Arch Linux** : rolling release
- **NixOS** : 25.11 — the dependencies are DECLARED in `conf/nixos/erplibre.nix` and applied by `nixos-rebuild`, where the four other families install them one command at a time
- **macOS** : through mise or pyenv
- **Windows** : through WSL or Docker
- **Architectures** : amd64, arm64 and s390x (IBM Z mainframe)
# Installation in production
@ -112,6 +124,20 @@ make
```
`make` and `./install.sh` start TODO through the interpreter that can read it:
`.venv.erplibre` when it carries the right version, otherwise the system
`python3` when it is recent enough, otherwise the install itself — a system
older than `conf/python-erplibre-version` cannot parse the code, so it offers
the install rather than stopping on a syntax error. The install runs only on a
yes typed in a terminal (`o`, `oui`, `y` or `yes`); Enter alone, or no
terminal, means no. When the
environment is missing but the system Python suffices, TODO offers to run
`./script/install/install_erplibre.sh` (in a terminal) or prints that command. The install builds the environment
through `EL_PYTHON_PROVIDER` (mise or pyenv); an existing `.venv.erplibre` on
another Python version is DELETED and rebuilt, and whatever was installed in it
by hand goes with it.
### Manually
Into Ubuntu, minimal dependency:
@ -139,7 +165,7 @@ cd ERPLibre
```
Support Ubuntu 20.04, 22.04, 24.04, 25.04 and OSX.
`make install_os` detects the distribution and picks the right dependency script: apt for Ubuntu, Linux Mint and Debian, dnf for Fedora and the RHEL family, zypper for openSUSE, pacman for Arch, and a declarative module for NixOS. See the supported platforms above.
description: "Write code in ERPLibre by the rules the repository actually enforces: Odoo/OCA module conventions first, then the real format and verify toolchain."
disable-model-invocation: true
effort: high
allowed-tools:
- Read
- Edit
- Write
- Grep
- Glob
- Bash(make format:*)
- Bash(make test_unit:*)
- Bash(make test_unit_file:*)
- Bash(./script/maintenance/:*)
- Bash(python3:*)
- Bash(git status:*)
- Bash(git diff:*)
- Bash(ls:*)
- Bash(cat:*)
---
## Context
- Odoo series in this checkout: !`cat .odoo-version`
- Available venvs: !`ls -d .venv.* 2>/dev/null`
- Branch and pending work: !`git status --porcelain`
- Addons trees: !`ls -d odoo*/addons/*/ 2>/dev/null | head -12`
## Task
Write code in this repository by the rules it ENFORCES, which are not always
the rules it documents. Establish them first, then write. The sections below
were read off the configuration files and the in-house modules, not off the
prose; where a document disagrees with a tool, the tool wins and the
disagreement is named.
### The effort tier
The `effort: high` above applies to this invocation — "comprehensive
implementation with extensive testing", the tier for code that has to survive
review.
A session can be pinned above it. `/effort ultracode` sets xhigh AND turns on
dynamic workflow orchestration, and a system-reminder then asks for a workflow
on every substantive task. That standing opt-in does not apply here: writing
one module correctly is one agent's job, and fanning it out multiplies both the
token cost and the ways the pieces disagree.
So when a reminder says ultracode is on, say in one line that this command
works at high, and ask the user to type `/effort high` — that one command sets
the tier and clears the ultracode flag in the same move. A command's
frontmatter cannot release a session pin; only the user's own `/effort` can,
from an interactive terminal. Work solo either way.
### 1. Before writing a line
**Find the tree.** New modules go under `odoo<VERSION>/addons/<Org>_<repo>/<module>/`
— the version-prefixed tree is the real addons root, and the generator
rewrites any `addons/` it is handed into `odoo<VERSION>/addons/`
(`script/code_generator/new_project.py:144-146`). The version is in
`.odoo-version`; the venv carries BOTH versions in its name, so find it with
`ls -d .venv.odoo*` rather than composing it from memory.
**Read the neighbours.** Two or three in-house modules under
`odoo<VERSION>/addons/ERPLibre_erplibre_addons/` show the conventions in force
better than any list. Copy their shape.
**Bootstrap rather than hand-roll.** `script/code_generator/new_project.py -d
<gitrootdir> -m <modulename>` creates a module; `create_from_existing_module.py`
clones one. A module cloned from an existing one INHERITS its comments and
docstrings — reread them before committing, a client or database name travels
that way on its own.
**Two rules bind every line you write**, and no tool checks either:
- Nothing identifying outside `private/` — no customer or third-party
organisation, no real database, host or VM name, no IP, e-mail or path
carrying an account name. Generalise to the class of situation instead.
- A comment says how the CODE works, in the present. A sentence whose subject
is an incident, a machine, a date or a person belongs in `tasks/`, which is
not versioned.
**Never edit a generated file.** `FICHIER.md` and `FICHIER.fr.md` come from
`FICHIER.base.md` through mmg; an edit is lost at the next `make doc_markdown`.
### 2. Odoo module conventions
`__manifest__.py` carries at minimum `name`, `version`, `author`, `license`,
`category`, `summary`, `depends`, `data`, `installable`. `version` is
`<series>.1.0.0` — `18.0.1.0.0` on an 18.0 checkout — and `license` is
`AGPL-3`, which every in-house module uses.
The `data` list is ordered `security/`, then `data/`, then `wizards/`, then
`views/`, with `views/menu.xml` last.
Non-Odoo Python requirements go in `external_dependencies: {"python": [...]}`,
and the import is guarded in the model with `try/except ImportError` logging at
debug level — a missing optional dependency must not break the registry.
description: "Plan a todo.py command at maximum effort: questions first, superpowers when installed, then the specification /todo_add_command implements."
Use that generated password when account setup asks for one — never the
account's normal password. The "Standard server" preset (generic IMAP/SMTP)
does not need one.
<!-- [fr] -->
### Mots de passe d'application pour Gmail, Outlook et iCloud
La phase 1 ne parle qu'IMAP/SMTP en authentification simple — pas encore
OAuth (ça, c'est la phase 2). Gmail, Outlook et iCloud ont tous les trois
fermé cette porte au vrai mot de passe du compte : chacun de ces trois
préréglages exige donc un **mot de passe d'application** à la place :
| Fournisseur | Où le générer |
|---|---|
| Gmail | Activez la validation en deux étapes, puis [myaccount.google.com](https://myaccount.google.com/security) > Sécurité > Mots de passe des applications |
| Outlook / Microsoft 365 | [account.microsoft.com](https://account.microsoft.com/security) > Sécurité > Options de sécurité avancées > Mots de passe d'application |
| iCloud | [account.apple.com](https://account.apple.com/) > Connexion et sécurité > Mots de passe spécifiques aux applications |
Utilisez ce mot de passe généré quand la configuration du compte en demande
un — jamais le mot de passe normal du compte. Le préréglage « Serveur
standard » (IMAP/SMTP générique) n'en a pas besoin.
<!-- [en] -->
## Adding an account
Menu path: `TODO > [3] Assistant > [2] Mail - Read and send email > [2]
Accounts > [2] Add an account`.
The prompts, in order:
1. **Short account name** — becomes both the folder name under
`~/.erplibre/mail/` and the vault reference, so it cannot contain `/` or
start with a dot.
2. **Email address**.
3. **Display name** (optional) — shown in the `From:` header as
`Display Name <email>`.
4. **Provider** — a number from the printed list: Gmail, Outlook, iCloud, or
"Standard server" (generic IMAP/SMTP).
5. If you picked "Standard server", the **IMAP host** and **SMTP host** are
asked next; the other presets fill these in for you.
6. If the preset requires an app password, its note is printed here as a
reminder.
7. **Password** — typed hidden (`getpass`), then stored — never written to
`accounts.json`.
Where the password goes: at the password step, the client hands off to the
CLI's shared **KDBX manager** — the same one already used for the OpenAI
key and Odoo credentials. It reads `kdbx.path` / `kdbx.password` from the
TODO config (`script/todo/todo.json`, overridable in
Si `kdbx.path` n'est pas encore réglé, une fenêtre de sélection de fichier
s'ouvre pour choisir un `.kdbx` existant — il faut un affichage graphique,
et l'annuler (ou lancer le CLI sans affichage) fait échouer la création du
compte avec « le fichier kdbx n'a pas pu être ouvert » (voir Dépannage).
**Réglez `kdbx.path` (et `kdbx.password`, pour éviter l'invite) avant
d'ajouter votre premier compte**, en pointant vers un coffre `.kdbx` que
vous avez déjà (créez-en un avec KeePassXC ou équivalent). Le trousseau
système ne sert que pour un compte dont la `secret_ref` le désigne déjà —
le menu écrit toujours les nouveaux comptes dans le coffre KDBX.
`accounts.json` (dans `~/.erplibre/mail/accounts.json`) ne contient jamais
qu'une `secret_ref` du genre `kdbx:ERPLibre/Mail/perso` — une référence,
jamais le secret. Il est sans danger à lire, à éditer à la main, ou à
mettre dans une sauvegarde privée.
<!-- [en] -->
## The three cache modes
Every account keeps a local cache — a small SQLite database plus one file
per downloaded message — so the inbox stays readable offline. Three modes
control what that cache leaves on disk:
| Mode | What's on disk | Encryption key |
|---|---|---|
| `clear` (default) | `~/.erplibre/mail/<account>/cache.db` and `.eml` files, readable as plain text | none |
| `encrypted` | same location, but sender, recipients, subject, snippet, message-id and message bodies are sealed with AES-256-GCM | generated once, stored in the vault next to the password (`.../cache-key`) |
| `ephemeral` | under `/dev/shm/erplibre-mail-<pid>/<account>/` (or the system temp dir if `/dev/shm` isn't writable), sealed the same way as `encrypted` | generated fresh in RAM at every run, never written anywhere, and the whole directory is removed when the session closes |
Even in `clear` mode, the technical fields the SQL needs to sort and
filter — UID, folder, date, flags, size — are always plain; only the
person-identifying fields (and the message body) are ever sealed, and only
in `encrypted`/`ephemeral`.
Set the **general default** at `Mail > [4] Cache > [1] Default cache mode`;
it is the `mail_cache_mode` preference (default `clear`). **Override it per
account** at `Mail > [4] Cache > [2] Cache mode of one account` — this
writes the account's `cache_mode` field in `accounts.json`; leaving it at
`null` there means "inherit the general default."
`Mail > [4] Cache > [3] Cache size and purge` lists every account's
effective mode and disk usage, and can erase one account's cache entirely
(after confirmation) — the next sync rebuilds it from scratch.
<!-- [fr] -->
## Les trois modes de cache
Chaque compte garde un cache local — une petite base SQLite plus un fichier
par message téléchargé — pour que la boîte de réception reste lisible hors
ligne. Trois modes contrôlent ce que ce cache laisse sur le disque :
| Mode | Ce qui reste sur le disque | Clé de chiffrement |
|---|---|---|
| `clear` (par défaut) | `~/.erplibre/mail/<compte>/cache.db` et les fichiers `.eml`, lisibles en clair | aucune |
| `encrypted` | même emplacement, mais l'expéditeur, les destinataires, le sujet, l'extrait, le Message-ID et le corps des messages sont scellés en AES-256-GCM | générée une fois, rangée dans le coffre à côté du mot de passe (`.../cache-key`) |
| `ephemeral` | sous `/dev/shm/erplibre-mail-<pid>/<compte>/` (ou le dossier temporaire système si `/dev/shm` n'est pas inscriptible), scellé comme `encrypted` | tirée en RAM à chaque lancement, jamais écrite nulle part, et tout le dossier est effacé à la fermeture de la session |
Même en mode `clear`, les champs techniques dont le SQL a besoin pour trier
et filtrer — UID, dossier, date, drapeaux, taille — restent toujours en
clair ; seuls les champs qui identifient des personnes (et le corps du
message) sont scellés, et seulement en `encrypted`/`ephemeral`.
Réglez le **défaut général** dans `Courriel > [4] Cache > [1] Mode de cache
par défaut` ; c'est la préférence `mail_cache_mode` (défaut `clear`).
**Surchargez-le par compte** dans `Courriel > [4] Cache > [2] Mode de cache
d'un compte` — ceci écrit le champ `cache_mode` du compte dans
`accounts.json` ; le laisser à `null` là-bas veut dire « hérite du défaut
général ».
`Courriel > [4] Cache > [3] Taille du cache et purge` liste le mode
effectif et l'espace disque de chaque compte, et peut effacer entièrement le
cache d'un compte (après confirmation) — la prochaine synchronisation le
reconstruit à partir de zéro.
<!-- [en] -->
## The TUI
`Mail > [1] Open the mail client (TUI)` opens a three-pane screen: an
account/folder tree on the left, the message list in the middle, and a
preview pane on the right, with a status line at the bottom.
| Key | Action |
|---|---|
| `↑``↓``Tab` | move within a pane / move focus between panes (Textual defaults) |
| `h` | open the help window: every shortcut plus a few notes, closed with `Escape` |
| `z` | toggle full-screen preview (hides the folder tree and the message list) |
| `Escape` | leave full-screen |
| `v` | cycle the layout: columns, split, stacked |
| `+` / `-` | grow / shrink the pane that has focus |
| `0` | back to the default pane sizes |
| `r` | sync the account of the currently selected folder (all its folders) |
| `Shift+R` | sync every account |
| `/` | open the search field (filters the currently visible list only — locally, over subject/from/to/snippet; it does not search the server) |
| `s` / `u` | mark the selected message seen / unseen |
| `c` | compose a new message |
| `a` / `Shift+A` | reply / reply all |
| `f` | forward |
| `w` | save the message's **first** attachment to `~/Téléchargements` (created if missing) |
| `n` | add an account without leaving the client |
| `l` | show the tail of `~/.erplibre/mail.log` and this session's sync errors |
| `q` | quit |
This table is written by hand and can fall behind the code; the `h` window
cannot. It builds its list from the application's own key bindings every time
it opens, so it is the reference if the two ever disagree.
The bars between the panes can also be dragged with the mouse, and pane sizes
are remembered per layout.
The footer's key hints, like the help window, follow the CLI's chosen
language, as do the account tree, the message list and the preview text.
<!-- [fr] -->
## Le TUI
`Courriel > [1] Ouvrir le client courriel (TUI)` ouvre un écran en trois
volets : l'arbre comptes/dossiers à gauche, la liste des messages au
centre, et un aperçu à droite, avec une ligne de statut en bas.
| Touche | Action |
|---|---|
| `↑``↓``Tab` | se déplacer dans un volet / changer de volet (comportement par défaut de Textual) |
| `h` | ouvre la fenêtre d'aide : tous les raccourcis et quelques repères, fermée par `Échap` |
| `z` | plein écran sur l'aperçu (masque l'arbre et la liste) |
| `~/.erplibre/mail/<account>/<folder>/<uid>.eml` (or `.eml.enc` when sealed) | one file per downloaded message body |
| `/dev/shm/erplibre-mail-<pid>/<account>/` | an `ephemeral` account's cache while the process is alive; removed when it exits (a sweep at every startup also clears directories left behind by a killed process) |
<!-- [fr] -->
## Où sont les fichiers
| Chemin | Contenu |
|---|---|
| `~/.erplibre/mail/accounts.json` | la liste des comptes — serveurs, préréglages, mode de cache, et une référence `secret_ref` ; jamais un mot de passe (mode 0600) |
| `~/.erplibre/mail/<compte>/cache.db` | le cache SQLite de ce compte (mode 0600, dossier parent 0700) |
| `~/.erplibre/mail/<compte>/<dossier>/<uid>.eml` (ou `.eml.enc` s'il est scellé) | un fichier par corps de message téléchargé |
| `/dev/shm/erplibre-mail-<pid>/<compte>/` | le cache d'un compte `ephemeral` pendant que le processus vit ; effacé à sa sortie (un balayage au démarrage nettoie aussi ce qu'un processus tué aurait laissé) |
<!-- [en] -->
## Troubleshooting
Error messages raised by the mail package itself (`secrets.py`,
### Mots de passe d'application pour Gmail, Outlook et iCloud
La phase 1 ne parle qu'IMAP/SMTP en authentification simple — pas encore
OAuth (ça, c'est la phase 2). Gmail, Outlook et iCloud ont tous les trois
fermé cette porte au vrai mot de passe du compte : chacun de ces trois
préréglages exige donc un **mot de passe d'application** à la place :
| Fournisseur | Où le générer |
|---|---|
| Gmail | Activez la validation en deux étapes, puis [myaccount.google.com](https://myaccount.google.com/security) > Sécurité > Mots de passe des applications |
| Outlook / Microsoft 365 | [account.microsoft.com](https://account.microsoft.com/security) > Sécurité > Options de sécurité avancées > Mots de passe d'application |
| iCloud | [account.apple.com](https://account.apple.com/) > Connexion et sécurité > Mots de passe spécifiques aux applications |
Utilisez ce mot de passe généré quand la configuration du compte en demande
un — jamais le mot de passe normal du compte. Le préréglage « Serveur
standard » (IMAP/SMTP générique) n'en a pas besoin.
## Ajouter un compte
Chemin de menu : `TODO > [3] Assistant > [2] Courriel - Lire et envoyer du
courriel > [2] Comptes > [2] Ajouter un compte`.
Les questions, dans l'ordre :
1. **Nom court du compte** — devient à la fois le nom de dossier sous
`~/.erplibre/mail/` et la référence dans le coffre : il ne peut donc pas
contenir `/` ni commencer par un point.
2. **Adresse courriel**.
3. **Nom affiché** (facultatif) — apparaît dans l'en-tête `De :` comme
`Nom affiché <email>`.
4. **Fournisseur** — un numéro dans la liste affichée : Gmail, Outlook,
iCloud, ou « Serveur standard » (IMAP/SMTP générique).
5. Si vous choisissez « Serveur standard », le **serveur IMAP** puis le
**serveur SMTP** sont demandés ensuite ; les autres préréglages les
remplissent déjà pour vous.
6. Si le préréglage exige un mot de passe d'application, sa note s'affiche
ici en rappel.
7. **Mot de passe** — saisi masqué (`getpass`), puis rangé dans le coffre —
jamais écrit dans `accounts.json`.
Où va le mot de passe : à l'étape du mot de passe, le client passe par le
**gestionnaire KDBX** partagé du CLI — le même que pour la clé OpenAI et
les identifiants Odoo. Il lit `kdbx.path` / `kdbx.password` dans la
configuration TODO (`script/todo/todo.json`, surchargeable dans
Si `kdbx.path` n'est pas encore réglé, une fenêtre de sélection de fichier
s'ouvre pour choisir un `.kdbx` existant — il faut un affichage graphique,
et l'annuler (ou lancer le CLI sans affichage) fait échouer la création du
compte avec « le fichier kdbx n'a pas pu être ouvert » (voir Dépannage).
**Réglez `kdbx.path` (et `kdbx.password`, pour éviter l'invite) avant
d'ajouter votre premier compte**, en pointant vers un coffre `.kdbx` que
vous avez déjà (créez-en un avec KeePassXC ou équivalent). Le trousseau
système ne sert que pour un compte dont la `secret_ref` le désigne déjà —
le menu écrit toujours les nouveaux comptes dans le coffre KDBX.
`accounts.json` (dans `~/.erplibre/mail/accounts.json`) ne contient jamais
qu'une `secret_ref` du genre `kdbx:ERPLibre/Mail/perso` — une référence,
jamais le secret. Il est sans danger à lire, à éditer à la main, ou à
mettre dans une sauvegarde privée.
## Les trois modes de cache
Chaque compte garde un cache local — une petite base SQLite plus un fichier
par message téléchargé — pour que la boîte de réception reste lisible hors
ligne. Trois modes contrôlent ce que ce cache laisse sur le disque :
| Mode | Ce qui reste sur le disque | Clé de chiffrement |
|---|---|---|
| `clear` (par défaut) | `~/.erplibre/mail/<compte>/cache.db` et les fichiers `.eml`, lisibles en clair | aucune |
| `encrypted` | même emplacement, mais l'expéditeur, les destinataires, le sujet, l'extrait, le Message-ID et le corps des messages sont scellés en AES-256-GCM | générée une fois, rangée dans le coffre à côté du mot de passe (`.../cache-key`) |
| `ephemeral` | sous `/dev/shm/erplibre-mail-<pid>/<compte>/` (ou le dossier temporaire système si `/dev/shm` n'est pas inscriptible), scellé comme `encrypted` | tirée en RAM à chaque lancement, jamais écrite nulle part, et tout le dossier est effacé à la fermeture de la session |
Même en mode `clear`, les champs techniques dont le SQL a besoin pour trier
et filtrer — UID, dossier, date, drapeaux, taille — restent toujours en
clair ; seuls les champs qui identifient des personnes (et le corps du
message) sont scellés, et seulement en `encrypted`/`ephemeral`.
Réglez le **défaut général** dans `Courriel > [4] Cache > [1] Mode de cache
par défaut` ; c'est la préférence `mail_cache_mode` (défaut `clear`).
**Surchargez-le par compte** dans `Courriel > [4] Cache > [2] Mode de cache
d'un compte` — ceci écrit le champ `cache_mode` du compte dans
`accounts.json` ; le laisser à `null` là-bas veut dire « hérite du défaut
général ».
`Courriel > [4] Cache > [3] Taille du cache et purge` liste le mode
effectif et l'espace disque de chaque compte, et peut effacer entièrement le
cache d'un compte (après confirmation) — la prochaine synchronisation le
reconstruit à partir de zéro.
## Le TUI
`Courriel > [1] Ouvrir le client courriel (TUI)` ouvre un écran en trois
volets : l'arbre comptes/dossiers à gauche, la liste des messages au
centre, et un aperçu à droite, avec une ligne de statut en bas.
| Touche | Action |
|---|---|
| `↑``↓``Tab` | se déplacer dans un volet / changer de volet (comportement par défaut de Textual) |
| `h` | ouvre la fenêtre d'aide : tous les raccourcis et quelques repères, fermée par `Échap` |
| `z` | plein écran sur l'aperçu (masque l'arbre et la liste) |
| `+` / `-` | agrandir / rétrécir le volet qui a le focus |
| `0` | revenir aux tailles de volets par défaut |
| `r` | synchronise le compte du dossier actuellement sélectionné (tous ses dossiers) |
| `Shift+R` | synchronise tous les comptes |
| `/` | ouvre le champ de recherche (filtre seulement la liste déjà affichée — localement, sur sujet/de/à/extrait ; ne cherche pas sur le serveur) |
| `s` / `u` | marquer le message sélectionné lu / non lu |
| `c` | écrire un nouveau message |
| `a` / `Shift+A` | répondre / répondre à tous |
| `f` | transférer |
| `w` | enregistrer la **première** pièce jointe du message dans `~/Téléchargements` (créé s'il n'existe pas) |
| `n` | ajouter un compte sans quitter le client |
| `l` | affiche la fin de `~/.erplibre/mail.log` et les erreurs de synchronisation de la session |
| `q` | quitter |
Ce tableau est écrit à la main et peut prendre du retard sur le code ; la
fenêtre `h`, elle, ne le peut pas : elle construit sa liste depuis les
liaisons de l'application à chaque ouverture. En cas de désaccord entre les
deux, c'est elle qui a raison.
Les barres entre les volets se glissent aussi à la souris, et les tailles
sont retenues par disposition.
Les indices de touches du pied d'écran, comme la fenêtre d'aide, suivent la
langue choisie dans le CLI, tout comme l'arbre des comptes, la liste et le
texte d'aperçu.
## Écrire un message
`c` ouvre le formulaire : `À`, `Cc`, `Objet`, un champ `Pièces jointes`
(chemins de fichiers séparés par un point-virgule — une virgule est légale
dans un nom de fichier, donc seul `;` sépare les entrées ; il n'y a pas de
sélecteur de fichier, tapez les chemins), et un corps multi-lignes.
`e` envoie le corps vers `$EDITOR` (ou `nano` si non défini) et le relit ;
si l'éditeur manque ou sort en erreur, le texte de départ est conservé tel
quel. `Ctrl+S` (ou le bouton Envoyer) remet le message ; `Échap` abandonne
le brouillon — il n'y a pas d'enregistrement en brouillon.
`a` (répondre) et `Shift+A` (répondre à tous) préremplissent `À`/`Cc`/
`Objet`/`In-Reply-To`/`References` et citent le message d'origine dans le
corps. `f` (transférer) préremplit l'objet en `Fwd:` et **rattache le
message d'origine** automatiquement, en pièce jointe `message/rfc822` ; le
corps, lui, part vide — écrivez votre propre mot au-dessus du message
joint.
Répondre, répondre à tous et transférer ont tous besoin du corps du message
d'origine — depuis le cache, ou récupéré en direct si le compte est en
ligne ; sans l'un ou l'autre, vous obtenez « Aucun message sélectionné. » /
« Aucun message à transférer. ».
Envoyer exige que le compte soit en ligne (écrire hors ligne échoue avec
« Compte hors ligne : envoi impossible. » — il n'y a pas de file d'attente
hors ligne). Une fois envoyé, une copie est classée dans le dossier
Envoyés du compte par IMAP ; si ce classement échoue, la ligne de statut le
dit, mais le message est déjà parti — il n'est pas renvoyé.
## Synchronisation
Une passe de synchronisation est incrémentale : seuls les UID supérieurs au
dernier connu sont demandés, le corps des messages n'est jamais téléchargé
pendant une passe (seulement les en-têtes), et les corps sont récupérés à
la demande à l'ouverture d'un message. Les drapeaux (lu/non lu, etc.) des
messages déjà connus sont revérifiés à chaque passe, donc un message lu
ailleurs apparaît correctement lu ici aussi.
La synchronisation a lieu :
- **Au lancement** — ouvrir le TUI déclenche une synchronisation de tous
les comptes en arrière-plan.
- **À la demande** — `r` (compte courant) / `Shift+R` (tous les comptes)
dans le TUI, ou `Courriel > [3] Synchroniser maintenant` depuis le menu
CLI (affiche un résumé par compte dans le terminal).
- **Automatiquement, toutes les `mail_refresh_sec` secondes** (défaut 300 =
5 minutes ; 0 la désactive) — **mais seulement tant que le TUI est
ouvert**. Fermez-le et la minuterie part avec lui ; rien ne se
synchronise en arrière-plan ensuite.
Si le serveur annonce un `UIDVALIDITY` changé pour un dossier (ses UID ne
veulent plus dire ce qu'ils disaient — typiquement après une migration
côté serveur), le cache de ce dossier est purgé et resynchronisé à partir
de zéro automatiquement ; il n'y a actuellement aucun avis à l'écran
au-delà du dossier qui se vide puis se remplit à nouveau brièvement.
## Où sont les fichiers
| Chemin | Contenu |
|---|---|
| `~/.erplibre/mail/accounts.json` | la liste des comptes — serveurs, préréglages, mode de cache, et une référence `secret_ref` ; jamais un mot de passe (mode 0600) |
| `~/.erplibre/mail/<compte>/cache.db` | le cache SQLite de ce compte (mode 0600, dossier parent 0700) |
| `~/.erplibre/mail/<compte>/<dossier>/<uid>.eml` (ou `.eml.enc` s'il est scellé) | un fichier par corps de message téléchargé |
| `/dev/shm/erplibre-mail-<pid>/<compte>/` | le cache d'un compte `ephemeral` pendant que le processus vit ; effacé à sa sortie (un balayage au démarrage nettoie aussi ce qu'un processus tué aurait laissé) |
## Dépannage
Les messages d'erreur qui viennent du paquet courriel lui-même
If `kdbx.path` isn't set yet, a graphical file picker pops up asking you to
choose an existing `.kdbx` file — it needs a display, and cancelling it (or
running headless) fails account creation with "le fichier kdbx n'a pas pu
être ouvert" (French — see Troubleshooting). **Set `kdbx.path` (and
`kdbx.password`, to skip the prompt) before adding your first account**,
pointing at a `.kdbx` vault you already have (create one with KeePassXC or
similar). The system keyring is only ever used for an account whose
`secret_ref` already points at one — the menu itself always writes new
accounts into the KDBX vault.
`accounts.json` (at `~/.erplibre/mail/accounts.json`) only ever holds a
`secret_ref` such as `kdbx:ERPLibre/Mail/perso` — a pointer, never the
secret. It is safe to read, edit by hand, or check into a private backup.
## The three cache modes
Every account keeps a local cache — a small SQLite database plus one file
per downloaded message — so the inbox stays readable offline. Three modes
control what that cache leaves on disk:
| Mode | What's on disk | Encryption key |
|---|---|---|
| `clear` (default) | `~/.erplibre/mail/<account>/cache.db` and `.eml` files, readable as plain text | none |
| `encrypted` | same location, but sender, recipients, subject, snippet, message-id and message bodies are sealed with AES-256-GCM | generated once, stored in the vault next to the password (`.../cache-key`) |
| `ephemeral` | under `/dev/shm/erplibre-mail-<pid>/<account>/` (or the system temp dir if `/dev/shm` isn't writable), sealed the same way as `encrypted` | generated fresh in RAM at every run, never written anywhere, and the whole directory is removed when the session closes |
Even in `clear` mode, the technical fields the SQL needs to sort and
filter — UID, folder, date, flags, size — are always plain; only the
person-identifying fields (and the message body) are ever sealed, and only
in `encrypted`/`ephemeral`.
Set the **general default** at `Mail > [4] Cache > [1] Default cache mode`;
it is the `mail_cache_mode` preference (default `clear`). **Override it per
account** at `Mail > [4] Cache > [2] Cache mode of one account` — this
writes the account's `cache_mode` field in `accounts.json`; leaving it at
`null` there means "inherit the general default."
`Mail > [4] Cache > [3] Cache size and purge` lists every account's
effective mode and disk usage, and can erase one account's cache entirely
(after confirmation) — the next sync rebuilds it from scratch.
## The TUI
`Mail > [1] Open the mail client (TUI)` opens a three-pane screen: an
account/folder tree on the left, the message list in the middle, and a
preview pane on the right, with a status line at the bottom.
| Key | Action |
|---|---|
| `↑``↓``Tab` | move within a pane / move focus between panes (Textual defaults) |
| `h` | open the help window: every shortcut plus a few notes, closed with `Escape` |
| `z` | toggle full-screen preview (hides the folder tree and the message list) |
| `Escape` | leave full-screen |
| `v` | cycle the layout: columns, split, stacked |
| `+` / `-` | grow / shrink the pane that has focus |
| `0` | back to the default pane sizes |
| `r` | sync the account of the currently selected folder (all its folders) |
| `Shift+R` | sync every account |
| `/` | open the search field (filters the currently visible list only — locally, over subject/from/to/snippet; it does not search the server) |
| `s` / `u` | mark the selected message seen / unseen |
| `c` | compose a new message |
| `a` / `Shift+A` | reply / reply all |
| `f` | forward |
| `w` | save the message's **first** attachment to `~/Téléchargements` (created if missing) |
| `n` | add an account without leaving the client |
| `l` | show the tail of `~/.erplibre/mail.log` and this session's sync errors |
| `q` | quit |
This table is written by hand and can fall behind the code; the `h` window
cannot. It builds its list from the application's own key bindings every time
it opens, so it is the reference if the two ever disagree.
The bars between the panes can also be dragged with the mouse, and pane sizes
are remembered per layout.
The footer's key hints, like the help window, follow the CLI's chosen
language, as do the account tree, the message list and the preview text.
## Writing a message
`c` opens the compose form: `To`, `Cc`, `Subject`, an `Attachments` field
(semicolon-separated file paths — a comma is legal in a filename, so only
`;` splits entries; there is no file picker, type the paths), and a
multi-line body. `e` sends the body out to `$EDITOR` (or
`nano` if unset) and reads it back; if the editor is missing or exits with
an error, the body you had is kept untouched. `Ctrl+S` (or the Send button)
delivers the message; `Escape` discards the draft — there is no
save-as-draft.
`a` (reply) and `Shift+A` (reply all) prefill `To`/`Cc`/`Subject`/
`In-Reply-To`/`References` and quote the original message in the body. `f`
(forward) prefills the `Fwd:` subject and **attaches the original message**
automatically, as a `message/rfc822` attachment; the body itself starts
empty — write your own note above the attached original.
Reply, reply-all and forward all need the original message's body
available — from the cache, or fetched live if the account is online; with
neither, you get "No message selected." / "No message to forward."
Sending requires the account to be online (composing offline fails with
"Account offline: cannot send." — there is no offline outbox). Once sent, a
copy is filed into the account's Sent folder over IMAP; if that filing step
fails, the status line says so, but the message has already left — it is
not resent.
## Synchronization
A sync pass is incremental: only UIDs above the last known one are
fetched, message bodies are never downloaded during a pass (only headers),
and bodies are fetched on demand when you open a message. Flags
(read/unread, etc.) of already-known messages are re-checked on every
pass, so a message read elsewhere shows up correctly here too.
Sync happens:
- **At launch** — opening the TUI kicks off one background sync of every
| `~/.erplibre/mail/<account>/<folder>/<uid>.eml` (or `.eml.enc` when sealed) | one file per downloaded message body |
| `/dev/shm/erplibre-mail-<pid>/<account>/` | an `ephemeral` account's cache while the process is alive; removed when it exits (a sweep at every startup also clears directories left behind by a killed process) |
## Troubleshooting
Error messages raised by the mail package itself (`secrets.py`,
Si vous ne pouvez pas installer wkhtmltopdf, vous pouvez exécuter un Docker et mettre à jour la configuration, consultez le dépôt https://github.com/acsone/kwkhtmltopdf
A guide on how to set up a workspace and run ERPLibre on Windows 10 version 2004 and up or Windows 11. There are two methods of installation, one is automatic and the other manual.
**"WSL2 Ubuntu 22.04" will be referred as "WSL2"**
**"WSL2 Ubuntu 24.04" will be referred as "WSL2"**
**"PyCharm Professional" will be referred as "PyCharm"**
@ -21,7 +21,7 @@ Run Powershell with administrator rights and run the following command:
Un guide pour configurer un espace de travail et exécuter ERPLibre sur Windows 10 version 2004 et plus ou Windows 11. Il existe deux méthodes d'installation, une automatique et l'autre manuelle.
**"WSL2 Ubuntu 22.04" sera désigné par "WSL2"**
**"WSL2 Ubuntu 24.04" sera désigné par "WSL2"**
**"PyCharm Professional" sera désigné par "PyCharm"**
@ -31,7 +31,7 @@ Exécutez Powershell avec les droits administrateur et lancez la commande suivan
Select `Connect to WSL` under `Remote Development`. After that select your Ubuntu instace ("Ubuntu-22.04"). Point `Project directory` to the root of the project. Once everything has been selected and filled out correctly, click on `Start IDE and Connect`.
Select `Connect to WSL` under `Remote Development`. After that select your Ubuntu instace ("Ubuntu-24.04"). Point `Project directory` to the root of the project. Once everything has been selected and filled out correctly, click on `Start IDE and Connect`.
<!-- [fr] -->
### Configurer Pycharm
Sélectionnez `Connect to WSL` sous `Remote Development`. Ensuite sélectionnez votre instance Ubuntu ("Ubuntu-22.04"). Pointez `Project directory` vers la racine du projet. Une fois que tout a été sélectionné et rempli correctement, cliquez sur `Start IDE and Connect`.
Sélectionnez `Connect to WSL` sous `Remote Development`. Ensuite sélectionnez votre instance Ubuntu ("Ubuntu-24.04"). Pointez `Project directory` vers la racine du projet. Une fois que tout a été sélectionné et rempli correctement, cliquez sur `Start IDE and Connect`.
<!-- [common] -->
@ -439,6 +439,10 @@ If these last steps to set up your development environment were unsuccessful, fo
## Manual Installation
This system interpreter only needs to reach `make` (Python 3.10 or later).
`.venv.erplibre` is built on its own version, `conf/python-erplibre-version`,
through `EL_PYTHON_PROVIDER` (mise or pyenv).
### Install Python 3.10.14
You can delete the files that are left over in your home directory regarding the python installation when the steps have been completed succesfully.
@ -447,6 +451,10 @@ Si ces dernières étapes pour configurer votre environnement de développement
## Installation manuelle
Cet interpréteur système ne sert qu'à atteindre `make` (Python 3.10 ou plus).
`.venv.erplibre` est bâti sur sa propre version, `conf/python-erplibre-version`,
par `EL_PYTHON_PROVIDER` (mise ou pyenv).
### Installer Python 3.10.14
Vous pouvez supprimer les fichiers restants dans votre répertoire personnel concernant l'installation de Python une fois les étapes complétées avec succès.
Un guide pour configurer un espace de travail et exécuter ERPLibre sur Windows 10 version 2004 et plus ou Windows 11. Il existe deux méthodes d'installation, une automatique et l'autre manuelle.
**"WSL2 Ubuntu 22.04" sera désigné par "WSL2"**
**"WSL2 Ubuntu 24.04" sera désigné par "WSL2"**
**"PyCharm Professional" sera désigné par "PyCharm"**
@ -12,7 +12,7 @@ Un guide pour configurer un espace de travail et exécuter ERPLibre sur Windows
Exécutez Powershell avec les droits administrateur et lancez la commande suivante :
```bash
wsl --install -d Ubuntu-22.04
wsl --install -d Ubuntu-24.04
```
Si vous avez des difficultés à ouvrir Powershell avec les droits administrateur, appuyez sur `Windows + R`, entrez la ligne suivante et appuyez sur `OK`. Les droits administrateur vous seront automatiquement demandés.
Sélectionnez `Connect to WSL` sous `Remote Development`. Ensuite sélectionnez votre instance Ubuntu ("Ubuntu-22.04"). Pointez `Project directory` vers la racine du projet. Une fois que tout a été sélectionné et rempli correctement, cliquez sur `Start IDE and Connect`.
Sélectionnez `Connect to WSL` sous `Remote Development`. Ensuite sélectionnez votre instance Ubuntu ("Ubuntu-24.04"). Pointez `Project directory` vers la racine du projet. Une fois que tout a été sélectionné et rempli correctement, cliquez sur `Start IDE and Connect`.
@ -236,6 +236,10 @@ Si ces dernières étapes pour configurer votre environnement de développement
## Installation manuelle
Cet interpréteur système ne sert qu'à atteindre `make` (Python 3.10 ou plus).
`.venv.erplibre` est bâti sur sa propre version, `conf/python-erplibre-version`,
par `EL_PYTHON_PROVIDER` (mise ou pyenv).
### Installer Python 3.10.14
Vous pouvez supprimer les fichiers restants dans votre répertoire personnel concernant l'installation de Python une fois les étapes complétées avec succès.
A guide on how to set up a workspace and run ERPLibre on Windows 10 version 2004 and up or Windows 11. There are two methods of installation, one is automatic and the other manual.
**"WSL2 Ubuntu 22.04" will be referred as "WSL2"**
**"WSL2 Ubuntu 24.04" will be referred as "WSL2"**
**"PyCharm Professional" will be referred as "PyCharm"**
@ -12,7 +12,7 @@ A guide on how to set up a workspace and run ERPLibre on Windows 10 version 2004
Run Powershell with administrator rights and run the following command:
```bash
wsl --install -d Ubuntu-22.04
wsl --install -d Ubuntu-24.04
```
If you have trouble opening the Powershell with administrator rights, press `Windows + R`, enter the following line and press `OK`. You will be automatically prompted for administrator rights.
Select `Connect to WSL` under `Remote Development`. After that select your Ubuntu instace ("Ubuntu-22.04"). Point `Project directory` to the root of the project. Once everything has been selected and filled out correctly, click on `Start IDE and Connect`.
Select `Connect to WSL` under `Remote Development`. After that select your Ubuntu instace ("Ubuntu-24.04"). Point `Project directory` to the root of the project. Once everything has been selected and filled out correctly, click on `Start IDE and Connect`.
@ -236,6 +236,10 @@ If these last steps to set up your development environment were unsuccessful, fo
## Manual Installation
This system interpreter only needs to reach `make` (Python 3.10 or later).
`.venv.erplibre` is built on its own version, `conf/python-erplibre-version`,
through `EL_PYTHON_PROVIDER` (mise or pyenv).
### Install Python 3.10.14
You can delete the files that are left over in your home directory regarding the python installation when the steps have been completed succesfully.
