Difference between revisions of "AUR Trusted User Guidelines"

From ArchWiki
Jump to: navigation, search
(TODO list for new Trusted Users)
m (improve links)
 
(34 intermediate revisions by 19 users not shown)
Line 1: Line 1:
 
[[Category:Package development]]
 
[[Category:Package development]]
 
[[es:AUR Trusted User Guidelines]]
 
[[es:AUR Trusted User Guidelines]]
 +
[[ja:AUR Trusted User ガイドライン]]
 
[[pt:AUR Trusted User Guidelines]]
 
[[pt:AUR Trusted User Guidelines]]
 
[[zh-CN:AUR Trusted User Guidelines]]
 
[[zh-CN:AUR Trusted User Guidelines]]
{{Article summary start}}
+
{{Related articles start}}
{{Article summary text|Explains guidelines for the Arch User Repository's Trusted Users.}}
+
{{Related|Arch User Repository}}
{{Article summary heading|Related}}
+
{{Related articles end}}
{{Article summary wiki|Arch User Repository}}
+
'''Trusted Users (TU)''' are members of the community charged with keeping the AUR in working order. They maintain popular packages ([https://mailman.archlinux.org/pipermail/aur-general/2010-September/010649.html 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.
{{Article summary end}}
+
 
+
The '''Trusted User (TU)''' is a member of the community charged with keeping the AUR in working order. He/she maintains popular packages ([https://mailman.archlinux.org/pipermail/aur-general/2010-September/010649.html communicating with and sending patches upstream as needed]), 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 [https://aur.archlinux.org/trusted-user/TUbylaws.html TU bylaws]
 
The TUs are governed using the [https://aur.archlinux.org/trusted-user/TUbylaws.html TU bylaws]
Line 16: Line 14:
 
# Read this entire wiki article.
 
# Read this entire wiki article.
 
# Read the [https://aur.archlinux.org/trusted-user/TUbylaws.html TU Bylaws].
 
# Read the [https://aur.archlinux.org/trusted-user/TUbylaws.html TU Bylaws].
# Make sure your account details on the [[Arch User Repository|AUR]] are up-to-date and that your sponsor has given you TU status.
+
# Make sure your account details on the [[AUR]] are up-to-date.
 
# Add yourself to the [[Trusted Users]] page.
 
# Add yourself to the [[Trusted Users]] page.
# Remind Allan/Andrea to change your account on forums.
+
# Subscribe to the public mailing list for Arch Linux development, [https://lists.archlinux.org/listinfo/arch-dev-public arch-dev-public].
 +
# Remind a [https://bbs.archlinux.org/userlist.php?username=&show_group=1&sort_by=username&sort_dir=ASC&search=Submit BBS admin] to change your account on forums.
 
# Ask some TU for the #archlinux-tu@freenode key and hang out with us in the channel. You do not have to do this, but it would be neat since this is where most dark secrets are spilled and where many new ideas are conceived.
 
# Ask some TU for the #archlinux-tu@freenode key and hang out with us in the channel. You do not have to do this, but it would be neat since this is where most dark secrets are spilled and where many new ideas are conceived.
# If you are not upgraded to a Trusted User group on bug tracker in two days, report this as a bug to Andrea Scarpino (andrea@archlinux.org).
 
# Send Ionuț Bîru (ibiru@archlinux.org) all the information based on this [https://www.archlinux.org/trustedusers/ template] to have access on dev interface.
 
# Install the {{pkg|devtools}} package.
 
# Send an email to Florian Pritz with one SSH public key attached. If you do not have one, use {{ic|ssh-keygen}} to generate one. Check the [[Using SSH Keys]] wiki page for more information about SSH keys.
 
 
# Create a PGP key for [[package signing]].
 
# Create a PGP key for [[package signing]].
# Send a signed email to all [https://www.archlinux.org/master-keys/ Master Keys owners] including your PGP key and the relative full key fingerprint. Your key needs to be signed at least by three of five master key holders.
+
# Send Ionuț Bîru (ibiru@archlinux.org) or Florian Pritz (bluewind@xinu.at) with all the information based on this [https://www.archlinux.org/trustedusers/ template] to have access on dev interface (archweb).
# Make the directories {{ic|~/staging/community}} and {{ic|~/staging/community-testing}} (and {{ic|~/staging/multilib}} if you are interested in maintaining multilib packages) on nymeria.archlinux.org. This step is '''important''' as the devtools scripts use this directory to process incoming packages.
+
# Send a signed email to Florian:
# Subscribe to the arch-dev-public ML and ask Florian to whitelist you.
+
#* Attach one SSH public key. If you do not have one, use {{ic|ssh-keygen}} to generate one. Check the [[Using SSH Keys]] wiki page for more information about SSH keys.
 +
#* Ask him to whitelist you from arch-dev-public.
 +
#* Tell him if you want an @archlinux.org email.
 +
# Ask your sponsor:
 +
#* to give you TU status on the AUR.
 +
#* to open a new task in the "Keyring" project of the bug tracker following the instructions in [https://lists.archlinux.org/pipermail/arch-dev-public/2013-September/025456.html this message] in order to have your PGP key signed by three master key holders.
 +
# Install the {{pkg|devtools}} package.
 +
# [[Arch_User_Repository#Authentication|Configure your private ssh key]] for {{ic|orion.archlinux.org}} and {{ic|repos.archlinux.org}} hosts.
 +
# Ssh to yourname@orion.archlinux.org (once you have permissions). Make the directories {{ic|~/staging/community}} and {{ic|~/staging/community-testing}} (and {{ic|~/staging/multilib}} if you are interested in maintaining multilib packages). This step is '''important''' as the devtools scripts use this directory to process incoming packages.
 +
# If you are not upgraded to a Trusted User group on bug tracker in two days, report this as a bug to arch-dev-public.
 
# Start contributing!
 
# Start contributing!
  
Line 41: Line 45:
  
 
=== Rules for Packages Entering the [community] Repo ===
 
=== Rules for Packages Entering the [community] Repo ===
 +
 +
* 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 [https://mailman.archlinux.org/mailman/listinfo/aur-general aur-general], search [https://bugs.archlinux.org/index.php?project=0&do=index&switch=1 all projects in the bugtracker], [[wikipedia:Grep|grep]] the [http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.log.html Subversion log], and send a quick message to the private TU [[IRC channel]].
  
 
* Only "popular" packages may enter the repo, as defined by 1% usage from [https://www.archlinux.de/?page=PackageStatistics pkgstats] or 10 votes on the AUR.
 
* Only "popular" packages may enter the repo, as defined by 1% usage from [https://www.archlinux.de/?page=PackageStatistics pkgstats] or 10 votes on the AUR.
Line 54: Line 60:
  
 
* 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.
 
* 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 ===
 
=== Accessing and Updating the Repository ===
 
          
 
          
The [community] repository now uses '''devtools''' which is the same system used for uploading packages to [core] and [extra], except that it uses another server {{ic|nymeria.archlinux.org}} instead of {{ic|gerolde.archlinux.org}}. Thus most of the instructions in [[DeveloperWiki:HOWTO Be A Packager|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 [[Arch_Build_System#Set_the_PACKAGER_variable_in_.2Fetc.2Fmakepkg.conf|set the PACKAGER variable]]. This is done in {{ic|/usr/share/devtools/makepkg-{i686,x86_64}.conf}} since the regular configuration file does not get placed in a clean chroot.
+
The [community] repository now uses '''devtools''' which is the same system used for uploading packages to [core] and [extra], except that it uses another server {{ic|nymeria.archlinux.org}} instead of {{ic|gerolde.archlinux.org}}. Thus most of the instructions in [[DeveloperWiki:HOWTO Be A Packager|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 [[Arch_Build_System#Set the PACKAGER variable in /etc/makepkg.conf|set the PACKAGER variable]]. This is done in {{ic|/etc/makepkg.conf}} for system-wide configuration, or in {{ic|~/.makepkg.conf}} for user specific configuration.
  
 
Initially you should do a '''non-recursive checkout''' of the [community] repository:
 
Initially you should do a '''non-recursive checkout''' of the [community] repository:
  svn checkout -N svn+ssh://svn-community@nymeria.archlinux.org/srv/repos/svn-community/svn
+
  <nowiki>svn checkout -N svn+ssh://svn-community@repos.archlinux.org/srv/repos/svn-community/svn svn-community</nowiki>
  
This creates a directory named "svn" which contains nothing. It does, however, know that it is an svn checkout.  
+
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 [[DeveloperWiki:HOWTO Be A Packager|Packager Guide]].
 
For '''checking''' out, '''updating''' all packages or '''adding''' a package see the [[DeveloperWiki:HOWTO Be A Packager|Packager Guide]].
  
 
To '''remove''' a package:
 
To '''remove''' a package:
  ssh nymeria.archlinux.org /community/db-remove community arch pkgname
+
  ssh nymeria.archlinux.org /community/db-repo-remove community arch pkgname
 +
 
 +
Here and in the following text, ''arch'' can be one of ''i686'' or ''x86_64'' which are the two architectures supported by Arch Linux.
 +
 
 +
{{Expansion|What about the "any" architecture?}}
 +
 
 +
When you are done with editing the PKGBUILD, etc., you should '''commit''' the changes ({{ic|svn commit}}).
  
Here and in the following text, arch can be one of i686 or x86_64 which are the two architectures supported by Arch Linux. (What about "any"?)
+
Build the package with {{ic|mkarchroot}} or the helper scripts {{ic|extra-i686-build}} and {{ic|extra-x86_64-build}}.
  
When you are done with editing the PKGBUILD, etc, you should '''commit''' the changes ({{ic|svn commit}}).
+
Sign the package with {{ic|gpg --detach-sign *.pkg.tar.xz}}. If you are using a different PGP key for package signing you can add it to {{ic|~/.makepkg.conf}} with {{ic|1=GPGKEY=<identifier>}}.
  
When you want to '''release''' a package, first copy the package to the ''staging/community'' directory on nymeria.archlinux.org using scp and then '''tag''' the package by going to the ''pkgname/trunk'' directory and issuing {{ic|archrelease community-arch}}. This makes an svn copy of the trunk entries in a directory named ''community-i686'' or ''community-x86_64'' indicating that this package is in the community repository for that architecture.
+
When you want to '''release''' a package, first copy the package along with its signatures  to the ''staging/community'' directory on ''nymeria.archlinux.org'' using {{ic|scp}} and then '''tag''' the package by going to the ''pkgname/trunk'' directory and issuing {{ic|archrelease community-arch}}. This makes an svn copy of the trunk entries in a directory named ''community-i686'' or ''community-x86_64'' indicating that this package is in the community repository for that architecture.
  
 
'''''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.''
 
'''''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.''
  
Thus the '''process''' of updating a package can be summarised as:
+
'''Package update summary:'''
  
* '''Update''' the package directory ({{ic|svn update some-package}})
+
* '''Update''' the package directory: {{ic|svn update some-package}}.
* '''Change''' to the package trunk directory ({{ic|cd some-package/trunk}})
+
* '''Change''' to the package trunk directory: {{ic|cd some-package/trunk}}.
* '''Edit''' the PKGBUILD, make necessary changes and {{ic|makepkg}}. It is recommended to build in a [[DeveloperWiki:Building in a Clean Chroot|clean chroot]].
+
* '''Edit''' the PKGBUILD, make necessary changes
* '''[[Namcap]]''' the PKGBUILD and the binary pkg.tar.gz.
+
* '''Build''' the package: either {{ic|makechrootpkg}} or {{ic|extra-i686-build}} and {{ic|extra-x86_64-build}}. It is '''mandatory''' to build in a [[DeveloperWiki:Building in a Clean Chroot|clean chroot]].
* '''Commit''', '''Copy''' and '''Tag''' the package using {{ic|communitypkg "commit message"}}. This automates the following:
+
* '''[[Namcap]]''' the PKGBUILD and the binary {{ic|pkg.tar.gz}}.
** '''Commit''' the changes to trunk ({{ic|svn commit}})
+
* '''Commit''', '''Sign''', '''Copy''' and '''Tag''' the package using {{ic|communitypkg "commit message"}}. This automates the following:
** '''Copy''' the package to nymeria.archlinux.org ({{ic|scp pkgname-ver-rel-arch.pkg.tar.xz* nymeria.archlinux.org:staging/community/}})
+
** '''Commit''' the changes to trunk: {{ic|svn commit}}.
** '''Tag''' the package ({{ic|archrelease community-{i686,x86_64}}})
+
** '''Sign''' the package: {{ic|gpg --detach-sign *.pkg.tar.xz}}.
* '''Update''' the repository ({{ic|ssh nymeria.archlinux.org /community/db-update}})
+
** '''Copy''' the package and its signature to ''nymeria.archlinux.org'': {{ic|scp *.pkg.tar.xz *.pkg.tar.xz.sig nymeria.archlinux.org:staging/community/}}.
 +
** '''Tag''' the package: {{ic|archrelease community-{i686,x86_64}}}.
 +
* '''Update''' the repository: {{ic|ssh nymeria.archlinux.org /community/db-update}}.
  
Also see the ''Miscellaneous'' section in the [[DeveloperWiki:HOWTO Be A Packager|Packager Guide]]. For the section ''Avoid having to enter your password all the time'' use nymeria.archlinux.org instead of gerolde.archlinux.org.
+
Also see the ''Miscellaneous'' section in the [[DeveloperWiki:HOWTO Be A Packager|Packager Guide]]. For the section ''Avoid having to enter your password all the time'' use ''nymeria.archlinux.org'' instead of ''gerolde.archlinux.org''.
  
 
=== Disowning packages ===
 
=== Disowning packages ===
Line 103: Line 119:
 
=== Moving packages from [community] to unsupported ===
 
=== Moving packages from [community] to unsupported ===
  
Remove the package using the instructions above and upload your source tarball to the AUR.
+
Remove the package using the instructions above and upload your source to the AUR.
  
 
=== Moving packages from [community-testing] to [community] ===
 
=== Moving packages from [community-testing] to [community] ===
Line 113: Line 129:
  
 
=== See also ===
 
=== See also ===
* [[DeveloperWiki#Packaging_Guidelines]]
+
* [[DeveloperWiki#Packaging Guidelines]]

Latest revision as of 04:13, 18 September 2016

Related articles

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

  1. Read this entire wiki article.
  2. Read the TU Bylaws.
  3. Make sure your account details on the AUR are up-to-date.
  4. Add yourself to the Trusted Users page.
  5. Subscribe to the public mailing list for Arch Linux development, arch-dev-public.
  6. Remind a BBS admin to change your account on forums.
  7. Ask some TU for the #archlinux-tu@freenode key and hang out with us in the channel. You do not have to do this, but it would be neat since this is where most dark secrets are spilled and where many new ideas are conceived.
  8. Create a PGP key for package signing.
  9. Send Ionuț Bîru (ibiru@archlinux.org) or Florian Pritz (bluewind@xinu.at) with all the information based on this template to have access on dev interface (archweb).
  10. Send a signed email to Florian:
    • Attach one SSH public key. If you do not have one, use ssh-keygen to generate one. Check the Using SSH Keys wiki page for more information about SSH keys.
    • Ask him to whitelist you from arch-dev-public.
    • Tell him if you want an @archlinux.org email.
  11. Ask your sponsor:
    • to give you TU status on the AUR.
    • to open a new task in the "Keyring" project of the bug tracker following the instructions in this message in order to have your PGP key signed by three master key holders.
  12. Install the devtools package.
  13. Configure your private ssh key for orion.archlinux.org and repos.archlinux.org hosts.
  14. Ssh to yourname@orion.archlinux.org (once you have permissions). Make the directories ~/staging/community and ~/staging/community-testing (and ~/staging/multilib if you are interested in maintaining multilib packages). This step is important as the devtools scripts use this directory to process incoming packages.
  15. If you are not upgraded to a Trusted User group on bug tracker in two days, report this as a bug to arch-dev-public.
  16. 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

  • 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.
  • 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
    • drivers
    • 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], except that it uses another server nymeria.archlinux.org instead of gerolde.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. This is done in /etc/makepkg.conf for system-wide configuration, or in ~/.makepkg.conf for user specific configuration.

Initially you should do a non-recursive checkout of the [community] repository:

svn checkout -N svn+ssh://svn-community@repos.archlinux.org/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 nymeria.archlinux.org /community/db-repo-remove community arch pkgname

Here and in the following text, arch can be one of i686 or x86_64 which are the two architectures supported by Arch Linux.

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: What about the "any" architecture? (Discuss in Talk:AUR Trusted User Guidelines#)

When you are done with editing the PKGBUILD, etc., you should commit the changes (svn commit).

Build the package with mkarchroot or the helper scripts extra-i686-build and extra-x86_64-build.

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 ~/.makepkg.conf with GPGKEY=<identifier>.

When you want to release a package, first copy the package along with its signatures to the staging/community directory on nymeria.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-i686 or community-x86_64 indicating that this package is in the community repository for that architecture.

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.

Package update summary:

  • Update the package directory: svn update some-package.
  • Change to the package trunk directory: cd some-package/trunk.
  • Edit the PKGBUILD, make necessary changes
  • Build the package: either makechrootpkg or extra-i686-build and extra-x86_64-build. It is mandatory to build in a clean chroot.
  • Namcap the PKGBUILD and the binary pkg.tar.gz.
  • Commit, Sign, Copy and Tag the package using communitypkg "commit message". This automates the following:
    • Commit the changes to trunk: svn commit.
    • Sign the package: gpg --detach-sign *.pkg.tar.xz.
    • Copy the package and its signature to nymeria.archlinux.org: scp *.pkg.tar.xz *.pkg.tar.xz.sig nymeria.archlinux.org:staging/community/.
    • Tag the package: archrelease community-{i686,x86_64}.
  • Update the repository: ssh nymeria.archlinux.org /community/db-update.

Also see the Miscellaneous section in the Packager Guide. For the section Avoid having to enter your password all the time use nymeria.archlinux.org instead of gerolde.archlinux.org.

Disowning packages

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 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 nymeria.archlinux.org /srv/repos/svn-community/dbscripts/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.

See also