pkgbuilds

Garuda Linux PKGBUILDs

Dieses Repository enthält PKGBUILDs für alle Pakete, die sich derzeit in seinem garuda -Repository befinden. Es wird aufgrund der umfangreichen Nutzung seines CI auf GitLab betrieben und verfügt über einen schreibgeschützten GitHub-Spiegel.

Umfang dieses Repos

Alle unsere eigenen PKGBUILDs sind hier enthalten. Historisch gesehen waren diese in eigene Repositories aufgeteilt. Um das Auffinden des richtigen PKGBUILD zu erleichtern und schnellere Beiträge zu ermöglichen, haben wir sie kürzlich in diesem neuen Repository konsolidiert. Enthalten sind die PKGBUILDs aller Pakete einschließlich ihrer Konfigurationsdateien (dies gilt für kleinere Dateien wie garuda-fish-config ). Bei einigen von ihnen, wie den garuda-*-settings -Paketen, ist der Inhalt möglicherweise immer noch in ihren jeweiligen Repositorys zu finden.

Haben Sie ein Problem gefunden?

Sollten Verpackungsprobleme oder Ähnliches auftreten, zögern Sie nicht, diese über unseren Problembereich zu melden. Sie können hier klicken, um ein neues zu erstellen.

Wie kann ich einen Beitrag leisten?

Wir freuen uns über Beiträge jeglicher Art! ? Gehen Sie dazu bitte wie folgt vor:

• Erstellen Sie einen Fork dieses Repositorys.
• Klonen Sie Ihren Fork lokal (kurzes Git-Tutorial).
• Fügen Sie die gewünschten Änderungen an PKGBUILDs oder Quellcode hinzu.
• Stellen Sie sicher, dass Shellcheck und Shfmt keine Probleme mit den geänderten Dateien melden
  • Die benötigten Abhängigkeiten müssen vorher installiert werden, z. über sudo pacman -S shfmt shellcheck
  • Führen Sie das Skript lint.sh über bash ./.ci/lint.sh Überprüfen Sie den Code
  • Bestimmte Vorschläge automatisch über bash ./ci/lint.sh apply anwenden
• Führen Sie einen Commit mit einer herkömmlichen Commit-Nachricht durch und übertragen Sie alle Änderungen zurück an Ihren Fork.
  • Die Commitiz-Anwendung hilft beim Erstellen einer passenden Commit-Nachricht. Sie können es über pip installieren, da es derzeit kein Paket in Arch-Repos gibt: pip install --user -U Commitizen . Fahren Sie dann fort, indem Sie cz commit im geklonten Ordner ausführen.
• Erstellen Sie eine neue Zusammenführungsanforderung in unserem Haupt-Repository.
• Überprüfen Sie, ob eine der Pipeline-Ausführungen fehlschlägt, und wenden Sie eventuelle Vorschläge an.

Anschließend prüfen wir die Änderungen und führen sie schließlich zusammen.

Umgang mit bestimmten Verpackungsproblemen

Veraltete und defekte Pakete

Es gibt Fälle von veralteten Paketen, die keinen Zweck mehr erfüllen und auch dazu führen, dass Systeme nicht aktualisiert werden können. Diese können behoben werden, indem das Paket zu conflicts() von garuda-common-settings und auto-pacman von garuda-update hinzugefügt wird. Das Ergebnis ist, dass das fehlerhafte Paket aufgrund des Konflikts automatisch entfernt wird.

CI-/Build-Tools

Das Folgende stammt teilweise aus der Dokumentation der Build-Tools und lässt Informationen weg, die für dieses Repo nicht relevant sind. Falls Sie nach Einrichtungsanweisungen suchen, lesen Sie bitte stattdessen die vollständige README-Datei.

Allgemein

Bereitstellungen können automatisch ausgelöst werden, indem entweder Inhalte in einem PKGBUILD-Verzeichnis geändert oder [deploy *] an die Commit-Nachricht angehängt werden. Im Gegensatz zu den PKGBUILD-Prüfungen sind diese nur für Commits im main verfügbar. Unterstützt werden:

