apt.llvm.org 为所有维护版本的 Debian 和 Ubuntu 发行版提供软件仓库。LLVM、Clang、clang 扩展工具、compiler-rt、polly、LLDB 和 LLD 包针对稳定版、稳定化版和开发版分支生成。

随着我们越来越多的用户使用这些软件包，我想分享一些关于近期变化的更新。

新功能

LLD
首先，一些很酷的新内容：lld 现在被提议并构建用于所有 Debian 和 Ubuntu 支持版本的 i386/amd64。测试套件也已执行，覆盖率结果 非常棒。

4.0
然后，在 4.0 版本分支后，我创建了新的软件仓库来提议此版本。
例如，对于 Debian 稳定版，只需在 /etc/apt/sources.list.d/llvm.list 中添加以下内容：

deb http://apt.llvm.org/jessie/ llvm-toolchain-jessie-4.0 main
  deb-src http://apt.llvm.org/jessie/ llvm-toolchain-jessie main

llvm-defaults
显然，主干现在是 5.0。如果使用 llvm-defaults，clang、lldb 和其他元软件包将自动更新到此版本。
因此，由于分支已失效，3.7 和 3.8 任务已禁用。请注意，这两个软件仓库仍然可以在 apt.llvm.org 上使用，并且不会被删除。

Zesty：新的 Ubuntu
针对下一个 Ubuntu 17.04 (zesty) 的软件包也针对 3.9、4.0 和 5.0 生成。

libfuzzer
它在几个月前就已经实现，但没有明确的沟通。libfuzzer 也有自己的软件包：libfuzzer-X.Y-dev（例如：libfuzzer-3.9-dev, libfuzzer-4.0-dev 或 libfuzzer-5.0-dev）。

基础设施中的变化

为了支持负载，我开始使用谷歌（再次感谢 Nick Lewycky）为我为 Debian 和 IRILL 运行的计划赞助的新刀片。这 6 个新刀片消除了所有等待时间。通过新的盐配置，我自动化了从属服务器的部署。如果负载再次增加，我们将可以使用更多刀片。

我还花时间修复了一些长期存在的问题

• 所有软件仓库都被签名并验证其是    
• i386 和 amd64 软件包现在一次上传，而不是单独上传。这在两种架构中的一种构建正确而另一种构建失败时会导致校验和错误（例如：测试失败）。

最后但并非最不重要的一点是，代码覆盖率结果 以更可靠的方式生成。

有关实现和服务的更多信息。

由于在 apt.llvm.org 上提供的与 Debian 和 Ubuntu 中的完全相同，因此打包文件存储在 Debian 版本控制服务器 上。

一个 Jenkins 实例 负责整个构建基础设施的编排。

主干软件包每天两次为每个 Debian 和 Ubuntu 软件包构建。分支（目前为 3.9 和 4.0）仅在触发作业发现更改时重新构建。

在这两种情况下，Jenkins 源代码作业都会检出其版本的 Debian SVN 分支，检出/更新 LLVM/clang/等仓库，并将所有内容重新打包以创建源代码包和 Debian 文件（dsc 等）。作业完成将触发二进制文件作业启动。这些作业，得益于 Debian Jenkins glue，将创建或更新 Debian/Ubuntu 版本。

然后，通过 pbuilder 对 i386 和 amd64 两种架构进行常规构建。所有测试套件都将执行。如果任何 LLVM 测试在 i386 或 amd64 上失败，整个构建都会失败。如果两种构建和 LLVM 测试套件都成功，同步作业将启动并将软件包 rsync 到 LLVM 服务器以在 CDN 上复制。如果一个或两个构建失败，将向管理员发送通知。

对软件包执行一些 Debian 静态分析 (lintian) 以防止一些打包错误。有时会发现一些有趣的问题。

同时，一些二进制构建有一些特殊的挂钩，例如 Coverity、代码覆盖率 或安装 Ubuntu precise 的更新版本 gcc。

报告错误

常见问题

如何提供帮助