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
Measured once rather than discovered a package at a time: dpkg says what each
of the 110 apt packages ships in /usr/bin, and each of those is tested against
the chroot. Two had already been found the slow way, rsync and makeinfo, and
each cost a full build to surface.
Sorted by what it means: ten are build tools that will each block something,
eleven are documentation already settled by --auto-features auto, and eight are
not gaps at all -- bison.yacc, fakeroot-tcp, automake-1.17, ncurses6-config and
the like are Debian's alternative names for tools that are present under Arch's.
Counting those as missing would have meant building packages that exist.
--- FR ---
Mesuré une fois plutôt que découvert un paquet à la fois : dpkg dit ce que
chacun des 110 paquets apt livre dans /usr/bin, et chacun est testé contre le
chroot. Deux avaient déjà été trouvés par la voie lente, rsync et makeinfo, au
prix d'une construction complète chacun.
Classé par ce que cela signifie : dix sont des outils de construction qui
bloqueront chacun quelque chose, onze sont de la documentation déjà tranchée par
--auto-features auto, et huit ne sont pas des manques -- bison.yacc,
fakeroot-tcp, automake-1.17, ncurses6-config et compagnie sont les noms
alternatifs de Debian pour des outils présents sous ceux d'Arch. Les compter
comme absents aurait fait bâtir des paquets qui existent.
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
Stage 2 could build and could not deliver. Four obstacles, all in the tail of
package(), after a compile that had already succeeded.
Our meson ships arch-meson and it passes --auto-features enabled, so each of
the nine documentation tools this chroot lacks was a hard error, not a skipped
feature. A wrapper appends --auto-features auto; meson honours the last one.
Building those tools was the alternative and it is not close -- doxygen alone
wants clang, fmt, spdlog, llvm-libs.
Then bsdtar would not start: stage-1 libxml2 asks for the host's
libicuuc.so.76, our icu ships 78, and bsdtar is what writes the package. The
package that would fix it was the one being built. libarchive only links
libxml2 for xar, which nothing here reads, so stage 1 drops it.
Verified: libxml2 rebuilt against libicuuc.so.78, provides libxml2.so=16-64,
zero multiarch paths.
--- FR ---
L'étage 2 savait bâtir et ne savait pas livrer. Quatre obstacles, tous dans la
queue de package(), après une compilation déjà réussie.
Notre meson livre arch-meson, qui passe --auto-features enabled : chacun des
neuf outils de documentation absents de ce chroot devenait une erreur franche
au lieu d'une option écartée. Une enveloppe ajoute --auto-features auto, meson
retenant la dernière occurrence. Bâtir ces outils était l'autre voie et l'écart
est net -- doxygen seul réclame clang, fmt, spdlog, llvm-libs.
Puis bsdtar ne démarrait plus : le libxml2 de l'étage 1 réclame le
libicuuc.so.76 de l'hôte, notre icu livre le 78, et bsdtar est ce qui écrit le
paquet. Le paquet qui corrigeait cela était celui qu'on bâtissait. libarchive
ne lie libxml2 que pour xar, que rien ici ne lit : l'étage 1 l'abandonne.
Vérifié : libxml2 rebâti sur libicuuc.so.78, fournit libxml2.so=16-64, aucun
chemin multiarch.
Assisted-by: Claude Opus 5
Two failures three packages apart, both from the same place: our pacman
package ships Arch's configuration verbatim, and Arch's is for x86_64.
libxml2/meson.build:1:0: ERROR: Unable to detect linker for compiler
`cc ... -march=x86-64 -mtune=generic ...`
configure_chroot fixed CARCH, CHOST, MAKEFLAGS and OPTIONS and left CFLAGS
alone. They are emptied rather than translated, because that is what stage 1
used -- the host's makepkg.conf has no CFLAGS line at all -- and 179 working
packages are the evidence. s390x tuning is a deliberate later choice.
Emptied by APPENDING, not commenting. The first attempt put a # in front of
each assignment, and CFLAGS spans several lines: commenting the first left the
continuations active and the quote unbalanced, so makepkg would not start.
Then readline. Its .pc says `Requires.private: termcap` and this repository
ships tinfo.pc; nothing provides termcap.pc. Nothing failed at build time --
a .pc is data, and pkg-config only follows Requires.private when a consumer
asks. The first consumer to ask was libxml2, in the chroot, one stage and
three packages from the cause.
--- FR ---
Deux échecs à trois paquets d'écart, de la même origine : notre paquet pacman
livre la configuration d'Arch telle quelle, et celle d'Arch vise x86_64.
libxml2/meson.build:1:0: ERROR: Unable to detect linker for compiler
`cc ... -march=x86-64 -mtune=generic ...`
configure_chroot corrigeait CARCH, CHOST, MAKEFLAGS et OPTIONS, et laissait
CFLAGS. Ils sont vidés plutôt que traduits, car c'est ce qu'a utilisé l'étage
1 — le makepkg.conf de l'hôte n'a aucune ligne CFLAGS — et 179 paquets
fonctionnels en sont la preuve. Le réglage pour s390x est un choix ultérieur
délibéré.
Vidés par AJOUT, non par commentaire. La première tentative mettait un # devant
chaque affectation, et CFLAGS s'étend sur plusieurs lignes : commenter la
première laissait les continuations actives et le guillemet déséquilibré, si
bien que makepkg ne démarrait plus.
Puis readline. Son .pc dit « Requires.private: termcap » alors que ce dépôt
livre tinfo.pc ; personne ne fournit termcap.pc. Rien n'échouait à la
compilation — un .pc est une donnée, et pkg-config ne suit Requires.private
que si un consommateur le demande. Le premier à demander fut libxml2, dans le
chroot, à une étape et trois paquets de la cause.
Assisted-by: Claude Opus 5
Debian patches sysconfig to prefer the "posix_local" scheme, so every
wheel-installing PKGBUILD ships /usr/local -- a tree Arch reserves and whose
every path the filesystem package owns. pacman refuses the transaction:
error: failed to commit transaction (conflicting files)
/usr/local/share/man exists in both 'filesystem' and 'meson'
Four packages hit it. Two were dropped for other reasons. Rather than write a
third and fourth relocation hook, build_package now exports
DEB_PYTHON_INSTALL_LAYOUT=deb_system, which moves the default from
/usr/local/lib/python3.13/dist-packages to /usr/lib/python3/dist-packages and
scripts from /usr/local/bin to /usr/bin. One line, every python package,
including ones not built yet.
It does not finish the job: deb_system still says dist-packages and Arch reads
site-packages. That move stays per-package, because only modules actually
imported on the target need it. meson does, and its hook does it -- targeting
the version of the python PACKAGE in repo/s390x, not the interpreter running
the build. Installed under the host's 3.13, /usr/bin/meson runs in the chroot
and then says ModuleNotFoundError, because the chroot's python is our 3.14 and
never looks in 3.13.
--- FR ---
Debian modifie sysconfig pour préférer le schéma « posix_local » : tout
PKGBUILD installant une roue livre donc /usr/local, arbre qu'Arch réserve et
dont le paquet filesystem possède chaque chemin. pacman refuse la transaction :
error: failed to commit transaction (conflicting files)
/usr/local/share/man exists in both 'filesystem' et 'meson'
Quatre paquets l'ont rencontré. Deux ont été écartés pour d'autres raisons.
Plutôt que d'écrire un troisième et un quatrième crochet de relocalisation,
build_package exporte désormais DEB_PYTHON_INSTALL_LAYOUT=deb_system, qui
déplace le défaut de /usr/local/lib/python3.13/dist-packages vers
/usr/lib/python3/dist-packages, et les scripts de /usr/local/bin vers /usr/bin.
Une ligne, tous les paquets python, y compris ceux pas encore bâtis.
Cela ne termine pas le travail : deb_system dit encore dist-packages quand
Arch lit site-packages. Ce déplacement reste par paquet, car seuls les modules
réellement importés sur la cible en ont besoin. meson en fait partie, et son
crochet le fait — en visant la version du PAQUET python de repo/s390x, non
l'interpréteur qui exécute la compilation. Installé sous le 3.13 de l'hôte,
/usr/bin/meson démarre dans le chroot puis annonce ModuleNotFoundError, le
python du chroot étant notre 3.14, qui ne regarde jamais dans 3.13.
Assisted-by: Claude Opus 5
Ten of the 159 PKGBUILDs call arch-meson and four call cmake, so a chroot
without them could rebuild most of the repository and then stop. Neither is a
dependency of anything in the repository, which is why no closure round ever
named them -- the same shape as fakeroot and bison, one layer up.
python returns with meson, and that is not the earlier decision being
reversed. Dropping python at stage 1 was about what the REPOSITORY must
supply: it was wanted only by two wheels Arch's own python could not load.
This is about what the BUILD ENVIRONMENT must contain, and meson is written in
Python. Different question, different answer.
python needed two fixes of its own. Its xvfb loop is in build() AND in
check(); stage 1 never ran the second because of --nocheck, but stage 2 drops
--nocheck on purpose, so it would have spun there too. And Python 3.13 removed
the vendored libmpdec, so --with-system-libmpdec is the only way to build and
needs the host headers -- reported nine hundred lines in as a missing make
rule for a file that used to be vendored.
cmake wanted rhash, then jsoncpp, then cppdap, one at a time. That is a queue,
and the rule in install_host_deps says a queue is a feature to disable. Not
applied here, deliberately: each exists as an Ubuntu package, so the queue
ends. The rule is for queues that do not, like dbus reaching a documentation
tool that needed Qt. Its Qt GUI is dropped -- a dialog box on a headless
mainframe.
--- FR ---
Dix des 159 PKGBUILD appellent arch-meson et quatre appellent cmake : un
chroot sans eux pourrait reconstruire l'essentiel du dépôt puis s'arrêter.
Aucun des deux n'est une dépendance de quoi que ce soit dans le dépôt, ce qui
explique qu'aucun tour de fermeture ne les ait nommés — même forme que
fakeroot et bison, une couche plus haut.
python revient avec meson, et ce n'est pas un revirement. L'écarter à l'étage
1 portait sur ce que le DÉPÔT doit fournir : il n'était voulu que par deux
roues que le python d'Arch ne pouvait pas charger. Ici il s'agit de ce que
l'ENVIRONNEMENT DE BUILD doit contenir, et meson est écrit en Python. Autre
question, autre réponse.
python a demandé deux correctifs propres. Sa boucle xvfb est dans build() ET
dans check() ; l'étage 1 n'a jamais exécuté la seconde grâce à --nocheck, mais
l'étage 2 l'abandonne exprès — elle y aurait tourné aussi. Et Python 3.13 a
retiré le libmpdec embarqué : --with-system-libmpdec est la seule voie et
réclame les en-têtes de l'hôte, signalé neuf cents lignes plus loin comme une
règle make manquante pour un fichier autrefois embarqué.
cmake a réclamé rhash, puis jsoncpp, puis cppdap, un par un. C'est une file, et
la règle d'install_host_deps dit qu'une file est une fonctionnalité à
désactiver. Non appliquée ici, délibérément : chacun existe en paquet Ubuntu,
donc la file se termine. La règle vise celles qui ne terminent pas, comme dbus
atteignant un outil de documentation qui exigeait Qt. Son interface Qt est
retirée — une boîte de dialogue sur un mainframe sans écran.
Assisted-by: Claude Opus 5
python's PKGBUILD hunts for a free X display before running make:
export servernum=99
while ! xvfb-run -a -n "$servernum" /bin/true 2>/dev/null; do
servernum=$((servernum+1)); done
xvfb-run is not installed here. It exits 127, `!` inverts that to true, and
the loop tries the next number. There is no exit condition for "the command
does not exist", and the 2>/dev/null swallows the one line that would have
said so.
Measured before anyone noticed: ten hours of wall clock, four million PIDs,
and a log frozen at `configure: creating Makefile`. Every signal said the
build was healthy -- alive, 40% CPU, sitting in a plausible source directory.
A process list cannot tell work from spinning. A stalled log next to a live
makepkg can, and that is all this guard does.
Forty-five minutes of COMPLETE silence, because real builds do go quiet: a
long link, a test suite that prints nothing, gcc between bootstrap stages.
The case this was written for ran two hundred times longer. EL_STALL_MIN=0
disables it.
Tested against a real spin loop: detected, whole process tree killed, rc=2 so
STALL reads differently from FAIL in the summary.
--- FR ---
Le PKGBUILD de python cherche un numéro d'affichage X libre avant make :
export servernum=99
while ! xvfb-run -a -n "$servernum" /bin/true 2>/dev/null; do
servernum=$((servernum+1)); done
xvfb-run n'est pas installé ici. Il sort en 127, le `!` inverse, et la boucle
essaie le numéro suivant. Il n'existe aucune condition de sortie pour « la
commande n'existe pas », et le 2>/dev/null avale la seule ligne qui l'aurait
dit.
Mesuré avant que quiconque s'en aperçoive : dix heures d'horloge, quatre
millions de PID, un journal figé à `configure: creating Makefile`. Tous les
signaux disaient que le build allait bien — vivant, 40 % de CPU, dans un
répertoire source plausible. Une liste de processus ne distingue pas le
travail du sur-place. Un journal figé à côté d'un makepkg vivant, si — et
c'est tout ce que fait ce garde-fou.
Quarante-cinq minutes de silence COMPLET, car de vrais builds se taisent :
une longue édition de liens, une suite de tests muette, gcc entre deux étages.
Le cas qui l'a motivé a tourné deux cents fois plus longtemps. EL_STALL_MIN=0
le désactive.
Éprouvé contre une vraie boucle infinie : détecté, arbre de processus tué en
entier, rc=2 pour que STALL se lise autrement que FAIL dans le bilan.
Assisted-by: Claude Opus 5
The loop applies each hook on the HOST -- /build is the same directory from
both sides, so makepkg in the chroot reads the patched PKGBUILD and nothing is
duplicated inside. It drops --nocheck: stage 1 skipped the test suites because
they ran against the host's libraries, and here they test what was built.
Each rebuilt package is installed into the chroot before the next one, with
the host's pacman and --root, because the chroot's own pacman will not start
until stage 2 has rebuilt it.
Two hooks must NOT run there, and both for the same satisfying reason: the
condition they work around does not exist in the chroot. libgcrypt.sh points
at a host prefix holding our libgpg-error, which the chroot has installed
properly. git.sh drops ZLIB_NG=1 because Ubuntu ships no zlib-ng headers,
while our own zlib-ng package ships them.
git is here because STAGE 2 needs it, not the repository: 51 of the 159
PKGBUILDs take their sources from git+https, and makepkg validates that clone
even under --noextract. Nothing depends on git. Its three -- perl-error,
perl-mailtools with perl-timedate, zlib-ng -- were read from the depends array
rather than from my own tool, which had reported `zsh` as a dependency of git.
It is not; the tool's regex was catching a neighbouring array.
--- FR ---
La boucle applique chaque crochet sur l'HÔTE — /build est le même répertoire
des deux côtés, donc makepkg dans le chroot lit le PKGBUILD corrigé et rien
n'est dupliqué dedans. Elle abandonne --nocheck : l'étage 1 sautait les suites
de tests parce qu'elles s'exécutaient contre les bibliothèques de l'hôte ; ici
elles éprouvent ce qui a été bâti. Chaque paquet reconstruit est installé dans
le chroot avant le suivant, avec le pacman de l'hôte et --root, celui du
chroot ne démarrant pas avant que l'étage 2 ne l'ait reconstruit.
Deux crochets ne doivent PAS y tourner, et pour la même raison satisfaisante :
la condition qu'ils contournent n'existe pas dans le chroot. libgcrypt.sh
pointe sur un préfixe hôte contenant notre libgpg-error, que le chroot a
installé correctement. git.sh retire ZLIB_NG=1 parce qu'Ubuntu ne livre pas
les en-têtes zlib-ng, alors que notre propre paquet zlib-ng les livre.
git est là parce que l'ÉTAGE 2 en a besoin, pas le dépôt : 51 des 159
PKGBUILD prennent leurs sources en git+https, et makepkg valide ce clone même
sous --noextract. Rien ne dépend de git. Ses trois dépendances — perl-error,
perl-mailtools avec perl-timedate, zlib-ng — ont été lues dans le tableau
depends plutôt que dans mon propre outil, qui annonçait `zsh` comme dépendance
de git. Elle ne l'est pas : la regex de l'outil attrapait un tableau voisin.
Assisted-by: Claude Opus 5
Stage 1 is done and its output is provably wrong in nine places: binaries
asking for libgpgme.so.11, libnettle.so.8, libicuuc.so.76 and six more at the
HOST's soname versions. Stage 2 dissolves all nine by rebuilding each package
against what the repository actually ships.
The constraint that shapes it: pacman cannot run inside the stage-1 rootfs,
because libalpm was linked against the host's gpgme. So the rootfs is
populated from OUTSIDE, with the host's pacman and --root, and the chroot is
used only to build. That is not a workaround, it is the order the problem has
-- stage 2's own output is the first pacman that will run on the target.
Five packages were added to stage 1 for this, and the resolver could never
have named them: nothing DEPENDS on fakeroot or bison, they are simply what a
build needs to happen. makepkg refuses to run as root, so the chroot carries a
user with the host's uid -- a bind mount keeps the numeric owner, and a
different uid inside could not write $srcdir.
The smoke test separates hard failures from known drift. makeinfo fails
because texinfo was built against the host's perl; that is what stage 2
repairs, so refusing to start over it would refuse to run the fix.
--- FR ---
L'étage 1 est terminé et sa sortie est démontrablement fausse en neuf points :
des binaires réclamant libgpgme.so.11, libnettle.so.8, libicuuc.so.76 et six
autres, aux versions de soname de l'HÔTE. L'étage 2 les dissout tous les neuf
en reconstruisant chaque paquet contre ce que le dépôt livre réellement.
La contrainte qui le façonne : pacman ne peut pas tourner dans le rootfs
d'étage 1, libalpm ayant été lié contre le gpgme de l'hôte. Le rootfs est donc
peuplé depuis l'EXTÉRIEUR, avec le pacman de l'hôte et --root, et le chroot ne
sert qu'à bâtir. Ce n'est pas un contournement mais l'ordre qu'a le problème :
la sortie de l'étage 2 est le premier pacman qui tournera sur la cible.
Cinq paquets ont rejoint l'étage 1 pour cela, et le résolveur n'aurait jamais
pu les nommer : rien ne DÉPEND de fakeroot ni de bison, ils sont simplement ce
qu'il faut pour qu'une compilation ait lieu. makepkg refuse de tourner en
root, le chroot porte donc un utilisateur avec l'uid de l'hôte — un bind mount
conserve le propriétaire numérique, et un uid différent ne pourrait pas
écrire $srcdir.
Le smoke test sépare les échecs durs des dérives connues. makeinfo échoue
parce que texinfo a été bâti contre le perl de l'hôte ; c'est précisément ce
que l'étage 2 répare, donc refuser de démarrer pour cela serait refuser de
lancer le correctif.
Assisted-by: Claude Opus 5
This host was configured with `libtool staticlibs`, which KEEPS what Arch
strips. Fifty-six of a hundred and fifty-nine packages carried .la files, and
nothing reported it until two sub-packages of one source both claimed the
same file:
/usr/lib/libcrypt.la exists in both 'libxcrypt' and 'libxcrypt-compat'
That is what .la files are for -- they record a link line -- so a split
library produces two descriptions of itself. Arch removes them because
nothing in a modern toolchain reads them and the paths they record are wrong
as soon as a package moves. OPTIONS now matches Arch, minus debug and lto:
debug wants a source-package pipeline this bootstrap has no use for, and lto
doubles a stage whose output stage 2 discards.
libnspr4-dev and mercurial came with nss. The nspr distinction is worth
keeping: the host had NOTHING, which the ordinary stage-1 rule fixes with a
host package. libgcrypt needed a hook because the host had something too OLD
-- 1.51 against a floor of 1.56 -- and no installation fixes that.
--- FR ---
Cet hôte était configuré avec `libtool staticlibs`, qui CONSERVE ce qu'Arch
retire. Cinquante-six paquets sur cent cinquante-neuf portaient des fichiers
.la, et rien ne l'avait signalé jusqu'à ce que deux sous-paquets d'une même
source réclament le même fichier :
/usr/lib/libcrypt.la exists in both 'libxcrypt' et 'libxcrypt-compat'
C'est à cela que servent les .la — ils consignent une ligne de liaison — donc
une bibliothèque scindée produit deux descriptions d'elle-même. Arch les
supprime parce que rien dans une chaîne moderne ne les lit et que les chemins
qu'ils consignent sont faux dès qu'un paquet se déplace. OPTIONS suit
désormais Arch, sauf debug et lto : debug réclame un pipeline de paquets
sources dont cet amorçage n'a que faire, et lto double une étape dont l'étage
2 jette la sortie.
libnspr4-dev et mercurial sont venus avec nss. La distinction sur nspr mérite
d'être gardée : l'hôte n'avait RIEN, ce que la règle ordinaire de l'étage 1
corrige par un paquet hôte. libgcrypt a exigé un crochet parce que l'hôte
avait quelque chose de trop VIEUX — 1.51 contre un plancher de 1.56 — et
qu'aucune installation ne corrige cela.
Assisted-by: Claude Opus 5
Our gcc package was built a dozen times and never once used to compile
anything -- stage 1 compiles with Ubuntu's gcc. The first program it was ever
asked to link was in the stage-2 chroot, and it failed twice.
collect2: fatal error: cannot find 'ld'
/usr/bin/ld was present, executable, on PATH, and ran as the same user. -B,
COMPILER_PATH and three symlinks changed nothing. strace settled it in one
line: it was looking for s390x-linux-gnu-ld, the DEBIAN triplet, and printing
the generic name. gcc's configure had recorded Ubuntu's copy, a file no Arch
system will ever have. --with-ld and --with-as now pin absolute paths, correct
on the host, in the chroot and on the target alike.
/usr/bin/ld: cannot find -lgcc_s
package_gcc() moves libgcc_s{,_asneeded}.so three directories deeper. The
asneeded one is a linker script and survives; libgcc_s.so is a symlink naming
its target relative to /usr/lib, so after the move it points at nothing. The
only libgcc_s.so on the system was dangling, so -lgcc_s could not resolve and
nothing linked at all -- not even int main(void){return 0;}.
Verified: the chroot now compiles and runs a program.
--- FR ---
Notre paquet gcc a été bâti une douzaine de fois sans jamais servir à
compiler : l'étage 1 compile avec le gcc d'Ubuntu. Le premier programme qu'on
lui a demandé de lier l'a été dans le chroot d'étage 2, et il a échoué deux
fois.
collect2: fatal error: cannot find 'ld'
/usr/bin/ld était présent, exécutable, dans le PATH, et répondait pour le même
utilisateur. -B, COMPILER_PATH et trois liens symboliques n'ont rien changé.
strace a tranché en une ligne : il cherchait s390x-linux-gnu-ld, le triplet
DEBIAN, en affichant le nom générique. La configuration de gcc avait
enregistré la copie d'Ubuntu, un fichier qu'aucun système Arch n'aura jamais.
--with-ld et --with-as épinglent désormais des chemins absolus, corrects sur
l'hôte, dans le chroot et sur la cible.
/usr/bin/ld: cannot find -lgcc_s
package_gcc() déplace libgcc_s{,_asneeded}.so trois répertoires plus bas.
Le second est un script ld et survit ; libgcc_s.so est un symlink dont la
cible est relative à /usr/lib, si bien qu'après le déplacement il ne pointe
plus sur rien. Le seul libgcc_s.so du système pendait dans le vide : -lgcc_s
ne pouvait se résoudre et plus rien ne se liait — pas même
int main(void){return 0;}.
Vérifié : le chroot compile et exécute désormais un programme.
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 fourth closure round asked for libaio and thin-provisioning-tools, both
wanted by lvm2 alone. thin-provisioning-tools is Rust now, so a language
runtime was arriving through a fourth-order dependency.
Nothing in the repository wants `lvm2`. Checked across every .PKGINFO:
cryptsetup wants device-mapper, and device-mapper is the other package this
same source produces. Dropping the sub-package removed both entries and the
Rust question with them.
The measurement is the argument, and it went the other way an hour earlier.
tcl, unixodbc and libmicrohttpd each cost zero new packages, so building them
beat dropping sub-packages. This one costs a language runtime, so dropping
wins. The rule is not to prefer either -- it is to measure each time.
device-mapper had also picked up the host's libselinux, silently. Seventh
package to do it, second found by reading binaries rather than by a build.
35 packages, then 19, then 2, then 0.
--- FR ---
Le quatrième tour de fermeture réclamait libaio et thin-provisioning-tools,
tous deux voulus par lvm2 seul. thin-provisioning-tools est en Rust
désormais : un environnement de langage arrivait par une dépendance de
quatrième ordre.
Rien dans le dépôt ne veut `lvm2`. Vérifié sur chaque .PKGINFO : cryptsetup
veut device-mapper, et device-mapper est l'autre paquet que cette même source
produit. Écarter le sous-paquet a retiré les deux entrées et la question Rust
avec elles.
La mesure est l'argument, et elle avait tranché dans l'autre sens une heure
plus tôt. tcl, unixodbc et libmicrohttpd coûtaient zéro paquet nouveau : les
bâtir valait mieux qu'écarter des sous-paquets. Celui-ci coûte un
environnement de langage : écarter gagne. La règle n'est de préférer ni l'un
ni l'autre — c'est de mesurer chaque fois.
device-mapper avait aussi ramassé le libselinux de l'hôte, en silence.
Septième paquet à le faire, deuxième trouvé en lisant des binaires plutôt que
par une compilation.
35 paquets, puis 19, puis 2, puis 0.
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
Thirty-five packages pulled in nineteen more, and those two. The resolver
named each round as precisely as the first, and it now reports satisfied:
101 packages, --nodeps off.
THE MEASUREMENT THAT CHANGED ITS ANSWER. Four of round two were going to be
avoided by dropping sub-packages -- sqlite-tcl, sqlite-analyzer, the openldap
server, debuginfod -- reasoning that had been right for python-brotli.
Measured instead: tcl, unixodbc and libmicrohttpd each cost ZERO new
packages, because the closure had filled in around them. Building them beats
four hooks, and it does not leave sqlite shipping an sqltclsh that cannot
start. The arithmetic that was right at forty packages was wrong at a hundred
and thirty.
ca-certificates-mozilla is the only entry here that is not a library: it is
the root certificate list itself, and ca-certificates is only the machinery
around it. Without it the target trusts nothing and every HTTPS verification
fails. It has no packaging repo -- nss produces it -- so nss and nspr came
too, measured first: nspr free, nss needing only mercurial on the host, and
hg.mozilla.org answering in 0.3s. 172 certificates shipped.
--- FR ---
Trente-cinq paquets en ont tiré dix-neuf autres, puis ces deux-là. Le
résolveur a nommé chaque tour aussi précisément que le premier, et il se
déclare maintenant satisfait : 101 paquets, --nodeps désactivé.
LA MESURE QUI A CHANGÉ SA RÉPONSE. Quatre paquets du deuxième tour allaient
être évités en écartant des sous-paquets — sqlite-tcl, sqlite-analyzer, le
serveur openldap, debuginfod — par un raisonnement juste pour python-brotli.
Mesuré plutôt que supposé : tcl, unixodbc et libmicrohttpd coûtent ZÉRO
paquet nouveau, la fermeture s'étant refermée autour d'eux. Les bâtir vaut
mieux que quatre crochets, et évite de livrer un sqlite contenant un sqltclsh
incapable de démarrer. L'arithmétique juste à quarante paquets était fausse à
cent trente.
ca-certificates-mozilla est la seule entrée ici qui ne soit pas une
bibliothèque : c'est la liste des certificats racine elle-même, et
ca-certificates n'en est que la mécanique. Sans lui la cible ne fait
confiance à rien et toute vérification HTTPS échoue. Il n'a pas de dépôt de
packaging — nss le produit — donc nss et nspr ont suivi, mesurés d'abord :
nspr gratuit, nss ne réclamant que mercurial sur l'hôte, et hg.mozilla.org
répondant en 0,3 s. 172 certificats livrés.
Assisted-by: Claude Opus 5
e2fsprogs builds fuse2fs, deletes it, and repackages it. Without fuse3 on the
host it was never compiled, so the delete aborted package() after a clean
build -- and its sub-package declares fuse3, which this port does not ship, so
even a success would have been uninstallable. Three reasons, one direction.
libsasl said `libpq-fe.h: No such file or directory` about a file that is
there, in /usr/include/postgresql. mysql.h is in /usr/include/mariadb, the
same shape one step behind it. Two headers that exist on paths configure does
not try is a queue, and this port already wrote down what a queue means: a
single missing library is a host dependency, a queue of them is a feature to
disable. Arch declares depends=(glibc) for libsasl and says why -- the SQL
plugins are dlopened, never linked.
python-audit and python-capng go the way python-brotli went, but the reason is
stated differently on purpose. Cost was the argument then; measured now,
python costs three packages rather than a subtree, so that argument no longer
holds. The ABI does: both are cp313 wheels and Arch ships 3.14.
--- FR ---
e2fsprogs bâtit fuse2fs, le supprime, puis le rempaquette. Sans fuse3 sur
l'hôte il n'a jamais été compilé : la suppression interrompait donc package()
après une compilation propre — et son sous-paquet déclare fuse3, que ce
portage ne livre pas, si bien qu'une réussite aurait été ininstallable. Trois
raisons, une seule direction.
libsasl annonçait « libpq-fe.h: No such file or directory » à propos d'un
fichier présent, sous /usr/include/postgresql. mysql.h est sous
/usr/include/mariadb, même forme un cran derrière. Deux en-têtes qui existent
sur des chemins que configure n'essaie pas font une file d'attente, et ce
dépôt a déjà consigné ce qu'une file signifie : une bibliothèque manquante est
une dépendance hôte, une file en est une fonctionnalité à désactiver. Arch
déclare depends=(glibc) pour libsasl et explique pourquoi — les greffons SQL
sont chargés dynamiquement, jamais liés.
python-audit et python-capng suivent python-brotli, mais le motif est énoncé
autrement à dessein. C'était le coût alors ; mesuré maintenant, python coûte
trois paquets et non un sous-arbre, cet argument ne tient donc plus. L'ABI,
si : les deux sont des roues cp313 quand Arch livre la 3.14.
Assisted-by: Claude Opus 5
Everything in stage 1 until now was added because a BUILD stopped. These were
added because test-chroot.sh ran the resolver with --nodeps OFF -- the check
the whole bootstrap skips -- and it listed exactly what the repository owed.
Nothing here is speculative.
Thirty-five packages, then five rounds of failures that each got further than
the last: 12 failed, then 7, then 4, then 0. The pattern was almost always a
host tool nobody had declared, and the fix for one uncovered the next --
ducktype then yelp-build, ss then lmdb, autoconf-archive then cmocka.
Two corrections worth keeping. libargon2-dev was the wrong package: openldap
passes --with-argon2=libsodium, so the error named argon2 and the answer was
sodium. And apt-cache reported NONE for all eight candidates because this host
answers `Candidat :`, not `Candidate:` -- the same locale trap that had broken
util-linux hours earlier, met again inside the script written to verify its
fix. Query apt under LC_ALL=C.
--- FR ---
Tout ce qui composait l'étage 1 jusqu'ici avait été ajouté parce qu'une
COMPILATION s'arrêtait. Ceux-ci l'ont été parce que test-chroot.sh a lancé le
résolveur avec --nodeps DÉSACTIVÉ — le contrôle que tout l'amorçage saute — et
qu'il a listé exactement ce que le dépôt devait. Rien ici n'est spéculatif.
Trente-cinq paquets, puis cinq tours d'échecs allant chacun plus loin que le
précédent : 12, puis 7, puis 4, puis 0. Le motif était presque toujours un
outil hôte que personne n'avait déclaré, et corriger l'un dévoilait le
suivant — ducktype puis yelp-build, ss puis lmdb, autoconf-archive puis
cmocka.
Deux corrections à garder. libargon2-dev était le mauvais paquet : openldap
passe --with-argon2=libsodium, l'erreur nommait donc argon2 quand la réponse
était sodium. Et apt-cache annonçait NONE pour les huit candidats parce que
cet hôte répond « Candidat : » et non « Candidate: » — le piège de locale même
qui avait cassé util-linux quelques heures plus tôt, retrouvé dans le script
écrit pour en vérifier le correctif. Interroger apt sous LC_ALL=C.
Assisted-by: Claude Opus 5
The first package the host is too OLD for rather than missing something.
libgcrypt 1.12.2 wants libgpg-error >= 1.56; Ubuntu ships 1.51. No -dev
package fixes a version floor.
We built 1.61 ourselves, so the material exists -- but using it crosses a
line worth naming: consuming stage 1's own output is the property that
defines stage 2. The alternative was deferring libgcrypt, which gnupg and
systemd both declare, leaving the repository unresolvable. Using our own is
also what a bootstrap does, and stage 2 erases the distinction anyway.
--with-libgpg-error-prefix looks like the mechanism and is not: it sets
GPG_ERROR_CONFIG to $prefix/bin/gpg-error-config, a program 1.61 no longer
ships. It would have named an absent file, fallen back to PATH, found 1.51
again, and the error would not have moved. GPGRT_CONFIG is what configure
consults. Verified on a copy: version >= 1.56 yes (1.61-unknown), rc=0.
The artefact carries no RPATH and no reference to the scratch prefix; it
links the bare soname, which the target resolves from its own /usr/lib.
--- FR ---
Le premier paquet pour lequel l'hôte est trop VIEUX plutôt qu'incomplet.
libgcrypt 1.12.2 veut libgpg-error >= 1.56 ; Ubuntu livre la 1.51. Aucun
paquet -dev ne corrige un plancher de version.
Nous avons bâti la 1.61 nous-mêmes, le matériel existe donc — mais l'employer
franchit une limite qu'il faut nommer : consommer la sortie de l'étage 1 est
la propriété qui définit l'étage 2. L'alternative était de reporter libgcrypt,
que gnupg et systemd déclarent tous deux, laissant le dépôt insoluble.
Employer le nôtre est aussi ce que fait un amorçage, et l'étage 2 efface la
distinction de toute façon.
--with-libgpg-error-prefix a l'air d'être le mécanisme et ne l'est pas : il
fixe GPG_ERROR_CONFIG à $prefix/bin/gpg-error-config, programme que la 1.61 ne
livre plus. Il aurait nommé un fichier absent, on serait retombé sur le PATH,
retrouvé la 1.51, et l'erreur n'aurait pas bougé. C'est GPGRT_CONFIG que
configure consulte. Vérifié sur une copie : version >= 1.56 yes
(1.61-unknown), rc=0.
L'artefact ne porte ni RPATH ni référence au préfixe temporaire ; il lie le
soname nu, que la cible résout depuis son propre /usr/lib.
Assisted-by: Claude Opus 5
Five packages, one shape: a default computed from this machine rather than
from Arch, and arch-meson's --auto-features enabled turning what was optional
into a requirement.
dbus taught the method. It stopped three times in a row on a different
documentation tool -- ducktype, then yelp-build, then qhelpgenerator. The
first two were installed. The third needs Qt, so the chain had no end. All
three are `auto` features promoted to mandatory; pinned off, they cost
nothing. A single missing library is a host dependency. A queue of them is a
feature that should be disabled.
pinentry wanted Qt6 for a passphrase prompt; tty and curses remain.
krb5 asked for a system ss library Ubuntu ships no headers for, and said
"cannot run test program" instead of saying so.
sqlite found tcl, then installed into share/tcltk because Ubuntu's
tclConfig.sh says so and Arch's says lib.
gettext linked the host's libselinux, silently -- the sixth package to do it,
and the first the audit caught rather than a build.
--- FR ---
Cinq paquets, une seule forme : une valeur par défaut calculée depuis cette
machine plutôt que depuis Arch, et le --auto-features enabled d'arch-meson qui
transforme l'optionnel en exigence.
dbus a enseigné la méthode. Il s'est arrêté trois fois de suite sur un outil
de documentation différent — ducktype, puis yelp-build, puis qhelpgenerator.
Les deux premiers ont été installés. Le troisième exige Qt : la chaîne ne
terminait nulle part. Les trois sont des features `auto` promues en
obligations ; épinglées à disabled, elles ne coûtent rien. Une bibliothèque
manquante est une dépendance hôte. Une file d'attente en est une
fonctionnalité à désactiver.
pinentry réclamait Qt6 pour une invite de mot de passe ; tty et curses
suffisent.
krb5 demandait une bibliothèque ss système dont Ubuntu ne livre aucun
en-tête, et annonçait « cannot run test program » plutôt que de le dire.
sqlite trouvait tcl, puis installait dans share/tcltk parce que le
tclConfig.sh d'Ubuntu le dit là où celui d'Arch dit lib.
gettext liait le libselinux de l'hôte, en silence — sixième paquet à le
faire, et le premier que l'audit a pris plutôt qu'une compilation.
Assisted-by: Claude Opus 5
An audit of every missing dependency spelled as a soname, asking the ARTEFACT
whether the package that declares it actually links it. It contradicted my
guesses: curl's krb5, ssh2 and idn2 are all real. Two were not.
make readelf -d usr/bin/make -> libc.so.6, and nothing else
gcc configure recorded ISLLIBS='' ISLINC=''; zero libisl in the tree
Both are false in our build environment and true in Arch's. --nodeps means
makepkg never checks, so each shipped a package asking for something this
port will never contain -- and only pacman ever notices, at install time.
Building isl was the first plan. Its Arch packaging repo was last touched in
2017 and its only source URL is isl.gforge.inria.fr, dead with INRIA's
GForge. There is nothing to build; the declaration goes instead, and Graphite
goes with it.
gnutls found the same shape from the other direction: --with-leancrypto
stopped configure, and 'leancrypto' sat in depends= where nothing checks it.
--- FR ---
Un audit de chaque dépendance manquante écrite en soname, demandant à
l'ARTEFACT si le paquet qui la déclare la lie vraiment. Il a contredit mes
suppositions : les krb5, ssh2 et idn2 de curl sont bien réels. Deux ne
l'étaient pas.
make readelf -d usr/bin/make -> libc.so.6, et rien d'autre
gcc configure a noté ISLLIBS='' ISLINC='' ; aucun libisl dans l'arbre
Les deux sont fausses dans notre environnement et vraies dans celui d'Arch.
--nodeps veut dire que makepkg ne vérifie jamais : chacun livrait donc un
paquet réclamant ce que ce portage ne contiendra jamais — et seul pacman s'en
aperçoit, à l'installation.
Bâtir isl était le premier plan. Son dépôt de packaging Arch n'a pas bougé
depuis 2017 et sa seule source pointe isl.gforge.inria.fr, morte avec le
GForge d'INRIA. Il n'y a rien à bâtir : c'est la déclaration qui part, et
Graphite avec elle.
gnutls a montré la même forme par l'autre bout : --with-leancrypto arrêtait
configure, et 'leancrypto' figurait dans depends= où rien ne le vérifie.
Assisted-by: Claude Opus 5
pacman's resolver named 70 unresolved dependencies. Excluding python-brotli
alone took that to 47 and removed `python` outright, with libffi, mpdecimal
and gdbm behind it. python-libseccomp would have re-admitted the same tree,
and nothing across 135 packages depends on either.
Both wheels are unusable on the target anyway: built by the host's python
3.13, ABI-tagged cpython-313, while Arch ships 3.14. Stage 2 produces real
ones.
systemd-ukify is different -- it is architectural. ukify assembles a PE
binary and its EFI_ARCH_MAP has no s390x entry, so guess_efi_arch() raises
ValueError on this machine. Shipping it would put a program in the repository
that cannot start. systemd-tests followed it out: a test suite behind
--nocheck, and the only reason five more python packages were wanted.
The dropped artefacts were still indexed in core.db afterwards. repo-add only
adds, so a sub-package removed from pkgname leaves its last build installable
forever. Removed by hand; TODO.md records the gap.
--- FR ---
Le résolveur de pacman nommait 70 dépendances non résolues. Écarter le seul
python-brotli a ramené le compte à 47 et retiré `python` d'un coup, avec
libffi, mpdecimal et gdbm derrière. python-libseccomp aurait réadmis le même
arbre, et rien parmi 135 paquets ne dépend de l'un ou de l'autre.
Les deux roues sont de toute façon inutilisables sur la cible : bâties par le
python 3.13 de l'hôte, marquées cpython-313, quand Arch livre la 3.14.
L'étage 2 en produira de vraies.
systemd-ukify est d'une autre nature — architectural. ukify assemble un
binaire PE et son EFI_ARCH_MAP n'a pas d'entrée s390x : guess_efi_arch() lève
donc ValueError sur cette machine. Le livrer mettrait au dépôt un programme
incapable de démarrer. systemd-tests l'a suivi : une suite de tests derrière
--nocheck, et la seule raison de réclamer cinq paquets python de plus.
Les artefacts écartés restaient indexés dans core.db. repo-add n'ajoute que :
un sous-paquet retiré de pkgname laisse sa dernière compilation installable à
jamais. Retirés à la main ; TODO.md consigne le manque.
Assisted-by: Claude Opus 5
A full disk does not say so. gcc's bootstrap reported
genattrtab: cannot close file tmp-attrtab.cc: No space left on device
seventeen thousand lines into its log, behind two hundred lines of make
recursion. Everything visible pointed at gcc, and the first grep for
"error:" matched cpp_error() -- a function name in gcc's own source, the
documented trap of grepping a whole file instead of the right part.
df would have said it in one line, before the forty minutes.
This host is shared, and the free margin is not stable, so it is checked per
package rather than assumed once. 8 GiB clears gcc, the largest build here;
smaller packages never trip it. The message names the reclaim command,
because the answer is not obvious either: the src trees are regenerable,
makepkg -C wipes them anyway.
--- FR ---
Un disque plein ne le dit pas. L'amorçage de gcc a signalé
genattrtab: cannot close file tmp-attrtab.cc: No space left on device
dix-sept mille lignes plus bas dans son journal, derrière deux cents lignes
de récursion make. Tout ce qui était visible accusait gcc, et le premier
grep sur « error: » est tombé sur cpp_error() — un nom de fonction dans les
sources de gcc, précisément le piège documenté qui consiste à grep un
fichier entier plutôt que le bon endroit.
df l'aurait dit en une ligne, avant les quarante minutes.
Cet hôte est partagé et la marge libre n'est pas stable : la vérification se
fait donc par paquet, sans rien supposer. 8 GiB suffisent à gcc, le plus
gros build ici ; les petits paquets ne la déclencheront jamais. Le message
nomme la commande de récupération, car la réponse n'est pas évidente non
plus : les arbres src se régénèrent, makepkg -C les efface de toute façon.
Assisted-by: Claude Opus 5
Deferred, Architectural and Environment all assume someone made a choice.
Four divergences this round were made by nobody: a build option whose
DEFAULT is computed from the build machine, so installing an unrelated
Ubuntu package changes what a PKGBUILD produces.
libdir and python.platlibdir come from meson asking dpkg-architecture.
EXPAT_BUILD_DOCS comes from whichever docbook converter is on PATH.
split-bin comes from whether the builder's /usr/sbin is a symlink. None of
them fail loudly, and one waited twenty-nine hours before it did.
They get their own section because the "To close" is the same for all four
and different from the others: stage 2 builds inside an Arch root, where
every one of these defaults is already right. Until then, pin rather than
hope.
Six entries added elsewhere, including two that are deliberately NOT fixed:
makedb's libselinux and the bare sonames !autodeps leaves behind.
--- FR ---
Deferred, Architectural et Environment supposent tous que quelqu'un a
choisi. Quatre divergences de ce tour n'ont été décidées par personne : une
option dont la valeur PAR DÉFAUT est calculée depuis la machine de build,
si bien qu'installer un paquet Ubuntu sans rapport change ce qu'un PKGBUILD
produit.
libdir et python.platlibdir viennent de meson interrogeant
dpkg-architecture. EXPAT_BUILD_DOCS vient du convertisseur docbook présent
dans le PATH. split-bin vient de savoir si le /usr/sbin du constructeur est
un lien. Aucune n'échoue bruyamment, et l'une a attendu vingt-neuf heures.
Elles ont leur section parce que le « pour clore » est le même pour les
quatre et diffère des autres : l'étage 2 construit dans une racine Arch, où
chacun de ces défauts est déjà le bon. D'ici là, épingler plutôt qu'espérer.
Six entrées ailleurs, dont deux délibérément NON corrigées : le libselinux
de makedb et les sonames sans version que laisse !autodeps.
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
The repository already knew four: pkgname, the build block, the _pick
lines, the explicit make targets. There is a fifth, and it is the only one
that fails silently -- the depends= array of a DIFFERENT sub-package.
--nodeps means makepkg never checks, so gcc-libs built, passed, and went
into the repository declaring a dependency on libhwasan, which this
architecture never produces. Nothing said a word. pacman did, the first
time anything tried to install it:
:: unable to satisfy dependency 'libhwasan' required by gcc-libs
This was already paid for once: an earlier pass hit it with libquadmath and
pruned that one name by hand. libhwasan joined the drop set afterwards and
the pruning was not extended. Pruning one name at a time was the bug.
The set that decides what is not built now also decides what is not
depended on, and an assertion refuses to let the two drift again.
--- FR ---
Le dépôt en connaissait déjà quatre : pkgname, le bloc de build, les lignes
_pick, les cibles make explicites. Il y en a un cinquième, et c'est le seul
qui échoue en silence — le tableau depends= d'un AUTRE sous-paquet.
--nodeps veut dire que makepkg ne vérifie jamais : gcc-libs s'est construit,
a été accepté, et est entré dans le dépôt en déclarant une dépendance envers
libhwasan, que cette architecture ne produit jamais. Rien n'a bronché.
pacman, si, à la première tentative d'installation :
:: unable to satisfy dependency 'libhwasan' required by gcc-libs
C'était déjà payé une fois : un passage antérieur avait rencontré le piège
avec libquadmath et élagué ce seul nom à la main. libhwasan a rejoint la
liste des retraits ensuite, sans que l'élagage suive. Élaguer nom par nom
était le vrai défaut.
L'ensemble qui décide de ce qui n'est pas construit décide désormais aussi
de ce dont on ne dépend pas, et une assertion interdit aux deux de diverger.
Assisted-by: Claude Opus 5
--auto-features enabled turns every auto feature into a requirement, so
installing a tool switches on code that never compiled here. Three of the
fifty host packages did exactly that, and only one failed for the reason
it named.
expat had built clean the day before. asciidoc pulled docbook-utils in as
an automatic dependency; it owns docbook2man, the third name in expat's
find_program list, so docs defaulted ON twenty-nine hours before anything
rebuilt. That tool is the SGML pipeline: on DocBook XML it writes nothing
and still exits 0, and the mv it feeds is what reported the failure. Arch
ships no xmlwf.1 either, so OFF is parity.
systemd's split-bin probes the BUILD host's /usr/sbin. Ubuntu's is a real
directory, so six binaries went where package() does not look -- and
arch-meson's --sbindir is ignored, systemd computes its own.
util-linux needed no option: poman-translate.sh greps po4a for the English
"Discard" and this host answers "Rejet de". The locale belongs to the host,
so it is pinned once on the makepkg line.
--- FR ---
--auto-features enabled fait de chaque fonction « auto » une exigence :
installer un outil active donc du code jamais compilé ici. Trois des
cinquante paquets hôte l'ont fait, et un seul a échoué pour la raison
qu'il annonçait.
expat compilait proprement la veille. asciidoc avait tiré docbook-utils en
dépendance automatique ; il fournit docbook2man, troisième nom de la liste
find_program d'expat, et la doc est passée à ON vingt-neuf heures avant
toute reconstruction. Cet outil est le pipeline SGML : sur du DocBook XML
il n'écrit rien et sort quand même 0, et le mv qu'il alimente est ce qui a
signalé la panne. Arch ne livre pas xmlwf.1 non plus : OFF, c'est la parité.
Le split-bin de systemd sonde le /usr/sbin de la machine de BUILD. Celui
d'Ubuntu est un vrai répertoire, donc six binaires sont partis là où
package() ne regarde pas — et le --sbindir d'arch-meson est ignoré, systemd
calcule le sien.
util-linux n'avait besoin d'aucune option : poman-translate.sh cherche le
« Discard » anglais de po4a, et cet hôte répond « Rejet de ». La locale
appartient à l'hôte : elle est épinglée une fois, sur la ligne makepkg.
Assisted-by: Claude Opus 5
--nodeps means every makedepend must be named here by hand. Seven builds
stopped on one, each naming a different tool: itstool, convert, fig2dev,
asciidoctor, libnsl, python -m build, libbpf, history.
The list was also a lie by omission. libreadline-dev, libncurses-dev,
zlib1g-dev, python3-dev, doxygen, xsltproc, docbook-xsl, elinks and
libcap2-bin were on this VM by hand and never declared. They made the
builds pass here and would fail on a fresh Ubuntu, for reasons that have
nothing to do with s390x.
history.pc is generated rather than copied: our own readline package
ships a correct one, but its libdir names /usr/lib, which on a multiarch
host holds no libhistory. The .pc has to describe THIS host.
Three hooks for what apt cannot buy. systemd asks for an EFI arch s390x
does not have -- and says "python3 is missing modules: elftools", which
sends you to apt for four lines before admitting the real reason.
--- FR ---
--nodeps veut dire que chaque makedepend doit être nommé ici à la main.
Sept compilations se sont arrêtées sur l'une d'elles, chacune désignant
un outil différent : itstool, convert, fig2dev, asciidoctor, libnsl,
python -m build, libbpf, history.
La liste mentait aussi par omission. libreadline-dev, libncurses-dev,
zlib1g-dev, python3-dev, doxygen, xsltproc, docbook-xsl, elinks et
libcap2-bin étaient posés à la main sur cette VM, jamais déclarés. Ils
faisaient passer les compilations ici et auraient échoué sur un Ubuntu
neuf, pour des raisons étrangères à s390x.
history.pc est généré et non copié : notre propre paquet readline en
livre un correct, mais son libdir nomme /usr/lib, qui sur un hôte
multiarch ne contient aucun libhistory. Le .pc doit décrire CET hôte-ci.
Trois crochets pour ce qu'apt n'achète pas. systemd réclame une
architecture EFI que s390x n'a pas — et annonce « python3 is missing
modules: elftools », ce qui envoie chez apt pour quatre lignes avant
d'avouer la vraie raison.
Assisted-by: Claude Opus 5
The previous commit read the chroot's "coreutils needs libselinux.so.1"
as a missing package. It is not one. Arch has no libselinux at all -- the
clone 404s -- and Arch's coreutils declares no selinux dependency,
because its build chroot has no selinux/selinux.h to find.
Ours found one. Ubuntu carries libselinux1-dev, gnulib probes for the
header unconditionally, and the audit names every victim:
coreutils 13 binaries findutils find sed tar glibc makedb
--without-selinux per package, which is what Arch gets for free. Arch
ships neither chcon nor runcon either, so this converges with Arch rather
than diverging. tar and find matter most: stage 2 runs makepkg inside
this rootfs, and makepkg calls both.
glibc is deliberately left alone. Nothing runs makedb, and rebuilding
glibc would relink the foundation under sixty-nine other packages; stage
2 does it in a chroot where the header cannot be found.
--- FR ---
Le commit précédent a lu le « coreutils réclame libselinux.so.1 » du
chroot comme un paquet manquant. Ce n'en est pas un. Arch n'a aucun
libselinux — le clone rend un 404 — et son coreutils ne déclare aucune
dépendance selinux, faute de selinux/selinux.h dans son chroot de
construction.
Le nôtre en a trouvé un. Ubuntu embarque libselinux1-dev, gnulib sonde
l'en-tête sans condition, et l'audit nomme chaque victime :
coreutils 13 binaires findutils find sed tar glibc makedb
--without-selinux par paquet, ce qu'Arch obtient gratuitement. Arch ne
livre ni chcon ni runcon non plus : on converge donc vers Arch au lieu de
s'en écarter. tar et find sont les plus critiques — l'étage 2 lance
makepkg dans ce rootfs, et makepkg les appelle tous deux.
glibc est laissé tel quel, délibérément. Rien n'exécute makedb, et le
reconstruire relierait la fondation sous soixante-neuf autres paquets ;
l'étage 2 s'en charge dans un chroot où l'en-tête est introuvable.
Assisted-by: Claude Opus 5
meson and cmake both ask the HOST where libraries go. On Ubuntu the
answer is lib/s390x-linux-gnu, so five packages already in the repository
ship theirs where Arch's ld.so and pkgconf never look. Measured:
expat 12 lz4 6 pacman 6 pkgconf 6 zstd 12 entries
Nothing failed. util-linux is where it finally shouted, and even there
the rm was the first victim, not the cause.
pacman is the one that matters: libalpm.so.16 landed where pacman's own
binary cannot load it, and a target installed from that package has no
working package manager left to repair itself with.
arch-meson now states the libdir devtools has no need to state, and is
reinstalled on every run -- editing the copy here changed nothing while
/usr/local/bin held a stale one. Four packages call bare meson or cmake
and get their own hook. util-linux's old hook chased lib64, which never
existed here; it is deleted.
--- FR ---
meson et cmake demandent tous deux à l'HÔTE où vont les bibliothèques.
Sous Ubuntu la réponse est lib/s390x-linux-gnu : cinq paquets déjà dans
le dépôt livrent donc les leurs là où ld.so et pkgconf d'Arch ne
regarderont jamais. Mesuré :
expat 12 lz4 6 pacman 6 pkgconf 6 zstd 12 entrées
Rien n'a échoué. util-linux est l'endroit où cela a fini par crier, et
même là le rm était la première victime, pas la cause.
pacman est celui qui compte : libalpm.so.16 atterrissait là où le binaire
de pacman ne peut pas la charger, et une cible installée depuis ce paquet
n'a plus de gestionnaire de paquets pour se réparer.
arch-meson énonce désormais le libdir que devtools n'a pas besoin
d'énoncer, et se réinstalle à chaque exécution : éditer la copie du dépôt
ne changeait rien tant que /usr/local/bin en gardait une périmée. Quatre
paquets appellent meson ou cmake nu et reçoivent leur crochet. L'ancien
crochet util-linux poursuivait un lib64 qui n'a jamais existé ici : il
est supprimé.
Assisted-by: Claude Opus 5
libselinux does not exist in Arch, so its clone 404'd. GitLab answers a
404 by asking for credentials, which is why the log read "could not read
Username" rather than "no such project" -- the first wrong culprit.
The second was mine. Neither the clone nor the cd that follows it was
guarded, so makepkg ran in whatever directory the previous package had
left. It rebuilt util-linux, wrote 119 KB of util-linux output into
log-libselinux.txt, and copied the artefact back into the repository.
The lesson is the repository's oldest one, one level up: an exit code
proves nothing, and neither does a log file's name. Verified by checking
every log against the "==> Making package:" line inside it.
--- FR ---
libselinux n'existe pas dans Arch, son clone a donc rendu un 404. GitLab
répond à un 404 en réclamant des identifiants : d'où le « could not read
Username » du journal, plutôt qu'un « projet inconnu ». Premier faux
coupable.
Le second était de mon fait. Ni le clone ni le cd qui le suit n'étaient
gardés, alors makepkg tournait dans le répertoire laissé par le paquet
précédent. Il a reconstruit util-linux, versé 119 ko de sortie util-linux
dans log-libselinux.txt, puis recopié l'artefact dans le dépôt.
La leçon est la plus ancienne du dépôt, d'un cran plus haut : un code de
sortie ne prouve rien, et le NOM d'un journal non plus. Vérifié en
confrontant chaque journal à la ligne « ==> Making package: » qu'il porte.
Assisted-by: Claude Opus 5
Arch Linux runs on s390x. Installing the repository into a rootfs and
entering it:
bash : 5.3.15(1)-release
uname -m : s390x
glibc : ldd (GNU libc) 2.44
Two things the test taught that sixty-eight successful builds had not.
bash would not start at all: "chroot: No such file or directory" on a
binary that was plainly there. That is the dynamic linker being absent
-- bash asks for /lib/ld64.so.1, and that path exists only through the
usr-merge symlinks the filesystem package installs. Without it an Arch
rootfs starts nothing.
coreutils then failed on libselinux.so.1. Not a port defect: a genuine
dependency that was never built. pacman had in fact listed all of them
before I passed --nodeps -- brotli, libxml2, pam, systemd,
pacman-mirrorlist, libmakepkg-dropins. The resolver works; the
repository was incomplete.
They are added to stage 1 by name, with the reason recorded. A build
that succeeds proves the compiler accepted the source. Only running the
binary proves the package.
--- FR ---
Arch Linux tourne sur s390x. Le depot installe dans un rootfs, puis on
y entre :
bash : 5.3.15(1)-release
uname -m : s390x
glibc : ldd (GNU libc) 2.44
Deux enseignements que soixante-huit compilations reussies n avaient
pas donnes.
bash ne demarrait pas du tout : « chroot: No such file or directory »
sur un binaire pourtant present. C est l interpreteur dynamique qui
manque -- bash reclame /lib/ld64.so.1, chemin qui n existe que par les
liens usr-merge du paquet filesystem. Sans lui, un rootfs Arch ne lance
rien.
coreutils echouait ensuite sur libselinux.so.1. Non pas un defaut du
portage : une dependance reelle jamais batie. pacman les avait
d ailleurs toutes nommees avant que je passe --nodeps -- brotli,
libxml2, pam, systemd, pacman-mirrorlist, libmakepkg-dropins. Le
resolveur fonctionne ; c est le depot qui etait incomplet.
Elles rejoignent l etage 1, avec la raison consignee. Une compilation
reussie prouve que le compilateur a accepte la source. Seul le binaire
qui s execute prouve le paquet.
Assisted-by: Claude Opus 5
Third attempt on this package, and the first one written after reading
the file instead of assuming its shape. The two before it failed for
the same reason:
1. Skipping ./bootstrap. The source is a git checkout, not a released
tarball, so that removed configure itself:
PKGBUILD: line 43: ./configure: No such file or directory
2. Editing `bootstrap`. The check is not there. It lives in
bootstrap.conf, inside a shell function, and its message is built
from a $url variable -- which is why grepping the literal text
found nothing, twice.
The check is two lines: a grep for the serial and a die. Both are
replaced by a no-op that keeps the enclosing function valid, verified
against the real file before being committed.
grep is the only package here that INSPECTS its host's m4 macros. This
is not an s390x incompatibility: pkg-config 0.29.2 ships that serial on
every distribution, x86 included.
The hook checks BOTH that the patch step was inserted and that
./bootstrap is still invoked, so mistake 1 cannot come back silently.
--- FR ---
Troisieme tentative sur ce paquet, et la premiere ecrite apres avoir lu
le fichier au lieu d en supposer la forme. Les deux precedentes ont
echoue pour la meme raison :
1. Sauter ./bootstrap. La source est un depot git, pas une archive de
version : cela supprimait configure lui-meme.
2. Modifier « bootstrap ». La verification n y est pas. Elle vit dans
bootstrap.conf, dans une fonction shell, et son message est
construit a partir d une variable $url -- d ou l echec, deux fois,
de la recherche du texte litteral.
La verification tient en deux lignes : un grep sur la serie et un die.
Les deux sont remplacees par une instruction vide qui laisse la
fonction valide, essai fait sur le vrai fichier avant de commiter.
grep est le seul paquet ici a EXAMINER les macros m4 de son hote. Ce
n est pas une incompatibilite s390x : pkg-config 0.29.2 livre cette
serie sur toutes les distributions, x86 compris.
Le crochet verifie A LA FOIS que l etape de correction est inseree et
que ./bootstrap est toujours appele, pour que l erreur 1 ne puisse pas
revenir en silence.
Assisted-by: Claude Opus 5
The previous version of this hook skipped ./bootstrap entirely, on the
assumption that the source was a released tarball and therefore already
bootstrapped. It is not -- it is a git checkout, so skipping bootstrap
removed configure itself:
PKGBUILD: line 43: ./configure: No such file or directory
That made things worse than the failure it was meant to fix, and it was
my assumption that was wrong, not the package.
What has to go is the check, not the bootstrap. grep is the only
package here that INSPECTS the version of the m4 macros its host
provides and refuses to proceed on Ubuntu's serial -- on any Ubuntu
host, x86 included. The check lives in the extracted source, so it is
removed from prepare().
The hook now verifies BOTH that the check is gone and that ./bootstrap
is still invoked, so this particular mistake cannot come back silently.
--- FR ---
La version precedente de ce crochet sautait ./bootstrap entierement, en
supposant que la source etait une archive de version, donc deja
amorcee. Elle ne l est pas -- c est un depot git, et sauter bootstrap
supprimait configure lui-meme :
PKGBUILD: line 43: ./configure: No such file or directory
Cela empirait l etat au lieu de le corriger, et c est mon hypothese qui
etait fausse, pas le paquet.
Ce qu il faut retirer, c est la verification, pas l amorcage. grep est
le seul paquet ici a EXAMINER la version des macros m4 de son hote et a
refuser la serie d Ubuntu -- sur n importe quel hote Ubuntu, x86
compris. La verification vit dans la source extraite : elle est donc
retiree depuis prepare().
Le crochet controle desormais A LA FOIS que la verification a disparu
et que ./bootstrap est toujours appele, pour que cette erreur precise
ne puisse pas revenir en silence.
Assisted-by: Claude Opus 5
grep is the only package here that INSPECTS the version of the m4
macros its build host provides, and refuses to proceed:
./bootstrap: do not use pkg.m4 serial 12
That is not an s390x incompatibility -- the same refusal happens on any
Ubuntu host, x86 included. The release tarball is already bootstrapped,
so re-running ./bootstrap regenerates what is already there and
skipping it costs nothing.
util-linux hits the lib64-versus-lib divergence already handled in
gcc.sh. Here it surfaces as
rm: cannot remove '.../usr/lib/lib*.la': No such file or directory
a glob that matched nothing, which rm reports as a missing file rather
than an empty expansion -- so the error names a path that was never
going to exist. Same remedy: merge the trees before package() touches
anything, leaving the upstream paths working unchanged.
That divergence has now appeared twice. If a third package hits it, it
belongs in the shared bootstrap rather than in per-package hooks.
--- FR ---
grep est le seul paquet ici a EXAMINER la version des macros m4 que lui
fournit son hote, et a refuser de poursuivre :
./bootstrap: do not use pkg.m4 serial 12
Ce n est pas une incompatibilite s390x -- le meme refus survient sur
n importe quel hote Ubuntu, x86 compris. L archive de version est deja
amorcee, donc relancer ./bootstrap regenere ce qui existe deja et le
sauter ne coute rien.
util-linux rencontre la divergence lib64 contre lib deja traitee dans
gcc.sh. Elle apparait ici sous la forme
rm: cannot remove '.../usr/lib/lib*.la': No such file or directory
un motif qui ne correspond a rien, que rm signale comme un fichier
manquant plutot que comme une expansion vide -- l erreur nomme donc un
chemin qui n allait jamais exister. Meme remede : fusionner les arbres
avant que package() ne touche a quoi que ce soit.
Cette divergence est apparue deux fois. Si un troisieme paquet la
rencontre, sa place est dans l amorcage partage et non dans des
crochets par paquet.
Assisted-by: Claude Opus 5
crypto/ec/ec_local.h:520:2: error:
"Can not enable ec_nistp_64_gcc_128 on big-endian systems"
Arch enables this elliptic-curve optimisation, which uses a 128-bit
integer representation that assumes little-endian byte order. s390x is
BIG-endian.
This is the first time in the whole port that endianness -- rather than
word size, instruction set or packaging layout -- decides anything. Ten
packages so far diverged on 32-bit multilib, missing front ends or path
conventions; this one diverges on how bytes are ordered in a word.
OpenSSL refuses at compile time rather than producing wrong results,
which is the right call and makes this one honest to diagnose. Dropping
the flag costs some NIST curve performance and nothing else: the curves
still work through the portable implementation.
--- FR ---
crypto/ec/ec_local.h:520:2: error:
"Can not enable ec_nistp_64_gcc_128 on big-endian systems"
Arch active cette optimisation de courbes elliptiques, qui repose sur
une representation entiere 128 bits supposant l ordre petit-boutiste.
s390x est GROS-boutiste.
C est la premiere fois dans tout le portage que l endianness -- et non
la taille de mot, le jeu d instructions ou la convention de chemins --
tranche quoi que ce soit. Dix paquets ont diverge jusqu ici sur le
multilib 32 bits, des frontaux absents ou des dispositions de
repertoires ; celui-ci diverge sur l ordre des octets dans un mot.
OpenSSL refuse a la compilation plutot que de produire des resultats
faux, ce qui est le bon choix et rend ce cas honnete a diagnostiquer.
Retirer l option coute un peu de performance sur les courbes NIST, et
rien d autre : elles fonctionnent par l implementation portable.
Assisted-by: Claude Opus 5
The PKGBUILD composes its target as "linux-$CARCH", giving
linux-s390x. That IS a valid OpenSSL target -- it is the 31-bit one.
The 64-bit target is linux64-s390x.
This one hid well. The log ends on
Configuring OpenSSL version 3.6.3 for target linux-s390x
and then fails, with the failure appearing to come from nowhere: the
target name is right there, it looks correct, and nothing says the
build is 31-bit on a 64-bit system. Four rounds of keyword grepping
found nothing, because the answer was not in the log at all -- it was
in the PKGBUILD, one line above the command that printed it.
The PKGBUILD already special-cases exactly this for riscv64, so s390x
joins that case rather than getting a mechanism of its own.
filesystem now builds: the gid 11 the host was missing was the whole
of it.
--- FR ---
Le PKGBUILD compose sa cible en « linux-$CARCH », ce qui donne
linux-s390x. C EST une cible OpenSSL valide -- celle du 31 bits. La
cible 64 bits s appelle linux64-s390x.
Celle-la se cachait bien. Le journal s acheve sur
Configuring OpenSSL version 3.6.3 for target linux-s390x
puis echoue, et l echec semble venir de nulle part : le nom de la cible
est la, il a l air juste, et rien ne dit qu on batit du 31 bits sur un
systeme 64 bits. Quatre tours de recherche par mots-cles n ont rien
trouve, parce que la reponse n etait pas dans le journal -- elle etait
dans le PKGBUILD, une ligne au-dessus de la commande qui l imprimait.
Le PKGBUILD traite deja exactement ce cas pour riscv64 ; s390x rejoint
donc cette branche plutot que d obtenir un mecanisme a lui.
filesystem se construit desormais : le gid 11 absent de l hote etait
tout le probleme.
Assisted-by: Claude Opus 5
install: invalid group: '11'
The filesystem package creates directories with `install -g 11`, and
GNU coreutils rejects a gid that resolves to nothing. gid 11 is `ftp`
on Arch; Ubuntu leaves it free.
This is the circular corner of any bootstrap: the package that DEFINES
/etc/group needs groups that do not exist yet. The way out is to give
the build host the target's id map, not to work around the check --
rewriting the install call to force a numeric gid would produce
directories owned by a group the target does not have.
Only the ids Arch uses and Ubuntu lacks are created, and only when
missing, so a host that is already correct is left alone. Checked one
by one: of 1, 2, 10, 11, 12 and 50, only 11 was absent.
--- FR ---
install: invalid group: '11'
Le paquet filesystem cree des repertoires avec « install -g 11 », et
GNU coreutils refuse un gid qui ne resout vers rien. Le gid 11 est
« ftp » sur Arch ; Ubuntu le laisse libre.
C est le coin circulaire de tout amorcage : le paquet qui DEFINIT
/etc/group reclame des groupes qui n existent pas encore. La sortie est
de donner a l hote de compilation la table d identifiants de la cible,
non de contourner la verification -- forcer l interpretation numerique
produirait des repertoires appartenant a un groupe que la cible n a
pas.
Seuls les identifiants qu Arch utilise et qu Ubuntu n a pas sont crees,
et seulement s ils manquent : un hote deja correct n est pas touche.
Verifie un a un : sur 1, 2, 10, 11, 12 et 50, seul le 11 etait absent.
Assisted-by: Claude Opus 5
mv: cannot stat 'usr/lib/libquadmath.a': No such file or directory
libquadmath implements __float128, which exists on x86 and ia64. On
s390x the directory is CONFIGURED -- it holds a Makefile, a config.log
and a config.status -- but no library is ever built. The half-created
directory is what makes this one confusing: it looks like a build that
failed rather than a target that has nothing to build.
Dropped from pkgname, from the _pick lines, and from the depends entry
in another sub-package. That last one matters: with --nodeps it is
harmless at build time and fatal at install time, which is exactly the
kind of defect that surfaces long after the build that introduced it.
package_libquadmath() is left in place. makepkg never calls a function
whose name is absent from pkgname, so removing it would be churn.
util-linux calls "python", which Ubuntu does not provide -- only
python3. python-is-python3 supplies the name.
--- FR ---
mv: cannot stat 'usr/lib/libquadmath.a': No such file or directory
libquadmath implemente __float128, qui existe sur x86 et ia64. Sur
s390x le repertoire est CONFIGURE -- il contient un Makefile, un
config.log et un config.status -- mais aucune bibliotheque n y est
jamais batie. C est ce repertoire a moitie cree qui rend le cas
trompeur : il a l air d une compilation ratee plutot que d une cible
qui n a rien a construire.
Retire de pkgname, des lignes _pick, et de la declaration depends d un
autre sous-paquet. Ce dernier point compte : avec --nodeps il est
inoffensif a la compilation et fatal a l installation, exactement le
genre de defaut qui se revele longtemps apres la compilation qui l a
introduit.
package_libquadmath() reste en place. makepkg n appelle jamais une
fonction dont le nom est absent de pkgname ; la retirer serait du
bruit.
util-linux appelle « python », qu Ubuntu ne fournit pas -- seulement
python3. python-is-python3 fournit le nom.
Assisted-by: Claude Opus 5
package_gcc() reached its very last step and stopped on one file:
mv: cannot stat 'usr/lib/libgfortran.spec': No such file or directory
The file exists, in usr/lib64/libgfortran.spec. lib64 is GCC's default
MULTILIB_OSDIRNAMES for 64-bit Z, while Arch puts everything in
usr/lib. So this is not one stray path: the whole package layout
differs, and every _pick naming usr/lib would miss the same way.
The trees are merged before any _pick runs, which leaves the upstream
package definitions working unchanged rather than rewriting each path
one at a time -- and keeps working if Arch adds a _pick later.
curl now builds, with HTTP/3 disabled and patchelf on the host.
--- FR ---
package_gcc() atteignait sa toute derniere etape et s arretait sur un
seul fichier :
mv: cannot stat 'usr/lib/libgfortran.spec': No such file or directory
Le fichier existe, dans usr/lib64/libgfortran.spec. lib64 est le
MULTILIB_OSDIRNAMES par defaut de GCC pour Z en 64 bits, quand Arch
place tout dans usr/lib. Ce n est donc pas un chemin isole : toute la
disposition du paquet differe, et chaque _pick nommant usr/lib
echouerait de la meme facon.
Les arbres sont fusionnes avant le premier _pick, ce qui laisse les
definitions amont fonctionner sans retouche plutot que de reecrire
chaque chemin un a un -- et continue de tenir si Arch ajoute un _pick
plus tard.
curl se construit desormais, HTTP/3 desactive et patchelf pose sur
l hote.
Assisted-by: Claude Opus 5
gcc failed on what looked like a missing header:
/usr/include/strings.h:23:10: fatal error:
.../gcc-build/prev-gcc/include/stddef.h: No such file or directory
The file was PRESENT when the tree was inspected afterwards. It is not
missing: it is generated by a rule that another rule consumes without
declaring the dependency, and with MAKEFLAGS=-j16 sixteen jobs win that
race often enough to fail. Read as an absent header, it sends you
hunting through include paths for nothing -- and past a set of host
symlinks that were, this time, innocent.
The bound goes into build() inside the PKGBUILD. My first attempt
exported MAKEFLAGS from the hook, which cannot work: hooks run in their
own bash process and never reach makepkg. gcc is the only package here
that bootstraps itself three times, so the limit is local to it.
util-linux wanted libmagic; curl wanted patchelf. Both installed.
--- FR ---
gcc echouait sur ce qui ressemblait a un en-tete manquant :
/usr/include/strings.h:23:10: fatal error:
.../gcc-build/prev-gcc/include/stddef.h: No such file or directory
Le fichier etait PRESENT a l inspection de l arbre apres coup. Il ne
manque pas : il est produit par une regle qu une autre consomme sans
declarer la dependance, et avec MAKEFLAGS=-j16 seize taches gagnent
cette course assez souvent pour echouer. Lu comme un en-tete absent, il
fait fouiller les chemins d inclusion pour rien -- et soupconner des
liens symboliques d hote qui, cette fois, etaient innocents.
La borne va dans build(), a l interieur du PKGBUILD. Ma premiere
tentative exportait MAKEFLAGS depuis le crochet, ce qui ne peut pas
fonctionner : les crochets tournent dans leur propre processus bash et
n atteignent jamais makepkg. gcc est le seul paquet ici a s amorcer
trois fois, la limite lui reste donc locale.
util-linux reclamait libmagic ; curl reclamait patchelf. Poses tous deux.
Assisted-by: Claude Opus 5
A port that does not track what it gave up drifts silently, and the gap
is found years later by whoever needs the missing feature. Every
deliberate difference is now written down, with the hook that
implements it and what it would take to close it.
The document separates two kinds, because the difference matters.
DEFERRED entries were dropped to get the bootstrap moving -- nothing
about s390x prevents them, they cost build time or a host dependency,
and they should come back. ARCHITECTURAL entries drop something that is
x86-specific by nature; there is nothing to restore, and they are
listed so nobody spends an afternoon rediscovering why.
A third section covers what is neither: environment facts, like
dev.gnupg.org being unreachable from this host, which close themselves
elsewhere.
curl joins the deferred list. Arch builds HTTP/3 through nghttp3 and
ngtcp2; Ubuntu packages neither, and building both to reach HTTP/3 is a
detour when pacman and ERPLibre talk to plain HTTPS mirrors. The
dependency declarations and the soname map go with the configure flags:
left in place, the package would claim to need libraries it no longer
links.
--- FR ---
Un portage qui ne trace pas ce qu il a abandonne derive en silence, et
l ecart se decouvre des annees plus tard par celui a qui la
fonctionnalite manque. Chaque difference deliberee est desormais
consignee, avec le crochet qui la met en oeuvre et ce qu il faudrait
pour la refermer.
Le document separe deux natures, parce que la distinction compte. Les
entrees DIFFEREES ont ete abandonnees pour faire avancer l amorcage --
rien dans s390x ne s y oppose, elles coutent du temps de compilation ou
une dependance d hote, et elles doivent revenir. Les entrees
ARCHITECTURALES retirent ce qui est par nature propre a x86 ; il n y a
rien a restaurer, et elles figurent la pour que personne ne passe un
apres-midi a redecouvrir pourquoi.
Une troisieme section couvre ce qui n est ni l un ni l autre : des
faits d environnement, comme dev.gnupg.org injoignable depuis cet hote,
qui se refermeront ailleurs.
curl rejoint la liste des differes. Arch batit HTTP/3 par nghttp3 et
ngtcp2 ; Ubuntu n empaquete ni l un ni l autre, et les batir tous deux
pour atteindre HTTP/3 est un detour quand pacman et ERPLibre parlent a
des miroirs HTTPS ordinaires. Les declarations de dependance et la
table de sonames partent avec les options de configuration : laissees
en place, le paquet pretendrait dependre de bibliotheques qu il ne lie
plus.
Assisted-by: Claude Opus 5
Two more shapes of the same multilib assumption, and the second is a
trap worth naming.
Some _pick lines write the 32-bit path in full:
mv: cannot stat 'usr/lib/gcc/s390x-ibm-linux-gnu/16/32/finclude/'
Others write BOTH paths in one line with a brace expansion --
$_libdir/{,32/}finclude/ expands to the normal path and the 32-bit one.
Deleting such a line would silently lose the path that DOES exist, so
only the alternative is removed: {,32/} and {,32} become nothing.
That distinction matters. A blanket "delete every line mentioning 32"
would have dropped gcc-fortran's finclude, libcaf and libgfortran.spec
from the package, and the loss would only have surfaced later, in
something that failed to link.
Host libraries again: libcryptsetup for util-linux, libgcrypt, libksba
and npth for gnupg, libpam for shadow.
--- FR ---
Deux formes de plus de la meme hypothese multilib, et la seconde est un
piege qui merite d etre nomme.
Certaines lignes _pick ecrivent le chemin 32 bits en entier :
mv: cannot stat 'usr/lib/gcc/s390x-ibm-linux-gnu/16/32/finclude/'
D autres ecrivent les DEUX chemins d un coup par expansion d accolades
-- $_libdir/{,32/}finclude/ produit le chemin normal et celui en 32
bits. Supprimer une telle ligne perdrait en silence le chemin qui
EXISTE, donc seule l alternative disparait : {,32/} et {,32} deviennent
rien.
La distinction compte. Un « supprimer toute ligne mentionnant 32 »
aurait retire finclude, libcaf et libgfortran.spec du paquet
gcc-fortran, et la perte ne serait apparue que plus tard, dans quelque
chose qui refuse de se lier.
Bibliotheques d hote, encore : libcryptsetup pour util-linux, libgcrypt,
libksba et npth pour gnupg, libpam pour shadow.
Assisted-by: Claude Opus 5
Disabling libgccjit took four separate cuts, and this is the fourth.
Removing the second configure pass, the pkgname entry and the _pick
lines still left package_gcc() calling
make -C gcc DESTDIR="$pkgdir" jit.install-common jit.install-info
which fails on a library that was never built:
install: cannot install libgccjit.so.0.0.1
The lesson repeats: in an Arch PKGBUILD a component is referenced in
several independent places -- the pkgname array, a build block, _pick
lines in package(), and explicit make targets. Removing it means
finding all four, and grepping for the component name after each cut is
the only way to know.
shadow and util-linux both stop on a missing libpam. Same family as
every host makedepend before them: invisible until a build names it,
because --nodeps forbids pacman from checking.
--- FR ---
Desactiver libgccjit aura demande quatre coupes distinctes, et voici la
quatrieme. Retirer la seconde passe de configuration, l entree de
pkgname et les lignes _pick laissait encore package_gcc() appeler
make -C gcc DESTDIR="$pkgdir" jit.install-common jit.install-info
qui echoue sur une bibliotheque jamais batie :
install: cannot install libgccjit.so.0.0.1
La lecon se repete : dans un PKGBUILD d Arch, un composant est
reference en plusieurs endroits independants -- le tableau pkgname, un
bloc de compilation, des lignes _pick dans package(), et des cibles
make explicites. Le retirer suppose de trouver les quatre, et chercher
son nom apres chaque coupe est le seul moyen de le savoir.
shadow et util-linux s arretent tous deux sur un libpam absent. Meme
famille que tous les makedepends d hote precedents : invisibles jusqu a
ce qu une compilation les nomme, puisque --nodeps interdit a pacman de
verifier.
Assisted-by: Claude Opus 5
Four packages -- grep, gnupg, pacman and curl -- were failing on my own
driver, not on the port. makepkg -f rebuilds but does not wipe $srcdir,
so a re-run re-entered the previous attempt's tree:
patch: ... already exists! Skipping patch.
1 out of 1 hunk ignored
mkdir: build-curl-compat: File exists
makepkg -C now cleans first. Worth stating plainly: those four looked
like port problems for two full rounds, and were not.
gcc: dropping sub-packages from pkgname was not enough. package_gcc()
_picks files out for every front end regardless of what was requested,
and _pick is a mv, so it fails on what was never built:
mv: cannot stat 'usr/bin/gnat': No such file or directory
The _pick lines for the disabled front ends are removed too.
shadow needed libaudit-dev on the host -- one more makedepend that
--nodeps hides until a build stops on it.
--- FR ---
Quatre paquets -- grep, gnupg, pacman et curl -- echouaient a cause de
mon propre pilote, pas du portage. makepkg -f reconstruit mais ne vide
pas $srcdir, si bien qu une reprise revenait dans l arbre de la
tentative precedente :
patch: ... already exists! Skipping patch.
1 out of 1 hunk ignored
mkdir: build-curl-compat: File exists
makepkg -C nettoie desormais d abord. A dire clairement : ces quatre-la
ont eu l air de problemes de portage pendant deux tours entiers, et ne
l etaient pas.
gcc : retirer les sous-paquets de pkgname ne suffisait pas.
package_gcc() extrait des fichiers pour chaque frontal quoi qu on ait
demande, et _pick est un mv, donc il echoue sur ce qui n a jamais ete
bati :
mv: cannot stat 'usr/bin/gnat': No such file or directory
Les lignes _pick des frontaux desactives sont retirees aussi.
shadow reclamait libaudit-dev sur l hote -- un makedepend de plus que
--nodeps masque jusqu a ce qu une compilation s y arrete.
Assisted-by: Claude Opus 5
Arch configures and compiles the whole gcc tree a SECOND time just for
libgccjit, because it needs --enable-host-shared and applying that to
the main compiler would slow it down. That pass is about half of gcc's
build time -- twenty minutes per attempt on this hardware -- and
nothing in the bootstrap or in ERPLibre uses it.
It is now skipped by default and restored with:
EL_GCC_JIT=1 bash scripts/build-stage1.sh
Verified both ways: off leaves zero libgccjit references in the
PKGBUILD, on leaves the ten upstream ones untouched, including the
--enable-languages=jit line the main-build sed deliberately avoids.
package_gcc() still manipulated the 32-bit tree in several places, and
each fails once multilib is off because usr/lib32 never exists:
'usr/lib/gcc/s390x-ibm-linux-gnu/16/libatomic.so' -> '../../../libatomic.so'
ln: No such file or directory
The link named in that error is the one that SUCCEEDED; the failure is
the usr/lib32 line right after it in the same loop. Read alone, it
sends you hunting for a missing libatomic that is in fact present. The
same loop also linked the D runtimes, gone with the D front end.
--- FR ---
Arch configure et compile l arbre gcc entier une SECONDE fois pour le
seul libgccjit, qui reclame --enable-host-shared -- appliquer cette
option au compilateur principal le ralentirait. Cette passe represente
environ la moitie du temps de compilation de gcc, soit vingt minutes
par tentative sur cette machine, et rien dans l amorcage ni dans
ERPLibre ne s en sert.
Elle est desormais ecartee par defaut et se retablit par :
EL_GCC_JIT=1 bash scripts/build-stage1.sh
Verifie dans les deux sens : desactive, il ne reste aucune reference a
libgccjit dans le PKGBUILD ; active, les dix references amont restent
intactes, y compris la ligne --enable-languages=jit que le sed du
build principal evite deliberement.
package_gcc() manipulait encore l arbre 32 bits en plusieurs endroits,
et chacun echoue une fois le multilib retire, puisque usr/lib32
n existe jamais :
'usr/lib/gcc/s390x-ibm-linux-gnu/16/libatomic.so' -> '../../../libatomic.so'
ln: No such file or directory
Le lien nomme dans cette erreur est celui qui a REUSSI ; l echec est la
ligne usr/lib32 juste apres, dans la meme boucle. Lue seule, elle fait
chercher un libatomic manquant qui est pourtant bien la. La meme boucle
liait aussi les runtimes D, partis avec le frontal D.
Assisted-by: Claude Opus 5
The PKGBUILD configures gcc twice: once for the compiler, once for
libgccjit with --enable-languages=jit. The hook rewrote every
occurrence, so the second tree built a compiler instead of a library
and package() died on
cp: cannot stat 'gcc/libgccjit.so*': No such file or directory
after forty minutes of compiling -- the worst kind of failure, at the
very end, from a patch that looked right.
The sed now skips any line containing jit. A patch that rewrites "every
occurrence" of anything in a PKGBUILD should be suspected by default:
these files configure the same source tree several times, for different
outputs.
--- FR ---
Le PKGBUILD configure gcc deux fois : une fois pour le compilateur, une
fois pour libgccjit avec --enable-languages=jit. Le crochet reecrivait
toutes les occurrences, si bien que le second arbre batissait un
compilateur au lieu d une bibliotheque, et package() mourait sur
cp: cannot stat 'gcc/libgccjit.so*': No such file or directory
apres quarante minutes de compilation -- le pire genre d echec, tout a
la fin, venu d un correctif qui semblait juste.
Le sed ecarte desormais toute ligne contenant jit. Un correctif qui
reecrit « toutes les occurrences » de quoi que ce soit dans un PKGBUILD
doit etre suspecte d office : ces fichiers configurent plusieurs fois le
meme arbre source, pour des sorties differentes.
Assisted-by: Claude Opus 5
