This repository contains a collection of custom PKGBUILD scripts for Arch Linux.
The repository includes all necessary configuration files to build the corresponding binary package repository with GitLab-CI. Nevertheless, the packages can also be build manually or using other CI-tools.
A PKGBUILD is a shell script providing all information required by the makepkg utility to build a binary package for Arch Linux and its package manager pacman.
More information on how to create packages can be found in the Arch Linux Wiki.
Important: The build scripts (.build-bin/*
, .build-lib/*
) are designed to be run in a dedicated container or virtual machine. Don't run these scripts on your main machine! You have been warned!
This repository already includes a pre-configured .gitlab-ci.yml configuration file for Gitlab-CI. It uses a docker runner to build the packages in a docker container using nfnty/arch-devel:latest
as image.
All you need to do: Read about the gitlab runner and using docker images to configure GitLab and GitLab-CI, such that a docker runner and the docker image nfnty/arch-devel:latest
are available to your archlinux-overlay
gitlab project.
Currently all packages are rebuild when going this way. The resulting repository is available for download as a tar or zip archive, but can also be made available to pacman directly: Just append the snippet below to /etc/pacman.conf and adjust the build-id
and url. Sadly, until gitlab-org/gitlab-ce#22536 is implemented, there's no simple way built into gitlab to refer to the most recent master
-branch build directly.
[archlinux-overlay]
Server = http(s)://gitlab.your-host.local/your-group/$repo/-/jobs/<build_id>/artifacts/raw/
SigLevel = Optional TrustAll
# Gitlab's only way to provide a direct link to the latest build requires adding
# a query string to the url, which is not suitable for pacman.
# See issue gitlab-org/gitlab-ce#22536.
# Workaround: provide entries for future builds! Urls are tried sequentially.
# Server = http(s)://gitlab.your-host.local/your-group/$repo/-/jobs/<build_id - 1>/artifacts/raw/
# Server = http(s)://gitlab.your-host.local/your-group/$repo/-/jobs/<build_id - 2>/artifacts/raw/
# ...
... a more comfortable way would be setting up a reverse proxy with a rewrite rule similiar to the following nginx example: rewrite ^/([^/]*)/([^/]*)/_artifacts/branch/(.*)/job/(.*)/(browse|download|raw)(/.*)? /$1/$2/-/jobs/artifacts/$3/$5$6?job=$4 break;
=> https://gitlab.example.com/episource/archlinux-overlay/_artifacts/branch/master/job/build_repo/raw/
Build artifacts (the repository) are deleted automatically after one week. Goto to the build's page and choose "keep" to preserve the repository for an unlimited time.
GitLab-Ci can also be used locally without a GitLab server.
Prerequisites: Install gitlab-ci-multi-runner: pacman -S gitlab-ci-multi-runner
. Nothing more! No need to start and configure the associated gitlab-runner service.
Now the repository is updated as such:
- Clone this repository & cd into its root
- Run the command below (as root or user having access to the docker socket) - the repository is then created inside a subdirectory
_repo
. If a PKGBUILD's version hasn't changed, existing binary packages are preserved and won't be rebuild. Otherwhise packages are replaced by newer versions, removing any outdated files.
mkdir -p _repo && OWNER=$(stat -c%u:%g _repo) && PERM=$(stat -c%a _repo) && \
gitlab-runner exec docker --pre-build-script "export REPODIR=/repo && chown -R nobody /repo && chmod -R u+rwx /repo" --docker-volumes "$PWD/_repo:/repo" build_repo; \
chown -R $OWNER _repo && chmod -R $PERM _repo
Set the environment variable PACMAN_MIRROR
to change builtin default pacman mirror. This can be done using the gitlab web UI for CI jobs or by using gitlab runner argument --env
. Take care to escape $
by doubling it, e.g. $$repo
.
The build environment needs to be based on Arch Linux. If a dockerized build environment is an option, take a look at the docker image nfnty/arch-devel
, which is a good point to start.
Important: During package build, packages may be installed or replaced and public keys might be added to the build user's keyring.
Here are the configuration steps required in addition to setting up the operating system:
- Install the meta-package
base-devel
:pacman -S --needed base-devel
- Optional - adjust
/etc/makepkg.conf
to your needs - see makepkg.conf(5) and Creating optimized packages for details. - Choose or create a user account for building the packages (below referred to as
the-user
):
- it needs to be a restricted (non-root) user account
- it will be granted permission to invoke (sudo) pacman as root without password
- it needs a writable home directory
- keys might be added to it's public keyring during build
- Grant
the-user
the right to invokepacman
as root:echo 'the-user ALL=(ALL) NOPASSWD: /usr/bin/pacman' >> /etc/sudoers
From now on, the whole repository is build with these steps:
- Checkout the
archlinux-overlay
git repository or make it available by other means (docker volume, ...) - Login as / change to user
the-user
- Optional, but recommended - update the system:
sudo pacman -Syu --noconfirm
- Change to the repository's source directory
- Choose a binary repository location & name:
export REPONAME="archlinux-overlay" && export REPODIR="_repo"
- Import missing validpgpkeys:
.build-bin/import-validpgpkeys.sh
- Build the whole repository:
.build-bin/build.sh
- Create the repository:
.build-bin/deploy.sh
Any binary package found within REPODIR
won't be rebuild until the PKGBUILD version has changed. Packages are replaced by newer versions, if available, and the old package's files are removed.
Steps 5-8 could also be scripted using the CI-build library .build-lib/ci-library.sh
:
#!/usr/bin/env bash
source "$REPO_SOURCE_PATH/.build-lib/ci-library.sh"
# list & sort repository packages based on (inter-)dependency hierarchy
# - it is assumed that the repository contains only compatible package versions,
# hence version information is ignored. If this assumption does not hold,
# makepkg will fail later on
_do list_packages
_do sort_packages_by_dependency
# add validpgpkeys to the current user's public keyring
_do gpg --recv-key $(get_validpgpkeys)
# build packages in the order calculated above
_do build_packages
# create / update the repository
mkdir -p "$REPODIR"
_do repo-add --new "${REPODIR}/${REPONAME}.db.tar.xz" "${REPODIR}"/*.pkg.tar.xz
[[ ! -f "${REPODIR}/${REPONAME}.db" ]] \
&& ln -s "${REPODIR}/${REPONAME}.db.tar.xz" "${REPODIR}/${REPONAME}.db"
[[ ! -f "${REPODIR}/${REPONAME}.files" ]] \
&& ln -s "${REPODIR}/${REPONAME}.files.tar.xz" "${REPODIR}/${REPONAME}.files"
You can always build single packages using makepkg. This requires you to take care of dependencies manually. You might also need to import the public keys listed as validpgpkeys into your user's keyring.
Building single packages this way is generally considered safe, so it is usually OK to do this on your main machine. However, you shouldn't use a root account. Makepkg even enforces this.
Here's what to do:
- Go to a PKGBUILDs directory
cd my-package
- Invoke makepkg
makepkg
Now the package can be installed using pacman -U /path/to/my-package.tar.xz
.
If makepkg reports missing dependencies you are required to install them manually. Keep in mind, that these dependencies might be part of the archlinux-overlay
repository and hence could require building them manually, too.
If makepkg fails with ERROR: One or more PGP signatures could not be verified!
, there are two possible reasons: 1) The source file signatures have been modified or 2) the user account invoking makepkg
is missing a key. In the later case, look for a validpgpkeys
array in the PKGBUILD and add these keys to your keyring using _do gpg --recv-key
.