Contributing

Community Involvement
One of the simplest ways to contribute back to Arch Linux ARM is to participate in the many discussions that happen daily or to create a new one. Many questions ranging from basic to difficult are asked on our forums and our IRC channel, and helping others will not only solve problems but increases your own knowledge base.

Report Issues
With the amount of software we build for this distribution, it's not possible for us to test all of it for every use case. If you find a problem with a program or package in our repositories, the best way to let us know is to file an issue on our GitHub issue tracker. Be sure to reference the package in question, along with the platform you're using. Since we support multiple architectures it's important to know where to start, and the more information we have to work with the faster it can be resolved.

Keep in mind that many of the packages in the repository do not come ready to use, and there is almost always some initial configuration that must take place beforehand. If you're not sure that it's an actual problem, ask about it in the forum or on IRC.

Requesting Changes to our PKGBUILDs or Submitting New PKGBUILDs
You have several options for submitting changes to code using Github. You can either file a bug report in the GitHub issue tracker or comment on either a PKGBUILD file or on lines in a file. You can also create a pull request.

Before submitting a pull request for a package, be sure you've read and understand the README on how our git repository is laid out along with any special flags you may need to define in the PKGBUILD to be processed correctly by our build system. Requests will not be merged if they do not meet the guidelines. These guidelines are also summarized below.

If you want to help the team with making new packages, or get involved with current development, hop into IRC!

Arch Linux ARM uses the upstream Arch Linux packages and AUR for nearly all of its packages. However, some packages require tweaks to build and run properly on ARM devices. The PKGBUILDs for those packages are modified from the upstream source and placed into our git repository on GitHub. They are kept up to date daily with the rest of the packages, and may move in or out of git depending on (in)compatible changes from the upstream release.

Viewing the Git Repository
To view our Github page in a web browser, visit https://github.com/archlinuxarm/PKGBUILDs.

Clone the Repository
To clone the repository, having installed git ("pacman -Syu git" on Arch Linux ARM), you can run the following command. The files will be placed into a folder named "PKGBUILDs".
git clone git://github.com/archlinuxarm/PKGBUILDs.git

Repository Layout
The folder structure in git mirrors the repos you find within Arch Linux ARM:

  • core, extra, community: Packages in these folders (unless for good reason) are the packages found in the upstream repos by the same names. These represent packages that needed to be changed from the upstream version, not the only ones we build.
  • aur: These are packages we have selected from the AUR to have pre-built and available for our users. Because building on ARM is not as easy as x86, we have done the legwork to provide compiled versions of popular or highly requested packages.
  • alarm: Packages created by Arch Linux ARM are placed in this folder, and are not packages that are found in either upstream Arch Linux or in the AUR.

New packages should be placed in the correct locations, with the package's base folder name reflecting the 'pkgname' for single-package PKGBUILDs, or 'pkgbase' for multiple-package PKGBUILDs. In the case of non-alarm packages, naming should
exactly match the base folder or package name as used upstream or in the AUR, respectively. This will ensure correct package->version matching in the build system update routines.

For packages created from a modified upstream source, a header near the top of the PKGBUILD is required. The first line should indicate the name and email for each contributor to the changes, followed by short descriptions of what was changed. This allows us to be able to get in contact with the original contributor if needed, and also allows us to maintain the changes in the future when the package is upgraded upstream.

We have defined additional variables to be used inside a package's PKGBUILD for special circumstances, and are for the benefit of our build system only; they are not used by makepkg. These should be defined at the top of the PKGBUILD below the comment header and separate from the other variables so that they are easily spotted for future modification.

  • noautobuild: If defined and non-zero, the package will be marked as done by the build system and will not be built. This flag should only be used in certain circumstances and is not applicable in most cases.
  • buildarch: This variable is the decimal representation of a binary bitmask representing the architectures the package should be built for. If left unspecified the default value is 1, which means that the package will build for all architectures. Other currently implemented values are:
    • 0000 0010 (2) - build only for armv5
    • 0000 0100 (4) - build only for armv7h
    • 0001 0000 (16) - build only for armv6h

This is just a brief synopsis, so please be sure to read the full README before making changes, and read the new issue guidelines before submitting a new issue.