tensorflow>=1.14.0-5 更新需要手动干预

tensorflow 包在 1.14.0-5 之前的版本缺少几个动态库的链接。这个问题已经在 1.14.0-5 中修复，所以更新过程需要覆盖掉 ldconfig 创建出的未被 pacman 跟踪的链接文件。如果你在更新时遇到如下报错

tensorflow: /usr/lib/libtensorflow.so.1 exists in filesystem
tensorflow: /usr/lib/libtensorflow_cc.so.1 exists in filesystem
tensorflow: /usr/lib/libtensorflow_framework.so.1 exists in filesystem

那么请使用如下命令

pacman -Suy --overwrite=usr/lib/libtensorflow.so.1,usr/lib/libtensorflow_cc.so.1,usr/lib/libtensorflow_framework.so.1

来完成系统更新。

https://www.archlinuxcn.org/tensorflow1140-5-update-requires-manual-intervention/

astyle>=3.1-2 更新需要手动干预

astyle 包在 3.1-2 之前的版本缺少了一个动态库的链接。这个问题已经在 3.1-2 中修复，所以更新过程需要覆盖掉 ldconfig 创建出的未被 pacman 跟踪的链接文件。如果你在更新时遇到如下报错：

astyle: /usr/lib/libastyle.so.3 exists in filesystem

那么请使用如下命令

pacman -Suy --overwrite usr/lib/libastyle.so.3

来完成系统更新。

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

网易开源镜像站（mirrors.163.com）用户请注意：其 Arch Linux 仓库已经延迟六天，Arch Linux CN 仓库已经延迟两天。

btrfs 用户在 5.2.x 系列内核有概率遇到 1. 系统卡死 或者 2. 最后的写入不完整从而下次开机无法挂载。 SUSE/btrfs 开发者建议对 5.2 内核打修复补丁，相应补丁已经应用于 linux 5.2.14.arch2 和 linux-zen 5.2.14.zen2 内核（ arch2 和 zen2 分别包含对应补丁），并准备合并入上游 5.2.15 和 5.3 。请使用 btrfs 并且内核在 5.2.x 系列内核的用户尽快升级至 5.2.14.arch2 / 5.2.14.zen2 之后的内核版本。5.1.x 及之前的内核比如 linux-lts 不受影响。相关报告见：
[1] https://bugs.archlinux.org/task/63733
[2] https://marc.info/?l=linux-btrfs&m=156827465218288

已经恢复同步。

https://mirrors.cqu.edu.cn/archlinuxcn/ 关闭了校外访问

#news
由于不可抗力，国庆期间重庆大学多个对外服务将无法从外部访问。镜像站服务亦受到牵连。恢复对外服务时间未知。对于所造成的不便我们深感遗憾。

`base` 元包替代了同名的包组并且要求安装，需要手动干预升级

原本的 base 包组（group）已经被替换为同名的元包（metapackage），我们建议所有用户安装这个新包（pacman -Syu base），因为从今往后事实上要求安装该包。
对寻求帮助和支持的用户，我们期待他们运行的系统安装了 base 包。

附加说明：
请注意，新的 base 包不再包含以下内容：
– 内核
– 编辑器
– 文件系统工具 （比如 e2fsprogs）
……以及可能还有别的你预期会有的包。对新安装的系统需要额外安装这些包。

https://www.archlinuxcn.org/base-group-replaced-by-mandatory-base-package-manual-intervention-required/

#news
镜像站现已恢复对外部的访问。再次对对各位造成的不便表示表示歉意。

关于此次 base 元包变更的缘由参见邮件列表上的提案和讨论：
https://lists.archlinux.org/pipermail/arch-dev-public/2019-January/029435.html
https://lists.archlinux.org/pipermail/arch-dev-public/2019-March/029491.html

关于旧 base 包组的更新进展参见：
https://www.archlinux.org/todo/base-group-removal/
可以用以下命令获取旧 base 包组的包列表：

w3m -dump https://www.archlinux.org/todo/base-group-removal/ | grep "Core" | awk '{print $3}'

安装新的 base 元包不会导致旧的 base 包组中的包被删除。
使用旧的 base 包组安装出来的系统中，那些 base 包组中的包会在安装时被 pacman 标记为“单独指定安装”，从而不会被自动清理。
新的 base 元包的依赖列表可以由以下命令查询：

LANG=C pacman -Si base | grep "Depends On[ ]*:" | sed "s/^.*: //;s/[ ]\+/\n/g"

在安装完新的 base 元包之后（可通过 pacman -Qi base 确认），可以用以下命令将 base 元包依赖的包标记为“作为依赖关系安装”：

LANG=C pacman -Qi base | grep "Depends On[ ]*:" | sed "s/^.*: //;s/[ ]\+/\n/g" | sudo pacman -D --asdeps -

或者将旧 base 包组中的包全都标为“作为依赖关系安装”：

w3m -dump https://www.archlinux.org/todo/base-group-removal/ | grep "Core" | awk '{print $3}' | sudo pacman -D --asdeps -

随后可以查询不再被依赖的孤儿包：

pacman -Qtd

挑选其中你觉得需要的包标记为“单独指定安装”（以 linux 包为例）

sudo pacman -D --asexplicit linux

随后可手动清理不再需要的孤儿包（注意确认包列表以免删除关键的包）：

pacman -Qtdq | sudo pacman -Rcs -

sudo 出了一个比较严重 bug，此问题后果严重，但是一般来说很难触发（配置不太常见）。1.8.28 修复
如果一个 sudoers 配置了以下 Runas 权限
alice = (ALL:!root) /path/to/bin
那么他可以使用 sudo -u#1234 id -u 以 UID 1234 执行命令。
但是，syscall setresuid(2) 和 setreuid(2) 对于UID为-1（或者4294967295）有特殊处理并且不会更改 EUID，同时 sudo 本身运行在 root 下，会造成提权漏洞。
https://www.sudo.ws/alerts/minus_1_uid.html

New mirrors 上线啦

mirrors.hit.edu.cn 自动解析
mirrors4.hit.edu.cn 仅解析 v4（仅校内）
mirrors6.hit.edu.cn 仅解析 v6

要求更新到比较新的 libarchive

压缩算法 zstd 带来了更快的压缩解压时间，同时保持接近 xz 的压缩率。通过它我们能让 pacman 能更快地安装包，并且不会带来什么坏处。

即将到来的 pacman 5.2 更新将允许打包工具使用 zstd 压缩软件包。要安装这些包需要有 zstd 支持的 libarchive ，相关更新已经在 2018 年 9 月左右进入软件仓库。为了允许我们开始发布 zstd 压缩的软件包，我们要求所有用户更新到至少 libarchive 3.3.3-1 或以后的版本。该版本发布至今已经有一年了，我们期待你已经更新到了，如果还没更新那请尽快。

如果你维护自己的脚本，请确保它们不依赖硬编码的文件扩展名。用 zstd 的软件包将会使用 .pkg.tar.zst 的扩展名。

https://www.archlinuxcn.org/required-update-to-recent-libarchive/

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)和脚本(script)接管，因此无需手动干预升级过程。

此次变更的目的是想让内核包更独立(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 等地方手动打包安装的相关软件包。