可重现构建

来自 ArchWiki

Arch Linux 目前正在努力使所有软件包都可重现。这让用户和研究人员可以验证来自 Arch Linux 的已分发软件包。有关可重现构建的确切定义及其优势,请查看项目网站

验证构建

软件仓库 vs. 重新构建

我们自己的基础设施上已经建立了一个实验性的 rebuilderd 实例,其 状态页面。Rebuilderd 重新构建我们的软件仓库软件包,并检查它们是否逐位相同。如果它们不可重现,则可能是工具存在错误,软件包不可重现,或者软件包未被干净地构建。

已知问题列表位于 /Status

重新构建 vs. 具有变体的另一次重新构建

Reproducible Builds 项目重新构建 Arch Linux 软件包,并将它们与在不同环境中另一次重新构建进行比较。软件包状态和环境变化列在 专门的 Arch Linux 页面中。

帮助

工具

帮助修复错误并为 repro 添加功能。

运行 Rebuilder 实例

设置 rebuilderd 以构建 Arch Linux 软件包有助于独立验证软件仓库软件包。

使用 repro 验证软件包并查找问题

一个极好的帮助方式是找到一个不可重现的软件包,并找出如何使其可重现。

  • 下载一个 Arch Linux 软件包或从 Arch Linux 归档 获取一个
  • 在下载的软件包或 pacman 缓存中的软件包上运行 repro。理想情况下使用 repro -d 以获得 diffoscope 输出。例如,repro -d /var/cache/pacman/pkg/curl-7.73.0-1-x86_64.pkg.tar.zst
注意: https://reproducible.archlinux.org 跳过了 check() 步骤,因为为所有软件包运行所有测试过于不稳定。如果 check() 具有副作用(例如 Python 软件包),这将创建虚假的不可重现软件包状态。

处理 tests.reproducible-builds.org 基础设施中的问题

Arch 用户可以通过查看 持续重现环境来帮助解决 Reproducible Build 问题。有各种问题可以解决

  • FTBS(无法从源代码构建):在本地重现构建失败,如果软件包无法从干净的 chroot 环境中构建extra-x86_64-buildmultilib-build),则创建错误报告。
  • 下载源文件失败,重现问题 (makepkg -o -d) 并在 Arch bugtracker 上创建错误报告。
  • 无法重现。在本地,您可以使用 reprotest 重现软件包。请注意,并非所有变体都可以使用。对于简单的时间相关测试
    $ reprotest --variations '+time' 'sudo extra-x86_64-build' '*.pkg.tar.zst'

软件包可能由于各种原因而不可重现,但在深入研究之前,请查看上游存储库或 Debian 中的可重现状态

本文或章节已过时。

原因: glibc 2.35-6 版本已包含 C.UTF-8。(在 Talk:Reproducible builds 中讨论)
  • 运行测试失败,这些失败很大程度上取决于测试环境。最可能的原因是设置了 LANG=C 并且 Arch 不支持 LANG=C.UTF-8

如果您对运行持续重现环境的代码感兴趣,则第一个构建代码从 salsa 上的这里开始

注意: tests.reproducible-builds.org 上的持续重现环境不重现官方 arch 软件包。它的目的只是模糊测试软件包并尝试触发尽可能多的错误,以便可以将它们报告给上游。

已知问题

GPG 验证

存在一种可能的重新构建场景,其中 GPG 密钥将无法验证,因为打包者已从密钥环中删除或吊销,因为我们使用最新的密钥环,并且我们需要的存档中的软件包可能需要由我们无法验证的已吊销密钥签名,并且构建将失败。

联系方式