• [deploy all] : Stellt eine vollständige garuda Routine bereit, d. h. alle PKGBUILDs in diesem Repository.
• [deploy $pkgname] : Stellt das Paket pkgname bereit, was bedeutet, dass man durch Ersetzen durch garuda-bash-settings garuda-bash-settings bereitstellen würde.

Sobald eine dieser Kombinationen erkannt wird, beginnt die Bereitstellung, nachdem einige Überprüfungen erfolgreich abgeschlossen wurden. Protokolle früherer Bereitstellungen können über den Abschnitt „Pipelines“ eingesehen werden.

Automatisierte Stöße

Dieses Repository stellt eine halbstündliche Pipeline bereit, die alle PKGBUILDs basierend auf dem neuesten verfügbaren Tag auf ihre neuesten Versionen aktualisiert, wenn sich ihre Quelle in einem anderen Repository befindet . Anschließend aktualisiert es die Prüfsummen und überträgt die Änderungen zurück an den Hauptzweig. Eine neue Bereitstellung wird automatisch ausgelöst, indem [deploy *] an die Commit-Nachricht angehängt wird. Das bedeutet, dass es ausreicht, ein neues Tag zu pushen, um die Bereitstellung einer neuen Paketversion für diese Pakete auszulösen. Wichtiger Hinweis:

• Dies gilt nicht für Pakete, deren gesamte Dateien sich in diesem Repository befinden
• Den Tags darf kein v vorangestellt werden
• Benötigte Informationen über die Quelle eines Pakets werden über die SOURCES-Datei bereitgestellt. Jede Zeile folgt dem Schema $url $pkgname $project_id . Letzteres wird zum Abrufen des neuesten Tags über die GitLab-API verwendet und ist auf der Seite mit den allgemeinen Einstellungen des Repositorys zu finden.

Die letzten Ausführungen dieses Jobs können durch Durchsuchen des Abschnitts „Pipelines“ überprüft werden. Jede Pipeline mit dem geplanten Abzeichen wurde vom Timer ausgeführt. Darüber hinaus kann die Pipeline manuell ausgelöst werden, indem Sie den Abschnitt „Pipeline-Zeitpläne“ durchsuchen und auf „Pipeline-Zeitplan ausführen“ klicken.

Manuelles Aktualisieren von Versionen

Bei einigen PKGBUILDs, wie etwa garuda-fish-config , befinden sich alle Dateien in diesem Repository. Stellen Sie beim Aktualisieren von PKGBUILDs bitte sicher, dass Sie auch die entsprechende .SRCINFO Datei aktualisieren, da diese zum Parsen aller paketbezogenen Informationen verwendet wird!

Pakete hinzufügen

Das Hinzufügen von Paketen ist so einfach wie das Erstellen eines neuen Ordners, der nach der $pkgbase des Pakets benannt ist. Legen Sie PKGBUILD und alle anderen erforderlichen Dateien hier ab. Das Hinzufügen von AUR-Paketen ist daher so einfach wie das Klonen des Repositorys und das Entfernen des .git Ordners. CI nutzt .SRCINFO Dateien, um die meisten Informationen zu analysieren. Daher ist es bei selbstverwalteten Paketen wichtig, dass diese vorhanden und auf dem neuesten Stand sind. Fügen Sie abschließend einen .CI Ordner hinzu, der die Basiskonfiguration enthält ( CI_PKGBUILD_SOURCE ist erforderlich, falls das externe Paket, selbstverwaltete PKBUILDs es nicht benötigen), übernehmen Sie alle Änderungen und übertragen Sie die Änderungen zurück an den Hauptzweig. Bitte befolgen Sie dabei die herkömmliche Commit-Konvention (cz-cli kann dabei helfen!). Das bedeutet Commits wie:

• feat($pkgname): init
• fix($pkgname): fix xyz
• chore($pkgname): update PKGBUILD
• ci(config): update

Dies trägt nicht nur zu einem einheitlichen Commit-Verlauf bei, sondern ermöglicht auch die automatische Generierung von Änderungsprotokollen.

Pakete entfernen

