DeveloperWiki:HOWTO Be A Packager

From ArchWiki

Follow Package Guidelines

Package guidelines can be found in the Arch Linux documentation. Please follow them closely.

Arch packaging standards

Preparation and Setup

Installing the Packages

Make sure you have the packages devtools and namcap installed.

SSH Config

If you have multiple SSH keys in your SSH Agent, you will need to make sure that the correct key is being used to contact the Arch servers. Also, when your local username differs from the one being used on the Arch servers, you need to take care of that too.

Example ~/.ssh/config excerpt:

	port 22
	user foobar
	IdentityFile ~/.ssh/id_arch
	IdentitiesOnly yes

makepkg Config

Make sure to configure your ~/.makepkg.conf with the correct PACKAGER and GPGKEY variables. Wrong signatures or missing PACKAGER will prevent your packages from entering the repository.

PACKAGER="Foo Bar <>"

Local SVN Setup using Non-Recursive Checkouts

As SVN provides the ability to do scoped checkouts you can initialize an empty local checkout and later on only fetch the packages that you want. To setup the local checkouts run the following commands.

For core, extra, testing and staging repos:

  svn checkout -N svn+ssh:// svn-packages

For community, community-testing, community-staging, multilib, multilib-testing, multilib-staging:

  svn checkout -N svn+ssh:// svn-community

This creates two directories named svn-packages and svn-community which contain nothing but are properly setup as svn repositories.

Helper Scripts (optional)

The packaged helper scripts below can be installed from the archlinux-tools group.

  • arch-rebuild-order — List the rebuild order of packages using the local pacman syncdb's.
  • arch-signoff — Signoff packages from [testing] interactively in your terminal.
  • arch-repro-status — List the reproducible status of your packages interactively in your terminal with the ability to see the build logs and diffoscope output per unreproducible package.
  • archlinux-contrib — Collection of contrib scripts used in Arch Linux.


This shell script eases setting up and maintaining the chroots for building the packages immensely. The script has been developed by Bluewind and can be found here: ch.

As this script relies on Btrfs, you have to create a Btrfs volume (20GiB is mostly sufficient), which can either be a file, a logical volume or a dedicated partition. Furthermore by default this script assumes that the Btrfs for the chroots is mounted at /mnt/chroots/arch.

Afterwards you can create a 64bit package using:

  ch build 64

(automatically and conveniently invokes makechrootpkg with all required arguments)

For further details please take a look at the head of the script, it provides some explanations and usage examples.

The Workflow

Checkout/update your Local Repository

  cd svn-community
  # update a specific package
  svn update <package_name>
  # update all packages
  svn update

Adding a new Package

This step is only required when adding a new package to the repository for the first time.

  cd svn-community
  mkdir -p new-package/{repos,trunk}
  cd new-package
  cp /usr/share/pacman/PKGBUILD.proto trunk/PKGBUILD
  svn add .
  svn commit
Warning: dbscripts does not support packages with a different split package architecture.

Updating the needed Package

  svn update some-package

Change and build

It is mandatory to build your package using a clean chroot. To ensure this, build with the scripts provided by devtools (i.e. extra-x86_64-build for extra and community, multilib-build for multilib, multilib-staging-build for multilib-staging, multilib-testing-build for multilib-testing, staging-x86_64-build for staging and community-staging, testing-x86_64-build for testing and community-testing).

  cd some-package/trunk/

Or, if you are using the ch helper, simply do:

  cd some-package/trunk/
  ch clean 64
  ch update 64
  ch build 64

Run namcap on both PKGBUILD and Package

Note: This is automatically done, when using the devtools build scripts.
  namcap PKGBUILD
  namcap some-package-1.0-1-x86_64.pkg.tar.xz

Run checkpkg on the Package

Run in the directory with your freshly built package to get a file list diff compared with the package version currently in the repos.

Note: This can be skipped when adding a new package to the repository for the first time (e.g. by importing it from AUR to community).

Run sogrep on identified soname change

If checkpkg identified a shared object name (aka. soname) change in package's library, it is required to rebuild packages directly depending on it.

To identify which packages rely on a given library in package in a repository (e.g. extra or community), use sogrep (see sogrep(1)).

   sogrep <repository>

Build package for its respective staging environment (by following the remaining steps in The Workflow) and create a TODO with the identified dependants, so their maintainers can rebuild them against the new version of package.

Note: First sync with trusted users and/ or developers, if any packages currently in the staging environment block the rebuilds against package.

Use devtools to sign, upload and commit

Once you are satisfied with the package, you need to make sure all your changes are tracked in the repository. Run:

  svn status

in the some-package/trunk/ directory and check the output carefully. If, for example, you have added a new some-package.install file, you need to tell svn to track that file, e.g.:

  svn add some-package.install

Make sure to never add the binary packages, makepkg logs, etc. to the repository!

When you are ready to proceed, you can run the devtools scripts to sign, upload and commit your work (i.e. communitypkg for community, community-stagingpkg for community-staging, community-testingpkg for community-testing, extrapkg for extra, gnome-unstablepkg for gnome-unstable, kde-unstablepkg for kde-unstable, multilibpkg for multilib, multilib-stagingpkg for multilib-staging, multilib-testingpkg for multilib-testing, stagingpkg for staging, testingpkg for testing), e.g.:

  extrapkg "update to 1.2.3, add post_upgrade hook to fix permissions"

