啟用 libglvnd 支援的 mesa 已在 testing 套件庫

發表於

原文:mesa with libglvnd support is now in testing

由於 Fedora 團隊的協助,以及 xorg-server 上游貢獻的修補,mesa-17.0.0-3 現在可與 nvidia-378.13 驅動程式併存,無須再使用各種 libgl/libglx 的 hacks 了。

  • 首先要做的是透過解除安裝某些 libgl 的相關套件,來移除 libglxxorg-server-1.19.1-3 的符號連結,以及相關的 mesa/nvidia 驅動程式。這項工作非常艱難,因為會導致 optimus 系統失效,也需要手動更新 xorg-server 的設定。

  • 接下來這步驟是藉由更新過的 10-nvidia-drm-outputclass.conf 設定檔的輔助,可以提供您的 xorg-server 在搭配 optimus 系統的環境下一個基本可用的體驗。

敬請多加測試,並將您的意見反饋發表到論壇討論串或是 bugtracker 上。

分階段取消對 i686 處理器家族的支援

發表於

原文:Phasing out i686 support

因為 i686 處理器家族在我們的開發者與社群用戶裡的能見度愈來愈低,我們決定要逐步取消這個平台的支援。

這項決策意謂著今年二月份的 ISO 映像檔會是最後一份可供安裝 32 位元版本 Arch Linux 的安裝媒體。接下來的為期九個月是不建議使用期,在這期間的 i686 處理器版本仍會收到更新的套件。自 2017 年 11 月開始,套件與套件庫相關工具的維護者將不再需要去特別標註他們維護的項目不支援 i686 處理器。

然而,還是有人對繼續維持 i686 版本感興趣,我們鼓勵社群在我們的指引下來從事這項工作。透過 arch-ports 郵遞列表以及在 Freenode 上的 #archlinux-ports IRC 頻道這些媒體,我們會有進一步的協調討論。

[multilib] 套件庫不受此變動的影響。

請務必在 2016-04-23 前升級到 pacman-5.0.1

發表於

原文:Required update to pacman-5.0.1 before 2016-04-23

pacman-5.0 版開始,新增了 “transactional hooks” 的支援。這項功能可以讓我們做到像是「在某次升級時,若有多組字型套件,以往每升級一組字型套件就要重建一次字型快取,現在則只需統一重建一次就好」如此的改進,無論在升級流程的速度提升,以及減少開發者與被信賴用戶 (Trusted Users) 的套件打包負擔都有所助益。

為了讓 “transactional hooks” 可以啟用,我們需要所有用戶配合,請在 2016-04-23 前將 pacman 至少升級 5.0.1 版。Pacman-5.0.1 已於 2016-02-23 釋出,所以各位有兩個月的時間可以升級您們的系統。

openssh-7.0p1 棄用 ssh-dss 類金鑰

發表於

原文:openssh-7.0p1 deprecates ssh-dss keys

因為近期揭露的安全弱點,新推出的 openssh-7.0p1 棄用了 ssh-dss 類型、亦即所謂的 DSA 型金鑰。詳情請參見官方公告

在更新與重新啟動遠端的 sshd 之前,請確認您沒有使用此類的金鑰來連接這台機器。要檢查機器上個別用戶是否採用了 DSA 型金鑰來獲取存取權限,可使用:

grep ssh-dss ~/.ssh/authorized_keys

如果您發現有使用此類金鑰,務必確認您有替代的登入方法,像是使用不同類型的金鑰,或是密碼驗證。

最後,ssh-dss 型的機器用金鑰 (host keys) 同樣也被棄用了,當您連上更新後的機器時,也需要重新確認新產生的金鑰指紋(針對不同金鑰類型的 host key)。

若使用了 discard 參數,軟體型 RAID 0 會發生資料毀損

發表於

原文:Data corruption on software RAID 0 when discard is used

幾週前送進 [core] 套件庫的 Linux 核心 (4.0.2+, LTS 3.14.41+) 有一個錯誤,檔案系統若以 discard 參數掛載、且配置在軟體型 RAID 0 陣列內就會引發資料毀損。然而即使未指定使用 discard 參數,當使用 fstrim 命令也同樣會觸發這個錯誤。 (如果您並未使用軟體型 RAID 0 搭配 discard 參數,那麼本問題並不會對您造成影響。)

本問題已經在 linux 4.0.4-2linux-lts 3.14.43-2 修正。但是由於這個問題的發生原理使然,很可能系統資料已經在前述有問題的核心版本上發生毀損情況了。強烈建議您在受到影響的檔案系統上做資料完整性檢查,可使用 fsck 工具,並(或)從現存的完整備份那邊還原資料。

若需要進一步的資訊,請參考 Holger Kiehl 在 LKML 發表的貼文、Phoronix 上的相關文章以及被 backport 到 Arch 核心的修正