TeX Live 打包改变了组织结构
从版本 2023.66594-9 开始,TeX Live 的打包改变了组织结构,更接近上游的集合(collections)。尽管新的
我们提供了新的 texlive-meta 元包用来安装所有子包(除了特定语种的),还有新的 texlive-doc 包提供了完整的文档,用以离线查阅。
https://www.archlinuxcn.org/tex-live-package-reorganization/
从版本 2023.66594-9 开始,TeX Live 的打包改变了组织结构,更接近上游的集合(collections)。尽管新的
texlive-basic
包替换了 texlive-core
包,很多原本属于 texlive-core 包的内容(包括一些特定语种的文件)现在被拆分到了别的包中去。如果想了解哪个 Arch 软件包中提供了特定 CTAN 宏包,可以使用 tlmgr 工具,比如:$ tlmgr info euler | grep collection这个的意思是说 euler CTAN 宏包包含在了
collection: collection-latexrecommended
texlive-latexrecommended
软件包中。你也可以使用 pacman -F
命令查询特定文件的归属。我们提供了新的 texlive-meta 元包用来安装所有子包(除了特定语种的),还有新的 texlive-doc 包提供了完整的文档,用以离线查阅。
https://www.archlinuxcn.org/tex-live-package-reorganization/
budgie-desktop >= 10.7.2-6 更新需要手动干预
当从 budgie-desktop 10.7.2-5 更新到版本 10.7.2-6 时,需要用 magpie-wm 包替代 mutter43 包,前者目前依赖 mutter 包。因为 mutter43 和 mutter 冲突,必须手动干预以完成更新。
首先删除 mutter43 ,然后紧接着进行更新。请勿在这两个步骤之间重新登入或重启。
当从 budgie-desktop 10.7.2-5 更新到版本 10.7.2-6 时,需要用 magpie-wm 包替代 mutter43 包,前者目前依赖 mutter 包。因为 mutter43 和 mutter 冲突,必须手动干预以完成更新。
首先删除 mutter43 ,然后紧接着进行更新。请勿在这两个步骤之间重新登入或重启。
pacman -Rdd mutter43https://www.archlinuxcn.org/budgie-desktop-1072-6-update-requires-manual-intervention/
pacman -Syu
ansible-core >= 2.15.3-1 更新可能需要手动干预
从
这意味着从
关于文档,可以在线查阅:https://docs.ansible.com/
关于配置文件,如 wiki 上说明的,基本配置可以用以下命令生成:
要恢复它,请运行以下命令:
从
ansible-core 2.15.3
起,上游将文档和示例代码放到了单独的专用仓库 (参见相关变更记录)。这意味着从
2.15.3
版本开始, ansible-core
包将不再打包文档和 /etc/ansible/ansible.cfg
下的默认配置样例。关于文档,可以在线查阅:https://docs.ansible.com/
关于配置文件,如 wiki 上说明的,基本配置可以用以下命令生成:
ansible-config init --disabled > ansible.cfg在从
<= 2.15.2-1
之前的版本升级到 2.15.3-1
之后版本的 ansible-core
之后,所有位于 /etc/ansible/ansible.cfg
的自定义全局 ansible 配置文件会变成 pacsave
文件。要恢复它,请运行以下命令:
mv /etc/ansible/ansible.cfg.pacsave /etc/ansible/ansible.cfg
https://www.archlinuxcn.org/ansible-core-2153-1-update-may-require-manual-intervention/默认密码哈希算法和 umask 配置的改动
随着 shadow >= 4.14.0 更新, Arch Linux 的默认密码哈希算法由 SHA512 变更为 yescrypt。
另外,umask 配置现在需要在 /etc/login.defs 中配置而不是在 /etc/profile 中。
这个改动应该不需要用户作任何手动干预。
使用 yescrypt 的理由
我们选择了基于密码的密钥推导函数 (KDF) 和密码哈希方案 yescrypt,因为它被 libxcrypt 所采用 (已经可以在 libxcrypt 中使用,libxcrypt 由 pam 使用),并且相较于 SHA512,yescrypt 对密码爆破有着更好的抵御能力。
虽然密码哈希竞赛的胜者是 argon2,但是这个算法目前还没有被 libxcrypt 采用 (第一次尝试,第二次尝试)。
配置 yescrypt
在 pam 实现对 /etc/login.defs 中的 YESCRYPT_COST_FACTOR 配置项的读取之前,该配置项没有任何作用。如果你需要为 YESCRYPT_COST_FACTOR 配置一个高于(或低于)默认值(5)的数值,那么你可以将其配置为使用 pam_unix 模块的 rounds 选项 ( 例如在 /etc/pam.d/system-auth 中)。
总体变更列表
* yescrypt 替代 SHA512 作为默认使用的密码哈希算法
* pam 会尊重在 /etc/login.defs 被选中的 ENCRYPT_METHOD 并且不会再覆盖被选中的方法
* filesystem (>= 2023.09.18) 和 pambase (>= 20230918) 中的改动确保了 umask 会在 /etc/login.defs 中被集中地配置而不再是在 /etc/profile 中
https://www.archlinuxcn.org/changes-to-default-password-hashing-algorithm-and-umask-settings/
随着 shadow >= 4.14.0 更新, Arch Linux 的默认密码哈希算法由 SHA512 变更为 yescrypt。
另外,umask 配置现在需要在 /etc/login.defs 中配置而不是在 /etc/profile 中。
这个改动应该不需要用户作任何手动干预。
使用 yescrypt 的理由
我们选择了基于密码的密钥推导函数 (KDF) 和密码哈希方案 yescrypt,因为它被 libxcrypt 所采用 (已经可以在 libxcrypt 中使用,libxcrypt 由 pam 使用),并且相较于 SHA512,yescrypt 对密码爆破有着更好的抵御能力。
虽然密码哈希竞赛的胜者是 argon2,但是这个算法目前还没有被 libxcrypt 采用 (第一次尝试,第二次尝试)。
配置 yescrypt
在 pam 实现对 /etc/login.defs 中的 YESCRYPT_COST_FACTOR 配置项的读取之前,该配置项没有任何作用。如果你需要为 YESCRYPT_COST_FACTOR 配置一个高于(或低于)默认值(5)的数值,那么你可以将其配置为使用 pam_unix 模块的 rounds 选项 ( 例如在 /etc/pam.d/system-auth 中)。
总体变更列表
* yescrypt 替代 SHA512 作为默认使用的密码哈希算法
* pam 会尊重在 /etc/login.defs 被选中的 ENCRYPT_METHOD 并且不会再覆盖被选中的方法
* filesystem (>= 2023.09.18) 和 pambase (>= 20230918) 中的改动确保了 umask 会在 /etc/login.defs 中被集中地配置而不再是在 /etc/profile 中
https://www.archlinuxcn.org/changes-to-default-password-hashing-algorithm-and-umask-settings/
警惕冒用本站管理员身份的虚假邮件
今收到多名镜像管理员的反馈,收到了发件人为「[email protected]」的关于 repo.archlinuxcn.org 的问询邮件,但回复因无此邮箱而被退信。
在此声明:此邮件是假冒的,依云(lilydjwg)并无此邮件地址。依云的主邮件地址为「[email protected]」,本站管理相关会使用「[email protected]」。如有需要,邮件可以被签名,GPG 密钥指纹为 356690A1E7404E30D0E902B2E64D049594A54F54。
请各方收到声称为本站管理员邮件时注意甄别,如有疑问可以到聊天群组找管理人员确认,或者直接发信到 [email protected] 询问。
今收到多名镜像管理员的反馈,收到了发件人为「[email protected]」的关于 repo.archlinuxcn.org 的问询邮件,但回复因无此邮箱而被退信。
在此声明:此邮件是假冒的,依云(lilydjwg)并无此邮件地址。依云的主邮件地址为「[email protected]」,本站管理相关会使用「[email protected]」。如有需要,邮件可以被签名,GPG 密钥指纹为 356690A1E7404E30D0E902B2E64D049594A54F54。
请各方收到声称为本站管理员邮件时注意甄别,如有疑问可以到聊天群组找管理人员确认,或者直接发信到 [email protected] 询问。
即将到来的 JDK/JRE 21包更新可能需要手动干预
我们将为我们的发行版中的 JDK/JRE 包引入一个改动。这个改动是由较新版本的 Java (> 9) 的 JRE 构建方式导致的。我们将在 Java 21 版本中引入这个改动。
总的来说,我们将会让 JDK 和 JRE 包冲突,而不再是允许它们在系统中共存。JDK 包已经包含了运行 Java 应用所需的运行时环境,所以如果你同时需要 Java 的运行时环境和编译环境的话,以后你只需要安装 JDK 包即可。如果你只需要 Java 的运行时环境的话,那么 JRE (或 jre-headless) 就足够了。
这可能需要由用户在系统升级时进行手动干预:
* 如果你同时安装了 JDK 和 JRE,那么你可以使用 pacman -Syu jdk-openjdk 命令来手动安装 JDK 并同时删除 JRE 相关的包。
* 如果你同时安装了 JRE 和 JRE-headless,那么你将会需要手动选择二者中的一个并手动安装它,因为这两个包现在会互相冲突。
* 如果你只安装了 JDK/JRE/JRE-headless 中的一个,那么 pacman 应该可以在不需要用户手动干预的情况下自行解析依赖。
目前,这些内容仅针对即将到来的 JDK 21 版本发布。
https://www.archlinuxcn.org/incoming-changes-in-jdk-jre-21-packages-may-require-manual-intervention/
我们将为我们的发行版中的 JDK/JRE 包引入一个改动。这个改动是由较新版本的 Java (> 9) 的 JRE 构建方式导致的。我们将在 Java 21 版本中引入这个改动。
总的来说,我们将会让 JDK 和 JRE 包冲突,而不再是允许它们在系统中共存。JDK 包已经包含了运行 Java 应用所需的运行时环境,所以如果你同时需要 Java 的运行时环境和编译环境的话,以后你只需要安装 JDK 包即可。如果你只需要 Java 的运行时环境的话,那么 JRE (或 jre-headless) 就足够了。
这可能需要由用户在系统升级时进行手动干预:
* 如果你同时安装了 JDK 和 JRE,那么你可以使用 pacman -Syu jdk-openjdk 命令来手动安装 JDK 并同时删除 JRE 相关的包。
* 如果你同时安装了 JRE 和 JRE-headless,那么你将会需要手动选择二者中的一个并手动安装它,因为这两个包现在会互相冲突。
* 如果你只安装了 JDK/JRE/JRE-headless 中的一个,那么 pacman 应该可以在不需要用户手动干预的情况下自行解析依赖。
目前,这些内容仅针对即将到来的 JDK 21 版本发布。
https://www.archlinuxcn.org/incoming-changes-in-jdk-jre-21-packages-may-require-manual-intervention/
Forwarded from TUNA Mirror Status (Harry)
Bugtracker 到 GitLab 的迁移已经完成
我们很高兴地宣布 bugtracker 到 GitLab 的迁移已经完成!🥳
感谢每个在迁移过程中提供了帮助的人。
这意味着 GitLab 上的软件包仓库的 issue tracker 和 merge request 现在已经被启用了。
在此之后,旧版的 bugtracker 将会被关闭。但是出于归档相关的原因,我们会为其提供一份静态副本,如此,链接(比如这个随机选取的 Task #56716)将会保持稳定可用。被迁移的 bug 的评论区会留有一个关闭评论区的评论,该评论会提供一个指向 GitLab 的新 URL。
软件包的打包 bug 现在在对应软件包的打包资源仓库中创建。archlinux.org 的软件包页面上的 “Add a new Bug” 按钮现在将会自动将你引导到正确的地方去创建 issue。在此之后,工作流基本上和原先的一致。首先,我们的 Bug Wrangler 们会查看并分类 issue,然后它们将会被交由对应的 Package Maintainer 们去处理。一个完整的 issue 列表可以在这里找到。
如果你没有一个(授权认证了我们的 SSO 服务的)GitLab 帐号的话,你可以像 banner 中建议的那样使用你想要的用户名来写一份邮件发送到 [email protected]。
https://www.archlinuxcn.org/bugtracker-migration-to-gitlab-completed/
我们很高兴地宣布 bugtracker 到 GitLab 的迁移已经完成!🥳
感谢每个在迁移过程中提供了帮助的人。
这意味着 GitLab 上的软件包仓库的 issue tracker 和 merge request 现在已经被启用了。
在此之后,旧版的 bugtracker 将会被关闭。但是出于归档相关的原因,我们会为其提供一份静态副本,如此,链接(比如这个随机选取的 Task #56716)将会保持稳定可用。被迁移的 bug 的评论区会留有一个关闭评论区的评论,该评论会提供一个指向 GitLab 的新 URL。
软件包的打包 bug 现在在对应软件包的打包资源仓库中创建。archlinux.org 的软件包页面上的 “Add a new Bug” 按钮现在将会自动将你引导到正确的地方去创建 issue。在此之后,工作流基本上和原先的一致。首先,我们的 Bug Wrangler 们会查看并分类 issue,然后它们将会被交由对应的 Package Maintainer 们去处理。一个完整的 issue 列表可以在这里找到。
如果你没有一个(授权认证了我们的 SSO 服务的)GitLab 帐号的话,你可以像 banner 中建议的那样使用你想要的用户名来写一份邮件发送到 [email protected]。
https://www.archlinuxcn.org/bugtracker-migration-to-gitlab-completed/
新系统中安装 archlinuxcn-keyring 包前需要手动信任 farseerfc 的 key
archlinuxcn 社区源的 keyring 包 archlinuxcn-keyring 由 farseerfc 的 key 签署验证,而 Arch Linux 官方 keyring 中包含了 farseerfc 的 key 。自12月初 archlinux-keyring 中删除了一个退任的 master key 导致 farseerfc 的 key 的信任数不足,由 GnuPG 的 web of trust 推算为 marginal trust,从而不再能自动信任 archlinuxcn-keyring 包的签名。
如果你在新系统中尝试安装 archlinuxcn-keyring 包时遇到如下报错:
请使用以下命令在本地信任 farseerfc 的 key 。此 key 已随 archlinux-keyring 安装在系统中,只是缺乏信任:
之后继续安装 archlinuxcn-keyring :
https://www.archlinuxcn.org/archlinuxcn-keyring-manually-trust-farseerfc-key/
archlinuxcn 社区源的 keyring 包 archlinuxcn-keyring 由 farseerfc 的 key 签署验证,而 Arch Linux 官方 keyring 中包含了 farseerfc 的 key 。自12月初 archlinux-keyring 中删除了一个退任的 master key 导致 farseerfc 的 key 的信任数不足,由 GnuPG 的 web of trust 推算为 marginal trust,从而不再能自动信任 archlinuxcn-keyring 包的签名。
如果你在新系统中尝试安装 archlinuxcn-keyring 包时遇到如下报错:
error: archlinuxcn-keyring: Signature from "Jiachen YANG (Arch Linux Packager Signing Key) <[email protected]>" is marginal trust
请使用以下命令在本地信任 farseerfc 的 key 。此 key 已随 archlinux-keyring 安装在系统中,只是缺乏信任:
sudo pacman-key --lsign-key "[email protected]"
之后继续安装 archlinuxcn-keyring :
sudo pacman -S archlinuxcn-keyring
https://www.archlinuxcn.org/archlinuxcn-keyring-manually-trust-farseerfc-key/
GitLab
Remove main key of diabonas (#246) · Issues · Arch Linux / Arch Linux Keyring · GitLab
Remove a main key Details Username:
Forwarded from oldherl
[archlinuxcn] 仓库主服务器 repo.archlinuxcn.org 暂时不可用,请使用其他镜像
从昨日(2023-12-27 13:30 UTC+8)起,本社区 [archlinuxcn] 仓库主服务器遭遇未知技术故障,无法访问。请暂时改用其他镜像服务器,如各大高校的镜像或海外 xTom 镜像等。注意各镜像服务器只有故障前的包的镜像,在主服务器故障期间它们将无法收到更新。
从昨日(2023-12-27 13:30 UTC+8)起,本社区 [archlinuxcn] 仓库主服务器遭遇未知技术故障,无法访问。请暂时改用其他镜像服务器,如各大高校的镜像或海外 xTom 镜像等。注意各镜像服务器只有故障前的包的镜像,在主服务器故障期间它们将无法收到更新。
由于遭受 DDoS 攻击,ArchWiki 在中国大陆部分地区(主要是中国电信的网络)会返回 403 错误。请知悉,受影响的用户可以考虑更换不同的网络进行访问。
另注,已经独立出来的中文版维基不受影响。也可以安装并使用仓库里的 arch-wiki-docs 或者 arch-wiki-lite 离线文档包。
https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/559
另注,已经独立出来的中文版维基不受影响。也可以安装并使用仓库里的 arch-wiki-docs 或者 arch-wiki-lite 离线文档包。
https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/559
GitLab
archwiki: 403 errors for multiple users from China (#559) · Issues · Arch Linux / infrastructure · GitLab
Recently multiple users report 403 errors (nginx error page) in our community, and I can see from a test website that requests from several places result in 403...
我们将 dbus-broker 设为默认的 D-Bus 守护进程
为了提高性能、可靠性以及与 systemd 的集成,我们将
在可预见的未来,我们仍将支持使用
如需了解更详细的原因,请参阅我们的 RFC 25 。
https://www.archlinuxcn.org/making-dbus-broker-our-default-d-bus-daemon/
为了提高性能、可靠性以及与 systemd 的集成,我们将
dbus-broker
设为 D-Bus 的默认实现。在可预见的未来,我们仍将支持使用
dbus-daemon
,即之前的实现。pacman 会询问你是否要安装 dbus-broker-units
或 dbus-daemon-units
。我们建议选择默认选项。如需了解更详细的原因,请参阅我们的 RFC 25 。
https://www.archlinuxcn.org/making-dbus-broker-our-default-d-bus-daemon/
GitLab
Files · master · Arch Linux / RFCs · GitLab
Arch Linux RFCs. https://rfc.archlinux.page/
mkinitcpio 迁移挂钩及早期微码更新
伴随 mkinitcpio v38 发布,几个之前以 Arch 打包提供的挂钩(hook)移动到了 mkinitcpio 上游项目中。这些挂钩是: systemd, udev, encrypt, sd-encrypt, lvm2 和 mdadm_udev。
为了保证不破坏用户设置,我们在相关包中加入了一些临时的冲突,避免安装不再相互兼容的包。
以下这些包必须同时更新:
另外请注意
https://www.archlinuxcn.org/mkinitcpio-hook-migration-and-early-microcode/
伴随 mkinitcpio v38 发布,几个之前以 Arch 打包提供的挂钩(hook)移动到了 mkinitcpio 上游项目中。这些挂钩是: systemd, udev, encrypt, sd-encrypt, lvm2 和 mdadm_udev。
为了保证不破坏用户设置,我们在相关包中加入了一些临时的冲突,避免安装不再相互兼容的包。
以下这些包必须同时更新:
- mkinitcpio 38-3
- systemd 255.4-2
- lvm2 2.03.23-3
- mdadm 4.3-2
- cryptsetup 2.7.0-3
另外请注意
mkinitpcio
的 --microcode
选项和 preset 文件中的 microcode
选项将被弃置,取而代之的是新的 microcode
挂钩。这可以让你删掉引导配置中的 initrd
加载微码的行,因为它们现在已经打包进了主 initramfs 镜像文件中。https://www.archlinuxcn.org/mkinitcpio-hook-migration-and-early-microcode/
由于受到大量下载的攻击,部分中国大陆的 IP 可能无法访问 repo.archlinuxcn.org ,请知悉,并改用镜像站点。
Please open Telegram to view this post
VIEW IN TELEGRAM