Arch Build System

Arch Build System (ABS) is Arch’s way of streamlining your workflow when you need to build a custom open source package.  It is well-documented on Arch Wiki here – https://wiki.archlinux.org/index.php/Arch_Build_System.

Here’s a tl;dr example-oriented summary to help new Arch Users get right down to it.  This example demonstrates how to build your vim editor with python-support enabled.

# Install and run abs (sync)
sudo pacman -S abs
sudo abs
# Prepare a build area
mkdir ~/abs
cd ~/abs
# Make a local copy
cp -r /var/abs/extra/vim .
cd vim
vim PKBGUID
# Change the "--disable-python" options to "--enable-python"
# Build the package
makepkg
# Wait for a while
# Install your new vim and runtime (these are created via the makepkg command above)
sudo pacman -U vim-runtime-7.4.335-4-x86_64.pkg.tar.xz
sudo pacman -U vim-7.4.335-4-x86_64.pkg.tar.xz
# Check it for "+python"
vim --version

Finally, if we are going to make sure that future updates to the vim package with pacman does not override our custom vim.  To do so, simply declare

# Pacman won't upgrade packages listed in IgnorePkg and members of IgnoreGroup
IgnorePkg   = vim
#IgnoreGroup =

And that’s pretty much it.

The important thing to remember is that your custom build depends on the PKGBUILD file.  The `abs` command rsyncs the PKBUILD file from arch repositories to your server whenever you need an updated PKGBUILD and this default PKGBUILD can then be copied over to your build directory and modified so you can decide which features you want to include in your customized package.

