telegram-desktop （使用 gcc 9.1.0-1 编译）的一些版本可能导致无法打开，具体有故障的版本是 1.7.7-3 和 1.7.9-1 ，请尝试回退到 1.7.7-2 , 1.7.7-4 或等待 1.7.9-2 （与 gcc 9.1.0-2 一同）从 community-testing 移动到 community 。相关 bug https://bugs.archlinux.org/task/62953 和 gcc bug https://bugs.archlinux.org/task/62977

更新到 community/telegram-desktop 1.7.9-3 （testing 用户是 community-testing/telegram-desktop 1.7.9-4 ）将修复此问题

新版 1.7.10-1 和 1.7.10-3 还是有点问题，请升级到 1.7.10-5 （testing 用户是 1.7.10-6）

#warning 由于系统重置，以及数据盘初始化，我们将暂停服务一个月。全站将重定向到USTC。对您造成的不便我们深表歉意。

大部分镜像（包括 archlinux 及 archlinuxcn）已经恢复正常同步。

mariadb 10.4.x 更新需要手动干预

遵从上游的建议， mariadb 更新到 10.4.6-1 或者之后的版本需要改变配置文件的布局。
主配置文件的位置从 /etc/mysql/my.cnf （以及它的引入文件夹 /etc/mysql/my.cnf.d/ ）移动到了 /etc/my.cnf （相应的 /etc/my.cnf.d/ ）。请确保迁移您的配置。

逐实例的服务（像 [email protected] 这种）不再用单独的文件配置（像 /etc/mysql/myfoo.cnf 这种），而是移动到了主配置文件中的带群组后缀的配置块里面，每个服务一个带后缀的配置块。一个配置块看起来类似这样：

[mysqld.foo]
datadir = /var/lib/mysql-foo
socket = /run/mysqld/mysqld-foo.sock

和之前几次 mariadb 功能性升级一样的是，这一次也需要升级 data 文件夹。在修改好配置文件之后请运行以下命令进行升级：
systemctl restart mariadb.service && mariadb-upgrade -u root -p

https://www.archlinux.org/news/mariadb-104x-update-requires-manual-intervention/

Intel AC 9xxx wifi 用户请注意， 新版 linux-firmware 20190628.70e4394-1 可能导致 wifi 无法工作，[1] 报告中受影响的 Intel AC 包括 9260 9560 等网卡。遇到问题请降级 linux-firmware 到 20190618.acb56f2-1 ，并等待修复。
[1] https://bugs.archlinux.org/task/63117

setting the iwlwifi module option swcrypto=1 seems to avoid the problem. https://www.tg-me.com/archlinuxcn_offtopic/1417603

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

libbloom: /usr/lib/libbloom.so.1 exists in filesystem

请通过：

pacman -Suy --overwrite usr/lib/libbloom.so.1

来完成更新

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

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