AUR Trusted User Guidelines (简体中文) - ArchWiki

Jump to content
翻译状态：本文是 AUR_Trusted_User_Guidelines 的翻译。上次翻译日期：2022-10-29。如果英文版本有所更改，则您可以帮助同步翻译。

相关文章

- AUR
- DeveloperWiki#Packaging Guidelines

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 将您加入 Arch Linux Trusted Users 组.
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.org` 和 `repos.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.

Warning: 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'

Note: 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 article or section needs expansion.

Reason: This list is incomplete for now and should be expanded. (Discuss in Talk:AUR Trusted User Guidelines (简体中文))

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` 更新校验和.
- 编译 软件包：使用 `makechrootpkg` 或 `extra-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 上远程编译

Warning: 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..."

Warning: 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
    $ ...

Note: 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 将他们的帐号移出 Arch Linux Trusted Users 组。
7. BBS 管理员 修改论坛的帐号。

Category:

- Package development (简体中文)

Hidden category:

- Pages or sections flagged with Template:Expansion