軟件包維護者指導原則

出自 Arch Linux 中文维基

Trusted User (TU) 是負責使 AUR 正常工作的社區成員。他們維護熱門的包(並在必要時與上游項目交涉或者向上游項目發送補丁),並且參與管理事務的表決。TU 由現任的 TU 從活躍的社區成員中民主選舉產生。 TU 是唯一具有決定 AUR 發展方向的權利的社區成員羣體。

TU們依靠TU bylaws來管理社區。

新 TU 的 TODO 列表[編輯 | 編輯原始碼]

  1. 仔細閱讀本頁面
  2. 閱讀 TU Bylaws
  3. 確認自己在 AUR 的賬户詳細信息是最新的
  4. 讓一個贊助者在 AUR 中給您 TU 狀態.
  5. 將你自己添加到 Trusted Users 頁面
  6. 訂閱 Arch Linux 開發郵件列表 arch-dev-public.
  7. 提醒 Arch wiki bureaucrat 將您加入 ⧼group-archtu⧽ 組.
  8. 提醒 BBS admin 更改你在論壇上的賬户
  9. 讓推薦人提供 #archlinux-staff#archlinux-tu 密碼,加入頻道,這雖然不是必須,但這是和團隊認識和合作的一個好方式。
    • 如果需要轉發,請申請 Matrix.
    • 如果需要 @archlinux/trusteduser/username,請連續羣組聯絡人 group contacts
  10. 讓一個贊助者在基礎設施問題追蹤中使用 Onboarding 模板創建任務,並提供如下信息:
    • 包含一個 SSH 公鑰,如果還沒有,使用 ssh-keygen 生成。Using SSH Keys 包含更多信息。
    • SSO 帳號要使用的用户名,此名稱也會用來創建 @archlinux.org 郵箱地址。
    • 全名.
    • 個人郵箱地址和有效的 PGP 公鑰 ID, 將會此信息創建開發者網站 (archweb) 帳號並連結到新建的 SSO 帳號。
    • 使用私人郵件還是馬上要創建的 username@archlinux.org 郵箱地址加入非公開郵件列表,並允許向 arch-dev-public 發送郵件。
  11. DeveloperWiki:Staff Services#Email 創建 @archlinux.org 郵箱
  12. Create a PGP key pair for package signing by following the
  13. 軟件包簽名創建 PGP key,執行添加打包人新密鑰動作(使用新的 <username>@archlinux.org 地址作為 uid).
  14. 按照此模板向 Ionuț Bîru (ibiru@archlinux.org) 或 Florian Pritz (bluewind@xinu.at)發郵件,包含所有信息以獲得 dev 接口的訪問權限
  15. 讓贊助者在 archlinux-keyring 倉庫問題追蹤使用 New Packager Key 模板創建任務,用至少三個主密鑰簽名您的 PGP。
  16. 安裝 devtools 軟件包
  17. 為主機 orion.archlinux.orgrepos.archlinux.org 上配置ssh 私鑰
  18. Ssh 到 yourname@repos.archlinux.org (得到權限之後).
  19. 如果你在兩天內沒有在 bugtracker 被升級到 TU 組,在 arch-dev-public 發郵件詢問
  20. 開始你的貢獻吧!

TU 和 AUR[編輯 | 編輯原始碼]

TU 應該仔細檢查那些被提交到 AUR 分類中的軟件是否含有惡意代碼,以及PKGBUILD包是否符合標準。在UNSUPPORTED 中,大約 80% 的 PKGBUILD 都非常簡單,TU 團隊可以很快的檢查其可用性以及安全性。

TU 也應該檢查 PKGBUILD 的一些小錯誤,提出修改以及改進建議。TU 應該努力確認所有的軟件包遵循了Arch Packging Guidelines/Standards 並與其他打包者分享他們的技能和經驗來提升 archlinux 的軟件包發行版本的質量。

TU 也很適合撰寫文檔來記錄一些值得推薦的行為。

Rewriting git history[編輯 | 編輯原始碼]

In some cases rewriting the history of an AUR repository is required, for example when a user inadvertently uses their real name in a published commit. This can be automated with git-filter-branch(1).

To force push the new history, forward the AUR_OVERWRITE=1 environment variable to git-push(1). See [1] for details.

警吿: It is recommended to create a backup of the repository before rewriting history.
Modify committer or author identity

Install git-filter-repo and run:

$ git-filter-repo --name-callback 'return name.replace(b"Old name", b"New name")' --email-callback 'return email.replace(b"old@email.com", b"new@email.com")'

Alternatively, use git filter-branch --env-filter with the GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL environment variables. For example:

git filter-branch --env-filter '
if test "$GIT_AUTHOR_EMAIL" = "lepetit@prince.com"; then
  GIT_AUTHOR_EMAIL=user@users.noreply.github.com