Dies kann durch Entfernen des Ordners erfolgen, der das PKGBUILD eines Pakets enthält. Ein Bereinigungsauftrag entfernt dann automatisch alle veralteten Pakete über die on-commit -Pipeline-Ausführung. Dabei werden auch alle geteilten Pakete berücksichtigt, die ein Paket möglicherweise erzeugen könnte. Das Umbenennen von Ordnern zählt auch als Entfernen von Paketen.

On-Commit-Pipeline

Immer wenn ein neues Commit gepusht wird, führt die CI-Pipeline die folgenden Aktionen aus:

• Überprüfen, wann das letzte scheduled Tag erstellt wurde. Dies wird verwendet, um zu bestimmen, welche Pakete geplant werden müssen.
• Es analysiert jedes Commit für eine [deploy $foldername] -Zeichenfolge und akzeptiert nur gültige Werte, die von den vorhandenen PKGBUILD-Ordnern abgeleitet sind. [deploy all] ist ebenfalls ein gültiger Parameter. Eine falsche Schreibweise $pkgname ist hier ein schwerwiegender Fehler. Alle Probleme müssen behoben und zwangsweise behoben werden.
• Anschließend werden die geänderten Dateien analysiert. Hierzu zählen auch entfernte Pakete. Jeder geänderte relevante Ordnerinhalt führt zu einer Paketbereitstellung des entsprechenden Pakets.
• Die letzte Aktion besteht darin, die Zeitplanparameter zu erstellen (über Artefakte an den geplanten Job zu übergeben) und alle veralteten Pakete zu entfernen, falls ein früherer Schritt erkannt wird.
• Wenn alle diese Aktionen erfolgreich sind, wird das scheduled Tag aktualisiert, sodass wir bei einer späteren Pipeline-Ausführung darauf zurückgreifen können.

Termingerechte Pipeline

Halbstündlich

Die termingerechte Pipeline führt alle halbe Stunde einige Aufgaben aus:

• Aktualisieren der CI-Vorlage aus dem Vorlagen-Repository (falls dies über .ci/config aktiviert ist)
• Überprüfen Sie, ob das geplante Tag nicht existiert oder geplant nicht auf HEAD verweist (in diesem Fall Mission abbrechen!)
• Überprüfen Sie, ob der .state-Arbeitsbaum mit dem Status der Pakete vorhanden ist. Ist dies der Fall, wird er eingerichtet. Andernfalls wird es von Grund auf neu erstellt (z. B. bei Force Push).
• Überprüfen Sie, ob der letzte Commit automatisiert ist (enthält „chore(packages): update packets [skip ci]“). Wenn ja, wird er durch den aus dem Zeitplan resultierenden Commit überschrieben, um den Commit-Verlauf sauber zu halten.
• Sammeln Sie AUR-Zeitstempel von Paketen, um festzustellen, ob sich ein PKGBUILD geändert hat
• Durchlaufen Sie jedes gültige Paket und führen Sie die folgenden Aktionen aus:
  • Lesen Sie die Datei .CI/config um Informationen über die Paketkonfiguration zu erhalten (z. B. ob das AUR-Repository verwaltet werden soll, die Quelle von PKGBUILD usw.).
  • Aktualisieren Sie PKGBUILD in den folgenden Fällen:
    • CI_PKGBUILD_SOURCE ist auf gitlab gesetzt: Aktualisiert PKGBUILD aus den GitLab-Repository-Tags
    • CI_PKGBUILD_SOURCE ist auf aur gesetzt: Aktualisiert PKGBUILD aus dem AUR-Repository, zieht das Git-Repo ein und ersetzt die vorhandenen Dateien durch die neuen. Wenn der AUR-Zeitstempel nicht früher erfasst werden konnte, wird die Paketaktualisierung übersprungen.
    • CI_PKGBUILD_SOURCE ist nicht auf gitlab oder aur eingestellt: versucht, PKGBUILD zu aktualisieren, indem das in CI_PKGBUILD_SOURCE angegebene Repository abgerufen wird. Falls das Klonen nach 2 Versuchen nicht erfolgreich war, wird der Update-Vorgang übersprungen.
  • Falls CI_GIT_COMMIT in den Konfigurationsvariablen des Pakets festgelegt ist, wird der letzte Commit der im source von PKGBUILD festgelegten Git-URL aktualisiert. Wenn es anders ist, planen Sie einen Build.
  • Falls ein benutzerdefinierter Hook vorhanden ist ( .CI/update.sh im Paketverzeichnis), wird dieser ausgeführt – dieser kann zum Aktualisieren von PKGBUILDs mit einem benutzerdefinierten Skript verwendet werden.
  • Benötigte Variablen zurück in .CI/config schreiben (z. B. Git-Hash)
