chaotic-aur/packages

# Chaotic-AUR PKGBUILD 文件 这里是提交软件包请求、错误报告或过时软件包的正确地点 隶属于 [Chaotic-AUR](https://aur.chaotic.cx) 📜 ⚠️ 我们已于 [10月18日切换至全新的基础设施4.0](https://gitlab.com/chaotic-aur/pkgbuilds)，这意味着我们现在基于 GitLab CI 运行！ 虽然我们仍会在 GitHub 上旧的 `packages` 仓库接受议题和错误报告，但所有的流水线、更新和整体运行状态洞察主要将在另一端进行。 旧仓库将作为仅推送的镜像保留。  ## 我们已经构建的一些软件包 - Linux 内核的各种变体，例如 - [Cachyos](https://aur.archlinux.org/packages/linux-cachyos) / [Cachyos-BORE](https://aur.archlinux.org/packages/linux-cachyos-bore), - [Clear](https://aur.archlinux.org/packages/linux-clear), - [Nitrous](https://aur.archlinux.org/packages/linux-nitrous), - [VFIO](https://aur.archlinux.org/packages/linux-vfio), - [XanMod](https://aur.archlinux.org/packages/linux-xanmod) / [XanMod-RT](https://aur.archlinux.org/packages/linux-xanmod-rt) / [XanMod-LTS](https://aur.archlinux.org/packages/linux-xanmod-lts), - [Mainline](https://aur.archlinux.org/packages/linux-mainline), - [LQX](https://aur.archlinux.org/packages/linux-lqx) - 以及上述内核的一些特定架构变体 - 模拟器和游戏工具 - 许多浏览器，例如 [Firedragon](https://github.com/dr460nf1r3/firedragon-browser), [Firefox-wayland-hg](https://aur.archlinux.org/packages/firefox-wayland-hg), [Floorp](https://floorp.app/), [Icecat](http://www.gnu.org/software/gnuzilla/), 以及 [Ungoogled Chromium](https://github.com/Eloston/ungoogled-chromium) - ... 以及更多 ... 此存储库中的每个文件夹都将由我们的构建系统构建， 有关当前排队的软件包和构建日志的信息 请查看我们的[构建状态页面](https://aur.chaotic.cx/status)！ 🕵️‍♀️ 软件包及其当前版本的完整列表也可以在 [此处](https://aur.chaotic.cx/packages)查看。 ## 修改过的软件包 虽然我们更倾向于不加修改地构建 AUR 软件包，但这样做通常不切实际或不可行。 - 依赖项、选项或命令可能缺失。 - 可能存在错误的选项或命令。 - 不修改软件包可能无法构建或运行。 - 软件包可能不符合打包标准。 为解决此类问题： - 构建系统会自动纠正一些常见错误。 - 可能通过 `interfere`（干预）应用手动更正。 - 可将原始软件包分叉为自定义软件包。 ## 特殊软件包 - `chaotic-keyring`：用于验证 Chaotic-AUR 软件包签名的公钥。 - `chaotic-mirrorlist`：镜像 Chaotic-AUR 软件包的服务器列表。 - `chaotic-interfere`：标记已手动应用的 `interfere`（干预）。此软件包 _不_ 应被安装。 ## 被屏蔽和拒绝的软件包 📑 以下是我们出于合理原因将拒绝接收的软件包列表： - **snapd**：我们不知道如何帮助用户解决它引发的_大量问题_。我们建议使用原生软件包或 [FlatPak](https://wiki.archlinux.org/title/Flatpak) 代替。 此外，[还有很多理由不要使用 Snaps](https://old.reddit.com/r/linuxmemes/comments/ppyz0g/damn_you_ubuntu/hd7jg1p/)。 - **lib32-\***：维护 32 位软件包的难度在增加，而其用处却在减少。可以考虑保留它们以使现有软件包（如 `wine-*`）能继续工作。否则，在有 64 位版本可用时请使用 64 位软件包。 - **gst-plugins-{ugly,bad}**：这些软件包需要过于频繁地重建，由于我们无法控制软件包的 `pkgrel`，这无法处理。最终会导致糟糕的用户体验。 - **ffmpeg-headless**：需要过于频繁地重建，由于我们无法控制软件包的 `pkgrel`，这无法处理。最终会导致糟糕的用户体验。 - **mpv-amd, ffmpeg-amd**：这只是去掉了 CUDA 和 NVENC 的 MPV/FFMPEG，旨在缩短构建时间，对最终用户没有实际益处。 - **unreal-engine (及 -git)**：部分镜像服务器没有足够的存储空间。 - **python2**：已停止维护多年，并且[已从 Arch 仓库中移除](https://archlinux.org/news/removing-python2-from-the-repositories/)。 - **linux-ck**：其他内核包含相同的优化，并且官方预编译二进制文件可从 [repo-ck](https://wiki.archlinux.org/title/Unofficial_user_repositories#repo-ck) 获得。 - 使用已停止维护、非标准或修改版 Electron 的软件包。将 Electron 用作网络浏览器的软件包。 - 没有任何依赖项的软件包：此类软件包本身无用。维护它们所花费的精力，可以更好地用在别处。 ## 因许可问题而被禁止的软件包 🛑 - **AMDGPU PRO** 驱动程序。禁止重新分发软件和文档。 - **aseprite{-git}**：其 [FAQ](https://www.aseprite.org/faq/#can-i-redistribute-aseprite) 中明确禁止重新分发。 - **feishu**：根据其[服务条款](https://www.feishu.cn/en/terms)，未经授权禁止重新分发其应用程序。 - **multimc\***：禁止重新分发包含其 API 密钥和商标资产的自定义二进制文件[明确禁止](https://multimc.org/#Branding)。 - **rider**：根据[服务条款](https://www.jetbrains.com/legal/docs/toolbox/user)禁止重新分发。 - **tlauncher**：法律灰色地带，因为它可能允许在没有许可证的情况下以有限制的方式游玩 Minecraft。 ## 构建系统详情 我们之前的构建工具，即所谓的 [toolbox](https://github.com/chaotic-aur/toolbox)，最初由 @pedrohlc 创建，用于解决一个问题：有大量软件包需要编译，但没有足够多的维护者来负责所有软件包。 此外，Chaotic-AUR 拥有异构性很强的构建器：服务器、个人设备以及一台 HPC，它们都需要以某种方式集成。 `toolbox` 对此有一个不错的方法——尽可能保持 KISS 原则，并使用 Git 在构建器之间分发软件包构建任务。构建器会根据其激活的例程抓取构建任务。虽然这运行得相当好，但它存在一些问题，我们尝试在新版本中解决这些问题。 关于这个新设置的一些关键理念： - 由于我们非常喜欢使用 CI，除了它能很好地增强自动化繁琐任务的能力，并使整个过程对公众更加透明之外，很明显 CI 应该是其主要组成部分。 - 系统应具有一个调度器，将构建任务分配给节点，这可以防止无用的构建例程，并使节点能够在任务排队时随时抓取任务。 - 工具应作为 Docker 容器提供，以便在 Arch 以外的其他系统上轻松使用。 - 除了调度器（使用 TypeScript 和 BullMQ 编写）之外的所有逻辑，都应使用 Bash 编写。 ## 工作原理 新系统由三个核心部分组成： - CI（可以是 GitLab CI 和 GitHub Actions！）处理 PKGBUILD 及其变更，并通过中央 Redis 实例利用 Chaotic Manager 容器来确定要构建什么、调度软件包。 - 中央 Redis 实例，存储当前已调度构建任务的信息。 - [Chaotic Manager](https://gitlab.com/garuda-linux/tools/chaotic-manager) 用于将新的构建任务添加到队列，并通过主管理器容器执行它们。所有容器都可以通过 SSH 隧道访问 Redis 实例，使构建容器能够在新任务进入队列时随时抓取它们。 与基础设施 3.0 相比，这意味着我们有以下关键区别： - 我们不再使用软件包列表，而是一个充满 PKGBUILD 文件夹的仓库。当一个软件包在 AUR 上更新时，这些 PKGBUILD 会被拉取；或者，如果 Git 仓库及其标签作为源，则会手动更新。 - 不再有专用的构建器（未来可能会改变，例如用于大型构建？），而是有一个公共构建队列。 - 例程不再必要——CI 根据需要确定并将软件包添加到计划中。我们唯一“类似例程”的东西是 CI 计划，执行 PKGBUILD 或版本更新等任务。 - 构建过程背后的实际逻辑（如 `interfere.sh` 或数据库管理）已移至 [Chaotic Manager 的构建器容器](https://gitlab.com/garuda-linux/tools/chaotic-manager/-/tree/main/builder-container?ref_type=heads)中——该容器会每日/按提交更新，并定期被管理器实例拉取。 - 实时更新的构建日志将通过 CI 提供——支持多个修订版本，而不仅仅是最新版本。 - 不再需要 `interfere` 仓库，相反，可以通过各 PKGBUILD 文件夹中的 `.CI` 文件夹来配置软件包构建。所有已知的 `interfere` 类型都可以放在这里（例如 `PKGBUILD.append` 或 `prepare.sh`），使现有的 `interfere` 继续工作。 - CI 对每个软件包的行为可以通过 `.CI` 文件夹中的 `config` 文件进行配置：此文件存储诸如 PKGBUILD 源（可以是 AUR 或其他来源）、AUR 上的 PKGBUILD 时间戳、最近的 Git 提交等信息，以及是否将 PKGBUILD 更改推回 AUR 等设置。 - 现在，对于重大更新（除 pkgver、哈希值、pkgrel 以外的所有更改），PKGBUILD 的更改可以进行审查——CI 会自动创建一个包含更改的 PR 供人工审查。 - 软件包的添加和删除完全通过 Git 控制——通过提交添加新的 PKGBUILD 文件夹后，相应的软件包将自动部署。删除文件夹则会产生相反的效果。 以下将包含理解各部分如何协同工作的信息，完整的构建系统 API 文档可在 [此处](https://chaotic-manager.pages.dev/)找到。 ## 工作流与信息 ### 添加软件包 添加软件包就像创建一个以该软件包的 `$pkgbase` 命名的新文件夹一样简单。将 PKGBUILD 和所有其他必需文件放在这里。 因此，添加 AUR 软件包只需克隆其仓库并删除 `.git` 文件夹。 CI 依赖 `.SRCINFO` 文件来解析大部分信息，因此对于自行管理的软件包，确保这些文件存在且保持更新非常重要。 最后，添加一个包含基本配置的 `.CI` 文件夹（如果是外部软件包，`CI_PKGBUILD_SOURCE` 是必需的；自行管理的 PKGBUILD 不需要它），提交任何更改，并将更改推送到主分支。 请在此过程中遵循[约定式提交规范](https://www.conventionalcommits.org/en/v1.0.0/)（[cz-cli](https://github.com/commitizen/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` 标签是否存在，或者 `scheduled` 是否指向 HEAD（如果不存在或不指向 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；对于重大更新（且仅当 `CI_HUMAN_REVIEW` 为 `true` 时），创建一个 PR 供审查 - 仅当 `diff` 实际报告当前 PKGBUILD 文件夹与 AUR PKGBUILD 仓库之间存在更改时，才会考虑更新 - 检测源文件的任何更改，但这_不会_检测软件包构建的上游项目源代码中的恶意更改 - 用新信息更新状态工作树 - 构建调度参数并通过工件传递给定时任务 - 修剪过时的分支（例如，已合并的审查 PR） - 再次更新 `scheduled` 标签 #### 每日一次 对于动态生成其 `pkgver` 的特定软件包，添加了每日管道计划。 要使用它，请在软件包的 `.CI/config` 文件中设置 `CI_ON_TRIGGER=daily`。 ### 手动调度 #### 通过非 Git 提交调度软件包 可以通过转到[管道运行](https://gitlab.com/chaotic-aur/pkgbuilds/-/pipelines)页面，选择“运行管道”并添加一个变量 `PACKAGES`（其值为软件包名称）来手动将软件包添加到调度中。然后，管道将获取这些软件包并对其进行调度。 `PACKAGES` 也可以设置为 `all` 来调度所有软件包。如果调度一个或多个软件包，需要遵循格式 `pkgname1:pkgname2:pkgname3`。 ##### 按需运行已调度的管道 这可以通过转到[管道运行](https://gitlab.com/chaotic-aur/pkgbuilds/-/pipeline_schedules)页面，选择“运行管道”（播放符号）来完成。将提供一个指向管道页面的链接，可以在其中获取管道日志。 ### 添加 interfere 将所需的 `interfere` 文件放入 PKGBUILD 文件夹的 `.CI` 文件夹中： - `prepare`：在构建 chroot 设置完成后执行的脚本。可用于在编译开始前导入环境变量或进行其他修改。 - 如果需要在实际编译过程之前进行设置，可以通过插入例如 `$CAUR_PUSH 'source /etc/profile'` 来推送命令。同样，可以解决软件包冲突，例如：`$CAUR_PUSH 'yes | pacman -S nftables'`（单引号很重要，因为我们希望变量/管道在客户机运行时求值，而不是在 `interfere` 时） - `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 管理器，并在执行调度命令时被读取。 无需手动干预。 ### .CI 配置 每个软件包目录中的 `.CI/config` 文件包含用于控制管道和构建过程的附加标志。 - `CI_MANAGE_AUR`：将此变量设置为 `true`，CI 将在管道运行结束时更新相应的 AUR 仓库（如果发生更改）（省略 CI 相关文件） - `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/config` 中添加 `CI_NVCHECKER=true` #### 示例配置 ``` [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 文档](https://nvchecker.readthedocs.io/en/latest/usage.html#configuration-files) #### 工作流 当 nvchecker 检测到更新时： 1. 更新 PKGBUILD 和 `.SRCINFO` 中的 `pkgver` 2. 创建一个带有 `ci, human-review, update, nvchecker` 标签的 PR 供审查 3. 必须经过人工审查批准后，软件包才会被重新构建 4. 当 `CI_MANAGE_AUR=true` 且 chaotic-aur 维护者被添加为共同维护者时，推回 AUR ### 已知状态变量 状态将保存在 `.state` 工作树中。可以通过浏览 PKGBUILD 仓库的 `state` 分支来查看。 每个软件包将有一个以其名称命名的文件。已知存储以下变量： - `CI_GIT_COMMIT`：CI 用于确定最新提交是否已更改。`fetch-gitsrc` 用它来调度新构建。如果软件包应被视为 git 软件包，则需要提供此变量。CI 将自动更新 PKGBUILD 的 `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，可通过 [direnv](https://direnv.net/) 自动设置所需的内容，例如 pre-commit 钩子和检查，以及必要的实用工具。这包括通过 `shellcheck` 和 `shfmt` 检查 PKGBUILD。 #### 使用 Nix 需要 `nix`（包管理器）和 [direnv](https://direnv.net/)，之后可以通过运行 `direnv allow` 进入环境。 #### 不使用 Nix 开发环境的捆绑变体可通过 `repo-common` 的 [GitLab CI 工件](https://gitlab.com/chaotic-aur/repo-common/-/pipelines) 获得。 下载并解压后，只需在 PKGBUILDS 文件夹中执行二进制文件。 引导过程可能需要一些时间，因为依赖项将被解压。

标签：应用安全, 搜索引擎查询, 请求拦截