There are many community contributed custom packages in AUR (https://aur.archlinux.org/) or on github.com so we can use those too, if a PKGBUILD that enables python support is already maintained by another contributor.

Bottomline?  Everything that controls how a package is built is declared in PKGBUILD so getting familiar with PKGBUILD will let you manage any custom package build you want.

Insufficient entropy pacman-key –init

As mentioned on https://wiki.archlinux.org/index.php/Pacman-key, pacman package manager uses GnuPGP keys to determine if the open source packages that you install via pacman are authentic.  The detailed explanations on this wiki document explains the specific details, including the Signature checking level option (SigLevel) in our /etc/pacman.conf file.

After upgrading your pacman to 4.0.3:


$ pacman --version

.--. Pacman v4.0.3 - libalpm v7.0.3
/ _.-' .-. .-. .-. Copyright (C) 2006-2012 Pacman Development Team
\ '-. '-' '-' '-' Copyright (C) 2002-2006 Judd Vinet
 '--'
 This program may be freely redistributed under
 the terms of the GNU General Public License.

you might run into GnuPGP key authentication issues like this:


$ pacman -S vim
resolving dependencies...
looking for inter-conflicts...

Targets (2): vim-runtime-7.3.600-1 vim-7.3.600-1

Total Download Size: 5.11 MiB
Total Installed Size: 27.90 MiB
Net Upgrade Size: 0.31 MiB

Proceed with installation? [Y/n] Y
:: Retrieving packages from extra...
 vim-runtime-7.3.600-1-x86_64 4.3 MiB 2.21M/s 00:02 [#########################################################################] 100%
 vim-7.3.600-1-x86_64 864.1 KiB 3.01M/s 00:00 [#########################################################################] 100%
(2/2) checking package integrity [#########################################################################] 100%
error: vim-runtime: key "7FB1A3800C84C0A5" is unknown
:: Import PGP key 0C84C0A5, "Thomas Dziedzic ", created 2011-10-31? [Y/n] Y
(2/2) checking package integrity [#########################################################################] 100%
error: vim-runtime: signature from "Thomas Dziedzic " is unknown trust
error: vim: signature from "Thomas Dziedzic " is unknown trust
error: failed to commit transaction (invalid or corrupted package (PGP signature))
Errors occurred, no packages were upgraded.

This means we are required to get our machine’s (local) pacman keys properly initialized before we attempt to install anything else.    In fact, this was mentioned when we upgraded our pacman to 4.0.3:


(12/13) installing archlinux-keyring [#########################################################################] 100%
(13/13) upgrading pacman [####################################e23####################################] 100%
 >>> Run `pacman-key --init; pacman-key --populate archlinux`
 >>> to import the data required by pacman for package verification.
 >>> See: https://www.archlinux.org/news/having-pacman-verify-packages

Oops. Should have followed the label.

However, running pacman-key –init resulted in a “hanged process”.

$ pacman-key --init
gpg: /etc/pacman.d/gnupg/trustdb.gpg: trustdb created
gpg: no ultimately trusted keys found
gpg: Generating pacman keychain master key...

https://wiki.archlinux.org/index.php/Pacman-key#Initializing_the_keyring mentions the solution by using haveged to generate the entropy (system randomness) necessary required by the  key generation process.

But we can’t really install haveged (pacman -S haveged) at the moment because we don’t yet have a master key. :-D

To solve that, we should change our SigLevel in pacman.conf for the community  repository to ‘Never’.


[community]
SigLevel = Never
Include = /etc/pacman.d/mirrorlist

Now, we can install haveged and then generate our master key. As explained in Arch Linux wiki:

pacman -S haveged
haveged -w 1024
pacman-key --init
pacman-key --populate archlinux
pkill haveged
pacman -Rs haveged

And we can now switch the community SigLevel in pacman.conf back to `SigLevel = PackageRequired`



													

Forcing glibc install on arch linux

On a fresh install of arch linux in linode, 2011.08 64bit, attempting to upgrade pacman will yield a glibc error.

Like this:


$ pacman -Sy pacman
:: Synchronizing package databases...
 core 105.9K 1322.3K/s 00:00:00 [#########################################################################] 100%
 extra 1408.5K 3.9M/s 00:00:00 [#########################################################################] 100%
 community 1748.9K 3.4M/s 00:00:01 [#########################################################################] 100%
resolving dependencies...
looking for inter-conflicts...

Targets (15): linux-api-headers-3.4.4-1 glibc-2.16.0-1 libarchive-3.0.4-1 ca-certificates-20120623-1 libssh2-1.4.2-1 curl-7.26.0-1 pth-2.0.7-4 libksba-1.2.0-2 libassuan-2.0.3-1
 pinentry-0.8.1-4 dirmngr-1.1.0-4 gnupg-2.0.19-2 gpgme-1.3.1-4 archlinux-keyring-20120622-1 pacman-4.0.3-2

Total Download Size: 13.05 MB
Total Installed Size: 61.67 MB

Proceed with installation? [Y/n] Y
:: Retrieving packages from core...
 linux-api-headers-3.4.4-1-x86_64 598.3K 3.0M/s 00:00:00 [#########################################################################] 100%
 glibc-2.16.0-1-x86_64 8.2M 3.9M/s 00:00:02 [#########################################################################] 100%
 libarchive-3.0.4-1-x86_64 529.3K 3.3M/s 00:00:00 [#########################################################################] 100%
 ca-certificates-20120623-1-any 127.1K 1579.5K/s 00:00:00 [#########################################################################] 100%
 libssh2-1.4.2-1-x86_64 185.7K 1942.8K/s 00:00:00 [#########################################################################] 100%
 curl-7.26.0-1-x86_64 495.4K 2.5M/s 00:00:00 [#########################################################################] 100%
 pth-2.0.7-4-x86_64 75.9K 1424.9K/s 00:00:00 [#########################################################################] 100%
 libksba-1.2.0-2-x86_64 109.9K 1329.7K/s 00:00:00 [#########################################################################] 100%
 libassuan-2.0.3-1-x86_64 76.5K 1444.7K/s 00:00:00 [#########################################################################] 100%
 pinentry-0.8.1-4-x86_64 93.1K 1403.4K/s 00:00:00 [#########################################################################] 100%
 dirmngr-1.1.0-4-x86_64 163.9K 1763.1K/s 00:00:00 [#########################################################################] 100%
 gnupg-2.0.19-2-x86_64 1449.6K 3.4M/s 00:00:00 [#########################################################################] 100%
 gpgme-1.3.1-4-x86_64 207.9K 2.2M/s 00:00:00 [#########################################################################] 100%
 archlinux-keyring-20120622-1-any 323.0K 2.3M/s 00:00:00 [#########################################################################] 100%
 pacman-4.0.3-2-x86_64 509.3K 2.4M/s 00:00:00 [#########################################################################] 100%
(15/15) checking package integrity [#########################################################################] 100%
(15/15) checking for file conflicts [#########################################################################] 100%
error: failed to commit transaction (conflicting files)
glibc: /usr/bin/tzselect exists in filesystem
glibc: /usr/sbin/zdump exists in filesystem
glibc: /usr/sbin/zic exists in filesystem
Errors occurred, no packages were upgraded.

This just means that tzselect, zdump and zic – which are all part of the glibc, the GNU C Library, that will be upgraded along with pacman – are already included by default in our fresh copy of arch linux OS; and if we want to upgrade pacman, we will have to do something about those existing files as the new pacman will not know what to do with them.
I am not sure why the pacman developers do not want simply kill off tzselect, zdump or zic but I would hazard to presume that they did not want to assume responsibility for removing them.

A quick chat with other arch linux users quickly confirmed my suspicions:

  1. pacman should not assume that the arch linux user wants his glibc library upgraded and userspace’s tzselect, zdump, zic forcibly removed
  2. pacman developers assume that most users would be using netinstall and not upgrading this version (provided by linode in my case)
  3. and the funniest reason of all, a “This-Is-Sparta” rationale – well, you are a Arch Linux user and not a Ubuntu user!  For such a trivial problem, you are expected to fix it yourself :-)

Okay…

IMPORTANT WARNING

DO NOT use `pacman -S glibc –force` if you are dealing with the /lib becomes a symlink to /usr/lib upgrade (reference: http://www.archlinux.org/news/the-lib-directory-becomes-a-symlink/)

The solution below worked prior to 13th July 2012.  From 14th July 2012 onwards, the correct solution is to use http://allanmcrae.com/2012/07/updating-arch-linux-from-a-core-install/.

Failing to heed this warning will lead to your glibc being wiped up and having a bricked system.

This only worked prior to 13th July 2012…

Anyhow, for those still scratching their head, the problem is exactly as the warning says. We can solve it by a couple of (simple) ways:

  1. Force glibc install first
    pacman -S glibc --force
    pacman -S pacman
    
  2. Or alternatively, just forcibly remove tzselect, zdump, zic
    rm /usr/bin/tzselect /usr/sbin/zdump /usr/sbin/zic
    pacman -S pacman
    

No magic here. Problem solved and moving on…