ITADN
chaotic-aur/packages
代码 动态 Issues1440 合并请求60 版本
chaotic-aur/packages · 文件 下载 ZIP
文件最后提交记录最后更新时间
README.md
以下内容由 AI 翻译，如有问题请点此提交 issue 反馈

Chaotic-AUR PKGBUILDs

这是提交 Chaotic-AUR 📜 的包请求、错误报告或过时包的正确位置

⚠️ 我们已于 10 月 18 日全面切换至 新的 infra 4.0，这意味着我们 现在运行在 GitLab CI 上！ 虽然我们仍然接受在 GitHub 上我们之前的 packages 仓库中提交的问题和错误报告， 但所有流水线、更新以及总体上的持续进展将主要发生在另一边。 旧仓库将作为仅推送镜像保留。

Chaotic-AUR

我们已构建的一些软件包

本仓库中的每个文件夹都会由我们的构建系统进行构建， 有关当前排队中的软件包和构建日志的信息， 请查看我们的 build status page！ 🕵️‍♀️

带有当前版本的完整软件包列表也可在 here 获取。

修改过的软件包

虽然我们更倾向于在不修改的情况下构建 AUR 软件包，但这样做往往不切实际或不可能。

  • 可能缺少依赖项、选项或命令。
  • 可能存在错误的选项或命令。
  • 软件包可能在不进行更改的情况下无法构建或运行。
  • 软件包可能不符合打包标准。

为解决此类问题：

  • 构建系统会自动纠正一些常见错误。
  • 可以通过 interfere 应用手动修正
  • 可以将原始软件包 fork 为自定义软件包。

特殊软件包

  • chaotic-keyring: 用于验证 Chaotic-AUR 软件包签名的公钥。
  • chaotic-mirrorlist: 镜像 Chaotic-AUR 软件包的服务器列表。
  • chaotic-interfere: 指示手动应用的 interferes 的标记。此软件包_不_打算被安装。

被禁止和拒绝的软件包 📑

以下是我们将因合理原因拒绝的软件包列表：

  • snapd: 我们不知道如何帮助用户处理它，因为它会破坏_大量_内容。我们建议使用原生软件包 或 FlatPak 代替。 此外，有很多其他原因不建议使用 Snaps。

  • lib32-*: 随着其有用性降低，维护 32 位软件包的难度正在增加。它们可能被视为保持现有软件包正常工作，例如 wine-*。否则，在可用时使用 64 位软件包。

  • gst-plugins-{ugly,bad}: 这些需要过于频繁地重新构建，这是我们无法处理的，因为我们不控制软件包的 pkgrel。最终这会导致糟糕的用户体验。

  • ffmpeg-headless: 需要过于频繁地重新构建，这是我们无法处理的，因为我们不控制 软件包的 pkgrel。最终这会导致糟糕的用户体验。

  • mpv-amd, ffmpeg-amd: 这只是没有 CUDA 和 NVENC 的 MPV/FFMPEG，以实现更短的构建时间而没有实际的 最终用户收益。

  • unreal-engine (and -git): 一些镜像没有足够的存储空间。

  • python2: 已经 EOL 多年，并且 已从 Arch 仓库中移除。

  • linux-ck：其他内核包含相同的优化，并且可从 repo-ck 获取官方预编译二进制文件。

  • 使用 EOL、非标准或修改版 Electron 的软件包。将 Electron 用作 Web 浏览器的软件包。

  • 没有任何依赖者的依赖项：此类软件包本身毫无用处。维护它们会浪费本可更好用于其他地方的精力。

因许可问题被禁止 🛑

  • AMDGPU PRO 驱动程序。禁止重新分发软件和文档。

  • aseprite{-git}：其 FAQ 中明确禁止重新分发。

  • feishu：根据 ToS，明确禁止未经授权重新分发其应用程序。

  • multimc*：明确禁止 重新分发包含其 API 密钥和商标资产的自定义二进制文件。

  • rider：根据 ToS，不允许重新分发。

  • tlauncher：法律灰色地带，因为它可能允许在未获得许可证的情况下以受限能力游玩 Minecraft。

构建系统详情