Please try to write concise commit messages. If the package is simply an upstream change, that is fine, but if anything more complex changes, please inform us by writing an appropriate commit message.

This will upload the package and its signature to their repository specific location in your user's ~/staging directory on

Update the Repository

Using db-update will find new packages for a set of repositories, depending on which is being called.

To release uploaded packages to core, extra, gnome-unstable, kde-unstable, staging, or testing use:

  ssh "/packages/db-update"

To release uploaded packages to community, community-staging, community-testing, multilib, multilib-staging, or multilib-testing use:

  ssh "/community/db-update"

Other Operations

Removing a Package

Using db-remove will remove a package from a specific binary repository.

To remove a package from core, extra, gnome-unstable, kde-unstable, staging, or testing use:

  ssh "/packages/db-remove <repo> <arch> <package_name>"


  ssh "/packages/db-remove core x86_64 openssh"

To remove a package from community, community-staging, community-testing, multilib, multilib-staging, or multilib-testing use:

  ssh "/community/db-remove <repo> <arch> <package_name>"


  ssh "/community/db-remove community x86_64 jack2"

If removing the package from the repositories altogether, it is encouraged to remove the entire package directory from version control as well.

   svn update <package_name>
   svn rm --force <package_name>
   svn commit <package_name> -m "Deleting <package_name> because of reason."

Sometime the previous command yields:

   svn: E155035: "'/path/to/pkg/<PKG>' is the root of a working copy and cannot be deleted"

You can remotely remove it with:

   svn rm svn+ssh://<PKG>

Moving a package between repos

Using db-move will move a package between two binary repositories.

To move packages of the same pkgbase between core, extra, gnome-unstable, kde-unstable, staging, or testing use:

  ssh "/packages/db-move <from_repo> <to_repo> [packages]"

e.g. to move packages of the pkgbases foo and bar from testing to core:

  ssh "/packages/db-move testing core foo bar"

To move packages of the same pkgbase between community, community-staging, community-testing, multilib, multilib-staging, or multilib-testing use:

  ssh "/community/db-move <from_repo> <to_repo> [packages]"

e.g. to move packages of the pkgbases foo and bar from community-testing to community:

  ssh "/community/db-move community-testing community foo bar"

Alternatively, the move from testing is so common, that there are helper scripts:

  /packages/testing2x openssh bzip2 coreutils
  /packages/testing2x64 openssh bzip2 coreutils

These scripts only work if the packages on the commandline are either in core or extra. If a package is only in testing, you have to use testing2core, testing2core64, testing2extra or testing2extra64.

For the special case of moving a binary package and its version controlled PKGBUILD (and potentially additional files) between community and extra (either direction), there are the two devtools helper scripts community2extra and extra2community.

E.g. to move a a package from community to extra, use:

   community2extra <package_name>

"Tagging" releases

Fetch the package dir using archco or communityco or from an svn checkout. Then:

  cd package-name/trunk
  archrelease extra-x86_64

This makes an svn copy of the trunk entries in a directory named extra-x86_64 indicating that this package is in the extra repository for the x86_64 architecture. This will be done automatically when using tools such as extrapkg (see Use devtools to sign, upload and commit).

Miscellaneous Stuff

Cleaning up your checkout

Since you are now maintaining a non-recursive checkout, you may want to get rid of packages that you are no longer tracking:

  svn update package1 package2 --set-depth exclude

Or if you want an empty toplevel again:

  svn update --set-depth empty

Avoid having to enter your password all the time

When working with extrapkg and the other devtools, quite a few ssh connections are established, even when using ssh keys and the ssh agent. You can work around that.

Add this to your ~/.ssh/config:

  ControlPath ~/.ssh/master-%h-%p-%r

Now, before you start working, open a ssh session with

  ssh -M

Enter your password and leave that session open until you are finished. All ssh sessions (including scp and svn+ssh) will now be tunneled through this connection.

Showing contributions on Github

Your packaging contributions in svn-community and svn-packages are contributed under $username@eb2447ed-0c53-47e4-bac8-5bc4a241df78 for svn-packages and $username@9fca08f4-af9d-4005-b8df-a31f2cc04f65 for svn-community where the username is the user on These contributions can be added to your Github profile by adding these addresses to your Github Email Settings, verification is not required for contributions to show up.


Pushing to the wrong repository

If you find yourself accidentally having pushed a package to the wrong repository (e.g. running communitypkg instead of extrapkg against example-1.0.0-any.pkg.tar.zst) you can undo it.

Note: This only applies to cases where the repository update has not been done yet. If the repository has been updated already, refer to moving a package between repos.

Remove the package from the staging location on the repos server:

 ssh "rm staging/community/example-1.0.0-any.pkg.tar.zst*"

Update your local svn directory and remove the wrong repos entry (assuming you are already in svn-packages/example/):

 svn update
 svn rm repos/community-any
 svn commit -m "Cleanup after accidental push to community."

Afterwards, proceed again with signing, uploading and committing.