From 5a5526ad352230bf29722d25eda6a7cbbc326d85 Mon Sep 17 00:00:00 2001 From: "Danilo M." Date: Sat, 4 Jul 2026 11:00:53 +0200 Subject: content: add Package buildsystem Slackware page New bilingual system/architecture page narrating the whole slackware64-current build pipeline: the QEMU VM, repo assembly (slackrepo_setup), the phantom-dep hint layer (mkhint), building (slackrepo, aclemons fork), publishing (finish hooks + pkgs-html-structure), and the separate 15.0 stable-testing safety net (sbo-batch-tester). Includes a theme-styled SVG pipeline flowchart, three inline repo CTAs, and a closing sign-off. Menu entry under the Slackware parent (weight 20). Spec and plan updated to match. Co-Authored-By: Claude Opus 4.8 --- .../en/slackware/buildsystem/buildsystem-flow.svg | 8 ++ content/en/slackware/buildsystem/header.jpg | Bin 0 -> 57329 bytes content/en/slackware/buildsystem/index.md | 121 +++++++++++++++++++ content/en/slackware/buildsystem/thumbnail.jpg | Bin 0 -> 34722 bytes .../it/slackware/buildsystem/buildsystem-flow.svg | 8 ++ content/it/slackware/buildsystem/header.jpg | Bin 0 -> 57329 bytes content/it/slackware/buildsystem/index.md | 128 +++++++++++++++++++++ content/it/slackware/buildsystem/thumbnail.jpg | Bin 0 -> 34722 bytes 8 files changed, 265 insertions(+) create mode 100644 content/en/slackware/buildsystem/buildsystem-flow.svg create mode 100644 content/en/slackware/buildsystem/header.jpg create mode 100644 content/en/slackware/buildsystem/index.md create mode 100644 content/en/slackware/buildsystem/thumbnail.jpg create mode 100644 content/it/slackware/buildsystem/buildsystem-flow.svg create mode 100644 content/it/slackware/buildsystem/header.jpg create mode 100644 content/it/slackware/buildsystem/index.md create mode 100644 content/it/slackware/buildsystem/thumbnail.jpg (limited to 'content') diff --git a/content/en/slackware/buildsystem/buildsystem-flow.svg b/content/en/slackware/buildsystem/buildsystem-flow.svg new file mode 100644 index 0000000..877f59e --- /dev/null +++ b/content/en/slackware/buildsystem/buildsystem-flow.svg @@ -0,0 +1,8 @@ +SLACKWARE64-CURRENT · ONE QEMU VMThe package buildsystemHow a SlackBuild becomes a published package, in the order a build happens.1▤Assemble the repoSLACKREPO_SETUPMY TOOLWeekly: clone Ponce's SBo current, overlay my-slackbuilds +Slackware-Pentesting-Suite as subtrees, shadow duplicates.2◈Fix -current depsMKHINT -FMY TOOLSweep the tree and write DELREQUIRES hints for phantomdeps that -current already ships.3⚙BuildSLACKREPOUPSTREAMCompile each package + deps in a clean chroot, track gitrevisions to rebuild only what moved.4☁PublishFINISH HOOKS + REPO-HTML-STRUCTUREMY TOOLRegenerate slackpkg+ metadata, build the themed HTMLfrontend, rsync live to packages.danix.xyz, notify.Test on 15.0 stableSBO-BATCH-TESTERMY TOOLFor my own SBo-bound packages only: build in a disposable overlaychroot over clean Slackware 15.0 to catch current-vs-stable drift.↳ BEFORE SBo SUBMIT · SIDE PATH (does not gate the main pipeline)↻ Weekly cycle: reassemble → fix deps → build → publish, with a 15.0 spot-test for anything headed upstream. \ No newline at end of file diff --git a/content/en/slackware/buildsystem/header.jpg b/content/en/slackware/buildsystem/header.jpg new file mode 100644 index 0000000..15ca99e Binary files /dev/null and b/content/en/slackware/buildsystem/header.jpg differ diff --git a/content/en/slackware/buildsystem/index.md b/content/en/slackware/buildsystem/index.md new file mode 100644 index 0000000..9db3f14 --- /dev/null +++ b/content/en/slackware/buildsystem/index.md @@ -0,0 +1,121 @@ ++++ +title = "Package buildsystem" +tagline = "How I build and publish my personal slackware64-current package repository." +status = "active" +tags = ["slackware", "slackrepo", "packaging", "buildsystem"] + +[menus.main] + name = "buildsystem" + parent = "slackware" + weight = 20 ++++ + +My personal Slackware packages for **slackware64-current** are built by a small +pipeline of tools running inside one dedicated QEMU virtual machine. Nothing here +is a single program: it is a repository that gets reassembled, a dependency layer +that gets patched, a builder that turns SlackBuilds into packages, and a +publishing step that puts them online at +[packages.danix.xyz](https://packages.danix.xyz). This page walks the whole flow +in the order a build actually happens. + +{{< image src="buildsystem-flow.svg" alt="Flowchart of the package buildsystem: assemble the repo with slackrepo_setup, fix -current dependencies with mkhint, build with slackrepo, and publish through the finish hooks, with a separate green side path for testing on Slackware 15.0 stable before submitting to SBo." caption="The pipeline end to end. The green side path is the 15.0 stable test, run only for packages headed to SlackBuilds.org." />}} + +## The VM + +The buildsystem lives in a QEMU virtual machine running **slackware64-current**, +kept up to date with `slackpkg` against a local mirror of Slackware's own system +packages. It has 8 CPU cores and around 8 GB of RAM, enough to build all but the +heaviest packages comfortably, and I reach it over SSH. Keeping it in its own VM +means a build, a broken dependency, or a full repository regeneration never +touches my daily driver: the box exists to be hammered and, if needed, thrown +away and rebuilt. + +## Assembling the repository + +Once a week the SlackBuilds tree is regenerated from scratch. It starts as a +clone of [Ponce's slackbuilds](https://github.com/Ponce/slackbuilds) checked out +on the `current` branch, the community tree that tracks SlackBuilds.org against +slackware-current. On top of that I overlay my own two collections as squashed +git subtrees: [my-slackbuilds](https://github.com/danixland/my-slackbuilds) for +general personal packages and +[Slackware-Pentesting-Suite](https://github.com/danixland/Slackware-Pentesting-Suite) +for security tooling. + +Where a personal package shares a name with an upstream one, the upstream copy is +*shadowed*: its directory is removed so my version wins. The result is a single +local tree that is standard SBo plus my additions, ready to build. That whole +assembly is one script, which will get its own page here later. + +## The -current dependency problem + +SBo SlackBuilds target Slackware **stable**, so some of their build-time +dependencies are unnecessary on -current, which already ships them as system +packages or newer versions. `rust-opt` and `google-go-lang` are typical: needed +on stable, pointless on -current. These "phantom" dependencies would otherwise +force needless rebuilds. + +slackrepo strips a dependency from a package with a per-package hint file carrying +`DELREQUIRES`, but writing one by hand for every affected package after each +weekly regeneration is exactly the tedium a script should own. That job belongs to +[mkhint](/slackware/mkhint/): its `-F` sweep reads a list of phantom deps and, for +every package whose requirements hit one, writes or merges the right +`DELREQUIRES` across the freshly rebuilt tree in a single pass. + +{{< actions use="repo" url="https://git.danix.xyz/mkhintfile/" desc="Read the mkhint source" caption="Curious how the phantom-dep sweep actually works? The whole thing is one Bash script." >}} + +## Building + +The actual building is done by +[slackrepo](https://github.com/aclemons/slackrepo), an automated SlackBuild +builder for Slackware, now maintained by Andrew Clemons. It compiles each package and its dependencies in a clean +chroot, tracks upstream git revisions to work out what has changed and needs +rebuilding, and produces a repository that plugs straight into `slackpkg+`. I run +it with a start hook that first rebases my SlackBuilds tree onto upstream, so +every build starts from a current tree, and it handles the dependency ordering so +a single command rebuilds everything that moved. + +## Publishing + +When a build finishes, a chain of slackrepo finish hooks takes over. They +regenerate the `slackpkg+` repository metadata, build the styled HTML frontend for +the package site, sync the result out to the live server, and send a notification +that the run is done. The frontend wraps Apache's plain directory autoindex in a +themed header and footer so [packages.danix.xyz](https://packages.danix.xyz) reads +as a proper repository rather than a bare file listing. That frontend is its own +small project and will get a page here later too. + +{{< actions use="repo" url="https://git.danix.xyz/pkgs-html-structure/" desc="See the frontend generator" caption="It is mostly a shell hook that walks the package tree and writes the header and footer HTML. Have a look under the hood." >}} + +## Testing against 15.0 stable + +Some of the packages I write are meant to be submitted upstream to +SlackBuilds.org, which targets Slackware **stable**, not -current. Since my whole +buildsystem is -current, a package building fine here proves nothing about 15.0. +Before I submit one, I test it with a separate, independent tool built for exactly +that: it resolves the SlackBuild's dependency tree locally, then builds and +installs every package in a fresh disposable overlay chroot layered over a clean, +read-only Slackware 15.0 base. That catches the current-versus-15.0 drift a +-current build hides. + +It does not touch or drive slackrepo, and its built packages are throwaway: the +only question it answers is "does this still build clean on 15.0". One limit worth +naming: it shares the host kernel, so packages that build kernel modules still +want a real 15.0 VM. This tool will also get its own page here in time. + +{{< actions use="repo" url="https://git.danix.xyz/sbo-batch-tester/" desc="Browse sbo-batch-tester" caption="The overlay-chroot and dependency-resolution logic live here if you want to read how the 15.0 test is built." >}} + +## The weekly rhythm + +Put together, the week is one repeatable cycle: regenerate the SlackBuilds tree, +sweep the phantom-dependency hints with `mkhint -F`, build and publish with +slackrepo and its hooks, and, for anything headed to SlackBuilds.org, spot-test it +against a clean 15.0 base first. Four small tools, each doing one job well, and a +disposable VM to run them in. Very Slackware. + +I hope you found this walk through my buildsystem interesting. If you end up +running something similar, or you have questions, ideas, or suggestions about any +piece of it, drop me a line and I will gladly get in touch. + +See you next time. + +{{< actions use="repo" url="https://packages.danix.xyz" desc="Browse the package repository" caption="Everything the buildsystem produces lands here. If you run slackware64-current, you can point slackpkg+ at it and pull my packages straight in." >}} diff --git a/content/en/slackware/buildsystem/thumbnail.jpg b/content/en/slackware/buildsystem/thumbnail.jpg new file mode 100644 index 0000000..7cf816b Binary files /dev/null and b/content/en/slackware/buildsystem/thumbnail.jpg differ diff --git a/content/it/slackware/buildsystem/buildsystem-flow.svg b/content/it/slackware/buildsystem/buildsystem-flow.svg new file mode 100644 index 0000000..877f59e --- /dev/null +++ b/content/it/slackware/buildsystem/buildsystem-flow.svg @@ -0,0 +1,8 @@ +SLACKWARE64-CURRENT · ONE QEMU VMThe package buildsystemHow a SlackBuild becomes a published package, in the order a build happens.1▤Assemble the repoSLACKREPO_SETUPMY TOOLWeekly: clone Ponce's SBo current, overlay my-slackbuilds +Slackware-Pentesting-Suite as subtrees, shadow duplicates.2◈Fix -current depsMKHINT -FMY TOOLSweep the tree and write DELREQUIRES hints for phantomdeps that -current already ships.3⚙BuildSLACKREPOUPSTREAMCompile each package + deps in a clean chroot, track gitrevisions to rebuild only what moved.4☁PublishFINISH HOOKS + REPO-HTML-STRUCTUREMY TOOLRegenerate slackpkg+ metadata, build the themed HTMLfrontend, rsync live to packages.danix.xyz, notify.Test on 15.0 stableSBO-BATCH-TESTERMY TOOLFor my own SBo-bound packages only: build in a disposable overlaychroot over clean Slackware 15.0 to catch current-vs-stable drift.↳ BEFORE SBo SUBMIT · SIDE PATH (does not gate the main pipeline)↻ Weekly cycle: reassemble → fix deps → build → publish, with a 15.0 spot-test for anything headed upstream. \ No newline at end of file diff --git a/content/it/slackware/buildsystem/header.jpg b/content/it/slackware/buildsystem/header.jpg new file mode 100644 index 0000000..15ca99e Binary files /dev/null and b/content/it/slackware/buildsystem/header.jpg differ diff --git a/content/it/slackware/buildsystem/index.md b/content/it/slackware/buildsystem/index.md new file mode 100644 index 0000000..7b02412 --- /dev/null +++ b/content/it/slackware/buildsystem/index.md @@ -0,0 +1,128 @@ ++++ +title = "Package buildsystem" +tagline = "Come costruisco e pubblico il mio repository personale di pacchetti per slackware64-current." +status = "active" +tags = ["slackware", "slackrepo", "packaging", "buildsystem"] + +[menus.main] + name = "buildsystem" + parent = "slackware" + weight = 20 ++++ + +I miei pacchetti Slackware personali per **slackware64-current** sono costruiti da +una piccola pipeline di strumenti che gira dentro un'unica macchina virtuale QEMU +dedicata. Niente qui è un singolo programma: c'è un repository che viene +riassemblato, uno strato di dipendenze che viene corretto, un builder che +trasforma gli SlackBuild in pacchetti e un passo di pubblicazione che li mette +online su [packages.danix.xyz](https://packages.danix.xyz). Questa pagina segue +l'intero flusso nell'ordine in cui una build avviene davvero. + +{{< image src="buildsystem-flow.svg" alt="Diagramma di flusso del buildsystem: assemblaggio del repository con slackrepo_setup, correzione delle dipendenze -current con mkhint, build con slackrepo e pubblicazione tramite gli hook finali, con un ramo laterale verde separato per il test su Slackware 15.0 stable prima dell'invio a SBo." caption="La pipeline dall'inizio alla fine. Il ramo laterale verde è il test su 15.0 stable, eseguito solo per i pacchetti diretti a SlackBuilds.org." />}} + +## La VM + +Il buildsystem vive in una macchina virtuale QEMU che esegue +**slackware64-current**, tenuta aggiornata con `slackpkg` da un mirror locale dei +pacchetti di sistema di Slackware. Ha 8 core CPU e circa 8 GB di RAM, abbastanza +per compilare comodamente tutti i pacchetti tranne i più pesanti, e vi accedo via +SSH. Tenerla in una VM dedicata fa sì che una build, una dipendenza rotta o una +rigenerazione completa del repository non tocchino mai la mia macchina di tutti i +giorni: quella scatola esiste per essere martellata e, se serve, buttata via e +ricostruita. + +## Assemblare il repository + +Una volta a settimana l'albero degli SlackBuild viene rigenerato da zero. Parte +come clone degli [slackbuilds di Ponce](https://github.com/Ponce/slackbuilds) sul +branch `current`, l'albero della community che segue SlackBuilds.org su +slackware-current. Sopra vi sovrappongo le mie due collezioni come git subtree +compressi: [my-slackbuilds](https://github.com/danixland/my-slackbuilds) per i +pacchetti personali generici e +[Slackware-Pentesting-Suite](https://github.com/danixland/Slackware-Pentesting-Suite) +per gli strumenti di sicurezza. + +Dove un pacchetto personale condivide il nome con uno upstream, la copia upstream +viene *oscurata*: la sua directory viene rimossa perché vinca la mia versione. Il +risultato è un unico albero locale che è SBo standard più le mie aggiunte, pronto +per la build. Tutto questo assemblaggio è uno script, che avrà una sua pagina qui +più avanti. + +## Il problema delle dipendenze su -current + +Gli SlackBuild di SBo puntano a Slackware **stable**, quindi alcune delle loro +dipendenze di compilazione sono inutili su -current, che le fornisce già come +pacchetti di sistema o in versioni più recenti. `rust-opt` e `google-go-lang` sono +tipiche: servono su stable, sono superflue su -current. Queste dipendenze +"fantasma" costringerebbero altrimenti a ricompilazioni inutili. + +slackrepo rimuove una dipendenza da un pacchetto con un hint file per pacchetto che +contiene `DELREQUIRES`, ma scriverne uno a mano per ogni pacchetto interessato +dopo ogni rigenerazione settimanale è proprio la noia di cui uno script dovrebbe +farsi carico. Quel compito spetta a [mkhint](/it/slackware/mkhint/): il suo sweep +`-F` legge una lista di dipendenze fantasma e, per ogni pacchetto le cui dipendenze +ne toccano una, scrive o unisce il `DELREQUIRES` giusto in tutto l'albero appena +ricostruito, in un solo passaggio. + +{{< actions use="repo" url="https://git.danix.xyz/mkhintfile/" desc="Leggi il sorgente di mkhint" caption="Curioso di come funziona davvero lo sweep delle dipendenze fantasma? È tutto un singolo script Bash." >}} + +## La build + +La compilazione vera e propria è affidata a +[slackrepo](https://github.com/aclemons/slackrepo), un builder automatico di +SlackBuild per Slackware, ora mantenuto da Andrew Clemons. Compila ogni pacchetto e le sue dipendenze in un chroot +pulito, segue le revisioni git upstream per capire cosa è cambiato e va +ricostruito, e produce un repository che si aggancia direttamente a `slackpkg+`. +Lo eseguo con un hook iniziale che prima ribasa il mio albero di SlackBuild su +upstream, così ogni build parte da un albero aggiornato, e gestisce l'ordine delle +dipendenze in modo che un singolo comando ricostruisca tutto ciò che si è mosso. + +## Pubblicazione + +Quando una build finisce, subentra una catena di hook finali di slackrepo. +Rigenerano i metadati del repository per `slackpkg+`, costruiscono il frontend HTML +a tema per il sito dei pacchetti, sincronizzano il risultato sul server live e +inviano una notifica di fine esecuzione. Il frontend avvolge il semplice autoindex +delle directory di Apache in un header e un footer a tema, così +[packages.danix.xyz](https://packages.danix.xyz) si legge come un vero repository e +non come un nudo elenco di file. Anche quel frontend è un suo piccolo progetto e +avrà una pagina qui più avanti. + +{{< actions use="repo" url="https://git.danix.xyz/pkgs-html-structure/" desc="Guarda il generatore del frontend" caption="È soprattutto un hook shell che percorre l'albero dei pacchetti e scrive l'HTML di header e footer. Dai un'occhiata sotto il cofano." >}} + +## Test contro 15.0 stable + +Alcuni dei pacchetti che scrivo sono destinati a essere proposti a monte su +SlackBuilds.org, che punta a Slackware **stable**, non a -current. Dato che tutto +il mio buildsystem è -current, il fatto che un pacchetto compili bene qui non dice +nulla su 15.0. Prima di proporne uno, lo testo con uno strumento separato e +indipendente pensato esattamente per questo: risolve localmente l'albero delle +dipendenze dello SlackBuild, poi costruisce e installa ogni pacchetto in un chroot +overlay usa e getta stratificato su una base Slackware 15.0 pulita e in sola +lettura. Così emerge lo scostamento tra -current e 15.0 che una build su -current +nasconde. + +Non tocca né guida slackrepo, e i pacchetti che produce sono usa e getta: l'unica +domanda a cui risponde è "compila ancora pulito su 15.0". Un limite da segnalare: +condivide il kernel dell'host, quindi i pacchetti che costruiscono moduli del +kernel vogliono comunque una vera VM 15.0. Anche questo strumento avrà la sua +pagina qui col tempo. + +{{< actions use="repo" url="https://git.danix.xyz/sbo-batch-tester/" desc="Esplora sbo-batch-tester" caption="La logica dell'overlay-chroot e della risoluzione delle dipendenze è qui, se vuoi leggere come è costruito il test su 15.0." >}} + +## Il ritmo settimanale + +Messo insieme, la settimana è un unico ciclo ripetibile: rigenerare l'albero degli +SlackBuild, spazzare gli hint delle dipendenze fantasma con `mkhint -F`, costruire +e pubblicare con slackrepo e i suoi hook e, per tutto ciò che è diretto a +SlackBuilds.org, testarlo prima contro una base 15.0 pulita. Quattro piccoli +strumenti, ciascuno che fa bene un solo lavoro, e una VM usa e getta in cui +eseguirli. Molto Slackware. + +Spero che questo giro nel mio buildsystem ti sia sembrato interessante. Se +finisci per metterne in piedi uno simile, o hai domande, idee o suggerimenti su +qualunque suo pezzo, scrivimi due righe e sarò felice di risponderti. + +Alla prossima. + +{{< actions use="repo" url="https://packages.danix.xyz" desc="Sfoglia il repository dei pacchetti" caption="Tutto ciò che il buildsystem produce finisce qui. Se usi slackware64-current, puoi puntarci slackpkg+ e tirare dentro i miei pacchetti direttamente." >}} diff --git a/content/it/slackware/buildsystem/thumbnail.jpg b/content/it/slackware/buildsystem/thumbnail.jpg new file mode 100644 index 0000000..7cf816b Binary files /dev/null and b/content/it/slackware/buildsystem/thumbnail.jpg differ -- cgit v1.2.3