Forwarded from 哈尔滨工业大学计算学部 Linux 开源学生俱乐部
要求更新到比较新的 libarchive
压缩算法
即将到来的 pacman 5.2 更新将允许打包工具使用
如果你维护自己的脚本,请确保它们不依赖硬编码的文件扩展名。用
https://www.archlinuxcn.org/required-update-to-recent-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/
Forwarded from TUNA Mirror Status (Miao Wu)
TUNA Mirrors 的 IPv6 地址暂时处于不可用状态
Forwarded from Akatsuki
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
bugs.archlinux.org
FS#64239 : [pacman] -U with personal gpgkey signature package let pacman core dump
Flyspray, a Bug Tracking System written in PHP.
{jpn.,ger.,ind.,sgp.,mex.,}mirror.pkgbuild.com 服务器正在维护,请暂时更换其它镜像服务器并耐心等待,预计数小时内恢复服务。服务器同步状态见 https://www.archlinux.org/mirrors/mirror.pkgbuild.com/
Arch Linux Chinese Messages
`base` 元包替代了同名的包组并且要求安装,需要手动干预升级 原本的 base 包组(group)已经被替换为同名的元包(metapackage),我们建议所有用户安装这个新包(pacman -Syu base),因为从今往后事实上要求安装该包。 对寻求帮助和支持的用户,我们期待他们运行的系统安装了 base 包。 附加说明: 请注意,新的 base 包不再包含以下内容: – 内核 – 编辑器 – 文件系统工具 (比如 e2fsprogs) ……以及可能还有别的你预期会有的包。对新安装的系统需要额外安装这些包。…
关于 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' 这个名字这么清晰明确。知道历史渊源可能会让我们有倾向,但是明显比起同时有
Q: 我们是否需要更新包的依赖关系让它们依赖 base 包而不是依赖 base 的成员?
A: 在这方面没有任何变化,我们没有严格规则是否需要这么做。这个话题更宽泛地说,是关于是否应该有间接包依赖关系的问题,这个我们今后会继续讨论。我的观点是保留直接依赖即可,因为完全没必要让整个宇宙都依赖 base 元包。不过,可能显式地列出直接依赖比起不列出依赖更正确、清晰、有用。
Q: 接下来呢,还有别的计划么?
A: 最重要的工作是把这个总结传达出去,帮助大家解决疑惑。接下来应该是继续一项一项地讨论剩下的议提——比如我们应该如何处理 systemd-sysvcompat 和本次变更带来的别的讨论。
原文: https://lists.archlinux.org/pipermail/arch-dev-public/2019-October/029693.html
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
Wikipedia
曲速引擎
曲速引擎(英語:Warp drive)是一种假想的超光速(faster-than-light, FTL)推进系统,经常出现于科幻小说的设定中,尤以在影片《星际旅行》中最为常见 。一架装载着曲速引擎的宇宙飞船,可以以快于光速的几个数量级的速度航行,同时又回避了时间膨胀的相对论性的问题。与其他科幻作品的超光速技术(比如跳跃引擎、銀河便車指南系列中的无限不可能引擎)不同,曲速引擎并不允许在两点间进行瞬时旅行;曲速引擎技术在宇宙飞船周围创造出了一种正常时空的人工“气泡”。(这与进入独立的区域或次元截然相反,比如…
关于新内核包和 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/
我们的官方内核: 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 等地方手动打包安装的相关软件包。
由于 Arch Linux 官方仓库和 [archlinuxcn] 仓库是分开的,镜像站上有可能其中之一有延迟而另一个没有,造成更新之后部分依赖 Python 的软件包无法使用。
cn 源的用户们需要注意以上不一致的情况可能导致的问题,若有疑虑请考虑这两天不要更新,等待软件包重建完成和镜像完全同步。另外记得重新打包从 AUR 等地方手动打包安装的相关软件包。
primus_vk>=1.3-1 更新需要手动干预
primus_vk 包在版本 1.3-1 之前缺少了一些动态库链接。这个错误已经在 1.3-1 中修正了,所以升级时需要手动覆盖掉没有被跟踪到的动态库链接。如果你遇到如下报错:
https://www.archlinuxcn.org/primus-vk13-1-update-requires-manual-intervention/
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,此次更新如果你遇到如下错误信息那么需要手动干预:
https://www.archlinuxcn.org/xorg-cleanup-requires-manual-intervention/
我们正在清理 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/
bugs.archlinux.org
FS#64892 : [Xorg] remove dead Xorg packages
Flyspray, a Bug Tracking System written in PHP.
现在开始使用 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/
邮件列表上已经宣布了,从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/
Telegram
Arch Linux Chinese Messages
要求更新到比较新的 libarchive
压缩算法 zstd 带来了更快的压缩解压时间,同时保持接近 xz 的压缩率。通过它我们能让 pacman 能更快地安装包,并且不会带来什么坏处。
即将到来的 pacman 5.2 更新将允许打包工具使用 zstd 压缩软件包。要安装这些包需要有 zstd 支持的 libarchive ,相关更新已经在 2018 年 9 月左右进入软件仓库。为了允许我们开始发布 zstd 压缩的软件包,我们要求所有用户更新到至少 libarchive 3.3.3-1 或以后的…
压缩算法 zstd 带来了更快的压缩解压时间,同时保持接近 xz 的压缩率。通过它我们能让 pacman 能更快地安装包,并且不会带来什么坏处。
即将到来的 pacman 5.2 更新将允许打包工具使用 zstd 压缩软件包。要安装这些包需要有 zstd 支持的 libarchive ,相关更新已经在 2018 年 9 月左右进入软件仓库。为了允许我们开始发布 zstd 压缩的软件包,我们要求所有用户更新到至少 libarchive 3.3.3-1 或以后的…
rsync 兼容性
我们的
所以我们决定去掉内嵌的依赖库,发布一个使用系统
https://www.archlinuxcn.org/rsync-compatibility/
我们的
rsync
包一直以来通过内嵌 zlib
的方式提供和老式 --compress
参数的兼容,维持对 3.1.0 以前版本的兼容性。版本 3.1.1 是2014年6月22日发布的,现在主流发行版应该都已经提供了。所以我们决定去掉内嵌的依赖库,发布一个使用系统
zlib
库的新版本。这也能修复迄今为止的和未来的安全问题。如果你运行 rsync 3.1.3-3
遇到报错,请去指责那些还在使用老版本的系统。https://www.archlinuxcn.org/rsync-compatibility/
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
相关bug: https://bugs.archlinux.org/task/65517
相关打包变更: https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/openssh&id=e8cca9cc928c87ac028aa81bead31a25fea1c2af
bugs.archlinux.org
FS#65517 : [openssh] upgrade to 8.2p1-1 breaks logins
Flyspray, a Bug Tracking System written in PHP.
更新到 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/
更新到 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/
bugs.archlinux.org
FS#65517 : [openssh] upgrade to 8.2p1-1 breaks logins
Flyspray, a Bug Tracking System written in PHP.
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/
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 前删除了 firewalld 包,下次安装 firewalld 包仍然会有文件冲突,此时请使用:
安装 firewalld 包。
https://www.archlinuxcn.org/firewalld081-2-update-requires-manual-intervention/
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:已延迟两天
上海科技大学 GeekPie:已延迟25天(此镜像大部分仓库都在延迟)
浙江大学 zju:已延迟20天(此镜像的 Arch Linux 官方仓库同样延迟)
腾讯云:已延迟四天
莞工 GNU/Linux 协会 dgut:已延迟两天