我们之前的构建工具，即所谓的 toolbox，最初由 @pedrohlc 创建，以解决一个问题：有大量需要编译的软件包，但维护者却不多。 此外，Chaotic-AUR 的构建者相当不均匀：服务器、个人设备以及一台 HPC，它们都需要以某种方式集成。 该工具箱对此采用了一种不错的做法——尽可能保持 KISS 原则，并使用 Git 在构建者之间分发软件包构建。 这些构建者随后会根据其激活的例程获取构建。虽然这运行得相当好，但它存在一些我们试图在新版本中消除的问题。 关于此新设置的几个关键理念：

  • 由于我们非常喜欢使用 CI，除了它能为自动化繁琐任务提供极大增强外，还能使整个过程对公众更加透明，因此显然 CI 应该是其中的主要部分。
  • 系统应有一个调度器，将构建任务分发到节点，这可以防止无用的构建例程，并使节点能够在任务排队时随时获取作业。
  • 这些工具应作为 Docker 容器提供，以便在非 Arch 系统上轻松使用。
  • 除调度器（使用 TypeScript 和 BullMQ 编写）外的所有逻辑都应使用 Bash 编写

工作原理

新系统由三个组成部分构成：

  • CI（可以是 GitLab CI 或 GitHub Actions！）负责处理 PKGBUILD 及其变更，并确定需要构建的内容，利用 Chaotic Manager 容器通过中央 Redis 实例来调度软件包。
  • 存储当前已调度构建信息的中央 Redis 实例。
  • Chaotic Manager]，用于将新构建添加到队列并通过主管理器容器执行它们。所有容器都通过 SSH 隧道访问 Redis 实例，使构建容器能够在进入队列时随时获取新的构建任务。

与 Infra 3.0 相比，这意味着我们有以下主要区别：

  • 我们不再拥有软件包列表，而是一个包含 PKGBUILD 文件夹的仓库。这些 PKGBUILD 要么在软件包更新后从 AUR 拉取，要么在 Git 仓库及其标签作为源的情况下手动更新。
  • 不再有专用的构建器（未来可能会改变，例如用于重型构建？），而是使用通用的构建队列。
  • 不再需要例程 - CI 会根据需要确定并将软件包添加到计划中。我们唯一“类似例程” 的事情是 CI 计划，执行诸如 PKGBUILD 或版本更新之类的任务。
  • 构建过程背后的实际逻辑（如 interfere.sh 或数据库管理）已移至 Chaotic Manager 的构建容器 - 该容器每天/在提交时更新，并定期由 Manager 实例拉取。
  • 实时更新的构建日志将通过 CI 提供 - 多个修订版本，而不仅仅是最新版本。
  • 不再需要 interfere 仓库，相反，软件包构建可以通过其 各自的 PKGBUILD 文件夹中的 .CI 文件夹进行配置。所有已知的 interfere 类型都可以放在这里（例如 PKGBUILD.append 或 prepare.sh）， 保持现有 interfere 正常工作。
  • CI 针对每个软件包的行为可以通过 .CI 文件夹中的 config 文件进行配置：该文件存储 信息，如 PKGBUILD 源（可以是 AUR 或其他）、AUR 上的 PKGBUILD 时间戳、最近的 Git 提交以及设置，例如是否将 PKGBUILD 更改推送回 AUR。
  • PKGBUILD 的更改现在可以在主要（除 pkgver、哈希值、pkgrel 以外的所有更改）更新时进行审查 - CI 会自动创建一个包含这些更改的 PR 以供人工审查。
  • 添加和移除软件包完全通过 Git 控制 - 在通过提交添加新的 PKGBUILD 文件夹后， 相应的软件包将自动部署。移除它则产生相反的效果。

以下内容将包含理解其整体运作方式所需的信息，完整的构建系统 API 文档 可在此处找到。

工作流与信息

添加软件包

添加软件包只需创建一个以软件包的 $pkgbase 命名的新文件夹。将 PKGBUILD 和所有 其他必需文件放在这里。 因此，添加 AUR 软件包只需克隆其仓库并删除 .git 文件夹。 CI 依赖 .SRCINFO 文件来解析大部分信息，因此，对于自管理软件包，确保这些文件存在且保持最新 至关重要。 最后，添加一个包含基本配置的 .CI 文件夹（如果是外部软件包，则 CI_PKGBUILD_SOURCE 是必需的， 自管理的 PKGBUILD 不需要它），提交任何更改，并将更改推送回主分支。 请遵循约定式提交规范 (cz-cli 可以帮助完成此操作！)。这意味着提交信息如下：

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

这不仅有助于保持统一的提交历史，还允许自动生成变更日志。

移除软件包

可以通过删除包含软件包 PKGBUILD 的文件夹来实现。随后，清理任务将通过 on-commit 流水线运行自动移除 任何过时的软件包。这也会考虑软件包可能产生的任何拆分软件包。 重命名文件夹同样被视为移除软件包。

提交时流水线