fi
if test "$GIT_AUTHOR_NAME" = "Antoine de Saint-Exupéry"; then
  GIT_AUTHOR_NAME=user
fi'
注意: git-log(1) only displays the git author by default. Use git log --pretty=fuller to display the author and committer.

Handling AUR requests[編輯 | 編輯原始碼]

這篇文章的某些內容需要擴充。

原因: This list is incomplete for now and should be expanded. (在 Talk:軟件包維護者指導原則 中討論)

TUs should periodically check the requests filed on the AUR. For that there are some generic rules what to check for each request type:

Orphan request
  • check if the request is older then 14 days (the date column turns red in the overview) (you cannot accept it before that anyway)
  • check if there was no update to the package itself (commit or release) done in the past 14 days
  • check if there was no comment from the package maintainer done in the past 14 days


If all of the above points are true then you can accept the Orphan Request.

TU 和 [community], 包維護導引[編輯 | 編輯原始碼]

軟件包進入 [community] 倉庫的規則[編輯 | 編輯原始碼]

  • 軟件包還沒有加入其它任何倉庫,確保其它打包者沒有同時提交軟件包。檢查 AUR 評論,閱讀 aur-general 中文章的標題,在 bugtracker 的全部項目中搜索, grep Subversion 日誌,然後向私有 TU IRC channel 發送消息.
  • Pacman 包裝程序是一個特例,不管投票數有多高,都不會被批准進入。如果是 AUR helper,可以寫封郵件到 arch-dev-public,需提供希望添加的包和團隊的贊同和反對意見。
  • 只有「流行」的軟件包才能進入倉庫,如 pkgstats 規定的 1% 使用數或者 AUR 中 10 票以上
  • 自動屬於此規則的例外的軟件包包括:
    • i18n 包
    • 輔助功能軟件包
    • 驅動程序
    • 滿足「流行」定義的軟件包所依賴的包,包括 makedeps 和 optdeps
    • 屬於同一集合併一起發佈的軟件包,前提是這一集合的某些軟件包滿足「流行」定義
  • 任何其他不屬於上述例外的軟件包想要進入倉庫都需首先在 aur-general 郵件列表中提出申請,並解釋成為例外的原因(例如重命名的軟件包、新軟件包等)。軟件包進入倉庫需要其他三名 TU 同意。維護大量的「不流行」軟件包的 TU 的申請更有可能被拒絕。
  • 強烈建議 TU 移除 [community] 倉庫中他們正在維護的低使用率的軟件包。儘管離職的 TU 的軟件包在被採用之前會被過濾的情況會發生,移除的行為不會被強制要求
  • 軟件包從 AUR 提升到其它倉庫時,應該將 pkgrel 的數值加 1,這樣已經安裝了軟件包的用户還可以繼續收到軟件自動更新。還有一個好處就是避免 pkgrel 重置為 1 時用户收到本地軟件包更新的警吿.

訪問並更新倉庫[編輯 | 編輯原始碼]

[community] 倉庫現在使用和 [core] 和 [extra] 倉庫相同的工具 devtools 來上傳軟件包。唯一的不同在於 [core] 和 [extra] 使用伺服器 https://archlinux.org 而 [community] 倉庫使用伺服器repos.archlinux.org。因此 Packager Guide 頁面中大多數指令都能在不用改動的情況下使用。這裏介紹關於 [community] 倉庫的一些特殊的信息。devtools 需要軟件打包人員設置 makepkg.conf 中的 PACKAGER 變量.

首先,你應該做一個 [community] 軟件倉庫的非遞歸簽出

$ svn checkout -N svn+ssh://svn-community@repos.archlinux.org/srv/repos/svn-community/svn svn-community

這一步驟將會創建一個名為 svn-community 的目錄,裏面只有包含 svn 信息的 .svn 目錄。

關於簽出更新所有軟件包或添加一個軟件包,請參見 Packager Guide

移除一個軟件包:

$ ssh repos.archlinux.org /community/db-repo-remove community arch pkgname

每一個分割的軟件包都需要此操作,在此處及下文中,arch 應該是 x86_64, 這是在Arch 棄用 i686 之後唯一支持的架構。

注意: 如果編輯的是 any 架構的軟件包,可以按 x86_64 執行,一般都能正常使用。

當你完成了 PKGBUILD 等之後,你應該提交你的更改(svn commit)。

用腳本 extra-x86_64-build 編譯軟件包. 如該要上傳到 testing,也需要運行 testing-x86_64-build.

gpg --detach-sign *.pkg.tar.xz 簽署軟件包. 如果使用不同密鑰進行簽名,可以在 ~/.makepkg.conf 中設置 GPGKEY=<identifier>.