• Entweder aktualisieren Sie das PKGBUILD stillschweigend bei geringfügigen Änderungen oder erstellen Sie eine PR zur Überprüfung bei größeren Aktualisierungen (und nur, wenn CI_HUMAN_REVIEW wahr ist).
  • Aktualisierungen werden nur berücksichtigt, wenn diff tatsächlich Änderungen zwischen dem aktuellen PKGBUILD-Ordner und dem AUR PKGBUILD-Repo meldet
  • Alle an den Quelldateien vorgenommenen Änderungen werden erkannt, böswillige Änderungen in der Upstream-Projektquelle, die das Paket erstellt, werden jedoch nicht erkannt
• Der Zustandsarbeitsbaum wird mit neuen Informationen aktualisiert
• Zeitplanparameter werden erstellt und per Artefakt an den geplanten Job übergeben
• Veraltete Zweige (z. B. PRs für zusammengeführte Bewertungen) werden beschnitten
• Das geplante Tag wird erneut aktualisiert

Täglich

Für bestimmte Pakete, deren pkgver dynamisch generiert wird, wurde ein täglicher Pipeline-Zeitplan hinzugefügt. Um es zu nutzen, legen Sie CI_ON_TRIGGER=daily in der .CI/config Datei des Pakets fest.

Manuelle Planung

Planen von Paketen ohne Git-Commits

Pakete können dem Zeitplan manuell hinzugefügt werden, indem Sie zur Seite „Pipelineausführungen“ gehen, „Pipeline ausführen“ auswählen und PACKAGES als Variable mit den Paketnamen als Wert hinzufügen. Die Pipeline holt dann die Pakete ab und plant sie. PACKAGES kann auch auf all gesetzt werden, um alle Pakete zu planen. Falls ein oder mehrere Pakete geplant werden, muss es dem Format pkgname1:pkgname2:pkgname3 folgen.

Geplante Pipelines nach Bedarf ausführen

Gehen Sie dazu zur Seite „Pipeline-Ausführungen“ und wählen Sie „Pipeline ausführen“ (das Wiedergabesymbol). Es wird ein Link zur Pipeline-Seite bereitgestellt, auf der die Pipeline-Protokolle abgerufen werden können.

Hinzufügen stören

Legen Sie die erforderliche Interferenzdatei im .CI Ordner eines PKGBUILD-Ordners ab:

• prepare : Ein Skript, das ausgeführt wird, nachdem die Gebäude-Chroot eingerichtet wurde. Es kann verwendet werden, um Umgebungsvariablen als Quelle zu verwenden oder andere Dinge zu ändern, bevor die Kompilierung beginnt.
  • Wenn vor dem eigentlichen Kompilierungsprozess etwas eingerichtet werden muss, können Befehle durch Einfügen von z. B. gepusht werden. $CAUR_PUSH 'source /etc/profile' . Ebenso können Paketkonflikte gelöst werden, z.B. wie folgt: $CAUR_PUSH 'yes | pacman -S nftables' (einfache Anführungszeichen sind wichtig, da wir möchten, dass die Variablen/Pipes in der Laufzeit des Gasts ausgewertet werden und nicht, während sie stören)
