Rust is not optional. ERPLibre's poetry.lock requires cryptography 46.0.5 with
optional = false, plus jiter, orjson, pydantic-core and rpds-py -- all of which
build Rust from source where no wheel exists, and none exists for s390x. Without
Rust, `pip install cryptography` fails and ERPLibre does not start.
The bootstrap cycle is not the obstacle it looks like: rust-1.90.0 ships an
official s390x-unknown-linux-gnu tarball, verified with HTTP 200, and the host
already carries rustc 1.85.1. What costs is llvm and clang.
Measured before choosing, the way glib2 and iproute2 were: beyond what this port
already has, llvm and clang want libedit, python-psutil, python-sphinx and
python-myst-parser. The last two are documentation only, and behind them sit
docutils, babel, pygments, snowballstemmer, imagesize, alabaster, the
sphinxcontrib family, markdown-it-py and mdit-py-plugins -- some fifteen packages
to render HTML for a compiler whose manual nothing here reads.
-DLLVM_ENABLE_SPHINX=OFF removes all of it.
Their package() ends on `rm -r .../html/{_sources,.buildinfo}`, which Sphinx
creates. Seventeenth appearance of that shape, and the FIRST found before the
build rather than after -- the procedure written in jsoncpp's hook, applied
forwards.
python-psutil is a stage-2 package: built on the host it shipped 41 dist-packages
paths, and the ARTEFACT check caught it.
--- FR ---
Rust n'est pas optionnel. Le poetry.lock d'ERPLibre exige cryptography 46.0.5 en
optional = false, plus jiter, orjson, pydantic-core et rpds-py, qui tous
compilent du Rust depuis les sources là où aucune roue n'existe — et il n'en
existe pas pour s390x. Sans Rust, `pip install cryptography` échoue et ERPLibre ne
démarre pas.
Le cycle d'amorçage n'est pas l'obstacle qu'il paraît : rust-1.90.0 publie une
archive officielle s390x-unknown-linux-gnu, vérifiée en HTTP 200, et l'hôte porte
déjà rustc 1.85.1. Ce qui coûte, c'est llvm et clang.
Mesuré avant de choisir, comme glib2 et iproute2 : au-delà de ce que ce portage a
déjà, llvm et clang veulent libedit, python-psutil, python-sphinx et
python-myst-parser. Les deux derniers ne servent qu'à la documentation, et
derrière eux viennent docutils, babel, pygments, snowballstemmer, imagesize,
alabaster, la famille sphinxcontrib, markdown-it-py et mdit-py-plugins — une
quinzaine de paquets pour produire du HTML sur un compilateur dont personne ici ne
lit le manuel. -DLLVM_ENABLE_SPHINX=OFF supprime tout cela.
Leur package() finit sur `rm -r .../html/{_sources,.buildinfo}`, que Sphinx crée.
Dix-septième apparition de cette forme, et la PREMIÈRE trouvée avant la
construction plutôt qu'après — la procédure inscrite dans le hook de jsoncpp,
appliquée à l'endroit.
python-psutil est un paquet d'étage 2 : bâti sur l'hôte, il livrait 41 chemins
dist-packages, et le test ARTEFACT l'a attrapé.
Assisted-by: Claude Opus 5
nss will not configure without gyp:
Building NSS requires an installation of gyp: https://gyp.gsrc.io
Google's build-file generator, which nss uses to produce its ninja files. It is a
real Arch package and a Python program, so it joins the Python set.
jsoncpp is the fourteenth instance of this shape and the sixth of my own making.
Removing the doxybuild.py call stopped the API html being generated; package()
still copied the directory it would have produced, and the name carries pkgver so
the path is not greppable without knowing the version.
The rule is mechanical enough now to state as a procedure rather than a lesson:
after removing a documentation build, grep package() for the OUTPUT directory
name, not for the tool. The tool appears in build(); the path appears in
package(), and it is the path that fails.
--- FR ---
nss ne se configure pas sans gyp :
Building NSS requires an installation of gyp: https://gyp.gsrc.io
Le générateur de fichiers de construction de Google, dont nss se sert pour produire
ses fichiers ninja. C'est un vrai paquet Arch et un programme Python : il rejoint
l'ensemble Python.
jsoncpp est la quatorzième occurrence de cette forme, et la sixième de ma main.
Retirer l'appel à doxybuild.py a arrêté la génération du html d'API ; package()
copiait toujours le répertoire qu'il aurait produit, et son nom porte pkgver — le
chemin n'est donc pas trouvable par grep sans connaître la version.
La règle est assez mécanique pour être énoncée en procédure plutôt qu'en leçon :
après avoir retiré une construction de documentation, chercher dans package() le
nom du répertoire de SORTIE, pas celui de l'outil. L'outil est dans build() ; le
chemin est dans package(), et c'est le chemin qui échoue.
Assisted-by: Claude Opus 5
pacman refused the rebuilt binutils:
binutils: <root>/usr/lib64 exists in filesystem (owned by filesystem)
binutils: <root>/usr/lib64/libiberty.a exists in filesystem
--libdir=/usr/lib was not enough. libiberty installs into
$(libdir)$(MULTIOSSUBDIR), and gcc reports ../lib64 for
-print-multi-os-directory on s390x. In the installed system that resolves
through the symlink filesystem now provides, so the file lands in /usr/lib --
but pkgdir has no symlink, so make creates a real pkg/usr/lib64/ and makepkg
records the literal path. The two fixes are not alternatives: the symlink is what
keeps meson and cmake choosing lib, and this moves the one file that still writes
through the multi-os subdirectory.
cmake is the eleventh instance of removing a documentation build and leaving its
cleanup: with Sphinx off there is no html, and the PKGBUILD deletes _sources from
it. rm -rf rather than deleted -- on a machine with Sphinx it is real.
The binutils hook also assumed package_binutils(). binutils is not a split
package; its own assertion caught that.
--- FR ---
pacman a refusé le binutils reconstruit :
binutils: <root>/usr/lib64 exists in filesystem (owned by filesystem)
binutils: <root>/usr/lib64/libiberty.a exists in filesystem
--libdir=/usr/lib ne suffisait pas. libiberty s'installe dans
$(libdir)$(MULTIOSSUBDIR), et gcc annonce ../lib64 pour
-print-multi-os-directory sur s390x. Dans le système installé cela se résout par
le lien que filesystem fournit désormais, donc le fichier atterrit dans
/usr/lib — mais pkgdir n'a pas de lien : make crée un vrai pkg/usr/lib64/ et
makepkg enregistre le chemin littéral. Les deux correctifs ne sont pas des
alternatives : le lien est ce qui fait choisir lib à meson et cmake, et celui-ci
déplace le seul fichier qui écrive encore par le sous-répertoire multi-os.
cmake est la onzième occurrence du retrait d'une documentation sans son nettoyage :
sans Sphinx il n'y a pas de html, et le PKGBUILD en supprime _sources. rm -rf
plutôt que supprimé — sur une machine dotée de Sphinx, il est réel.
Le hook binutils supposait aussi package_binutils(). binutils n'est pas un paquet
scindé ; sa propre assertion l'a arrêté.
Assisted-by: Claude Opus 5
from vcs_versioning import Configuration
ModuleNotFoundError: No module named vcs_versioning
setuptools-scm was split upstream and its own build imports the half that left.
The traceback runs through setuptools build_meta, so what the log showed for
several passes was
ERROR Backend subprocess exited when trying to invoke build_wheel
a backend complaint about a package that had been divided in two. Fifth Python
build-time package this port has had to add, after flit_core, setuptools,
poetry-core and hatchling.
--- FR ---
from vcs_versioning import Configuration
ModuleNotFoundError: No module named vcs_versioning
setuptools-scm a ete scinde en amont, et sa propre construction importe la moitie
partie. La trace passe par build_meta de setuptools : ce que le journal montrait
depuis plusieurs passes etait
ERROR Backend subprocess exited when trying to invoke build_wheel
une plainte de moteur au sujet d un paquet coupe en deux. Cinquieme paquet Python
de construction que ce portage doit ajouter, apres flit_core, setuptools,
poetry-core et hatchling.
Assisted-by: Claude Opus 5
Two install commands passed one --nodeps and looked like they were skipping
dependencies. pacman documents the difference: -d skips dependency VERSION
checks, -dd skips them entirely. So cython could not be installed --
warning: cannot resolve python-pygments, a dependency of cython
:: unable to satisfy dependency python-numpy required by cython
-- and the numbers matter. cython is wanted here only as a BUILD tool, for
libseccomp Python binding, while its declared RUNTIME dependencies are numpy and
pygments, and numpy brings BLAS and LAPACK. A single -d nearly bought a numerical
stack to compile one .pyx file.
The message named numpy and numpy was not the subject. The subject was a missing
letter d.
python-poetry-core joins the list: the fourth Python build backend needed here
after flit_core, setuptools and hatchling.
--- FR ---
Deux commandes d installation passaient un seul --nodeps et semblaient sauter les
dependances. pacman documente la difference : -d saute les controles de VERSION,
-dd les saute entierement. cython ne pouvait donc pas etre installe --
warning: cannot resolve python-pygments, a dependency of cython
:: unable to satisfy dependency python-numpy required by cython
-- et les chiffres comptent. cython n est voulu ici que comme OUTIL de
construction, pour la liaison Python de libseccomp, alors que ses dependances d
EXECUTION declarees sont numpy et pygments, et numpy tire BLAS et LAPACK. Un seul
-d a failli faire compiler une pile numerique pour un fichier .pyx.
Le message nommait numpy, et numpy n etait pas le sujet. Le sujet etait un d
manquant.
python-poetry-core rejoint la liste : quatrieme moteur de construction Python
necessaire ici, apres flit_core, setuptools et hatchling.
Assisted-by: Claude Opus 5
xz got past po4a and stopped on
../../../doxygen/update-doxygen: doxygen command not found
Two documentation toolchains in one package: po4a for the translated man pages,
doxygen for the liblzma API reference. --disable-doc is xz own switch, checked
present in configure before use.
libpsl stopped on
make: *** No rule to make target
/usr/share/publicsuffix/effective_tld_names.dat, needed by ...
publicsuffix-list is DATA. libpsl compiles the Public Suffix List into a lookup
table, so the list is an input to the build -- the first entry in this port whose
absence is neither a program nor a library, and it reads exactly like a broken
Makefile.
--- FR ---
xz a passe po4a et s est arrete sur
../../../doxygen/update-doxygen: doxygen command not found
Deux chaines de documentation dans un seul paquet : po4a pour les pages de manuel
traduites, doxygen pour la reference d API de liblzma. --disable-doc est son
propre interrupteur, verifie present dans configure avant usage.
libpsl s est arrete sur
make: *** No rule to make target
/usr/share/publicsuffix/effective_tld_names.dat, needed by ...
publicsuffix-list est une DONNEE. libpsl compile la Public Suffix List en table
de correspondance : la liste est une entree de la construction — premiere entree
de ce portage dont l absence n est ni un programme ni une bibliotheque, et elle se
lit exactement comme un Makefile casse.
Assisted-by: Claude Opus 5
libevent: mv: cannot stat '<pkgdir>/usr/share/doc': No such file or directory
pam: rm: cannot remove '.../Linux-PAM/*.pdf': No such file or directory
Both are hooks I wrote in this session, and both stopped a build in exactly the
way this port has documented eight times: the documentation build was disabled
and its install was left in place. Turning EVENT__DOXYGEN off does not stop
package() moving usr/share/doc into the libevent-doc split; -Ddocs=disabled does
not stop pam deleting PDFs it no longer produces.
fakeroot was the first one I made myself. This makes three, so the rule is worth
stating instead of rediscovering: after disabling documentation anywhere, search
package() for share/doc, man, and the split arrays before believing the hook is
finished.
pam's rm becomes tolerant rather than deleted -- on a machine with the DocBook
stack the PDFs are real, and the comment above the line says why they must go:
they are not reproducible.
--- FR ---
libevent: mv: cannot stat '<pkgdir>/usr/share/doc': No such file or directory
pam: rm: cannot remove '.../Linux-PAM/*.pdf': No such file or directory
Deux hooks que j'ai écrits dans cette session, et deux arrêts de construction de
la façon exacte que ce portage a documentée huit fois : la construction de la
documentation désactivée, son installation laissée en place. Éteindre
EVENT__DOXYGEN n'empêche pas package() de déplacer usr/share/doc vers le
sous-paquet libevent-doc ; -Ddocs=disabled n'empêche pas pam de supprimer des PDF
qu'il ne produit plus.
fakeroot fut le premier de ma main. Cela en fait trois : la règle mérite d'être
énoncée plutôt que redécouverte — après avoir désactivé une documentation,
chercher dans package() share/doc, man, et les tableaux de sous-paquets avant de
croire le hook terminé.
Le rm de pam devient tolérant plutôt que supprimé : sur une machine dotée de la
pile DocBook les PDF existent, et le commentaire au-dessus dit pourquoi ils
doivent partir — ils ne sont pas reproductibles.
Assisted-by: Claude Opus 5
gnupg builds two architecture diagrams into its manual, one needing ImageMagick
and one transfig -- two toolchains for two pictures. --disable-doc is gnupg own
switch, verified present in configure before use.
The hook was written twice. The first version looked for a ./configure line
ending in a backslash and asserted its way out; gnupg uses an options ARRAY.
Both shapes appear in this port, so a hook has to read the file rather than
assume the house style.
systemd generates source from jinja2 templates and stops without it. Not
documentation this time -- the build cannot proceed.
--- FR ---
gnupg construit deux diagrammes dans son manuel, l un exigeant ImageMagick et
l autre transfig -- deux chaines d outils pour deux images. --disable-doc est son
propre interrupteur, verifie present dans configure avant usage.
Le hook a ete ecrit deux fois. La premiere version cherchait une ligne
./configure terminee par une contre-oblique et s est arretee sur son assertion ;
gnupg emploie un TABLEAU d options. Les deux formes existent dans ce portage : un
hook doit lire le fichier plutot que supposer le style maison.
systemd genere du code depuis des gabarits jinja2 et s arrete sans lui. Pas de la
documentation cette fois -- la construction ne peut pas avancer.
Assisted-by: Claude Opus 5
libaio is a real closure gap: lvm2 stops on "libaio.h: No such file or
directory". This port had already met that library from the other side, noting
Ubuntu's time64 rename to libaio.so.1t64 long before anything needed its headers.
fakeroot is the interesting one. The first hook removed the po4a call and nothing
else, so build() ended on a bare `cd doc` and package() failed on
install: cannot stat './faked.1': No such file or directory
The English man pages ARE shipped. What is not shipped are the translations:
doc/Makefile carries SUBDIRS = de es fr nl pt ro sv, each holding only Makefiles
whose man_MANS name files po4a was supposed to generate. Removing the generator
and leaving the recursion is the same mistake as removing a build target and
leaving its install target.
shadow needs distinguishing: xsltproc exists here now, from our libxslt. What is
missing is the DocBook XML data its stylesheets read -- the same as pam.
--- FR ---
libaio est un vrai trou de fermeture : lvm2 s'arrête sur « libaio.h: No such file
or directory ». Ce portage avait déjà croisé cette bibliothèque par l'autre bout,
en notant le renommage time64 d'Ubuntu en libaio.so.1t64 bien avant que ses
en-têtes servent.
fakeroot est le cas intéressant. Le premier hook retirait l'appel à po4a et rien
d'autre : build() finissait sur un `cd doc` nu et package() échouait sur
install: cannot stat './faked.1': No such file or directory
Les pages anglaises SONT livrées. Ce qui ne l'est pas, ce sont les traductions :
doc/Makefile porte SUBDIRS = de es fr nl pt ro sv, chacun ne contenant que des
Makefiles dont man_MANS nomme des fichiers que po4a devait générer. Retirer le
générateur en laissant la récursion est la même erreur que retirer une cible de
construction en laissant celle d'installation.
shadow mérite une distinction : xsltproc existe désormais, via notre libxslt. Ce
qui manque, ce sont les données DocBook que lisent ses feuilles de style — comme
pour pam.
Assisted-by: Claude Opus 5
gold failed to link with
s390.cc: undefined reference to `void gold::gold_error_at_location<32, true>'
Its s390 target file compiles code for both s390 and s390x and references
<32, true> instantiations, which exist only when a 32-bit s390 target is
configured. The PKGBUILD asks for --enable-targets=x86_64-pep,bpf-unknown-none.
x86_64-pep is the PE+ target for x86_64: it means nothing here, and on x86_64 it
is what happens to bring in the 32-bit instantiations gold's target files want.
So this was never a gold bug -- it is the -march=x86-64 story one layer further
in. s390-linux-gnu is the honest translation of that line.
gcc now compiles, Fortran front end included, and stopped in package_gcc() on
libstdc++'s doxygen man pages -- two places, build and install, the eighth time
this port has met that shape.
--- FR ---
gold ne se liait pas :
s390.cc: undefined reference to `void gold::gold_error_at_location<32, true>'
Son fichier de cible s390 compile pour s390 et s390x et référence des
instanciations <32, true>, qui n'existent que si une cible s390 32 bits est
configurée. Le PKGBUILD demande --enable-targets=x86_64-pep,bpf-unknown-none.
x86_64-pep est la cible PE+ d'x86_64 : elle ne veut rien dire ici, et sur x86_64
c'est elle qui amène par hasard les instanciations 32 bits que gold réclame. Ce
n'était donc pas un défaut de gold — c'est l'histoire du -march=x86-64 une couche
plus loin. s390-linux-gnu est la traduction honnête de cette ligne.
gcc compile désormais, front-end Fortran compris, et s'arrêtait dans
package_gcc() sur les pages de manuel doxygen de libstdc++ — deux endroits,
construction et installation, huitième fois que ce portage rencontre cette forme.
Assisted-by: Claude Opus 5
nlohmann-json is a real closure gap, not a documentation cut: both cmake and
cppdap stop on "Could NOT find nlohmann_json". It is a header-only C++ library,
one of the cheapest packages in the list, and cmake is not optional -- the
cmake/cppdap/jsoncpp/libuv group behind it is what several other packages build
with.
The other three are doxygen and sphinx again. jsoncpp's is the least readable
failure in the port so far: doxybuild.py is handed an empty doxygen path and
raises Exception('path is empty.'), so a missing tool arrives as a Python
traceback about a path.
libuv needed two places -- `make man -C docs` and the install of
docs/build/man/libuv.1 -- the same shape as libxml2's docs split and pam's PDFs:
a failure on a path at the end of package(), after a compile that worked.
--- FR ---
nlohmann-json est un vrai trou de fermeture, pas une coupe de documentation :
cmake et cppdap s'arrêtent tous deux sur « Could NOT find nlohmann_json ». C'est
une bibliothèque C++ d'en-têtes seuls, l'un des paquets les moins chers de la
liste, et cmake n'est pas optionnel — le groupe cmake/cppdap/jsoncpp/libuv
derrière lui est ce avec quoi plusieurs autres se bâtissent.
Les trois autres sont encore doxygen et sphinx. Celui de jsoncpp est l'échec le
moins lisible du portage jusqu'ici : doxybuild.py reçoit un chemin de doxygen
vide et lève Exception('path is empty.'), donc un outil manquant arrive sous la
forme d'une trace Python parlant d'un chemin.
libuv demandait deux endroits — `make man -C docs` et l'installation de
docs/build/man/libuv.1 — même forme que le découpage de libxml2 et les PDF de
pam : un échec sur un chemin en fin de package(), après une compilation réussie.
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
Four packages -- m4, libtool, groff, libnghttp2 -- failed in prepare() on
fatal: unable to access 'https://github.com/...': Could not resolve host
Failed to clone 'gl-mod/bootstrap' a second time, aborting
Arch takes its sources from git and these fetch gnulib as a submodule, so a
chroot with no resolv.conf cannot start the build at all. The retry line is what
makepkg prints; the reason sits one line above it.
Six more stopped on wget, which links libnettle.so.8 -- Ubuntu's soname, where
ours is .9. Our gnutls is already a stage-2 package and correctly wants .9; wget
was the last thing holding the old one, and gnulib's bootstrap fetches
translation catalogues WITH wget, so the tool it needed to fix itself was itself.
It joins libxml2 in STAGE2_HOST_EXTRACT: the host, which has a working wget, runs
prepare(); the chroot compiles.
Also fixed: my own ca-certificates hook left build() containing nothing but a
comment, which bash reports as a syntax error on the closing brace.
--- FR ---
Quatre paquets — m4, libtool, groff, libnghttp2 — ont échoué dans prepare() sur
fatal: unable to access 'https://github.com/...': Could not resolve host
Failed to clone 'gl-mod/bootstrap' a second time, aborting
Arch tire ses sources de git et ceux-là récupèrent gnulib en sous-module : un
chroot sans resolv.conf ne peut pas même commencer. La ligne de reprise est ce
qu'affiche makepkg ; la raison est juste au-dessus.
Six autres se sont arrêtés sur wget, qui lie libnettle.so.8 — le soname
d'Ubuntu, quand le nôtre est .9. Notre gnutls est déjà un paquet d'étage 2 et
demande bien .9 ; wget était le dernier à retenir l'ancien, et le bootstrap de
gnulib récupère les catalogues de traduction AVEC wget : l'outil dont il avait
besoin pour se réparer était lui-même. Il rejoint libxml2 dans
STAGE2_HOST_EXTRACT — l'hôte, qui a un wget valide, exécute prepare() ; le chroot
compile.
Corrigé aussi : mon propre hook ca-certificates laissait build() avec un seul
commentaire, ce que bash signale comme une erreur de syntaxe sur l'accolade.
Assisted-by: Claude Opus 5
Stage-2 pass two never reached its first package:
unable to satisfy dependency 'perl-locale-gettext' required by help2man
stage2: populate failed
help2man had built cleanly the moment before. Stage 1 builds with --nodeps, so
a successful build says nothing about whether the repository is complete -- and
this is the failure that says it out loud, by refusing to assemble the chroot.
Asked the resolver for the whole closure rather than fixing one name and trying
again: pacman stops at the first unsatisfiable dependency, so the count matters
more than the first line. One gap, then 148 packages resolved with --nodeps off,
up from 101 before the tools went in.
--- FR ---
La deuxième passe de l'étage 2 n'a jamais atteint son premier paquet :
unable to satisfy dependency 'perl-locale-gettext' required by help2man
stage2: populate failed
help2man venait de se bâtir sans une erreur. L'étage 1 bâtit avec --nodeps :
une construction réussie ne dit rien de la complétude du dépôt — et voici
l'échec qui le dit tout haut, en refusant d'assembler le chroot.
Le résolveur a été interrogé sur toute la fermeture, plutôt que de corriger un
nom et de réessayer : pacman s'arrête au premier manque, donc le compte importe
plus que la première ligne. Un seul trou, puis 148 paquets résolus avec --nodeps
éteint, contre 101 avant l'ajout des outils.
Assisted-by: Claude Opus 5
Six built on the host. libxslt will not: its configure demands libxml2 2.15.1
and Ubuntu ships 2.14.5. Ours is 2.15.3 and exists only inside the stage-2
chroot, so that chroot is the only place libxslt can come from -- built BY
stage 2 rather than installed into it, and hoisted so it precedes shadow, which
died on `xsltproc is missing`.
That is a shape worth naming: a package the host cannot build because the host
is behind. Not contamination and not a closure gap -- the wrong machine.
Three more tools were asked for and refused: po4a for fakeroot, a2x for
ca-certificates, asciidoctor for cryptsetup. Perl, Python and Ruby respectively,
each to render a man page. Hooks instead.
--- FR ---
Six se bâtissent sur l'hôte. Pas libxslt : son configure exige libxml2 2.15.1 et
Ubuntu livre 2.14.5. Le nôtre est en 2.15.3 et n'existe que dans le chroot de
l'étage 2 : ce chroot est donc le seul endroit d'où libxslt puisse venir — bâti
PAR l'étage 2 plutôt qu'installé dedans, et hissé pour précéder shadow, mort sur
`xsltproc is missing`.
La forme mérite un nom : un paquet que l'hôte ne peut pas bâtir parce que l'hôte
est en retard. Ni contamination ni trou de fermeture — la mauvaise machine.
Trois autres outils réclamés et refusés : po4a pour fakeroot, a2x pour
ca-certificates, asciidoctor pour cryptsetup. Perl, Python et Ruby
respectivement, chacun pour rendre une page de manuel. Des hooks à la place.
Assisted-by: Claude Opus 5
zlib stopped on '__builtin_s390_vec_unpackl' requires '-mvx', after its own
configure had detected vector support and defined -DHAVE_S390X_VX. Both halves
were right, so it was worth measuring rather than patching:
host gcc (Ubuntu) --with-arch=z13 --with-tune=z16 default -march=arch11
our gcc nothing default -march=arch5
arch5 is z900, from 2000. Arch's PKGBUILD names no s390x baseline because Arch
has no s390x, so ours fell back to the oldest machine imaginable while zlib went
on detecting a CPU the compiler had been told to forget. Every distribution
picks one of these; this port had never said which, and silence chose 2000.
z13 is what Ubuntu s390x already requires, so nothing that runs today stops.
Set in two places: makepkg.conf, how this distribution is compiled, and gcc's
--with-arch, what the compiler we ship assumes with no flags at all.
--- FR ---
zlib s'est arrêté sur '__builtin_s390_vec_unpackl' requires '-mvx', après que
son propre configure avait détecté le support vectoriel et défini
-DHAVE_S390X_VX. Les deux moitiés avaient raison : il fallait mesurer, pas
rustiner.
gcc de l'hôte --with-arch=z13 --with-tune=z16 défaut -march=arch11
notre gcc rien défaut -march=arch5
arch5, c'est z900, de l'an 2000. Le PKGBUILD d'Arch ne nomme aucune base s390x
puisque Arch n'a pas de s390x : le nôtre retombait sur la machine la plus
ancienne imaginable pendant que zlib détectait un processeur qu'on avait dit au
compilateur d'oublier. Toute distribution en choisit une ; ce portage ne l'avait
jamais dit, et le silence a choisi 2000.
z13 est ce qu'Ubuntu s390x exige déjà : rien qui tourne aujourd'hui ne cesse de
tourner. Posé aux deux endroits : makepkg.conf, comment cette distribution est
compilée, et le --with-arch de gcc, ce que suppose le compilateur qu'on livre.
Assisted-by: Claude Opus 5
glibc rebuilt inside the chroot; binutils died on `make info-recursive`, and
makeinfo said why: its XS module was compiled against the host's perl 5.40 and
our perl is 5.42. Stage-1 texinfo cannot run in there. Everything that builds
.info documentation needs it, and it sat near the end of the list because that
is where its own dependencies are, so stage 2 hoists it.
linux-api-headers stopped earlier on `rsync: command not found` -- the kernel's
headers_install runs it. apt had put it there and a build that finds its tool
says nothing, so stage 1 never mentioned it. Its man pages come from Markdown
the git tag does not pre-render, hence --disable-md2man.
An inventory of the 110 apt packages against the chroot found 84 more such
binaries. Most are documentation; the rest wait until something needs them.
--- FR ---
glibc a été rebâti dans le chroot ; binutils est mort sur `make info-recursive`,
et makeinfo en donne la raison : son module XS a été compilé contre le perl 5.40
de l'hôte, or le nôtre est en 5.42. Le texinfo de l'étage 1 ne peut pas tourner
là-dedans. Tout ce qui bâtit de la documentation .info en dépend, et il figurait
en fin de liste, là où sont ses propres dépendances : l'étage 2 le remonte.
linux-api-headers s'était arrêté avant sur `rsync: command not found` — le
headers_install du noyau l'appelle. apt l'avait posé, et une construction qui
trouve son outil n'en dit rien : l'étage 1 ne l'a jamais mentionné. Ses pages de
manuel viennent d'un Markdown que l'étiquette git ne rend pas, d'où
--disable-md2man.
Un inventaire des 110 paquets apt face au chroot a trouvé 84 autres binaires du
même genre. La plupart sont de la documentation ; le reste attendra qu'un paquet
les réclame.
Assisted-by: Claude Opus 5
Stage 2 could rebuild one named package. It could not rebuild a hundred and
thirty-three, for reasons that were all about the driver.
The order is not re-derived: it is the closure stage 1 arrived at over four
rounds of resolver output and then confirmed by 179 builds, so it moves to
packages.sh and both stages read it. make_rootfs wipes the chroot every run,
which is what makes it reproducible and what made stage 2 unresumable --
stage2.state outlived the packages it named. Its output is now put back.
The stall guard is shared rather than copied: stage 2 needs it more, since a
test suite is the likeliest thing in a build to wait forever. Build trees are
removed after a package installs, never after it fails.
--- FR ---
L'étage 2 savait rebâtir un paquet nommé. Il ne savait pas en rebâtir cent
trente-trois, pour des raisons qui tenaient toutes au pilote.
L'ordre n'est pas réinventé : c'est la fermeture obtenue à l'étage 1 en quatre
tours de sortie du résolveur, puis confirmée par 179 constructions. Il passe
donc dans packages.sh, que les deux étages lisent. make_rootfs efface le chroot
à chaque passage — ce qui le rend reproductible et rendait l'étage 2
irreprenable, stage2.state survivant aux paquets qu'il nommait. Sa production y
est désormais réinstallée.
La garde d'immobilité est partagée plutôt que recopiée : l'étage 2 en a plus
besoin, une suite de tests étant ce qui attend le plus volontiers pour
toujours. Les arbres de compilation sont effacés après installation, jamais
après un échec.
Assisted-by: Claude Opus 5