如果你想要發佈一個軟件包,首先將軟件包和簽名用 scp 拷貝到 repos.archlinux.org 的 staging/community 目錄下,然後通過進入 pkgname/trunk 目錄並運行 archrelease community-arch 來為標識該軟件包。這將在 community-x86_64 目錄下創建一份 trunk 條目的 svn 拷貝。這也表示這一軟件包已經在所在平台的 [community] 倉庫中了。注意 staging 目錄與 staging 倉庫不一樣,所有軟件包都需要上傳到 staging 目錄。可以使用 communitypkg 腳本自動執行這個過程。

軟件包更新匯總:

  • 更新軟件包目錄 (svn update some-package)
  • 改變當前目錄到軟件包的 trunk 目錄 (cd some-package/trunk)
  • 編輯 PKGBUILD,做出必要的更改,用 updpkgsums 更新校驗和.
  • 編譯軟件包:使用 makechrootpkgextra-x86_64-build. 必須乾淨的chroot環境中構建軟件包。
  • Namcap PKGBUILD 文件和 pkg.tar.gz 二進制包
  • 使用 communitypkg "commit message" 提交簽名拷貝標識此軟件包。這將自動進行下面步驟
    • 將改變提交至 trunk (svn commit)
    • 簽署軟件包: gpg --detach-sign *.pkg.tar.xz.
    • 將軟件包和簽名拷貝到 orion.archlinux.org (scp pkgname-ver-rel-arch.pkg.tar.xz *.pkg.tar.xz.sig repos.archlinux.org:staging/community/)
    • 標識此軟件包 (archrelease community-x86_64)
  • 更新軟件倉庫(ssh repos.archlinux.org /community/db-update)

另外請閱讀 Packager Guide 頁面的 Miscellaneours 部分和 SSH keys#ssh-agent

停止維護軟件包[編輯 | 編輯原始碼]

如果一個 TU 不想再維護一個軟件包了,他應該在 AUR 郵件列表中發出一個通知,以便其他的 TU 可以繼續維護該軟件包。一個軟件包即是在沒有其他 TU 維護的情況下仍然能夠被一個 TU 停止維護。但是 TU 應該儘量不要放棄放棄很多軟件包(他們不應該負責超過他們時間允許的工作)。如果一個軟件包已經過時或者不再被使用,那麼也應該被完全移除。

如果一個軟件包已經被完全移除,它也可以重新上傳到 UNSUPPORTED,使得普通用户可以替 TU 維護它。

將軟件包從 unsupported 移到 [community][編輯 | 編輯原始碼]

按照普通的向 community 倉庫添加軟件包的步驟即可,但是記得將相應的軟件包從 unsupported 中移除。

將軟件包從 [community] 移至 unsupported[編輯 | 編輯原始碼]

按照上面提到的方法移除軟件包,並將你的原始碼上傳到 AUR 即可。

將軟件包從 [community-testing] 移至 [community][編輯 | 編輯原始碼]

 $ ssh repos.archlinux.org /community/db-move community-testing community package

從 unsupported 刪除軟件包[編輯 | 編輯原始碼]

沒必要移除虛設的軟件包,因為他們會在試圖跟蹤依賴關係時被重新創建。如果有人上傳了一個實際的軟件包,那麼所有依賴的軟件包都會指向正確的位置。

在 build.archlinux.org 上遠程編譯[編輯 | 編輯原始碼]

警吿: The following procedures defeats the Web Of Trust model: a user with root access to PKGBUILD.com could alter the package and/or the signature before it gets published.

TU 和開發者可以 SSH 到 build.archlinux.org,並使用 devtools 編譯軟件包。和本地編譯相比,這樣做有如下好處:

  • 編譯快,網絡快
  • 環境僅需要建立一次.
  • 本地系統可以不是 Arch Linux.

The process is similar to that of a local setup with devtools. Your GnuPG private is required for signing but you do not want to upload it for obvious security reasons. As such, you will need to forward the GnuPG agent socket from your local machine to the server: this will allow you to sign packages on the build server without communicating your key. This also means that we need to disable the agent on the server before we can run anything.

First, connect to build.archlinux.org and disable

$ ssh build.archlinux.org
$ systemctl --user mask gpg-agent.service

Make sure gpg-agent is not running (systemctl --user stop gpg-agent.service). At this point, make sure that no sockets exist in the folder pointed by gpgconf --list-dir socketdir. If they do, remove them or log out and in again. If you have a custom $GNUPGHOME (eg. to move it to ~/.config/gnupg), you will need to unset that, as it is not possible in gnupg to set the homedir without setting the socketdir. On build.archlinux.org, StreamLocalBindUnlink yes is set in sshd_config, therefore removing the sockets manually on logout is not necessary.

While the PGP private keys remain on your local machine, the public keys must be on the build server. Export your public ring to the build server, e.g. from you local machine