• interfere.patch : eine Patch-Datei, die zum Reparieren mehrerer Dateien oder von PKGBUILD verwendet werden kann, wenn viele Änderungen erforderlich sind. Alle Änderungen müssen dieser Datei hinzugefügt werden.
• PKGBUILD.prepend : Der Inhalt dieser Datei wird am Anfang von PKGBUILD hinzugefügt.
• PKGBUILD.append : Der Inhalt dieser Datei wird am Ende von PKGBUILD hinzugefügt. Das Reparieren von build() ist so einfach wie das Hinzufügen des korrigierten build() zu dieser Datei. Dies kann für alle Arten von Korrekturen verwendet werden. Wenn einem Array etwas hinzugefügt werden muss, ist dies so einfach wie makedepend+=(somepackage) .
• on-failure.sh : Ein Skript, das ausgeführt wird, wenn der Build fehlschlägt.
• on-success.sh : Ein Skript, das ausgeführt wird, wenn der Build erfolgreich ist.

Anstoßendes Paket

Dies geschieht nun durch Hinzufügen der erforderlichen Variablen CI_PACKAGE_BUMP zu .CI/config . Weitere Informationen finden Sie weiter unten.

Abhängigkeitsbäume

Das CI erstellt automatisch Abhängigkeitsbäume. Sie werden als CI-Artefakt an den Chaotic-Manager übergeben und immer dann gelesen, wenn ein Zeitplanbefehl ausgeführt wird. Es ist kein manueller Eingriff erforderlich.

.CI/config

Die .CI/config Datei in jedem Paketverzeichnis enthält zusätzliche Flags zur Steuerung der Pipelines und Build-Prozesse.

• CI_MANAGE_AUR : Wenn Sie diese Variable auf true setzen, aktualisiert das CI das entsprechende AUR-Repository am Ende eines Pipeline-Laufs, wenn Änderungen auftreten (CI-bezogene Dateien werden dabei weggelassen).
• CI_PACKAGE_BUMP : Steuert Paket-Bumps für alle Pakete, bei denen CI_MANAGE_AUR nicht auf true gesetzt ist. Es erhöht pkgrel um 0.1 für jede +1 Erhöhung dieser Variablen.
• CI_PKGBUILD_SOURCE : Legt die Quelle für alle PKGBUILD-bezogenen Dateien fest, die zum Abrufen aktualisierter Dateien aus Remote-Repositorys verwendet werden. Derzeit gültige Werte sind:
  • gitlab : Ruft das PKGBUILD aus den GitLab-Repository-Tags ab. Es muss dem Format gitlab:$PROJECT_ID folgen. Die ID erhalten Sie, indem Sie den allgemeinen Abschnitt der Repository-Einstellungen durchsuchen.
  • aur : Ruft das PKGBUILD aus dem AUR-Repository ab, zieht das Git-Repo ein und ersetzt die vorhandenen Dateien durch die neuen.
• CI_ON_TRIGGER : Kann bereitgestellt werden, falls ein spezieller Zeitplan-Trigger das entsprechende Paket planen soll. Dies kann verwendet werden, um Pakete täglich zu planen, indem der Wert auf daily gesetzt wird. Da dadurch geprüft wird, ob „$TRIGGER == $CI_ON_TRIGGER“ ist, kann jeder benutzerdefinierte Zeitplan erstellt werden, indem Pipeline-Zeitpläne verwendet und TRIGGER auf midnight gesetzt wird, indem ein passender Zeitplan hinzugefügt und CI_ON_TRIGGER für jedes betroffene Paket auf midnight gesetzt wird.
• CI_REBUILD_TRIGGERS : Fügen Sie Pakete hinzu, von denen bekannt ist, dass sie Neuerstellungen zu dieser Variablen verursachen. Über den CI_LIB_DB -Parameter der Repositorys wird eine Liste der Repositorys bereitgestellt, für die Paketversionen verfolgt werden sollen. Jede Paketversion wird gehasht und in .ci/lib.state gespeichert. Jeder geplante Pipeline-Lauf vergleicht Versionen durch Überprüfung von Hash-Nichtübereinstimmungen und stößt jedes betroffene Paket über CI_PACKAGE_BUMP an.
• BUILDER_CACHE_SOURCES : Kann auf true gesetzt werden, falls die Quellen zwischen Builds zwischengespeichert werden sollen. Dies kann bei langsamen Quellen oder Quellen, die nicht immer verfügbar sind, nützlich sein. Quellen werden nach einem Monat automatisch gelöscht. Dies ist wichtig für den Fall, dass Pakete entfernt werden oder sich die Quelle ändert.