每次推送新提交时，CI 流水线将执行以下操作：

  • 检查最后一次创建 scheduled 标签的时间。这用于确定哪些软件包需要被调度。
  • 它解析每个提交中的 [deploy $foldername] 字符串，仅接受源自现有 PKGBUILD 文件夹的有效值。[deploy all] 也是有效参数。此处拼写错误 $pkgname 是致命错误。任何 问题都必须修复并强制推送。
  • 然后，解析已更改的文件。这也包括已移除的软件包。任何已更改的相关文件夹内容都将 导致相应软件包的部署。
  • 最后一步是构建调度参数（通过工件将其传递给计划任务），并在检测到早期步骤时移除 所有过时的软件包。
  • 如果所有这些操作都成功，scheduled 标签将得到更新，以便我们可以在后续的流水线运行中引用它。

计划流水线

每小时

每小时，计划流水线将执行几项任务：

  • 从模板仓库更新 CI 模板（如果通过 .ci/config 启用了此功能）
  • 检查计划标签是否存在，或 scheduled 是否不指向 HEAD（在这种情况下中止任务！）
  • 检查包含软件包状态的 .state 工作树是否存在，如果存在，则对其进行设置。否则， 从头重新创建它（例如，在强制推送时）
  • 检查最后一个提交是否为自动化提交（包含 "chore(packages): update packages [skip ci]"），如果是， 由计划生成的提交将覆盖它，以保持提交历史整洁。
  • 收集软件包的 AUR 时间戳，以确定 PKGBUILD 是否已更改
  • 遍历每个有效软件包并执行以下操作：
    • 读取 .CI/config 文件以获取有关软件包配置的信息（例如，是否管理 AUR 仓库、PKGBUILD 的来源等）
    • 在以下情况下更新 PKGBUILD：
      • CI_PKGBUILD_SOURCE 设置为 gitlab：从 GitLab 仓库标签更新 PKGBUILD
      • CI_PKGBUILD_SOURCE 设置为 aur：从 AUR 仓库更新 PKGBUILD，拉取 git 仓库并 用新文件替换现有文件。 如果之前未能收集 AUR 时间戳，则跳过该软件包的更新。
      • CI_PKGBUILD_SOURCE 未设置为 gitlab 或 aur： 尝试通过拉取 CI_PKGBUILD_SOURCE 中指定的仓库来更新 PKGBUILD。 如果尝试 2 次后克隆仍未成功，则跳过更新流程。
    • 如果在软件包配置变量中设置了 CI_GIT_COMMIT，则更新 PKGBUILD 中 source 部分设置的 git URL 的最新提交。 如果存在差异，则安排构建。
    • 如果存在自定义钩子（软件包目录内的 .CI/update.sh），则执行该钩子 - 这可用于 通过自定义脚本更新 PKGBUILD。
    • 将所需变量写回 .CI/config（例如 Git 哈希值）
  • 对于次要更改，静默更新 PKGBUILD；对于主要更新，创建 PR 以供审查（且 仅当 CI_HUMAN_REVIEW 为 true 时）
    • 仅当 diff 实际报告当前 PKGBUILD 文件夹与 AUR PKGBUILD 仓库之间存在更改时，才视为更新
    • 对源文件所做的任何更改都会被检测到，但这 不会 检测软件包所构建的上游 项目源中的恶意更改
  • 状态工作树使用新信息进行更新
  • 调度参数被构建并通过工件传递给计划任务
  • 过时的分支（例如已合并的审查 PR）被修剪
  • 调度标签再次被更新

每日

已为动态生成其 pkgver 的特定软件包添加了每日流水线计划。 要使用它，请在软件包的 .CI/config 文件中设置 CI_ON_TRIGGER=daily。

手动调度

调度没有 git 提交的软件包

可以通过前往 pipeline runs 页面，选择 "Run pipeline" 并 添加 PACKAGES 作为变量，其值为软件包名称，来手动将软件包添加到计划中。然后流水线将获取这些软件包并 进行调度。 也可以将 PACKAGES 设置为 all 以调度所有软件包。如果一个或多个软件包被调度，它 需要遵循格式 pkgname1:pkgname2:pkgname3。

按需运行已调度的流水线

可以通过前往 pipeline runs 页面， 选择 "Run pipeline"（播放符号）来完成。将提供指向流水线页面的链接，可以在那里获取 流水线日志。

添加 interfere

