AUR Trusted User Guidelines
Trusted Users (TU) are members of the community charged with keeping the AUR in working order. They maintain popular packages (communicating with and sending patches upstream as needed), and vote in administrative matters. A TU is elected from active community members by current TUs in a democratic process. TUs are the only members who have a final say in the direction of the AUR.
The TUs are governed using the TU bylaws
TODO list for new Trusted Users
- Read this entire wiki article.
- Read the TU Bylaws.
- Make sure your account details on the AUR are up-to-date.
- Ask one of your sponsors to give you TU status on the AUR.
- Add yourself to the Trusted Users page.
- Remind a bureaucrat to add your wiki account to the Arch Linux Trusted Users group.
- Remind a BBS admin to change your account on forums.
- Ask one of your sponsors for the #archlinux-staff and #archlinux-tu keys and join us in the channels (this is not mandatory, but a great way of getting to know parts of the team and collaborate).
- Ask one of your sponsors to create a ticket in the infrastructure repository issue tracker (using the
Onboardingtemplate) and provide them with the following information:
- An SSH public key. If you do not have one, follow SSH keys#Generating an SSH key pair to create one.
- A username which will be used for your SSO account and for your (to be created)
- Your full name.
- Your (personal) e-mail address and a valid PGP public key ID for it, which will be used to provide the initial password for the dev interface (archweb) to you and which will be linked to your (to be created) SSO account.
- Whether your private or your (to be created)
email@example.com address should be used for the non-public mailing lists and be allowed to post to the arch-dev-public mailing list.
- Set the password for your
@archlinux.orge-mail address by following DeveloperWiki:Staff Services#Email.
- Create a PGP key pair for package signing by following the workflow for adding a new packager key (using your new
<username>@archlinux.orgaddress as uid).
- Ask one of your sponsors to create a ticket in the archlinux-keyring repository issue tracker (using the
New Packager Keytemplate) in order to have your PGP key signed by (at least) three main key holders.
- Install the package.
- Configure your private ssh key for
- Ssh to firstname.lastname@example.org (once you have permissions).
- Start contributing!
The TU and the AUR
The TUs should also make an effort to check package submissions in the AUR for malicious code and good PKGBUILDing standards. In around 80% of cases the PKGBUILDs in the UNSUPPORTED are very simple and can be quickly checked for sanity and malicious code by the TU team.
TUs should also check PKGBUILDs for minor mistakes, suggest corrections and improvements. The TU should endeavor to confirm that all packages follow the Arch Packaging Guidelines/Standards and in doing so share their skills with other package builders in an effort to raise the standard of package building across the distribution.
TUs are also in an excellent position to document recommended practices.
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.
To force push the new history, forward the
AUR_OVERWRITE=1 environment variable to . See  for details.
- Modify committer or author identity
$ git-filter-repo --name-callback 'return name.replace(b"Old name", b"New name")' --email-callback 'return email.replace(b"email@example.com", b"firstname.lastname@example.org")'
git filter-branch --env-filter with the
GIT_COMMITTER_EMAIL environment variables. For example:
git filter-branch --env-filter ' if test "$GIT_AUTHOR_EMAIL" = "email@example.com"; then GIT_AUTHOR_EMAILfirstname.lastname@example.org fi if test "$GIT_AUTHOR_NAME" = "Antoine de Saint-Exupéry"; then GIT_AUTHOR_NAME=user fi'
git log --pretty=fullerto display the author and committer.
The TU and [community], guidelines for package maintenance
Rules for packages entering the [community] repository
- A package must not already exist in any of the Arch Linux repositories. You should take necessary precautions to ensure no other packager is in the process of promoting the same package. Double-check the AUR package comments, read the latest subject headings in aur-general, search all projects in the bugtracker, grep the Subversion log, and send a quick message to the private TU IRC channel.
- Pacman wrappers, as a special exception, will never be permitted. If wanting to otherwise add an AUR helper, write an email to
arch-dev-publicwith the proposed addition, and respect any objections provided by team members.
- Only "popular" packages may enter the repo, as defined by 1% usage from pkgstats or 10 votes on the AUR.
- Automatic exceptions to this rule are:
- i18n packages
- accessibility packages
- dependencies of packages who satisfy the definition of popular, including makedeps and optdeps
- packages that are part of a collection and are intended to be distributed together, provided a part of this collection satisfies the definition of popular
- Any additions not covered by the above criteria must first be proposed on the aur-general mailing list, explaining the reason for the exemption (e.g. renamed package, new package). The agreement of three other TUs is required for the package to be accepted into [community]. Proposed additions from TUs with large numbers of "non-popular" packages are more likely to be rejected.
- TUs are strongly encouraged to move packages they currently maintain from [community] if they have low usage. No enforcement will be made, although resigning TUs packages may be filtered before adoption can occur.
- It is good practice to always bump the pkgrel by 1 (in other words, set it to n + 1) when promoting a package from AUR. This is to facilitate automatic updates for those who already have the package installed, so that they may continue to receive updates from the official channel. Another positive effect of this is that users are not warned that their local copy is newer, as is the case if a packager does reset the pkgrel to 1.
Accessing and updating the repository
The [community] repository now uses devtools which is the same system used for uploading packages to [core] and [extra] to
repos.archlinux.org. Thus most of the instructions in Packager Guide work without any change. Information which is specific for the [community] repository (like changed URLs) have been put here. The devtools require packagers to set the PACKAGER variable in
Initially you should do a non-recursive checkout of the [community] repository:
$ svn checkout -N svn+ssh://email@example.com/srv/repos/svn-community/svn svn-community
This creates a directory named "svn-community" which contains nothing but a ".svn" folder.
For checking out, updating all packages or adding a package see the Packager Guide.
To remove a package:
$ ssh repos.archlinux.org /community/db-repo-remove community arch pkgname
Here and in the following text, arch should be x86_64 which is the only architecture supported by Arch Linux since i686 support has been deprecated.
When you are done with editing the PKGBUILD, etc., you should commit the changes (
Build the package with the helper script
extra-x86_64-build. If you want to upload to testing you need to build with the testing script
Sign the package with
gpg --detach-sign *.pkg.tar.xz. If you are using a different PGP key for package signing you can add it to
When you want to release a package, first copy the package along with its signatures to the staging/community directory on repos.archlinux.org using
scp and then tag the package by going to the pkgname/trunk directory and issuing
archrelease community-arch. This makes an svn copy of the trunk entries in a directory named community-x86_64 indicating that this package is in the community repository for that architecture. Note that the staging directory is different from the staging repository and every package needs to be uploaded to the staging directory. This process can be automated with the
communitypkg script, see the summary below.
Package update summary:
- Update the package directory:
svn update some-package.
- Change to the package trunk directory:
- Edit the PKGBUILD, make necessary changes, update hashes with
- Build the package:
extra-x86_64-build. It is mandatory to build in a clean chroot.
- Namcap the PKGBUILD and the binary
- Commit, Sign, Copy and Tag the package using
communitypkg "commit message". This automates the following:
- Commit the changes to trunk:
- Sign the package:
gpg --detach-sign *.pkg.tar.xz.
- Copy the package and its signature to repos.archlinux.org:
scp *.pkg.tar.xz *.pkg.tar.xz.sig repos.archlinux.org:staging/community/.
- Tag the package:
- Commit the changes to trunk:
- Update the repository:
ssh repos.archlinux.org /community/db-update.
If a TU cannot or does not want to maintain a package any longer, a notice should be posted to the AUR Mailing List, so another TU can maintain it. A package can still be disowned even if no other TU wants to maintain it, but the TUs should try not to drop many packages (they should not take on more than they have time for). If a package has become obsolete or is not used any longer, it can be removed completely as well.
If a package has been removed completely, it can be uploaded once again (fresh) to UNSUPPORTED, where a regular user can maintain the package instead of the TU.
Moving packages from unsupported to [community]
Follow the normal procedures for adding a package to community, but remember to delete the corresponding package from unsupported!
Moving packages from [community] to unsupported
Remove the package using the instructions above and upload your source to the AUR.
Moving packages from [community-testing] to [community]
$ ssh repos.archlinux.org /community/db-move community-testing community package
Deleting packages from unsupported
There is no point in removing dummy packages, because they will be re-created in an attempt to track dependencies. If someone uploads a real package then all dependents will point to the correct place.
Remote build on build.archlinux.org
Trusted users and developers can connect to build.archlinux.org via SSH to, among others, build packages using the devtools. This has numerous advantages over a local setup:
- Builds are fast and network speed is high.
- The environment needs setup only once.
- Your local system need not be 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:
PACKAGER="John Doe <firstname.lastname@example.org>" ## 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..."
Disable passphrase caching with the following settings:
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:
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
gpg-agent-extra.socket will be forwarded to build.archlinux.org.
Start the dedicated agent with
$ gpg-agent --homedir ~/.gnupg-archlinux --daemon
$ 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:
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://email@example.com/srv/repos/svn-community/svn svn-community $ ...
TODO list retiring a Trusted User
When a TU resigns the following list has be followed, these steps do not apply when a TU resigns but is still a Developer.
- All packages packaged by the retiree should be resigned (so rebuild). Packages packaged by the retiree can be found in Archweb https://archlinux.org/packages/?sort=&q=&packager=$packager&flagged= where packager is the username on Archweb.
- The account of the retiree should be disabled on Archweb and added to the 'Retired Trusted users' group. The retiree should be removed from the 'Trusted Users' and the repository permissions should be reduced to none.
- The shell access to our servers should be disabled. (notably repos.archlinux.org, pkgbuild.com)
- The GPG key should be removed and a new archlinux-keyring package should be pushed to the repos. Create bug reports in the keyring project to remove the keys of the retired Trusted Users.
- Remove the TU group from their AUR account.
- A bureaucrat should remove their wiki account from the Arch Linux Trusted Users group.
- A BBS admin should change their account on forums.