# Arch Linux ARM PKGBUILDs: the recipes that build on ARM > The Arch Linux ARM PKGBUILDs repository holds package recipes that have been changed from their upstream Arch or AUR form so they compile on ARM hardware, organised into core, extra, aur and alarm. It also defines build variables that exist only inside the ALARM build system. **archlinuxarm/PKGBUILDs** — PKGBUILDs modified to build on Arch Linux ARM - Repository: https://github.com/archlinuxarm/PKGBUILDs - Website: https://archlinuxarm.org - Stars: 1,045 · Forks: 652 - Language: Shell - License: not declared - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/archlinuxarm-pkgbuilds ## What this repository holds and what it refuses The repository hosts PKGBUILDs that have been modified from the upstream Arch Linux release so that they build on the architectures supported by Arch Linux ARM. The README states the exclusion rule in the same breath: unmodified upstream packages do not belong here. That is the whole editorial policy of the project, and it has a practical consequence for anyone browsing it. A directory of a hundred recipes here means a hundred recipes that needed an ARM adjustment, and the absence of a package says nothing about whether it is available for ARM, only that nobody had to change it. The intended builders are people running Arch Linux ARM, and the second audience is the packagers who maintain those recipes, since the same tree is the submission point for anyone who wants an ARM port to become part of the distribution. ## The four directories and the naming rule behind them New recipes go into one of four locations, and the tree holds core/, extra/, aur/ and alarm/: ```text core/ extra/ aur/ alarm/ ``` The core and extra folders take packages that exist upstream under the same name, with exceptions for things the project considers in scope for those repositories, such as their own kernels. The aur folder holds a selection of AUR packages that the community asked for often enough to be worth pre-compiling, and the README is careful to add that the AUR remains usable exactly as it is on Arch, with cower and packer included for that purpose. The alarm folder is for packages the project created or that were submitted to it to make ARM systems work, including packages changed so far from upstream or the AUR that they no longer belong in the other two. On top of that sits a naming rule: the folder name has to be the pkgname for a single package recipe or the pkgbase for a multi-package one, and for anything not native to ALARM the name has to match upstream or the AUR exactly, because the build system relies on that to match a package to its version during update runs. ## The changelog inside a PKGBUILD is a maintenance contract The README sets one requirement for modified recipes, and it is the requirement that makes this repository maintainable. A PKGBUILD that came from upstream, from the AUR, or was written for the ALARM repository has to carry the author's name and email in the header, together with a changelog of the modifications that were needed to make the package build correctly. The stated purpose is to let the project identify those changes and merge them into a newer version of the package later. That is a real mechanism rather than a formality. Without a recorded diff, an update to a new upstream release means redoing the ARM work from scratch, and the person doing it has no way to know which of a dozen edits were still needed. The changelog is the difference between an upstream bump and a port from scratch. ## The three build variables that only ALARM understands The README documents a set of PKGBUILD variables that are not part of the official PKGBUILD specification and exist only to steer the Arch Linux ARM build system. There are three. noautobuild, if set to a non-zero value, makes the build system mark the package as done and not build it for any architecture, and the README is explicit that this is not for regular use and depends on access to a non-public interface for getting built packages into the repositories. highmem, also non-zero, marks the package as requiring a builder with more than 2GB of RAM to build successfully. buildarch is the interesting one, and it is described separately because it takes a numeric bitmask rather than a flag. Any of these variables is a no-op on vanilla Arch, so a recipe copied out of this tree carries instructions that only one build system will honour. ## Reading the buildarch bitmask The buildarch value is a bitmask of the architectures to build the package for, written as the decimal equivalent of the mask, and the values can be combined with a bitwise OR to select more than one. The README lists three cases, and the default is the important detail. A mask of 0000 0001, which is 1, is the default and means the package is built for all architectures. A mask of 0000 0100, which is 4, means the package is built only for armv7h. A mask of 0000 1000, which is 8, means it is built only for armv8, the 64 bit target. Leaving the variable out means the package builds everywhere, which is the right default for a recipe that is portable, and the reason to set it is a recipe that only compiles for one target, where building the other would fail on the architecture it was never meant for. ## What building one of these recipes involves The README is a contribution guide rather than a user guide, so the practical sequence has to be read out of the structure. The recipes are meant to be built on an Arch Linux ARM system rather than on a desktop x86 machine, and each recipe lives in its own directory under one of the four top level folders, named to match the package. The build system then uses the buildarch and highmem values to route the recipe to a builder with the right architecture and enough memory, and marks it done according to noautobuild when it must not be built at all. For the AUR packages specifically, the repository ships cower and packer so that a user can compile and install straight from the AUR in the usual way, which is the faster route when the AUR version already builds on ARM. ## Where the repository stops and the distribution takes over Two things are outside this repository, and both matter when you adopt it. The first is the licence. The tree holds a .gitignore, a CONTRIBUTING.md, the README and the four package folders, and no licence file, so the terms for copying and reusing these recipes are not stated in the project itself, and that is a question to settle with the maintainers rather than to assume from the Arch ecosystem. The second is the binary side. These PKGBUILDs are the source of the pre-compiled packages, and the artefacts themselves are produced by the ALARM build system and published through the project's own repositories, which is why the noautobuild variable talks about a non-public interface for getting packages into the repos. The last push was on 2026-10-19, so the recipe tree is maintained actively even though the repository publishes no tagged releases of its own. ## Arch Linux ARM packaging next to the plain AUR The alternative is the AUR itself, and the README names it as a first-class option: the AUR works on ARM exactly as it does on Arch, and the cower and packer helpers in this repository exist so that a user can compile and install from the AUR directly. The difference in approach is where the ARM work sits. An AUR PKGBUILD is the upstream recipe, patched by whoever submitted it, and you build it on your own board, so you can see exactly what was changed and carry that patch forward yourself. A recipe from this repository is one that the project has already made work, with the maintainer header and the changelog of changes recorded, and it is what the build system consumes to produce the pre-compiled packages. If you want the compiled artefact with a maintained ARM port, this tree is the better route. If you want to audit and maintain the patch yourself, the AUR with the included helpers is the shorter path. ## Conclusion The Arch Linux ARM PKGBUILDs repository fits a maintainer of an ARM board who wants package recipes that are already known to build on armv7h and armv8, and it fits a packager who intends to contribute ARM fixes upstream. It does not fit someone who wants a plain upstream recipe, since an unmodified copy does not belong here, and the custom build variables mean a recipe from this tree behaves differently outside the ALARM build system. Before using one of these recipes, check the header of the PKGBUILD for the maintainer name and the changelog of what was changed, and read the buildarch value, because a recipe built for one architecture will not simply work on the other. ## FAQ ### What belongs in the Arch Linux ARM PKGBUILDs repository? Only packages whose recipes have been modified from the upstream Arch release or the AUR so that they build on ARM. The README states that unmodified upstream packages do not belong in the repository. ### What is the difference between the core, extra, aur and alarm folders? Core and extra hold packages that exist upstream under the same name, with exceptions such as the project's own kernels. The aur folder holds frequently requested AUR packages, and the alarm folder holds packages created for ARM or changed far enough from upstream to belong elsewhere. ### How should a new package be named in the Arch Linux ARM PKGBUILDS tree? The folder name must be the pkgname for a single package recipe or the pkgbase for a multi-package one, and for packages that are not native to ALARM it has to match the upstream or AUR name exactly, because the build system matches packages to versions by that name during update runs. ### What does the buildarch variable do in an Arch Linux ARM PKGBUILD? It is a bitmask of the architectures to build for, written as a decimal value. A value of 1 is the default and builds for all architectures, 4 builds only for armv7h, and 8 builds only for armv8, and values can be combined. ### What is the highmem variable for? Setting it to a non-zero value marks the package as requiring a builder with more than 2GB of RAM for the build to succeed. ### What happens when noautobuild is set in a PKGBUILD? The build system marks the package as done and does not build it for any architecture. The README says this is not for regular use and that it needs access to a non-public interface for getting built packages into the repositories. ## Sources - [archlinuxarm/PKGBUILDs on GitHub](https://github.com/archlinuxarm/PKGBUILDs) - [Issues](https://github.com/archlinuxarm/PKGBUILDs/issues) - [Project website](https://archlinuxarm.org) - [README](https://github.com/archlinuxarm/PKGBUILDs/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/archlinuxarm-pkgbuilds