AUR-Pakete verwalten

AUR-Pakete können über dieses Repository auch automatisiert mit .CI_CONFIG verwaltet werden. Das bedeutet, dass das AUR-Repository nach jeder geplanten und festgeschriebenen Pipeline aktualisiert wird, um die an den Dateien des PKGBUILD-Ordners vorgenommenen Änderungen widerzuspiegeln. Dateien, die für die AUR-Wartung nicht relevant sind (z. B. .CI Ordner), werden weggelassen. Die Commit-Nachricht spiegelt die Tatsache wider, dass der Commit von einer CI-Pipeline erstellt wurde, und enthält den Link zum Commit-Verlauf des Quell-Repositorys und zur Pipeline-Ausführung, die den Update-Commit ausgelöst hat.

Aktualisieren der CI-Skripte

Dies erfolgt automatisch über die CI-Pipeline. Sobald Änderungen im Vorlagen-Repository erkannt werden, werden alle Dateien auf die aktuelle Version aktualisiert.

Probleme und Pipeline-Ausfälle

Die letzte On-Commit-Pipeline ist fehlgeschlagen

Dies kann aus mehreren Gründen passieren, beispielsweise wenn ein ungültiger Paketname angegeben wurde. Dies führt dazu, dass das scheduled Tag nicht aktualisiert wird. In diesem Fall kann die termingerechte Pipeline nicht ausgeführt werden. Die letzte On-Commit-Pipeline muss repariert werden, bevor die On-Schedule-Pipeline wieder ausgeführt werden kann. Buildfehler werden jedoch nicht berücksichtigt, da das scheduled Tag bereits aktualisiert würde, sobald die Planungsparameter generiert wurden. In einem solchen Fall wird das erzwungene Pushen eines festen Commits aktiv gefördert, da das Pushen eines anderen Commits dazu führt, dass das CI die vorherigen Commits auswertet, die es verpasst hat, was dazu führt, dass dasselbe Problem erneut bemerkt wird und aussteigt, anstatt stillschweigend fortzufahren. Dies war eine Entwurfsentscheidung, um zu verhindern, dass Fehler übersehen werden.

Zurücksetzen der Build-Warteschlange

In seltenen Fällen kann ein Zurücksetzen der Build-Warteschlange erforderlich sein. Dies kann durch Herunterfahren der zentralen Redis-Instanz, Entfernen ihres Dumps und Neustarten ihres Dienstes erfolgen.

Chaotischer Manager

Dieses Tool wird als Docker-Container verteilt und besteht aus einem Paar Manager- und Builder-Instanzen.

• Manager: registry.gitlab.com/garuda-linux/tools/chaotic-manager/manager
• Builder: registry.gitlab.com/garuda-linux/tools/chaotic-manager/builder
  • Dieses enthält die eigentliche Logik hinter Paket-Builds (hier zu sehen), die aus Infra 3.0 bekannt sind, wie interfere.sh , database.sh usw.
  • Wählt Pakete zum Erstellen aus der Redis-Instanz aus, die von der Manager-Instanz verwaltet wird

Der Manager wird von GitLab CI im schedule-package -Job verwendet und plant Pakete, indem es zur Build-Warteschlange hinzugefügt wird. Der Builder kann von jedem Computer verwendet werden, der den Container ausführen kann. Es wählt verfügbare Jobs aus unserer zentralen Redis-Instanz aus.

Entwicklungsaufbau

Dieses Repository verfügt über einen NixOS-Flake, der verwendet werden kann, um die erforderlichen Dinge wie Pre-Commit-Hooks und -Prüfungen sowie benötigte Dienstprogramme automatisch über direnv einzurichten. Dazu gehört die Überprüfung von PKGBUILDs per shellcheck und shfmt . Benötigt werden nix (der Paketmanager) und direnv. Danach kann die Umgebung durch Ausführen direnv allow betreten werden.