Run against stage 2's output for the first time, the check reported:
python 17 x s390x-linux-gnu/
filesystem 11 x usr/local/
Both are correct. CPython names two paths after the build triplet on every
platform -- the Arch x86_64 package ships
_sysconfigdata__linux_x86_64-linux-gnu.py and config-3.14-x86_64-linux-gnu/ --
so the triplet there is CPython's convention, not Debian's layout leaking in. And
creating /usr/local's skeleton is what the filesystem package exists for; the FHS
requires those directories.
Exempted by (package, pattern) pair rather than by package, so python is still
checked for lib64 and dist-packages and filesystem for multiarch. A blanket
exemption is how a real leak gets waved through -- and this check has now
condemned correct code three times: the tcl8.6 grep in sqlite's hook, the
intolerant-rm guard in systemd's, and this.
With the exemptions, stage 2's 209 packages pass: no multiarch, no lib64, no
dist-packages, no usr/local.
--- FR ---
Passé pour la première fois sur la production de l'étage 2, le test signalait :
python 17 x s390x-linux-gnu/
filesystem 11 x usr/local/
Les deux sont justes. CPython nomme deux chemins d'après le triplet de
construction sur toute plateforme — le paquet Arch x86_64 livre
_sysconfigdata__linux_x86_64-linux-gnu.py et config-3.14-x86_64-linux-gnu/ — le
triplet y est donc une convention de CPython, non la disposition de Debian qui
s'infiltre. Et créer le squelette de /usr/local est la raison d'être du paquet
filesystem ; le FHS l'exige.
Exemptés par couple (paquet, motif) et non par paquet : python reste contrôlé pour
lib64 et dist-packages, filesystem pour le multiarch. Une exemption globale est la
façon dont une vraie fuite passe — et ce test a désormais condamné du code juste
trois fois : le grep tcl8.6 du hook sqlite, le garde rm de celui de systemd, et
ceci.
Avec les exemptions, les 209 paquets de l'étage 2 passent : ni multiarch, ni
lib64, ni dist-packages, ni usr/local.
Assisted-by: Claude Opus 5
python-build, python-wheel and python-pyproject-hooks were built on the host,
reported OK, and installed everything under usr/lib/python3/dist-packages --
Debian's name for site-packages. Our python 3.14 never looks there, so every
module in them was unreachable. Nothing about them looked wrong.
Their package() computes install paths from the RUNNING python:
local site_packages=$(python -c "import site; print(site.getsitepackages()[0])")
rm "$pkgdir/$site_packages/$_name"/*.exe
which is why the other three in the same batch FAILED -- on `rm` finding
nothing. Those failures were protective. All six are built by stage 2 now, where
python is ours; a stage-1 run is expected to report them as failed, like libxslt.
The ARTEFACT check said the repository was clean throughout, truthfully: it only
ever asked about C library directories. It now also counts dist-packages and
usr/local paths, so the next time this happens it says so.
--- FR ---
python-build, python-wheel et python-pyproject-hooks ont été bâtis sur l'hôte,
déclarés OK, et ont tout installé sous usr/lib/python3/dist-packages — le nom
Debian de site-packages. Notre python 3.14 n'y regarde jamais : chaque module
était inatteignable. Rien en eux n'avait l'air faux.
Leur package() calcule les chemins depuis le python COURANT :
local site_packages=$(python -c "import site; print(site.getsitepackages()[0])")
rm "$pkgdir/$site_packages/$_name"/*.exe
d'où l'échec des trois autres du même lot — sur un `rm` qui ne trouvait rien. Ces
échecs étaient protecteurs. Les six sont désormais bâtis par l'étage 2, où le
python est le nôtre ; une passe d'étage 1 doit les déclarer en échec, comme
libxslt.
Le test ARTEFACT affirmait un dépôt propre, véridiquement : il n'interrogeait que
les répertoires de bibliothèques C. Il compte maintenant aussi dist-packages et
usr/local, pour le dire la prochaine fois.
Assisted-by: Claude Opus 5
libxslt reported
configure: error: Package requirements (python-3.14) were not met:
Package 'python-3.14' not found
with python 3.14.7 installed and /usr/lib/pkgconfig/python-3.14.pc present. The
chain, none of whose links resembles the others:
binutils installs libiberty.a into /usr/lib64, because s390x's default
MULTILIB_OSDIRNAME is lib64, creating that path as a REAL directory. meson
chooses its default libdir by inspecting the system, and 64-bit plus a real
/usr/lib64 means lib64 -- a symlink does not count, which is why Arch never
sees this and arch-meson passes no --libdir at all. pkgconf is a meson
package, so it installed there and COMPILED IN /usr/lib64/pkgconfig as its
search path. Every .pc in the distribution is in /usr/lib/pkgconfig.
Fixed at all three levels: binutils pinned to --libdir=/usr/lib, the chroot's
arch-meson wrapper pins --libdir lib as a backstop, and the ARTEFACT check --
which said "no Debian multiarch libdir anywhere", truthfully and uselessly --
now also counts paths under usr/lib64.
--- FR ---
libxslt annonçait
configure: error: Package requirements (python-3.14) were not met:
Package 'python-3.14' not found
avec python 3.14.7 installé et /usr/lib/pkgconfig/python-3.14.pc bien présent.
La chaîne, dont aucun maillon ne ressemble aux autres :
binutils dépose libiberty.a dans /usr/lib64, le MULTILIB_OSDIRNAME par défaut
de s390x, et crée donc ce chemin comme VRAI répertoire. meson choisit son
libdir par défaut en inspectant le système : 64 bits plus un vrai /usr/lib64
donne lib64 — un lien ne compte pas, d'où le fait qu'Arch ne voit jamais cela
et qu'arch-meson ne passe aucun --libdir. pkgconf étant un paquet meson, il
s'y est installé et a COMPILÉ /usr/lib64/pkgconfig comme chemin de recherche.
Or tous les .pc de la distribution sont dans /usr/lib/pkgconfig.
Corrigé aux trois niveaux : binutils épinglé à --libdir=/usr/lib, l'enveloppe
arch-meson du chroot épingle --libdir lib en filet, et le test ARTEFACT — qui
répondait « aucun libdir multiarch Debian », véridiquement et inutilement —
compte désormais aussi les chemins sous usr/lib64.
Assisted-by: Claude Opus 5
The soname check reported seventeen missing libraries. Four were false: it
built its "shipped" set from DT_SONAME alone, and tcl's libtcl9.0.so records
no SONAME at all. The file sits in usr/lib and ld.so resolves it by name, so
the check was calling a correct package broken -- which would have sent the
next reader hunting for a packaging bug that does not exist. Shipped filenames
and symlinks now count as supplied.
The remaining twelve needed separating, because an unclassified list is only
alarming. A missing soname whose library exists at a DIFFERENT version is
stage 1 working as designed: it linked the host, and stage 2 dissolves it. A
missing soname with no provider at any version is a closure gap. Nine and
three.
The three are each understood: pylibmount's cp313 extension (inert, no python
is shipped), makedb's libselinux (deliberate), and libtcl8.6 against our tcl
9.0 -- which is the honest cost of a decision made an hour before on closure
size without looking at ABI.
TODO.md records all twelve, with the note that stage 2 must install using the
host's pacman, because pacman inside the stage-1 rootfs cannot start.
--- FR ---
La vérification de sonames annonçait dix-sept bibliothèques manquantes. Quatre
étaient fausses : elle construisait son ensemble « livré » à partir du seul
DT_SONAME, et le libtcl9.0.so de tcl n'enregistre aucun SONAME. Le fichier est
dans usr/lib et ld.so le résout par son nom : la vérification déclarait donc
défectueux un paquet correct — de quoi envoyer le lecteur suivant chasser un
défaut d'empaquetage inexistant. Les noms de fichiers et les liens livrés
comptent désormais comme fournis.
Les douze restants demandaient d'être séparés, une liste non classée n'étant
qu'alarmante. Un soname manquant dont la bibliothèque existe à une AUTRE
version, c'est l'étage 1 fonctionnant comme prévu : il a lié l'hôte, et
l'étage 2 le dissout. Un soname sans aucun fournisseur est un trou de
fermeture. Neuf et trois.
Les trois sont compris : l'extension cp313 de pylibmount (inerte, aucun python
livré), le libselinux de makedb (délibéré), et libtcl8.6 contre notre tcl 9.0
— coût honnête d'une décision prise une heure plus tôt sur la taille de la
fermeture, sans regarder l'ABI.
TODO.md consigne les douze, avec la note que l'étage 2 devra installer avec le
pacman de l'hôte, celui du rootfs d'étage 1 ne pouvant pas démarrer.
Assisted-by: Claude Opus 5
The resolver reported satisfied. The rootfs installed 102 packages. bash,
coreutils, tar, sed and find all ran inside the chroot, on s390x, against
glibc 2.44. Every check passed.
Then a fourth check, reading ELF headers instead of metadata, found seventeen
libraries that some shipped binary asks for and no shipped package provides.
Most are the ordinary stage-1 artefact -- the host's soname where Arch's
differs, libgpgme.so.11 against our .45 -- and stage 2 dissolves those by
rebuilding inside the chroot.
One was not. kbd's loadkeys needed libxkbcommon.so.0 while kbd declared
glibc, gzip and pam. An UNDER-DECLARED dependency: invisible to pacman's
resolver and to this port's own closure computation, because both read
declarations. And the cause was mine -- libxkbcommon-dev went into
install_host_deps for systemd, and kbd, built later, probed for it and linked
it. Arch declares it nowhere, so its chroot fails the same probe;
--disable-xkb converges rather than diverges.
Also here: the test now uses its own package cache. The shared one held a
coreutils from before its selinux fix, at the same pkgver-pkgrel, and pacman
called it corrupted.
--- FR ---
Le résolveur se déclarait satisfait. Le rootfs installait 102 paquets. bash,
coreutils, tar, sed et find tournaient tous dans le chroot, sur s390x, contre
la glibc 2.44. Toutes les vérifications passaient.
Puis une quatrième, lisant les en-têtes ELF au lieu des métadonnées, a trouvé
dix-sept bibliothèques qu'un binaire livré réclame et qu'aucun paquet livré ne
fournit. La plupart sont l'artefact ordinaire de l'étage 1 — le soname de
l'hôte là où celui d'Arch diffère, libgpgme.so.11 contre notre .45 — et
l'étage 2 les dissout en reconstruisant dans le chroot.
Une ne l'était pas. Le loadkeys de kbd réclamait libxkbcommon.so.0 quand kbd
déclarait glibc, gzip et pam. Une dépendance SOUS-DÉCLARÉE : invisible au
résolveur de pacman comme au calcul de fermeture de ce portage, puisque tous
deux lisent des déclarations. Et la cause était mienne — libxkbcommon-dev est
entré dans install_host_deps pour systemd, et kbd, bâti plus tard, l'a sondé
et lié. Arch ne le déclare nulle part, son chroot échoue donc à la même
sonde ; --disable-xkb converge au lieu de diverger.
Aussi ici : le test utilise désormais son propre cache de paquets. Le cache
partagé gardait un coreutils d'avant son correctif selinux, au même
pkgver-pkgrel, et pacman le déclarait corrompu.
Assisted-by: Claude Opus 5
Sixty-eight successful builds said nothing true about whether the port
worked. One chroot found the missing dynamic linker and the missing
packages in a single run -- and it was done by hand, so "is it still true?"
had no cheap answer.
Three checks, kept apart because they fail for different reasons. RESOLVE
runs pacman's own resolver with --nodeps OFF, the check the whole bootstrap
skips. ARTEFACT greps every package for host contamination that raises no
error. RUN installs for real and executes the binaries -- the only one that
can catch an absent ld.so, since a package whose interpreter is missing
installs perfectly.
It earned itself immediately. ARTEFACT is clean across all 86 packages, and
RESOLVE named the next milestone precisely: about forty packages are still
missing, from pcre2 and libxcrypt to python and perl.
--- FR ---
Soixante-huit compilations réussies n'ont rien dit de vrai sur le
fonctionnement du portage. Un seul chroot a trouvé l'interpréteur dynamique
absent et les paquets manquants — et il avait été fait à la main, si bien
que « est-ce toujours vrai ? » n'avait pas de réponse bon marché.
Trois vérifications, tenues séparées parce qu'elles échouent pour des
raisons différentes. RESOLVE lance le résolveur de pacman avec --nodeps
DÉSACTIVÉ, le contrôle que tout l'amorçage saute. ARTEFACT inspecte chaque
paquet pour les contaminations de l'hôte qui ne lèvent aucune erreur. RUN
installe pour de vrai et exécute les binaires — seul capable de détecter un
ld.so absent, puisqu'un paquet dont l'interpréteur manque s'installe
parfaitement.
Il s'est rentabilisé aussitôt. ARTEFACT est propre sur les 86 paquets, et
RESOLVE a nommé l'étape suivante avec précision : une quarantaine de paquets
manquent encore, de pcre2 et libxcrypt jusqu'à python et perl.
Assisted-by: Claude Opus 5
