¡Ya disponible! Investigación de Telegram 2025 — los principales insights del año 
Arch Linux Chinese Messages
Ir al canal en Telegram
Arch Linux 中文相关信息 跟进 Arch Linux 日常踩坑预警，翻译官方新闻， testing 测试预警等。另有 @archlinuxcn_updates 提供滚动打包记录。 频道内容来自 Arch Linux 中文社区群组 @archlinuxcn_group https://fars.ee/~readme.html 杜洛夫在所有订阅数较多的频道下方都添加了广告，其收益并不分配给频道主，频道主也无法控制其内容。如果在本频道下方看到广告，均与 Arch CN 社区无关，请勿点击或相信其内容
Mostrar más📈 Análisis del canal de Telegram Arch Linux Chinese Messages
El canal Arch Linux Chinese Messages (@archlinuxcn) en el segmento lingüístico de Chino es un actor destacado. Actualmente la comunidad reúne a 10 887 suscriptores, ocupando la posición 11 460 en la categoría Tecnologías y Aplicaciones y el puesto 19 303 en la región China.
📊 Métricas de audiencia y dinámica
Desde su creación el невідомо, el proyecto ha mostrado un crecimiento acelerado, reuniendo a 10 887 suscriptores.
Según los últimos datos del 10 junio, 2026, el canal mantiene una actividad estable. En los últimos 30 días la variación de miembros fue de 99, y en las últimas 24 horas de 1, conservando un alto alcance.
- Estado de verificación: No verificado
- Tasa de interacción (ER): El promedio de interacción de la audiencia es 65.43%. Durante las primeras 24 horas tras publicar, el contenido suele obtener 18.22% de reacciones respecto al total de suscriptores.
- Alcance de las publicaciones: Cada publicación recibe en promedio 7 125 visualizaciones. En el primer día suele acumular 1 984 visualizaciones.
- Reacciones e interacción: La audiencia responde de forma activa: el promedio de reacciones por publicación es 145.
📝 Descripción y política de contenido
El autor describe el recurso como un espacio para expresar opiniones subjetivas:
“Arch Linux 中文相关信息
跟进 Arch Linux 日常踩坑预警，翻译官方新闻， testing 测试预警等。另有 @archlinuxcn_updates 提供滚动打包记录。
频道内容来自 Arch Linux 中文社区群组 @archlinuxcn_group
https://fars.ee/~readme.html
杜洛夫在所有订阅数较多的频道下方都添加了广告，其收益并不分配给频道主，频道主也无法控制其内容。如果在本频道下方看到广告，均与 Arch CN 社区无关，请勿点击或...”
Gracias a la alta frecuencia de actualizaciones (últimos datos recibidos el 11 junio, 2026), el canal mantiene la vigencia y un amplio alcance. La analítica demuestra que la audiencia interactúa activamente con el contenido, lo que lo convierte en un punto de referencia dentro de la categoría Tecnologías y Aplicaciones.
10 887
Suscriptores
+124 horas
+97 días
+9930 días
Archivo de publicaciones
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/
Python 3.8 于14日晚上已经进入 extra 仓库，伴随着大量 Python 包的更新。[archlinuxcn] 仓库的大多数依赖 Python 的包应该会在15日早上或者中午完成更新，但是不能排除因为打包出错而延迟的情况。
由于 Arch Linux 官方仓库和 [archlinuxcn] 仓库是分开的，镜像站上有可能其中之一有延迟而另一个没有，造成更新之后部分依赖 Python 的软件包无法使用。
cn 源的用户们需要注意以上不一致的情况可能导致的问题，若有疑虑请考虑这两天不要更新，等待软件包重建完成和镜像完全同步。另外记得重新打包从 AUR 等地方手动打包安装的相关软件包。
关于新内核包和 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/
关于 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{jpn.,ger.,ind.,sgp.,mex.,}mirror.pkgbuild.com 服务器正在维护，请暂时更换其它镜像服务器并耐心等待，预计数小时内恢复服务。服务器同步状态见 https://www.archlinux.org/mirrors/mirror.pkgbuild.com/
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要求更新到比较新的 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/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关于此次 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 -
`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
由于不可抗力，国庆期间重庆大学多个对外服务将无法从外部访问。镜像站服务亦受到牵连。恢复对外服务时间未知。对于所造成的不便我们深感遗憾。
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
网易开源镜像站（mirrors.163.com）用户请注意：其 Arch Linux 仓库已经延迟六天，Arch Linux CN 仓库已经延迟两天。
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/
