Difference between revisions of "AUR Trusted User Guidelines"
m (Protected "AUR Trusted User Guidelines" ([edit=sysop] (indefinite) [move=sysop] (indefinite)))
m (Changed protection level for "AUR Trusted User Guidelines" ([edit=autoconfirmed] (expires 08:53, 24 July 2009 (UTC)) [move=autoconfirmed] (expires 08:53, 24 July 2009 (UTC))))
Revision as of 08:53, 23 July 2009
Template:Article summary start Template:Article summary text Template:Article summary heading Template:I18n entry Template:I18n entry Template:I18n entry Template:Article summary heading Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary end
- 1 The Trusted User (TU)
- 1.1 TU Duties
- 1.1.1 TODO list for new Trusted Users
- 1.1.2 The TU and UNSUPPORTED
- 1.1.3 The TU and [community], Guidelines for Package Maintenance
- 220.127.116.11 Rules for Packages Entering the [community] Repo
- 18.104.22.168 Accessing the Repo
- 22.214.171.124 Uploading packages to x86_64-version of community
- 126.96.36.199 Adopting Packages
- 188.8.131.52 Disowning packages
- 184.108.40.206 Deleting packages from unsupported
- 220.127.116.11 Deleting packages from [community]
- 18.104.22.168 Moving packages from [community] to unsupported
- 1.1.4 AURtools
- 1.1 TU Duties
The Trusted User (TU)
The Trusted User (TU) is a member of the community charged with keeping the AUR in working order. He/she maintains popular packages, and votes 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
- Send your ssh public key to Loui Chang.
- Remind Allan to change your account on forums
- Make sure your sponsor has given you TU status on the AUR
- Ask some TU for the #archlinux-tu@freenode key
- Add yourself to the Trusted Users page
- Read the Trusted User Guidelines and AURtools Tutorial again
- If you are not upgraded to a Trusted User group on bugtracker in two days, report this as a bug to Roman
- Ask Aaron for access to the x86_64 build machine if you need it (when it comes back online)
- Start contributing!
The TU and UNSUPPORTED
The TUs should also make an effort to check package submissions in UNSUPPORTED 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 pkgs 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 distro.
TUs are also in an excellent position to document recommended practices.
The TU and [community], Guidelines for Package Maintenance
Rules for Packages Entering the [community] Repo
Any packages to be added to the [community] repo must meet the guidelines listed on this page.
Accessing the Repo
Follow these instructions for uploading/modifying packages once you have become a TU:
- Install the "aurtools" package. Make sure you read the AURtools Tutorial
- Email your ssh public key (~/.ssh/id_rsa.pub) to whoever is in charge of the AUR CVS repo (Aaron Griffin, Loui Chang).
- If you don't have an ssh key: ssh-keygen Check the Using SSH Keys wiki page for more information about creating ssh keys and setting up an ssh-agent to use them.
- Run the following commands to checkout the AUR CVS:
export CVS_RSH=ssh cvs -d :ext:<userid>@aur.archlinux.org:/srv/cvs/community co community
- To add a new package:
- Make a commit: cvs commit
- To upload a binary package: Please note that AUR password is to be used with tupkg (NOT the CVS password) tupkg --user <userid> --password <aur-password> <packagefile.pkg.tar.gz>
- After uploading a package and committing the build files, tag the files with this command: cvs tag -cFR CURRENT <newpackagebuilddir> Package changes become available on every full and half of hour. Verify everything was uploaded properly, then select the newly added or updated package in the web interface and set yourself as the maintainer.
cvs add <directory> cd <directory> cvs add PKGBUILD
Note: Steps 5-7 can be run with communitypkg in one command as mentioned below in the AURtools tutorial.
Note: In some cases, especially for community packages, an x86_64 TU might bump the pkgrel by .1 (and not +1). This indicates that the change to the PKGBUILD is x86_64 specific and i686 maintainers should not rebuild the package for i686. When the TU decides to bump the pkgrel , it should be done with the usual increment of +1. However, a previous pkgrel=2.1 must not become pkgrel=3.1 when bumped by the TU and must instead be pkgrel=3. In a nutshell, leave dot (.) releases exclusive to the x86_64 TU's to avoid confusion.
Uploading packages to x86_64-version of community
- step 1 till 5 are the same as mentioned above.
- when using tupkg add "--port 1035" to the list of parameters
- Tag the package with "cvs tag -cFR CURRENT-64"
A TU may adopt any package at any time, but because a TU's time is limited, he/she should try to only adopt popular packages. The voting mechanism in the AUR allows a TU to quickly gauge which packages users want.
A maintainer should adopt his/her selected package(s) via the web interface. That maintainer is then responsible for bug fixes and new version updates. Packages must be properly cleaned and fixed after adoption.
You can disown packages by choosing "Disown Packages" in the AUR webinterface. If a TU can't or doesn't 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 shouldn't take on more than they have time for). If a package has become obsolete or isn't 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.
Deleting packages from unsupported
There's 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.
For an example of a dummy package see: http://aur.archlinux.org/packages.php?ID=23600
Deleting packages from [community]
Removing a package from [community] is easy but not straightforward. After you've removed it from community, you could re-add it to unsupported (make sure to keep a copy!) and orphan it, for adoption by some other user in unsupported.
To remove a package, all you really need to do is remove the CURRENT (and possibly CURRENT-64) tag from the PKGBUILD. You do this by doing:
cvs tag -d CURRENT PKGBUILD cvs tag -d CURRENT-64 PKGBUILD
If you wish to remove the package materials from CVS for future revisions (because you don't want the old stuff lying around), you can do the following FROM THE PACKAGE'S DIRECTORY in your checked out version of the community repo (this is very important!):
cd /path/to/<packagedirname> cvs tag -dl CURRENT #or CURRENT-64 cvs rm -fl cvs commit
BE VERY CAREFUL with CVS delete commands! By untagging current on the whole repo you risk removing EVERYTHING in [community]. I've suggested commands that hope to minimize that possibility, but there's still danger where delete is involved. Especially note that the tag delete takes IMMEDIATELY before committing, so be very careful.
Also, due to weirdness of CVS, actually removing the package directory is impossible. It will still show up in a checked out version unless you set up a ~/.cvsrc file that will help prune empty directories. The following is helpful:
cvs -q diff -uN rdiff -u checkout -P update -dP
Any TU can remove any package in [community] so keep this in mind and be extra super careful with this ability, lest you accidentally wipe out someone else's package.
After untagging and deleting the files you have to upload straightforward the PKGBUILD to the AUR (don't worry about the AUR showing the package in [community])
Moving packages from [community] to unsupported
Upload your source tarball to the AUR and immediately untag and delete files from [community] CVS.
To help the Trusted Users with their duties, the AURtools were written based on the tupkg tool. If you are Trusted User, it is highly recommended that you use the AURtools. The AURtools Tutorial was written to help you to get used to them.