将所需的 interfere 文件放入 PKGBUILD 文件夹的 .CI 文件夹中：

  • prepare: 在构建 chroot 设置完成后执行的脚本。可用于在编译开始前加载环境变量或修改其他内容。
    • 如果需要在实际编译过程之前进行设置，可以通过插入例如 $CAUR_PUSH 'source /etc/profile' 来推送命令。同样，可以解决软件包冲突，例如 如下所示：$CAUR_PUSH 'yes | pacman -S nftables'（单引号很重要，因为我们希望变量/管道在来宾运行时中求值，而不是在干扰时求值）
  • interfere.patch: 一个补丁文件，可用于修复多个文件或 PKGBUILD（如果需要大量更改）。所有更改都需要添加到该文件中。
  • PKGBUILD.prepend: 该文件的内容将添加到 PKGBUILD 的开头。
  • PKGBUILD.append: 该文件的内容将添加到 PKGBUILD 的末尾。修复 build() 只需将修复后的 build() 添加到该文件中即可。这可用于各种修复。如果需要向数组添加内容， 只需 makedepend+=(somepackage) 即可。
  • on-failure.sh: 如果构建失败，将执行此脚本。
  • on-success.sh: 如果构建成功，将执行此脚本。

更新 pkgrel

现在通过向 .CI/config 添加所需的变量 CI_PACKAGE_BUMP 来完成。更多信息请参见下文。

依赖树

CI 会自动构建依赖树。它们作为 CI 工件传递给 Chaotic manager，并在执行调度命令时读取。 无需手动干预。

.CI/config

每个包目录中的 .CI/config 文件包含用于控制流水线（pipelines）和构建（build）过程的额外标志（flags）。

  • CI_MANAGE_AUR: 将此变量设置为 true 后，如果发生更改（忽略与 CI 相关的文件），CI 将在管道运行结束时更新对应的 AUR 仓库
  • CI_NVCHECKER: 设置为 true 以通过 nvchecker 启用自动版本检查。需要在包目录中提供 .nvchecker.toml 或 nvchecker.toml 配置文件。
  • CI_NVCHECKER_REVIEW: 设置为 true 以创建由 nvchecker 触发的更新的 PR（需要启用 CI_NVCHECKER 和 CI_HUMAN_REVIEW）。在全局 CI 配置中默认为 true。
  • CI_PACKAGE_BUMP: 控制所有未将 CI_MANAGE_AUR 设置为 true 的包的版本升级。需要遵循的格式为 1:1.2.3-1/1（斜杠后为完整的当前版本和升级次数）或 1.2.3（完整的当前 包版本， 解析为升级次数 1）。
  • CI_PKGBUILD_SOURCE: 设置所有 PKGBUILD 相关文件的来源，用于从远程仓库拉取更新的文件。 目前有效的值为：
    • gitlab: 从 GitLab 仓库标签中拉取 PKGBUILD。它需要遵循格式 gitlab:$PROJECT_ID。 可以通过浏览仓库设置中的常规部分获取 ID。
    • aur: 从 AUR 仓库拉取 PKGBUILD，拉取 git 仓库并用新文件替换现有文件。
  • CI_ON_TRIGGER: 如果特殊计划触发器应调度对应的包，可以提供此值。这可以通过将值设置为 daily 来用于每日调度包。 由于这检查 "$TRIGGER == $CI_ON_TRIGGER"，因此可以使用管道计划创建任何自定义计划 并将 TRIGGER 设置为 midnight，添加一个适配计划，并将任何受影响包的 CI_ON_TRIGGER 设置为 midnight。 设置了此变量的包不会通过常规的计划内流水线进行调度，因此这也可以 用于防止浪费构建器资源，例如对于具有大量提交活动的巨大 -git 包非常有用， 例如 llvm-git。
  • CI_REBUILD_TRIGGERS：将已知会导致重新构建的包添加到此变量中。通过仓库的 CI_LIB_DB 参数提供要跟踪 包版本的仓库列表。每个包版本都会被哈希化并 转储到 .ci/lib.state。每次计划内的流水线运行都会通过检查哈希不匹配来比较版本，并通过 CI_PACKAGE_BUMP 提升 每个受影响的包。它必须遵循格式 package1:package2:package3。
  • BUILDER_CACHE_SOURCES：如果应在构建之间缓存源，可以将其设置为 true。这在源速度较慢或源并非始终可用的情况下 可能很有用。源将在 1 个月后自动清除，这在包被移除或源发生变化的情况下非常重要。
  • BUILDER_EXTRA_TIMEOUT：如果设置，将全局 BUILDER_TIMEOUT 值乘以给定的乘数。 例如，如果使用默认的超时值 3600，将此设置为 2 会将构建超时增加到 7200。

nvchecker 集成

nvchecker 可以在上游发布新版本时自动检测并更新软件包。这对于非基于 git 但具有版本化发布的软件包非常有用。