$ scp ~/.gnupg/pubring.gpg build.archlinux.org:~/.gnupg/pubring.gpg

SSH is required to checkout and commit to the SVN repository. You can either set up a new SSH key pair on the server (it is highly discouraged to put your local private key on a server for security reasons) or reuse your local keys via socket forwarding. If you opt for the latter, make sure to disable ssh-agent on the build server if you had enabled it previously (it is not running by default).

Configure you build environment on the build server:

~/.makepkg.conf
PACKAGER="John Doe <john@doe.example>"
## Optional
PKGDEST="/home/johndoe/packages"
SRCDEST="/home/johndoe/sources"
SRCPKGDEST="/home/johndoe/srcpackages"
LOGDEST="/home/johndoe/logs"
## If your PGP key is not the default, specify the right fingerprint:
GPGKEY="ABCD1234..."
警吿: Forwarding your gpg-agent socket to a remote machine makes it possible for anyone with root access to that system to use your unlocked GPG credentials. To circumvent this issue, we need to disable passphrase caching.

Disable passphrase caching with the following settings:

gpg-agent.conf
default-cache-ttl 0
max-cache-ttl 0

Because we will want to keep our usual GPG agent running with its current settings, we are going to run another GPG agent dedicated to the task at hand. Create a ~/.gnupg-archlinux folder and symlink everything from ~/.gnupg there, except ~/.gnupg/gpg-agent.conf. Configure the new GPG agent:

~/.gnupg-archlinux
extra-socket /home/doe/.gnupg-archlinux/S.gpg-agent.extra
default-cache-ttl 0
max-cache-ttl 0
pinentry-program /usr/bin/pinentry-gtk-2

The gpg-agent-extra.socket will be forwarded to build.archlinux.org.

Start the dedicated agent with

$ gpg-agent --homedir ~/.gnupg-archlinux --daemon

Connect with:

$ ssh -R $REMOTE_SSH_AUTH_SOCK:$SSH_AUTH_SOCK -R /run/user/$REMOTE_UID/gnupg/S.gpg-agent:/home/doe/.gnupg-archlinux/S.gpg-agent.extra build.archlinux.org

or, if using GnuPG as your SSH agent:

$ ssh -R /run/user/$REMOTE_UID/gnupg/S.gpg-agent.ssh:/run/user/$LOCAL_UID/gnupg/S.gpg-agent.ssh -R /run/user/$REMOTE_UID/gnupg/S.gpg-agent:/home/doe/.gnupg-archlinux/S.gpg-agent.extra build.archlinux.org

Replace $REMOTE_UID and $LOCAL_UID by your user identifier as returned by id -u on the build server and locally, respectively. If using ssh-agent, replace $REMOTE_SSH_AUTH_SOCK by the path to the SSH socket on the remote host (it can be anything).

You can make the forwarding permanent for that host. For instance with gpg-agent.ssh:

~/.ssh/config
Host build.archlinux.org
  RemoteForward /run/user/$REMOTE_UID/gnupg/S.gpg-agent /run/user/$LOCAL_UID/gnupg/S.gpg-agent.extra
  RemoteForward /run/user/$REMOTE_UID/gnupg/S.gpg-agent.ssh /run/user/$LOCAL_UID/gnupg/S.gpg-agent.ssh

Again, replace $REMOTE_UID and $LOCAL_UID with their respective values.

From then on, the procedure should be exactly the same as a local build:

$ ssh build.archlinux.org
$ svn checkout -N svn+ssh://svn-community@repos.archlinux.org/srv/repos/svn-community/svn svn-community
$ ...
注意: pinentry-curses might not work with socket forwarding. If it fails for you, try using a different pinentry.

TU 辭職需要完成的事項[編輯 | 編輯原始碼]

當一個 TU 辭去自己的職務,而且不再是一個開發者時,需要執行如下操作:

  1. 此 TU 的所有軟件包需要被重新簽名(重新打包). TU 編譯的軟件包可以通過下面 URL 從 Archweb 查詢 https://archlinux.org/packages/?sort=&q=&packager=$packager&flagged= where packager 替換成 TU 在 Archweb 的用户名.
  2. Archweb 需要禁用此 TU 帳號,並添加到 'Retired Trusted users' 組. 從 'Trusted Users' 移除此 TU,軟件倉庫權限收回。
  3. 從伺服器上禁用此帳號的 shell 訪問權限(尤其是 repos.archlinux.org, pkgbuild.com)
  4. 移除此用户的 GPG key,倉庫中提交新的 archlinux-keyring 軟件包。在 keyring 項目中創建任務,刪除辭職人員的密鑰。
  5. 從 AUR 帳號中刪除此 TU 帳號.
  6. Arch wiki bureaucrat 將他們的帳號移出 ⧼group-archtu⧽ 組。
  7. BBS 管理員修改論壇的帳號。