TUNA Mirrors 的 IPv6 地址暂时处于不可用状态

已经恢复

pacman 5.2.0-2 在 -U 升级包的时候导入 PGP Key 目前存在 Bug.
会导致 Key 无法导入, 甚至使 pacman Coredump.
如果安装的包带有 .sig 签名文件的第三方包, 请先删除 .sig 再 -U 安装. (不推荐)
或者手动 pacman-key 导入 PGP Key.
或者等待 pacman 更新.
Ref: https://bugs.archlinux.org/task/64239 & https://lists.archlinux.org/pipermail/pacman-dev/2019-October/023749.html

{jpn.,ger.,ind.,sgp.,mex.,}mirror.pkgbuild.com 服务器正在维护，请暂时更换其它镜像服务器并耐心等待，预计数小时内恢复服务。服务器同步状态见 https://www.archlinux.org/mirrors/mirror.pkgbuild.com/

关于 base 元包的 Q&A

Q: 为什么这次变化执行得如此突然？
A: 这是个好问题，虽然我们曾经多次讨论过这个主题并且在 arch-dev-public 邮件列表发布过具体提案（以及讨论的总结），但是之后没有什么能测试的具体步骤。不过在柏林举行 [arch-conf](https://conf.archlinux.org/) 的时候，大家强烈的热情和冲动让我们对这个议程动用了 [曲速10级引擎](https://zh.wikipedia.org/wiki/%E6%9B%B2%E9%80%9F%E5%BC%95%E6%93%8E)。我们承认应该更谨慎地对待这件事，但是本着 arch-conf 精神的号召请原谅我们。比如我们本应该在测试的过程中注意到没有安装 systemd-sysvcompat 会导致的后果，后来我们也把它加入了 base 包中，因为大家不希望遇到也没有讨论过没有它导致的影响，这个话题将在今后继续讨论。

Q: 为什么用元包（meta-package）替代了包组(group)？
A: 新的 base 包最重要的区别在于，它定义了一条边界。如果你修改你的系统超过了这条边界，我们明确地告诉你，你搞坏了你的系统，你买单——也就是说现在是你自己的责任诊断问题修复你的系统，因为你打破了我们对于基础系统的假设。这一点理论上来说在这次变更之前就已经是这样了，因为原本很多包就期待系统中安装了旧的 base 组。但是另一方面，以前一直没有明确表明过那些包是必须的依赖，结果是有些包可能不能正常运行甚至正常安装。

基于这一点，使用元包（meta-package）就成了很自然的选择。用元包让我们可以在今后对要求的包列表做变化（增删包），下次系统升级就会直接反应这些变化，从而避免了破坏我们对系统基础包的假设。一个简单的例子是 systemd 包，无论你的应用场景如何（就算在微型容器内）我们假定你必须安装了 systemd 因为系统很多部分需要它（像 sysusers, tmpdirs 这类）。

Q: 为什么它变小了，不再包含 $package 这个包了？
A: 新的 base 元包是想要作为所有使用场景的最大公约数，使用场景包括桌面用途、直接跑在硬件上的服务器、或者容器环境，从而它定义了大家构建自己所需环境的基础。老的 base 组不光包含了太多不算必须的包，以至于我们没法叫它为最大公约数，并且它也没有一致性，（比如它包含了 reiserfsprogs 但却没有 btrfs-progs）。

总结一下目前为止的反馈也能看到，以前的 base 组某种程度上被误用为简易的安装器了。这种用法本身没什么错，但是如果说我们希望能在我们这边解决这个问题，我们应该去找最优方案而不是一味地遵循传统。无论是提供一个真的安装器、还是一个 base-extra 的包组，或者就这样不提供任何东西，这都在本次修改的议提之外了，我们应该单独讨论这个——或者说讨论这个有点 [xkcd#1172](https://xkcd.com/1172/) 的感觉。


Q: 为什么就不能加一个新的包，同时保持原来的 base 组继续存在？
A: 主要原因是 base （按这个名字来说）应该是最小基础，是不同使用场景的最大公约数。如果我们增加别的什么包而不是 'base' 来替代这个任务，无论是 base-system, base-minimal, base-foundation 或者随便别的什么名字，它不再像 'base' 这个名字这么清晰明确。知道历史渊源可能会让我们有倾向，但是明显比起同时有 base 和 base-minimal 并需要区分它们，现在的做法更清晰地表达意图。

Q: 我们是否需要更新包的依赖关系让它们依赖 base 包而不是依赖 base 的成员？
A: 在这方面没有任何变化，我们没有严格规则是否需要这么做。这个话题更宽泛地说，是关于是否应该有间接包依赖关系的问题，这个我们今后会继续讨论。我的观点是保留直接依赖即可，因为完全没必要让整个宇宙都依赖 base 元包。不过，可能显式地列出直接依赖比起不列出依赖更正确、清晰、有用。

Q: 接下来呢，还有别的计划么？
A: 最重要的工作是把这个总结传达出去，帮助大家解决疑惑。接下来应该是继续一项一项地讨论剩下的议提——比如我们应该如何处理 systemd-sysvcompat 和本次变更带来的别的讨论。

原文： https://lists.archlinux.org/pipermail/arch-dev-public/2019-October/029693.html

关于新内核包和 mkinitcpio 挂钩的变动

我们的官方内核： linux, linux-lts, linux-zen 和 linux-hardened ，将不再直接把内核安装到 /boot 中去了。

安装和删除的步骤现在由 mkinitcpio 的挂钩(hook)和脚本(noscript)接管，因此无需手动干预升级过程。

此次变更的目的是想让内核包更独立(self-contained)，并且让启动过程更灵活，同时保持向后兼容性。

目前只有 mkinitcpio 有挂钩负责处理安装删除内核，我们还没有为 dracut 提供类似的支持，不过今后 dracut 将会有类似的挂钩。

https://www.archlinuxcn.org/new-kernel-packages-and-mkinitcpio-hooks/

Python 3.8 于14日晚上已经进入 extra 仓库，伴随着大量 Python 包的更新。[archlinuxcn] 仓库的大多数依赖 Python 的包应该会在15日早上或者中午完成更新，但是不能排除因为打包出错而延迟的情况。

由于 Arch Linux 官方仓库和 [archlinuxcn] 仓库是分开的，镜像站上有可能其中之一有延迟而另一个没有，造成更新之后部分依赖 Python 的软件包无法使用。

cn 源的用户们需要注意以上不一致的情况可能导致的问题，若有疑虑请考虑这两天不要更新，等待软件包重建完成和镜像完全同步。另外记得重新打包从 AUR 等地方手动打包安装的相关软件包。

primus_vk>=1.3-1 更新需要手动干预
primus_vk 包在版本 1.3-1 之前缺少了一些动态库链接。这个错误已经在 1.3-1 中修正了，所以升级时需要手动覆盖掉没有被跟踪到的动态库链接。如果你遇到如下报错：

primus_vk: /usr/lib/libnv_vulkan_wrapper.so.1 exists in filesystem
primus_vk: /usr/lib/libprimus_vk.so.1 exists in filesystem

那么请使用如下命令:

pacman -Syu --overwrite=/usr/lib/libnv_vulkan_wrapper.so.1,/usr/lib/libprimus_vk.so.1

进行更新。
https://www.archlinuxcn.org/primus-vk13-1-update-requires-manual-intervention/

Xorg 清理需要手动干预

我们正在清理 Xorg，此次更新如果你遇到如下错误信息那么需要手动干预：

:: installing xorgproto (2019.2-2) breaks dependency 'inputproto' required by lib32-libxi
:: installing xorgproto (2019.2-2) breaks dependency 'dmxproto' required by libdmx
:: installing xorgproto (2019.2-2) breaks dependency 'xf86dgaproto' required by libxxf86dga
:: installing xorgproto (2019.2-2) breaks dependency 'xf86miscproto' required by libxxf86misc

更新时，请使用命令： pacman -Rdd libdmx libxxf86dga libxxf86misc && pacman -Syu 来完成更新。

https://www.archlinuxcn.org/xorg-cleanup-requires-manual-intervention/

现在开始使用 zstd 替代 xz 进行软件包压缩

邮件列表上已经宣布了，从2019年12月27日开始，我们的软件包压缩格式已经从 xz (.pkg.tar.xz) 改为了 zstd (.pkg.tar.zst)。

zstd 相较于 xz 用压缩比换来高性能。用我们的压缩参数调用 zstd 重新压缩软件包导致了总体包大小增加 ～0.8% ，相对的这些包的解压时间总体有 ～1300% 的提速。

我们的软件源中已经有超过 545 个 zstd 压缩的软件包了，随着我们发布更新包，更多的会不断加入。目前为止我们还未发现任何用户可见的问题，所以感觉一切顺利。

如果你是一名打包者，如果你在使用最新的 devtools (>= 20191227) 那么你将自动开始打包新的 .pkg.tar.zst 包。
如果你是一名最终用户，没有手动操作需要做，只要你已经阅读并遵从了去年新闻中的建议。

如果你从 2018 年到现在还没有升级过 libarchive ，还有希望拯救你的系统！在 Eli Schwartz 的个人源中提供了打包好的 pacman-static 二进制包，用他的受信用户(Trusted User)密钥签名，可以用这个完成系统升级。

译注：除Eli Schwartz 的个人源之外，[archlinuxcn]社区源也提供了 pacman-static 的二进制包，由 lilac 签名，欢迎使用。

https://www.archlinuxcn.org/now-using-zstandard-instead-of-xz-for-package-compression/

rsync 兼容性

我们的 rsync 包一直以来通过内嵌 zlib 的方式提供和老式 --compress 参数的兼容，维持对 3.1.0 以前版本的兼容性。版本 3.1.1 是2014年6月22日发布的，现在主流发行版应该都已经提供了。

所以我们决定去掉内嵌的依赖库，发布一个使用系统 zlib 库的新版本。这也能修复迄今为止的和未来的安全问题。如果你运行 rsync 3.1.3-3 遇到报错，请去指责那些还在使用老版本的系统。

https://www.archlinuxcn.org/rsync-compatibility/

Plasma 5.18.0-1 解锁桌面布局选项消失

tags: #testing #plasma 5.18.0-1

目前由于 Global Edit Mode 的引入，导致右键菜单栏的解锁小部件选项消失，无法改变桌面布局，如需解锁请执行以下命令，预计上游修复版本 5.18.1

qdbus org.kde.plasmashell /PlasmaShell evaluateScript "lockCorona(false)"

Arch 维护者已于 5.18.0-2 提前 patch 修复，可正常更新。

openssh 8.2p1 更新可能导致更新了包之后无法连上已经开着的 sshd ，更新后立刻重启 sshd 可避免之后连不上的问题。 core/openssh 8.2p1-3 打包在 post_upgrade 中会强制重启一次 sshd ，升级时请注意。
相关bug： https://bugs.archlinux.org/task/65517
相关打包变更： https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/openssh&id=e8cca9cc928c87ac028aa81bead31a25fea1c2af

更新到 openssh-8.2p1 后需要重启 sshd

更新到 openssh-8.2p1 之后，已经开启的 SSH 服务会无法接受新的连接（，详见 FS#65517 ）。在远程服务器上更新包时，请确保在 pacman -Syu 升级之后立刻用命令 systemctl restart sshd 重启后台服务。如果更新到了 openssh-8.2p1-3 或以后的版本，将会在升级包时自动重启服务。

https://www.archlinuxcn.org/sshd-needs-restarting-after-upgrading-to-openssh-82p1/

Arch Linux 项目负责人的未来

Aaron Griffin 于 2020-02-24 发布：

大家好，

以前当我在 Arch 更活跃的时候大概还有很多人认识我，但是现在大概大部分人只在网站上看到过我的名字。我已经参与 Arch 很长一段时间了，在 2007 年的时候从 Judd 接过这个项目的负责人位置。但是就像很多事情一样，我的参与随着时间已经下滑到底端。现在是改变的时候了。

Arch Linux 需要有更多参与的领导来做出困难抉择并带领整个计划走向未来方向。而我不再适合做这件事。

经过团队共同努力，Arch Linux 团队决定了未来推选负责人的一套新流程。从今开始，团队将通过选举方式推选出任期两年的负责人。新流程的细节可以参考这里。

在第一次正式选举中，Levente Polyak (anthraxx)， Gaetan Bisson (vesath), Giancarlo Razzolini (grazzolini)，和 Sven-Hendrik Haase (svenstaro) 作为候选人，通过 58 名记名投票，选举出了新的当选者：

Levente Polyak (anthraxx) 将成为团队的新带领者。恭喜！

感谢大家多年来的支持，
Aaron Griffin (phrakture)

https://www.archlinuxcn.org/the-future-of-the-arch-linux-project-leader/

firewalld>=0.8.1-2 更新需要手动干预

firewalld 包在 0.8.1-2 之前的版本打包时遗漏了编译 python 模块。这已在 0.8.1-2 中修复，所以更新时需要覆盖掉没有被跟踪到的 pyc 文件。如果你升级时遇到如下报错：

firewalld: /usr/lib/python3.8/site-packages/firewall/__pycache__/__init__.cpython-38.pyc exists in filesystem
firewalld: /usr/lib/python3.8/site-packages/firewall/__pycache__/client.cpython-38.pyc exists in filesystem
firewalld: /usr/lib/python3.8/site-packages/firewall/__pycache__/dbus_utils.cpython-38.pyc exists in filesystem
...更多报错...

那么请使用如下命令升级：

pacman -Suy --overwrite /usr/lib/python3.8/site-packages/firewall/\*

译注：
如果升级 firewalld 前删除了 firewalld 包，下次安装 firewalld 包仍然会有文件冲突，此时请使用：

pacman -Suy --overwrite /usr/lib/python3.8/site-packages/firewall/\* firewalld

安装 firewalld 包。

https://www.archlinuxcn.org/firewalld081-2-update-requires-manual-intervention/

[archlinuxcn] 仓库镜像状况：

上海科技大学 GeekPie：已延迟25天（此镜像大部分仓库都在延迟）
浙江大学 zju：已延迟20天（此镜像的 Arch Linux 官方仓库同样延迟）
腾讯云：已延迟四天
莞工 GNU/Linux 协会 dgut：已延迟两天

腾讯云和 dgut 已经恢复正常同步。

hplip 3.20.3-2 更新需要手动干预

hplip 包在 3.20.3-2 之前的版本缺失了一些预编译的 python 模块。这个问题已经在 3.20.3-2 版本中修复，所以更新时需要覆盖掉那些没有被跟踪到的 pyc 文件。如果你遇到如下报错

hplip: /usr/share/hplip/base/__pycache__/__init__.cpython-38.pyc exists in filesystem
hplip: /usr/share/hplip/base/__pycache__/avahi.cpython-38.pyc exists in filesystem
hplip: /usr/share/hplip/base/__pycache__/codes.cpython-38.pyc exists in filesystem
...更多类似报错...

那么在更新时请使用命令：

pacman -Suy --overwrite /usr/share/hplip/\*

来完成更新

https://www.archlinuxcn.org/hplip-3203-2-update-requires-manual-intervention/

nss>=3.51.1-1 及 lib32-nss>=3.51.1-1 更新需要手动干预

nss 及 lib32-nss 两个包在版本 3.51.1-1 之前各缺失了一个动态库软链接。这个问题已经在 3.51.1-1 中修复，所以更新时需要覆盖 ldconfig 创建出的未被跟踪到的文件。如果你在升级时遇到如下报错：

nss: /usr/lib/p11-kit-trust.so exists in filesystem
lib32-nss: /usr/lib32/p11-kit-trust.so exists in filesystem

那么请使用命令：

pacman -Syu --overwrite /usr/lib\*/p11-kit-trust.so

完成更新。

https://www.archlinuxcn.org/nss3511-1-and-lib32-nss3511-1-updates-require-manual-intervention/