设置

  1. 在软件包目录中创建一个 .nvchecker.toml 或 nvchecker.toml 文件
  2. 将 CI_NVCHECKER=true 添加到软件包的 .CI/config 中

示例配置

[plasma6-wallpapers-blurredwallpaper]
source = "github"
github = "bouteillerAlan/blurredwallpaper"
use_latest_release = true

配置选项

  • source: 源类型（github、gitlab、aur、http 等）
  • github/gitlab: 格式为 owner/repo 的仓库
  • use_latest_release: 使用最新的 GitHub/GitLab 发布标签
  • regex: 用于从源中提取版本的自定义正则表达式
  • 完整选项，请参阅 nvchecker 文档

工作流

当 nvchecker 检测到更新时：

  1. Updates pkgver in PKGBUILD and .SRCINFO
  2. Creates a PR with ci,human-review,update,nvchecker labels for review
  3. Human review must approve before the package is rebuilt
  4. Pushes back to AUR when CI_MANAGE_AUR=true and chaotic-aur maintainer is added to co-maintainers

已知状态变量

状态将保存在 .state 工作树中。可以通过浏览 PKGBUILD 仓库的 state 分支来查看。 每个包都会有一个以包名命名的文件。已知存储的变量如下：

  • CI_GIT_COMMIT: 用于 CI 判断最新提交是否已更改。由 fetch-gitsrc 用于调度新 构建。如果软件包应被视为 git 软件包，则必须提供此项。CI 将自动更新 source 部分中设置的 git URL 的最新可用提交。如果存在差异，则调度 构建。-CI_PKGBUILD_TIMESTAMP: AUR 上 PKGBUILD 的最后修改日期。这用于判断 PKGBUILD 是否已更改。如果存在差异，则调度构建。将自动维护。

管理 AUR 软件包

AUR 软件包也可以通过此仓库以自动化方式使用 .CI_CONFIG 进行管理。 这意味着在每次计划执行和提交触发的流水线之后，AUR 仓库将更新以反映对 PKGBUILD 文件夹中文件所做的更改。 与 AUR 维护无关的文件（例如 .CI 文件夹）将被忽略。 提交信息反映了该提交是由 CI 流水线创建的事实， 并包含指向源仓库提交历史以及触发更新提交的流水线运行的链接。

更新 CI 脚本

这通过 CI 流水线自动完成。一旦检测到模板仓库上的更改，所有文件 都将更新到当前版本。

问题和流水线故障

最后一次提交触发的流水线失败

这可能会由几种原因导致，例如提供了无效的包名。这会导致 scheduled 标签未被更新。 在这种情况下，按计划触发的流水线将无法运行。 在按计划触发的流水线能够再次运行之前，必须修复最后一次按提交触发的流水线。 然而，构建失败不会被计入，因为一旦调度 参数生成，scheduled 标签就已经被更新。 在这种情况下，强烈建议强制推送修复后的提交，因为推送另一个提交会导致 CI 评估其之前遗漏的提交，从而再次注意到相同的问题并中止，而不是静默 继续。 这是一个设计决策，旨在防止失败被忽视。

重置构建队列

在极少数情况下，可能需要重置构建队列。这可以通过关闭中央 Redis 实例、删除其转储文件并重启其服务来完成。然而，这也会清除存储在 Redis 中的任何日志。

实时更新日志

日志是实时更新的，可以通过 Web 服务器实时查看。 如果使用 GitLab 且设置了 PACKAGE_REPOS_NOTIFIERS， 将为 CI 运行期间调度的每个包创建一个外部 CI 阶段，并链接到日志。

Prometheus 指标

Prometheus 指标可通过 Web 服务器的 /metrics 端点获取。 目前，我们收集默认的 prom-client 指标，以及每种构建状态（失败、成功、已构建、超时）的总事件数统计， 以及关于整体构建时间的指标。 这些可以通过 Prometheus 实例收集，然后使用 Grafana 进行可视化。

开发环境设置

此仓库包含一个 NixOS flake，可用于自动设置所需的内容，例如 pre-commit 钩子和检查， 以及所需的实用工具，通过 direnv。这包括通过 shellcheck 和 shfmt 检查 PKGBUILD。

使用 Nix

需要 nix（包管理器）和 direnv，之后，可以通过 运行 direnv allow 进入环境。

不使用 Nix

通过 repo-common GitLab CI 工件 提供捆绑的 devshell 变体。 下载并解压后，只需在 PKGBUILDS 文件夹中执行二进制文件即可。 引导过程需要一些时间，因为依赖项将被解包。