Alpine Linux - User contributions [en]

Flatpak

2021-12-23T12:51:19Z

Eddsalkield: /* Setup / Installation */ Fix instructions for local user accounts

{{Draft|More documentation and testing is needed, but everything currently here should be safe to follow.}}

Flatpak is a technology for building and distributing applications with the goal of having a universal package format for all Linux distributons, it is similar to [https://en.wikipedia.org/wiki/Snappy_(package_manager) Snap],

= Setup / Installation =

''From: https://flatpak.org/setup/Alpine/''

To install Flatpak you will need to enable the Community repository, See: [https://wiki.alpinelinux.org/wiki/Post_installation#Repositories Post Installation - Repositories]

To install Flatpak run:

{{cmd|# apk add flatpak}}

It's recommended to run flatpak as your user, rather than as root. Therefore, add your user to the flatpak group:

{{cmd|# adduser <YourUsername> flatpak}}

Next you need to add a repository, for this guide we will use the recommended repository, [https://flathub.org Flathub].

{{cmd|flatpak remote-add --user --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo}}

Now reboot to complete setup

{{Note|graphical installation of Flatpak apps may not be possible with Alpine.}}

 

= Usage =

To get all of the available options to use with the '''flatpak''' command run: '''flatpak --help''' or '''flatpak -h''',

 

==== Search ====

To search for applications run '''flatpak search <appplicationname>'''

Example:
{{cat|flatpak search chromium|Name Description Application ID Version Branch Remotes
Chromium Web Browser The web browser from Chromium project org.chromium.Chromium 96.0.4664.93 stable flathub
Chromium B.S.U. Fast paced, arcade-style, top-scrolling space shooter net.sourceforge.chromium-bsu 0.9.16.1 stable flathub
ungoogled-chromium A lightweight approach to removing Google web service dependency com.github.Eloston.UngoogledChromium 96.0.4664.45 stable flathub}}

 

==== Install ====

To install a package run '''flatpak install <applicationname>'''

{{cat|$ flatpak install com.github.Eloston.UngoogledChromium|Looking for matches…

com.github.Eloston.UngoogledChromium permissions:
ipc network cups pulseaudio wayland x11
devices file access [1] dbus access [2] bus ownership [3] system dbus access [4]

[1] /run/.heim_org.h5l.kcm-socket, home, xdg-run/pipewire-0
[2] org.freedesktop.FileManager1, org.freedesktop.Notifications, org.freedesktop.secrets, org.gnome.SessionManager
[3] org.mpris.MediaPlayer2.chromium.*
[4] org.freedesktop.Avahi, org.freedesktop.UPower

ID Branch Op Remote Download
1. com.github.Eloston.UngoogledChromium.Codecs stable i flathub < 1.1 MB
2. com.github.Eloston.UngoogledChromium.Locale stable i flathub < 112.8 kB
3. com.github.Eloston.UngoogledChromium stable i flathub < 119.0 MB

Proceed with these changes to the system installation? [Y/n]:}}

or if you dont know or dont want to type the exact package name:

{{cat|$ flatpak install chromium|Looking for matches…
Similar refs found for ‘chromium’ in remote ‘flathub’ (system):

1) app/net.sourceforge.chromium-bsu/x86_64/stable
2) runtime/com.github.Eloston.UngoogledChromium.Codecs/x86_64/stable
3) runtime/org.chromium.Chromium.Codecs/x86_64/stable
4) app/org.chromium.Chromium/x86_64/stable
5) app/com.github.Eloston.UngoogledChromium/x86_64/stable

Which do you want to use (0 to abort)? [0-5]:}}

 

==== Remove ====

To remove a package run: '''flatpak remove <applicationname>'''

{{cat|$ flatpak remove com.github.Eloston.UngoogledChromium|

ID Branch Op
1. com.github.Eloston.UngoogledChromium stable r
2. com.github.Eloston.UngoogledChromium.Codecs stable r
3. com.github.Eloston.UngoogledChromium.Locale stable r

Proceed with these changes to the system installation? [Y/n]:}}

or if you dont know or dont want to type the exact package name:

{{cat|$ flatpak remove chromium|Similar installed refs found for ‘chromium’:

1) app/com.github.Eloston.UngoogledChromium/x86_64/stable (system)
2) runtime/com.github.Eloston.UngoogledChromium.Codecs/x86_64/stable (system)
3) All of the above

Which do you want to use (0 to abort)? [0-3]:}}

 

= Developers =

* [https://docs.flatpak.org/en/latest/available-runtimes.html Flatpak - available runtimes]

These are all hosted on [https://flathub.org/ Flathub.org].

= Troubleshooting =

==== Permission errors ====

If you receive errors about permissions then you may need to add your user to the '''flatpak''' group:

{{cmd|adduser <YourUsername> flatpak}}

 

{{Note|You may need to log out and log back in or reboot for the group change(s) to take effect}}

 

==== Fixing audio issues ====

If you have a minimal setup and don't have access to audio devices you will need to set the XDG_RUNTIME_DIR variable. Save the following script in /etc/profile.d/xdg_runtime_dir.sh and re-login to have it set up properly.

if test -z "${XDG_RUNTIME_DIR}"; then
export XDG_RUNTIME_DIR=/tmp/$(id -u)
fi

When you launch a Flatpak you will need to start pulseaudio as well:
{{Cmd|pulseaudio --start && flatpak run com.example.Example}}

 

= Links =
* [https://flatpak.org/ Flatpak]
* [https://flathub.org/ Flathub]
* [https://winepak.org/ Winepak]

 

= See Also =

[[Category:Package Manager]]
[[Category: Desktop]]

Flatpak

2021-12-23T12:42:43Z

Eddsalkield: /* Permission errors */

{{Draft|More documentation and testing is needed, but everything currently here should be safe to follow.}}

Flatpak is a technology for building and distributing applications with the goal of having a universal package format for all Linux distributons, it is similar to [https://en.wikipedia.org/wiki/Snappy_(package_manager) Snap],

= Setup / Installation =

''From: https://flatpak.org/setup/Alpine/''

 

To install Flatpak you will need to enable the Community repository, See: [https://wiki.alpinelinux.org/wiki/Post_installation#Repositories Post Installation - Repositories]

 

To install Flatpak run:

{{cmd|# apk add flatpak}}

 

Next you need to add a repository, for this guide we will use the recommended repository, [https://flathub.org Flathub]

{{cmd|flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo}}

 

Now reboot to complete setup

 

{{Note|graphical installation of Flatpak apps may not be possible with Alpine.}}

 

= Usage =

To get all of the available options to use with the '''flatpak''' command run: '''flatpak --help''' or '''flatpak -h''',

 

==== Search ====

To search for applications run '''flatpak search <appplicationname>'''

Example:
{{cat|flatpak search chromium|Name Description Application ID Version Branch Remotes
Chromium Web Browser The web browser from Chromium project org.chromium.Chromium 96.0.4664.93 stable flathub
Chromium B.S.U. Fast paced, arcade-style, top-scrolling space shooter net.sourceforge.chromium-bsu 0.9.16.1 stable flathub
ungoogled-chromium A lightweight approach to removing Google web service dependency com.github.Eloston.UngoogledChromium 96.0.4664.45 stable flathub}}

 

==== Install ====

To install a package run '''flatpak install <applicationname>'''

{{cat|$ flatpak install com.github.Eloston.UngoogledChromium|Looking for matches…

com.github.Eloston.UngoogledChromium permissions:
ipc network cups pulseaudio wayland x11
devices file access [1] dbus access [2] bus ownership [3] system dbus access [4]

[1] /run/.heim_org.h5l.kcm-socket, home, xdg-run/pipewire-0
[2] org.freedesktop.FileManager1, org.freedesktop.Notifications, org.freedesktop.secrets, org.gnome.SessionManager
[3] org.mpris.MediaPlayer2.chromium.*
[4] org.freedesktop.Avahi, org.freedesktop.UPower

ID Branch Op Remote Download
1. com.github.Eloston.UngoogledChromium.Codecs stable i flathub < 1.1 MB
2. com.github.Eloston.UngoogledChromium.Locale stable i flathub < 112.8 kB
3. com.github.Eloston.UngoogledChromium stable i flathub < 119.0 MB

Proceed with these changes to the system installation? [Y/n]:}}

or if you dont know or dont want to type the exact package name:

{{cat|$ flatpak install chromium|Looking for matches…
Similar refs found for ‘chromium’ in remote ‘flathub’ (system):

1) app/net.sourceforge.chromium-bsu/x86_64/stable
2) runtime/com.github.Eloston.UngoogledChromium.Codecs/x86_64/stable
3) runtime/org.chromium.Chromium.Codecs/x86_64/stable
4) app/org.chromium.Chromium/x86_64/stable
5) app/com.github.Eloston.UngoogledChromium/x86_64/stable

Which do you want to use (0 to abort)? [0-5]:}}

 

==== Remove ====

To remove a package run: '''flatpak remove <applicationname>'''

{{cat|$ flatpak remove com.github.Eloston.UngoogledChromium|

ID Branch Op
1. com.github.Eloston.UngoogledChromium stable r
2. com.github.Eloston.UngoogledChromium.Codecs stable r
3. com.github.Eloston.UngoogledChromium.Locale stable r

Proceed with these changes to the system installation? [Y/n]:}}

or if you dont know or dont want to type the exact package name:

{{cat|$ flatpak remove chromium|Similar installed refs found for ‘chromium’:

1) app/com.github.Eloston.UngoogledChromium/x86_64/stable (system)
2) runtime/com.github.Eloston.UngoogledChromium.Codecs/x86_64/stable (system)
3) All of the above

Which do you want to use (0 to abort)? [0-3]:}}

 

= Developers =

* [https://docs.flatpak.org/en/latest/available-runtimes.html Flatpak - available runtimes]

These are all hosted on [https://flathub.org/ Flathub.org].

= Troubleshooting =

==== Permission errors ====

If you receive errors about permissions then you may need to add your user to the '''flatpak''' group:

{{cmd|adduser <YourUsername> flatpak}}

 

{{Note|You may need to log out and log back in or reboot for the group change(s) to take effect}}

 

==== Fixing audio issues ====

If you have a minimal setup and don't have access to audio devices you will need to set the XDG_RUNTIME_DIR variable. Save the following script in /etc/profile.d/xdg_runtime_dir.sh and re-login to have it set up properly.

if test -z "${XDG_RUNTIME_DIR}"; then
export XDG_RUNTIME_DIR=/tmp/$(id -u)
fi

When you launch a Flatpak you will need to start pulseaudio as well:
{{Cmd|pulseaudio --start && flatpak run com.example.Example}}

 

= Links =
* [https://flatpak.org/ Flatpak]
* [https://flathub.org/ Flathub]
* [https://winepak.org/ Winepak]

 

= See Also =

[[Category:Package Manager]]
[[Category: Desktop]]

Emojis

2021-12-11T19:56:23Z

Eddsalkield: sudo -> doas

'''Emojis''' are characters with pictures used to express ideas, things, places in one character. Emojis are known to be used for creating and entering passwords and for [https://en.wikipedia.org/wiki/Emoji_domain registering domain names].

== Support ==

Currently Alpine Linux supports only one emoji font only available on [[Edge]] called Noto Color Emoji which is used in the Android operating system. The latest version of Noto Color Emoji supports [https://unicode.org/emoji/charts/full-emoji-list.html Emoji 5.0] released around 2017.

Currently, Edge has better emoji support for Firefox 58.x. Alpine 3.7.0 has Firefox 52.x which has broken emoji support but can be backported. Firefox can render some emojis based on the EmojiOne font without any changes to the system by the user.

Currently Cairo 1.14.10 doesn't have color emoji support enabled, so there may be no colored emojis on the terminal but show up in black and white.

== Installation ==

doas apk add font-noto-emoji

== Configuration ==

You need either a user ~/.config/fontconfig/conf.d/01-noto-emoji.conf or systemwide /etc/fonts/local.conf with the following:

<pre>
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>

<alias>
<family>sans-serif</family>
<prefer>
<family>Main sans-serif font name goes here</family>
<family>Noto Color Emoji</family>
<family>Noto Emoji</family>
</prefer>
</alias>

<alias>
<family>serif</family>
<prefer>
<family>Main serif font name goes here</family>
<family>Noto Color Emoji</family>
<family>Noto Emoji</family>
</prefer>
</alias>

<alias>
<family>monospace</family>
<prefer>
<family>Main monospace font name goes here</family>
<family>Noto Color Emoji</family>
<family>Noto Emoji</family>
</prefer>
</alias>
</fontconfig>
</pre>

== Testing and bugs ==

You can go to https://getemoji.com/ and every emoji should be properly rendered on a patched Cairo (but without patched there are a few not fully colored). The [https://en.wikipedia.org/wiki/Basic_Latin_(Unicode_block)#Emoji enclosing keycaps] are not properly rendered which is a known bug. It should look like [http://i.imgur.com/6URHgWC.png this screenshot].

DWM also has a bug if you have a program title with a emoji it will crash. There is a patch available. See [https://github.com/alpinelinux/aports/pull/3111 pull request].

[[Category:Infographics]]

Vpnc

2021-12-08T11:42:08Z

Eddsalkield: Initial vpnc configuration page

[https://www.unix-ag.uni-kl.de/~massar/vpnc/ vpnc] is a VPN client for Cisco hardware VPNs.

== Installation ==

vpnc is in the repositories and can be installed with the [https://pkgs.alpinelinux.org/packages?name=vpnc vpnc] package.

== Configuration ==

vpnc can be configured either on the command line or through its configuration file. The configuration files are stored in <code>/etc/vpnc</code>, with a template at <code>/etc/vpnc/default.conf</code>.

Copy the template file to <code>/etc/vpnc/vpnc.conf</code> and edit it to your preferences. A sensible configuration might look like:

<pre>
IPSec gateway <gateway>
IPSec ID <group-id>
IPSec secret <group-psk>
IKE Authmode <authmode>
Xauth username <username>
Xauth password <password>
Domain <domain>
</pre>

Debugging can be enabled at different levels by appending <code>Debug x</code> for some debug level x of 0 (default, does not print), 1 (minimal), 2 (verbose), 3 (everything except authentication data), or 99 (everything including authentication data).

You can run the VPN with
<pre># vpnc /etc/vpnc/vpnc.conf</pre>
and test that it's working with
<pre># ip a</pre>
You should see a new tunnel device (e.g. <code>tun0</code>).

You can now enable the service, and start it at boot if you require:

<pre>
# killall vpnc
# rc-service vpnc start
# rc-update add vpnc boot
</pre>

== NetworkManager ==

There exists a [https://gitlab.gnome.org/GNOME/NetworkManager-vpnc/ NetworkManager vpnc] plugin. Future work will consider packaging this tool for the repositories and continuing this guide to document the process.

LVM on LUKS

2021-12-05T21:29:46Z

Eddsalkield: /* Grub with UEFI */ Set more secure permissions when creating /mnt/crypto_keyfile.bin

= Introduction =

This documentation describes how to set up Alpine Linux on a fully encrypted disk (apart from the bootloader partition). We will have an LVM container installed inside an encrypted partition. To encrypt the partition containing the LVM volume group, dm-crypt (which is managed by the <code>cryptsetup</code> command) and its LUKS subsystem is used.

Note that your <code>/boot/</code> partition must be non-encrypted to work with Syslinux. When using GRUB2 it is possible to boot from an encrypted partition to provide a layer of protection from [https://en.wikipedia.org/wiki/Evil_maid_attack Evil Maid attacks], but Syslinux doesn't support that.

== Storage Device Name ==

To find your storage device's name, you could either install <code>util-linux</code> (<code>apk add util-linux</code>) and find your device using the <code>lsblk</code> command, or you could make an educated guess by using BusyBox's <code>blkid</code> and <code>df</code> commands, and running <code>ls /dev/sd*</code> if you are installing to a USB, SATA or SCSI device, <code>ls /dev/fd*</code> for floppy disks and <code>ls /dev/hd*</code> for IDE (PATA) devices.

The following documentation uses the <code>/dev/sda</code> device as installation destination. If your environment uses a different name for your storage device, use the corresponding device name in the examples.

= Setting up Alpine Linux Using LVM on Top of a LUKS Partition =

To install Alpine Linux on logical volumes running on top of a LUKS encrypted partition, you cannot use the [[Installation|official installation]] procedure. The installation requires several manual steps you must run in the Alpine Linux Live CD environment.

== Preparing the Temporary Installation Environment ==

Before you begin to install Alpine Linux, prepare the temporary environment:

Boot the latest Alpine Linux Installation CD. At the login prompt, use the <code>root</code> user without a password to log in. Now we will follow the [[Setup-alpine]] script and make our changes along the way.

Run the scripts in this order:

<pre># setup-keymap
# setup-hostname
# setup-interfaces
# rc-service networking start</pre>

If you are configuring static networking (i.e. you didn't configure any interfaces to use DHCP), run <code>setup-dns</code>.

If you are using Wi-Fi you may need to do run <code>rc-update add wpa_supplicant boot</code>.

<pre># passwd
# setup-timezone
# rc-update add networking boot
# rc-update add urandom boot
# rc-update add acpid default
# rc-service acpid start</pre>

Edit your {{Path|/etc/hosts}} to look like this, replacing <hostname> with your hostname and <domain> with your TLD (if you don't have a TLD, use 'localdomain':
{{Tip|The default text editor in BusyBox is <code>vi</code> (pronounced ''vee-eye'').}}
{{Cat|/etc/hosts|127.0.0.1 <hostname> <hostname>.<domain> localhost localhost.localdomain
::1 <hostname> <hostname>.<domain> localhost localhost.localdomain}}

<pre># setup-ntp
# setup-apkrepos
# apk update
# setup-sshd</pre>

Here's where we deviate from the install script.

Install the following packages required to set up LVM and LUKS:

{{Note|The <code>parted</code> partition editor is needed for advanced partitioning and GPT disklabels. BusyBox <code>fdisk</code> is a very stripped-down version with minimal functionality}}

<pre># apk add lvm2 cryptsetup e2fsprogs parted</pre>

Optionally, if you want to overwrite your storage with random data first, install <code>haveged</code>, which is a random number generator based on hardware events and has a higher throughput than <code>/dev/urandom</code>:

<pre># apk add haveged
# rc-service haveged start</pre>

== Creating the Partition Layout ==

Depending on your motherboard, bios features and configuration
we can either use partition table in MBR (legacy BIOS)
or GUID Partition Table (GPT).
We'll describe both with example layouts.

=== BIOS/MBR with DOS disklabel ===

We'll be partitioning the storage device with a non-encrypted <code>/boot</code> partition for use with the Syslinux bootloader. Syslinux is meant for use with legacy BIOS and an MSDOS MBR partition table. 
Syslinux does support GPT partition tables but GRUB2 is the better option for UEFI (UEFI is possible only with GPT).

<pre>+---------------------------+------------------------+-----------------------+
| Partition name | Partition purpose | Filesystem type |
+---------------------------+------------------------+-----------------------+
| /dev/sda1 | Boot partition | ext4 |
| /dev/sda2 | LUKS container | LUKS |
| |-> /dev/mapper/lvmcrypt | LVM container | LVM |
| |-> /dev/vg01/root | Root partition | ext4 |
| |-> /dev/vg01/swap | Swap partition | swap |
+---------------------------+------------------------+-----------------------+</pre>

{{Warning|This will delete an existing partition table and make your data very hard to recover. If you want to dual boot, stop here and ask an expert.}}

Create a partition of approximately 100MB to boot from, then assign the rest of the space to your LUKS partition.

<pre># parted -a optimal
(parted) mklabel msdos
(parted) mkpart primary ext4 0% 100M
(parted) name 1 boot
(parted) set 1 boot on
(parted) mkpart primary ext4 100M 100%
(parted) name 2 crypto-luks</pre>

To view your partition table, type <code>print</code> while still in <code>parted</code>. Your results should look something like this:
<pre>(parted) print
Model: ATA TOSHIBA ******** (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
1 1049kB 99.6MB 98.6MB primary ext4 boot
2 99.6MB 1000GB 1000GB primary ext4</pre>

=== UEFI with GPT disklabel ===

We will be encrypting the whole disk except for the EFI system partition mounted at <code>/boot/efi</code>. This means GRUB2 will decrypt the LUKS volume and load the kernel from there, preventing someone with physical access to your computer from maliciously installing a rootkit (or bootkit) in your boot partition while your computer is not unlocked. The partitioning scheme will look like this:

<pre>+---------------------------+------------------------+-----------------------+
| Partition name | Partition purpose | Filesystem type |
+---------------------------+------------------------+-----------------------+
| /dev/sda1 | EFI system partition | fat32 |
| /dev/sda2 | LUKS container | LUKS |
| |-> /dev/mapper/lvmcrypt | LVM container | LVM |
| |-> /dev/vg01/root | Root partition | ext4 |
| |-> /dev/vg01/boot | Boot partition | ext4 |
| |-> /dev/vg01/swap | Swap partition | swap |
+---------------------------+------------------------+-----------------------+</pre>

{{Warning|This will delete an existing partition table and make your data very hard to recover. If you want to dual boot, stop here and ask an expert.}}

Create an EFI system partition of approximately 200MB, then assign the rest of the space to your LUKS partition.

<pre># parted -a optimal
(parted) mklabel gpt
(parted) mkpart primary fat32 0% 200M
(parted) name 1 esp
(parted) set 1 esp on
(parted) mkpart primary ext4 200M 100%
(parted) name 2 crypto-luks</pre>

== Optional: Overwrite LUKS Partition with Random Data ==

This should be done if your hard drive wasn't encrypted previously. It helps purge old, non-encrypted data and makes it harder for an attacker to work out how much data you have on your drive if they have access to the encrypted contents.

We'll use <code>haveged</code> as it is considerably faster than <code>/dev/urandom</code> when generating pseudo-random numbers (it's almost as high in throughput as <code>/dev/zero</code>), and is (supposedly) very close to truly random.

<pre># haveged -n 0 | dd of=/dev/sda2</pre>

== Encrypting the LVM Physical Volume Partition ==

To encrypt the partition that will later contain the LVM PV, you could either use the default settings (aes-xts-plain64 cipher with 256-bit key and Argon2 hashing with iter-time 2000ms), or you could use these settings which have added security with the trade-off being a non-noticeable decrease in performance on modern computers:

Default settings:

<pre># cryptsetup luksFormat /dev/sda2</pre>

Optimized for security:

<pre># cryptsetup -v -c serpent-xts-plain64 -s 512 --hash whirlpool --iter-time 5000 --use-random luksFormat /dev/sda2</pre>

If using Alpine v3.11 or later, and GRUB2 with encrypted /boot, the following should be used instead (because GRUB2 does not yet support LUKS2 containers):

<pre># cryptsetup luksFormat --type luks1 /dev/sda2</pre>

=== Converting between LUKS2 and LUKS1 ===

It is sometimes possible to convert a LUKS2 volume to a LUKS1 volume. First take a backup of the LUKS header that you can restore if anything goes wrong:

<pre># cryptsetup luksHeaderBackup /dev/sda2 --header-backup-file sda2-luks-header-backup</pre>

Then make sure all keys use <code>pbkdf2</code> by adding a new key with:

<pre># cryptsetup luksAddKey --pbkdf pbkdf2 /dev/sda2</pre>

Remove keys that use <code>argon2i</code> or <code>argon2id</code> with <code>cryptsetup luksRemoveKey /dev/sda2</code>. You can check the key information using <code>cryptsetup luksDump /dev/sda2</code>.

Now you can try the conversion, although it may not work.

<pre># cryptsetup convert /dev/sda2 --type luks1</pre>

== Creating the Logical Volumes and File Systems ==

Open the LUKS partition:

<pre># cryptsetup luksOpen /dev/sda2 lvmcrypt</pre>

Create the PV on <code>lvmcrypt</code>:

<pre># pvcreate /dev/mapper/lvmcrypt</pre>

Create the <code>vg0</code> LVM VG in the <code>/dev/mapper/lvmcrypt</code> PV:

<pre># vgcreate vg0 /dev/mapper/lvmcrypt</pre>

=== LV Creation for BIOS/MBR ===

This will create a 2GB swap partition and a root partition which takes up the rest of the space. This setup is for those who do not need to use the hibernate/suspend to disk state. If you do need to suspend to disk, create a swap partition slightly larger than the size of your RAM (change the size after <code># lvcreate -L</code>).

<pre># lvcreate -L 2G vg0 -n swap
# lvcreate -l 100%FREE vg0 -n root</pre>

The LVs created in the previous steps are automatically marked active. To verify, enter:

<pre># lvscan</pre>

=== LV Creation for UEFI/GPT ===

This will create a 2GB swap partition, a 2GB boot partition and a root partition which takes up the rest of the space. This setup is for those who do not need to use the hibernate/suspend to disk state. If you do need to suspend to disk, create a swap partition slightly larger than the size of your RAM (change the size after <code># lvcreate -L</code>).

<pre># lvcreate -L 2G vg0 -n swap
# lvcreate -L 2G vg0 -n boot
# lvcreate -l 100%FREE vg0 -n root</pre>

The LVs created in the previous steps are automatically marked active. To verify, enter:

<pre># lvscan</pre>

== Creating and Mounting the File Systems ==

Format the <code>root</code> and <code>boot</code> LVs using the ext4 file system:

<pre># mkfs.ext4 /dev/vg0/root</pre>

Format the swap LV:

<pre># mkswap /dev/vg0/swap</pre>

Before you can install Alpine Linux, you must mount the partitions and LVs. Mount the root LV to the <code>/mnt/</code> directory:

<pre># mount -t ext4 /dev/vg0/root /mnt/</pre>

Next format your boot partition, create a mount point, then mount it:

* If you're using BIOS and MBR:

<pre># mkfs.ext4 /dev/sda1
# mkdir -v /mnt/boot
# mount -t ext4 /dev/sda1 /mnt/boot</pre>

* If you're using UEFI and GPT:

<pre># apk add dosfstools
# mkfs.fat -F32 /dev/sda1
# mkfs.ext4 /dev/vg0/boot
# mkdir -v /mnt/boot
# mount -t ext4 /dev/vg0/boot /mnt/boot
# mkdir -v /mnt/boot/efi
# mount -t vfat /dev/sda1 /mnt/boot/efi</pre>

Lastly, activate your swap partition:

<pre># swapon /dev/vg0/swap</pre>

== Installing Alpine Linux ==

In this step you will install Alpine Linux in the <code>/mnt/</code> directory, which contains the mounted file system structure:

<pre># setup-disk -m sys /mnt/</pre>

The installer downloads the latest packages to install the base installation. Additionally, the installer automatically creates the entries for the mount points in {{Path|/etc/fstab}} file, which is currently mounted in the <code>/mnt/</code> directory.

{{Note|The automatic writing of the master boot record (MBR) fails in this step. Later, you'll manually write the MBR to the disk.}}

The swap LV is not automatically added to the <code>fstab</code> file. so we need to add the following line to the {{Path|/mnt/etc/fstab}} file:

<pre>/dev/vg0/swap swap swap defaults 0 0</pre>

Edit the {{Path|/mnt/etc/mkinitfs/mkinitfs.conf}} file and append the <code>cryptsetup</code> module to the <code>features</code> parameter:

<pre>features="... cryptsetup"</pre>

If you are using GRUB with an encrypted <code>/boot</code> you must add the <code>cryptkey</code> feature so that Alpine can use a keyfile for decryption on boot.

{{Note|Alpine Linux uses the <code>en-us</code> keyboard mapping by default when prompting for the password to decrypt the partition at boot time. If you changed the keyboard mapping in the temporary environment and want to use it at the boot password prompt, be sure to add the <code>keymap</code> feature to the list above.}}

{{Note|Check the output of <code>mkinitfs -L</code> and add the features necessary for your system to boot. You may need to add <code>kms</code> in order to see a password prompt at boot. You may also need: <code>usb</code>, <code>lvm</code>, <code>ext4</code>, <code>nvme</code>...}}

Rebuild the initial RAM disk:

<pre># mkinitfs -c /mnt/etc/mkinitfs/mkinitfs.conf -b /mnt/ $(ls /mnt/lib/modules/)</pre>

The command uses the settings from the <code>mkinitfs.conf</code> file set in the <code>-c</code> parameter to generate the RAM disk. The command is executed in the <code>/mnt/</code> directory and the RAM disk is generated using the modules for the installed kernel. Without setting the kernel version using the <code>$(ls /mnt/lib/modules/</code>) option, <code>mkinitfs</code> tries to generate the RAM disk using the kernel version installed in the temporary environment, which can differ from the latest one installed by the <code>setup-disk</code> utility.

== Installing a bootloader ==

To get the UUID of your storage device into a file for later use, run this command:

<pre># blkid -s UUID -o value /dev/sda2 > ~/uuid</pre>

{{Tip|To easily read the UUID into a file so you don't have to type it manually, open the file in <code>vi</code>, then type <code>:r /root/uuid</code> to load the UUID onto a new line.}}

=== Syslinux with BIOS ===

Install the Syslinux package:

<pre># apk add syslinux</pre>

Edit {{Path|/mnt/etc/update-extlinux.conf}} and append the following kernel options to the <code>default_kernel_opts</code> parameter, replacing <UUID> with the UUID of <code>/dev/sda2</code>:

<pre>default_kernel_opts="... cryptroot=UUID=<UUID of sda2> cryptdm=lvmcrypt"</pre>

The <code>cryptroot</code> parameter sets the ID of the device/partition that contains encrypted volumes, and the <code>cryptdm</code> parameter uses the name of the mapping we have already configured a few lines above.

We can also double check if <code>modules</code> and <code>root</code> are set correctly, eg:
<pre>
modules=sd-mod,usb-storage,ext4,cryptsetup,keymap,cryptkey,kms,lvm
root=UUID=<UUID of /dev/mapper/vg0-root>
</pre>

Because the <code>update-extlinux</code> utility operates only on the <code>/boot/</code> directory, temporarily change the root to the <code>/mnt/</code> directory and update the boot loader configuration:

<pre># chroot /mnt/
# update-extlinux
# exit</pre>

: Because we didn't mount <code>/dev</code> nor <code>/proc</code> inside our <code>/mnt/</code> chroot, some errors may occur when we run <code>update-extlinux</code> command. But you can most likely ignore these.

Write the MBR (without partition table) to the <code>/dev/sda</code> device:

<pre># dd bs=440 count=1 conv=notrunc if=/mnt/usr/share/syslinux/mbr.bin of=/dev/sda</pre>

=== Grub with UEFI ===

To avoid having to type your decryption password twice every boot (once for GRUB and once for Alpine), add a keyfile to your LUKS partition. The filename is important.

<pre># touch /mnt/crypto_keyfile.bin
# chmod 600 /mnt/crypto_keyfile.bin
# dd bs=512 count=4 if=/dev/urandom of=/mnt/crypto_keyfile.bin
# cryptsetup luksAddKey /dev/sda2 /mnt/crypto_keyfile.bin
</pre>

This keyfile is stored encrypted (it is in your LUKS partition), so its presence does not affect system security.

Mount the required filesystems for the Grub EFI installer to the installation:

<pre># mount -t proc /proc /mnt/proc
# mount --rbind /dev /mnt/dev
# mount --make-rslave /mnt/dev
# mount --rbind /sys /mnt/sys</pre>

Then run chroot and use <code>grub-install</code> to install Grub.

<pre># chroot /mnt
# source /etc/profile
# export PS1="(chroot) $PS1"</pre>

Install <code>GRUB2</code> for EFI and (optionally) remove syslinux:

<pre># apk add grub grub-efi efibootmgr
# apk del syslinux</pre>

Edit {{Path|/etc/default/grub}} and add the following kernel options to the <code>GRUB_CMDLINE_LINUX_DEFAULT</code> parameter, replacing <UUID> with the UUID of the encrypted partition (in this case, <code>/dev/sda2</code>):

<pre>cryptroot=UUID=<UUID> cryptdm=lvmcrypt cryptkey</pre>

The <code>cryptroot</code> parameter sets the ID of the device/partition that contains encrypted volumes, and the <code>cryptdm</code> parameter uses the name of the mapping we configured a few lines above.
The <code>cryptkey</code> parameter indicates the existence of the file <code>/crypto_keyfile.bin</code> you created previously.

To enable GRUB to decrypt LUKS partitions and read LVM volumes add:

<pre>GRUB_PRELOAD_MODULES="luks cryptodisk part_gpt lvm"</pre>

If using Alpine v3.11 or later, <code>GRUB_ENABLE_CRYPTODISK=y</code> should also be added to {{Path|/etc/default/grub}}.

<pre># (chroot) grub-install --target=x86_64-efi --efi-directory=/boot/efi
# (chroot) grub-mkconfig -o /boot/grub/grub.cfg
# (chroot) exit</pre>

== Unmounting the Volumes and Partitions ==

Unmount the <code>/mnt/</code> partitions, deactivate the LVM volumes, close the LUKS partition and reboot:

<pre># cd
# umount -l /mnt/dev
# umount -l /mnt/proc
# umount -l /mnt/sys
# umount /mnt/boot/efi
# umount /mnt/boot
# swapoff /dev/vg0/swap
# umount /mnt
# vgchange -a n
# cryptsetup luksClose lvmcrypt
# reboot</pre>

= Troubleshooting =

== General Procedure ==

In case your system fails to boot, you can verify the settings and fix incorrect configurations.

Reboot and do the steps in [[#Preparing_the_Temporary_Installation_Environment|Prepare the temporary installation environment]] again.

Setup the LUKS partition and activate the LVs:

<pre># cryptsetup luksOpen /dev/sda2
# vgchange -ay</pre>

[[#Creating_and_Mounting_the_File Systems|Mount the file systems]]

Verify that you run the steps described in the [[#Installing_Alpine_Linux|Installing Alpine Linux]] section correctly. Update the configuration if necessary, unmount the partitions, then reboot.

== System can't find boot device ==

* GPT partition table on a motherboard that runs BIOS instead of UEFI
* running an MSDOS/MBR/Syslinux install without enabling legacy boot mode in the UEFI settings

== I see "can not mount /sysroot" during boot ==

* incorrect device UUID
* missing module in <code>/mnt/etc/update-extlinux.conf</code> or <code>/mnt/etc/mkinitfs/mkinitfs.conf</code>

== Secure boot ==

If secure boot complains of an unsigned bootloader, you can either disable it or adapt [https://wiki.archlinux.org/index.php/Secure_Boot this] guide to sign GRUB. If you're using Syslinux, then secure boot should be automatically disabled when you enable legacy boot mode.

= Hardening =

* To harden, you should disable DMA[https://old.iseclab.org/papers/acsac2012dma.pdf] and install a hardened version of AES (TRESOR[https://www1.informatik.uni-erlangen.de/tresor] or Loop-Amnesia[http://moongate.ydns.eu/amnesia.html]) since by default cryptsetup with luks uses AES by default.
* Disable DMA in the BIOS and set the password for the BIOS according to Wikipedia.[https://en.wikipedia.org/wiki/DMA_attack]
* Blacklist kernel modules that use DMA and any unused expansion modules (FireWire, CardBus, ExpressCard, Thunderbolt, USB 3.0, PCI Express and hotplug modules) that use DMA.

= Mounting additional encrypted filesystems at boot =

If you would like other encrypted LUKS partitions to be decrypted and mounted automatically during boot, for example if you have <code>/home</code> on a separate physical drive, some extra steps are required.
{{Note|This does not apply for volumes
within your main encrypted partition <code>/dev/sda2</code>}}
For the purposes of these instructions we will say <code>/dev/sdb1</code> contains an LVM volume that should be mounted at <code>/home</code>.

Create a keyfile and add it to the LUKS partition:

<pre># dd bs=512 count=4 if=/dev/urandom of=/root/crypt-home-keyfile.bin
# cryptsetup luksAddKey /dev/sdb1 /root/crypt-home-keyfile.bin
</pre>

Alpine, like Gentoo, uses the <code>dmcrypt</code> service rather than <code>/etc/crypttab</code>. Add the following lines to <code>/etc/conf.d/dmcrypt</code>:

<pre>target=crypt-home
source='/dev/sdb1'
key='/root/crypt-home-keyfile.bin'
</pre>

Add an entry to <code>/etc/fstab</code>, changing <code>vg1</code> to the name of your LVM volume group:

<pre>/dev/vg1/home /home ext4 rw,relatime 0 2</pre>

Enable the dmcrypt and lvm services to start on boot:

<pre># rc-update add dmcrypt boot
# rc-update add lvm boot
</pre>

After a reboot the partition should be decrypted and mounted automatically.

= See also =
*[[Bootloaders]]
*[[Alpine setup scripts]]
*[[Installing on GPT LVM]]
*[[Setting up LVM on GPT-labeled disks]]
*[[Setting up disks manually]]
*https://wiki.gentoo.org/wiki/Syslinux
*https://wiki.gentoo.org/wiki/GRUB2
*https://wiki.archlinux.org/index.php/Syslinux
*https://wiki.archlinux.org/index.php/GRUB
*https://wiki.gentoo.org/wiki/Sakaki's_EFI_Install_Guide
*https://battlepenguin.com/tech/alpine-linux-with-full-disk-encryption/
*https://wiki.gentoo.org/wiki/Dm-crypt

[[Category:Storage]]
[[Category:Security]]

LVM on LUKS

2021-12-01T13:21:44Z

Eddsalkield: /* Preparing the Temporary Installation Environment */ Set up NTP before services that require an accurate time

= Introduction =

This documentation describes how to set up Alpine Linux on a fully encrypted disk (apart from the bootloader partition). We will have an LVM container installed inside an encrypted partition. To encrypt the partition containing the LVM volume group, dm-crypt (which is managed by the <code>cryptsetup</code> command) and its LUKS subsystem is used.

Note that your <code>/boot/</code> partition must be non-encrypted to work with Syslinux. When using GRUB2 it is possible to boot from an encrypted partition to provide a layer of protection from [https://en.wikipedia.org/wiki/Evil_maid_attack Evil Maid attacks], but Syslinux doesn't support that.

== Storage Device Name ==

To find your storage device's name, you could either install <code>util-linux</code> (<code>apk add util-linux</code>) and find your device using the <code>lsblk</code> command, or you could make an educated guess by using BusyBox's <code>blkid</code> and <code>df</code> commands, and running <code>ls /dev/sd*</code> if you are installing to a USB, SATA or SCSI device, <code>ls /dev/fd*</code> for floppy disks and <code>ls /dev/hd*</code> for IDE (PATA) devices.

The following documentation uses the <code>/dev/sda</code> device as installation destination. If your environment uses a different name for your storage device, use the corresponding device name in the examples.

= Setting up Alpine Linux Using LVM on Top of a LUKS Partition =

To install Alpine Linux on logical volumes running on top of a LUKS encrypted partition, you cannot use the [[Installation|official installation]] procedure. The installation requires several manual steps you must run in the Alpine Linux Live CD environment.

== Preparing the Temporary Installation Environment ==

Before you begin to install Alpine Linux, prepare the temporary environment:

Boot the latest Alpine Linux Installation CD. At the login prompt, use the <code>root</code> user without a password to log in. Now we will follow the [[Setup-alpine]] script and make our changes along the way.

Run the scripts in this order:

<pre># setup-keymap
# setup-hostname
# setup-interfaces
# rc-service networking start</pre>

If you are configuring static networking (i.e. you didn't configure any interfaces to use DHCP), run <code>setup-dns</code>.

If you are using Wi-Fi you may need to do run <code>rc-update add wpa_supplicant boot</code>.

<pre># passwd
# setup-timezone
# rc-update add networking boot
# rc-update add urandom boot
# rc-update add acpid default
# rc-service acpid start</pre>

Edit your {{Path|/etc/hosts}} to look like this, replacing <hostname> with your hostname and <domain> with your TLD (if you don't have a TLD, use 'localdomain':
{{Tip|The default text editor in BusyBox is <code>vi</code> (pronounced ''vee-eye'').}}
{{Cat|/etc/hosts|127.0.0.1 <hostname> <hostname>.<domain> localhost localhost.localdomain
::1 <hostname> <hostname>.<domain> localhost localhost.localdomain}}

<pre># setup-ntp
# setup-apkrepos
# apk update
# setup-sshd</pre>

Here's where we deviate from the install script.

Install the following packages required to set up LVM and LUKS:

{{Note|The <code>parted</code> partition editor is needed for advanced partitioning and GPT disklabels. BusyBox <code>fdisk</code> is a very stripped-down version with minimal functionality}}

<pre># apk add lvm2 cryptsetup e2fsprogs parted</pre>

Optionally, if you want to overwrite your storage with random data first, install <code>haveged</code>, which is a random number generator based on hardware events and has a higher throughput than <code>/dev/urandom</code>:

<pre># apk add haveged
# rc-service haveged start</pre>

== Creating the Partition Layout ==

Depending on your motherboard, bios features and configuration
we can either use partition table in MBR (legacy BIOS)
or GUID Partition Table (GPT).
We'll describe both with example layouts.

=== BIOS/MBR with DOS disklabel ===

We'll be partitioning the storage device with a non-encrypted <code>/boot</code> partition for use with the Syslinux bootloader. Syslinux is meant for use with legacy BIOS and an MSDOS MBR partition table. 
Syslinux does support GPT partition tables but GRUB2 is the better option for UEFI (UEFI is possible only with GPT).

<pre>+---------------------------+------------------------+-----------------------+
| Partition name | Partition purpose | Filesystem type |
+---------------------------+------------------------+-----------------------+
| /dev/sda1 | Boot partition | ext4 |
| /dev/sda2 | LUKS container | LUKS |
| |-> /dev/mapper/lvmcrypt | LVM container | LVM |
| |-> /dev/vg01/root | Root partition | ext4 |
| |-> /dev/vg01/swap | Swap partition | swap |
+---------------------------+------------------------+-----------------------+</pre>

{{Warning|This will delete an existing partition table and make your data very hard to recover. If you want to dual boot, stop here and ask an expert.}}

Create a partition of approximately 100MB to boot from, then assign the rest of the space to your LUKS partition.

<pre># parted -a optimal
(parted) mklabel msdos
(parted) mkpart primary ext4 0% 100M
(parted) name 1 boot
(parted) set 1 boot on
(parted) mkpart primary ext4 100M 100%
(parted) name 2 crypto-luks</pre>

To view your partition table, type <code>print</code> while still in <code>parted</code>. Your results should look something like this:
<pre>(parted) print
Model: ATA TOSHIBA ******** (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
1 1049kB 99.6MB 98.6MB primary ext4 boot
2 99.6MB 1000GB 1000GB primary ext4</pre>

=== UEFI with GPT disklabel ===

We will be encrypting the whole disk except for the EFI system partition mounted at <code>/boot/efi</code>. This means GRUB2 will decrypt the LUKS volume and load the kernel from there, preventing someone with physical access to your computer from maliciously installing a rootkit (or bootkit) in your boot partition while your computer is not unlocked. The partitioning scheme will look like this:

<pre>+---------------------------+------------------------+-----------------------+
| Partition name | Partition purpose | Filesystem type |
+---------------------------+------------------------+-----------------------+
| /dev/sda1 | EFI system partition | fat32 |
| /dev/sda2 | LUKS container | LUKS |
| |-> /dev/mapper/lvmcrypt | LVM container | LVM |
| |-> /dev/vg01/root | Root partition | ext4 |
| |-> /dev/vg01/boot | Boot partition | ext4 |
| |-> /dev/vg01/swap | Swap partition | swap |
+---------------------------+------------------------+-----------------------+</pre>

{{Warning|This will delete an existing partition table and make your data very hard to recover. If you want to dual boot, stop here and ask an expert.}}

Create an EFI system partition of approximately 200MB, then assign the rest of the space to your LUKS partition.

<pre># parted -a optimal
(parted) mklabel gpt
(parted) mkpart primary fat32 0% 200M
(parted) name 1 esp
(parted) set 1 esp on
(parted) mkpart primary ext4 200M 100%
(parted) name 2 crypto-luks</pre>

== Optional: Overwrite LUKS Partition with Random Data ==

This should be done if your hard drive wasn't encrypted previously. It helps purge old, non-encrypted data and makes it harder for an attacker to work out how much data you have on your drive if they have access to the encrypted contents.

We'll use <code>haveged</code> as it is considerably faster than <code>/dev/urandom</code> when generating pseudo-random numbers (it's almost as high in throughput as <code>/dev/zero</code>), and is (supposedly) very close to truly random.

<pre># haveged -n 0 | dd of=/dev/sda2</pre>

== Encrypting the LVM Physical Volume Partition ==

To encrypt the partition that will later contain the LVM PV, you could either use the default settings (aes-xts-plain64 cipher with 256-bit key and Argon2 hashing with iter-time 2000ms), or you could use these settings which have added security with the trade-off being a non-noticeable decrease in performance on modern computers:

Default settings:

<pre># cryptsetup luksFormat /dev/sda2</pre>

Optimized for security:

<pre># cryptsetup -v -c serpent-xts-plain64 -s 512 --hash whirlpool --iter-time 5000 --use-random luksFormat /dev/sda2</pre>

If using Alpine v3.11 or later, and GRUB2 with encrypted /boot, the following should be used instead (because GRUB2 does not yet support LUKS2 containers):

<pre># cryptsetup luksFormat --type luks1 /dev/sda2</pre>

=== Converting between LUKS2 and LUKS1 ===

It is sometimes possible to convert a LUKS2 volume to a LUKS1 volume. First take a backup of the LUKS header that you can restore if anything goes wrong:

<pre># cryptsetup luksHeaderBackup /dev/sda2 --header-backup-file sda2-luks-header-backup</pre>

Then make sure all keys use <code>pbkdf2</code> by adding a new key with:

<pre># cryptsetup luksAddKey --pbkdf pbkdf2 /dev/sda2</pre>

Remove keys that use <code>argon2i</code> or <code>argon2id</code> with <code>cryptsetup luksRemoveKey /dev/sda2</code>. You can check the key information using <code>cryptsetup luksDump /dev/sda2</code>.

Now you can try the conversion, although it may not work.

<pre># cryptsetup convert /dev/sda2 --type luks1</pre>

== Creating the Logical Volumes and File Systems ==

Open the LUKS partition:

<pre># cryptsetup luksOpen /dev/sda2 lvmcrypt</pre>

Create the PV on <code>lvmcrypt</code>:

<pre># pvcreate /dev/mapper/lvmcrypt</pre>

Create the <code>vg0</code> LVM VG in the <code>/dev/mapper/lvmcrypt</code> PV:

<pre># vgcreate vg0 /dev/mapper/lvmcrypt</pre>

=== LV Creation for BIOS/MBR ===

This will create a 2GB swap partition and a root partition which takes up the rest of the space. This setup is for those who do not need to use the hibernate/suspend to disk state. If you do need to suspend to disk, create a swap partition slightly larger than the size of your RAM (change the size after <code># lvcreate -L</code>).

<pre># lvcreate -L 2G vg0 -n swap
# lvcreate -l 100%FREE vg0 -n root</pre>

The LVs created in the previous steps are automatically marked active. To verify, enter:

<pre># lvscan</pre>

=== LV Creation for UEFI/GPT ===

This will create a 2GB swap partition, a 2GB boot partition and a root partition which takes up the rest of the space. This setup is for those who do not need to use the hibernate/suspend to disk state. If you do need to suspend to disk, create a swap partition slightly larger than the size of your RAM (change the size after <code># lvcreate -L</code>).

<pre># lvcreate -L 2G vg0 -n swap
# lvcreate -L 2G vg0 -n boot
# lvcreate -l 100%FREE vg0 -n root</pre>

The LVs created in the previous steps are automatically marked active. To verify, enter:

<pre># lvscan</pre>

== Creating and Mounting the File Systems ==

Format the <code>root</code> and <code>boot</code> LVs using the ext4 file system:

<pre># mkfs.ext4 /dev/vg0/root</pre>

Format the swap LV:

<pre># mkswap /dev/vg0/swap</pre>

Before you can install Alpine Linux, you must mount the partitions and LVs. Mount the root LV to the <code>/mnt/</code> directory:

<pre># mount -t ext4 /dev/vg0/root /mnt/</pre>

Next format your boot partition, create a mount point, then mount it:

* If you're using BIOS and MBR:

<pre># mkfs.ext4 /dev/sda1
# mkdir -v /mnt/boot
# mount -t ext4 /dev/sda1 /mnt/boot</pre>

* If you're using UEFI and GPT:

<pre># apk add dosfstools
# mkfs.fat -F32 /dev/sda1
# mkfs.ext4 /dev/vg0/boot
# mkdir -v /mnt/boot
# mount -t ext4 /dev/vg0/boot /mnt/boot
# mkdir -v /mnt/boot/efi
# mount -t vfat /dev/sda1 /mnt/boot/efi</pre>

Lastly, activate your swap partition:

<pre># swapon /dev/vg0/swap</pre>

== Installing Alpine Linux ==

In this step you will install Alpine Linux in the <code>/mnt/</code> directory, which contains the mounted file system structure:

<pre># setup-disk -m sys /mnt/</pre>

The installer downloads the latest packages to install the base installation. Additionally, the installer automatically creates the entries for the mount points in {{Path|/etc/fstab}} file, which is currently mounted in the <code>/mnt/</code> directory.

{{Note|The automatic writing of the master boot record (MBR) fails in this step. Later, you'll manually write the MBR to the disk.}}

The swap LV is not automatically added to the <code>fstab</code> file. so we need to add the following line to the {{Path|/mnt/etc/fstab}} file:

<pre>/dev/vg0/swap swap swap defaults 0 0</pre>

Edit the {{Path|/mnt/etc/mkinitfs/mkinitfs.conf}} file and append the <code>cryptsetup</code> module to the <code>features</code> parameter:

<pre>features="... cryptsetup"</pre>

If you are using GRUB with an encrypted <code>/boot</code> you must add the <code>cryptkey</code> feature so that Alpine can use a keyfile for decryption on boot.

{{Note|Alpine Linux uses the <code>en-us</code> keyboard mapping by default when prompting for the password to decrypt the partition at boot time. If you changed the keyboard mapping in the temporary environment and want to use it at the boot password prompt, be sure to add the <code>keymap</code> feature to the list above.}}

{{Note|Check the output of <code>mkinitfs -L</code> and add the features necessary for your system to boot. You may need to add <code>kms</code> in order to see a password prompt at boot. You may also need: <code>usb</code>, <code>lvm</code>, <code>ext4</code>, <code>nvme</code>...}}

Rebuild the initial RAM disk:

<pre># mkinitfs -c /mnt/etc/mkinitfs/mkinitfs.conf -b /mnt/ $(ls /mnt/lib/modules/)</pre>

The command uses the settings from the <code>mkinitfs.conf</code> file set in the <code>-c</code> parameter to generate the RAM disk. The command is executed in the <code>/mnt/</code> directory and the RAM disk is generated using the modules for the installed kernel. Without setting the kernel version using the <code>$(ls /mnt/lib/modules/</code>) option, <code>mkinitfs</code> tries to generate the RAM disk using the kernel version installed in the temporary environment, which can differ from the latest one installed by the <code>setup-disk</code> utility.

== Installing a bootloader ==

To get the UUID of your storage device into a file for later use, run this command:

<pre># blkid -s UUID -o value /dev/sda2 > ~/uuid</pre>

{{Tip|To easily read the UUID into a file so you don't have to type it manually, open the file in <code>vi</code>, then type <code>:r /root/uuid</code> to load the UUID onto a new line.}}

=== Syslinux with BIOS ===

Install the Syslinux package:

<pre># apk add syslinux</pre>

Edit {{Path|/mnt/etc/update-extlinux.conf}} and append the following kernel options to the <code>default_kernel_opts</code> parameter, replacing <UUID> with the UUID of <code>/dev/sda2</code>:

<pre>default_kernel_opts="... cryptroot=UUID=<UUID of sda2> cryptdm=lvmcrypt"</pre>

The <code>cryptroot</code> parameter sets the ID of the device/partition that contains encrypted volumes, and the <code>cryptdm</code> parameter uses the name of the mapping we have already configured a few lines above.

We can also double check if <code>modules</code> and <code>root</code> are set correctly, eg:
<pre>
modules=sd-mod,usb-storage,ext4,cryptsetup,keymap,cryptkey,kms,lvm
root=UUID=<UUID of /dev/mapper/vg0-root>
</pre>

Because the <code>update-extlinux</code> utility operates only on the <code>/boot/</code> directory, temporarily change the root to the <code>/mnt/</code> directory and update the boot loader configuration:

<pre># chroot /mnt/
# update-extlinux
# exit</pre>

: Because we didn't mount <code>/dev</code> nor <code>/proc</code> inside our <code>/mnt/</code> chroot, some errors may occur when we run <code>update-extlinux</code> command. But you can most likely ignore these.

Write the MBR (without partition table) to the <code>/dev/sda</code> device:

<pre># dd bs=440 count=1 conv=notrunc if=/mnt/usr/share/syslinux/mbr.bin of=/dev/sda</pre>

=== Grub with UEFI ===

To avoid having to type your decryption password twice every boot (once for GRUB and once for Alpine), add a keyfile to your LUKS partition. The filename is important.

<pre># dd bs=512 count=4 if=/dev/urandom of=/mnt/crypto_keyfile.bin
# cryptsetup luksAddKey /dev/sda2 /mnt/crypto_keyfile.bin
</pre>

This keyfile is stored encrypted (it is in your LUKS partition), so its presence does not affect system security.

Mount the required filesystems for the Grub EFI installer to the installation:

<pre># mount -t proc /proc /mnt/proc
# mount --rbind /dev /mnt/dev
# mount --make-rslave /mnt/dev
# mount --rbind /sys /mnt/sys</pre>

Then run chroot and use <code>grub-install</code> to install Grub.

<pre># chroot /mnt
# source /etc/profile
# export PS1="(chroot) $PS1"</pre>

Install <code>GRUB2</code> for EFI and (optionally) remove syslinux:

<pre># apk add grub grub-efi efibootmgr
# apk del syslinux</pre>

Edit {{Path|/etc/default/grub}} and add the following kernel options to the <code>GRUB_CMDLINE_LINUX_DEFAULT</code> parameter, replacing <UUID> with the UUID of the encrypted partition (in this case, <code>/dev/sda2</code>):

<pre>cryptroot=UUID=<UUID> cryptdm=lvmcrypt cryptkey</pre>

The <code>cryptroot</code> parameter sets the ID of the device/partition that contains encrypted volumes, and the <code>cryptdm</code> parameter uses the name of the mapping we configured a few lines above.
The <code>cryptkey</code> parameter indicates the existence of the file <code>/crypto_keyfile.bin</code> you created previously.

To enable GRUB to decrypt LUKS partitions and read LVM volumes add:

<pre>GRUB_PRELOAD_MODULES="luks cryptodisk part_gpt lvm"</pre>

If using Alpine v3.11 or later, <code>GRUB_ENABLE_CRYPTODISK=y</code> should also be added to {{Path|/etc/default/grub}}.

<pre># (chroot) grub-install --target=x86_64-efi --efi-directory=/boot/efi
# (chroot) grub-mkconfig -o /boot/grub/grub.cfg
# (chroot) exit</pre>

== Unmounting the Volumes and Partitions ==

Unmount the <code>/mnt/</code> partitions, deactivate the LVM volumes, close the LUKS partition and reboot:

<pre># cd
# umount -l /mnt/dev
# umount -l /mnt/proc
# umount -l /mnt/sys
# umount /mnt/boot/efi
# umount /mnt/boot
# swapoff /dev/vg0/swap
# umount /mnt
# vgchange -a n
# cryptsetup luksClose lvmcrypt
# reboot</pre>

= Troubleshooting =

== General Procedure ==

In case your system fails to boot, you can verify the settings and fix incorrect configurations.

Reboot and do the steps in [[#Preparing_the_Temporary_Installation_Environment|Prepare the temporary installation environment]] again.

Setup the LUKS partition and activate the LVs:

<pre># cryptsetup luksOpen /dev/sda2
# vgchange -ay</pre>

[[#Creating_and_Mounting_the_File Systems|Mount the file systems]]

Verify that you run the steps described in the [[#Installing_Alpine_Linux|Installing Alpine Linux]] section correctly. Update the configuration if necessary, unmount the partitions, then reboot.

== System can't find boot device ==

* GPT partition table on a motherboard that runs BIOS instead of UEFI
* running an MSDOS/MBR/Syslinux install without enabling legacy boot mode in the UEFI settings

== I see "can not mount /sysroot" during boot ==

* incorrect device UUID
* missing module in <code>/mnt/etc/update-extlinux.conf</code> or <code>/mnt/etc/mkinitfs/mkinitfs.conf</code>

== Secure boot ==

If secure boot complains of an unsigned bootloader, you can either disable it or adapt [https://wiki.archlinux.org/index.php/Secure_Boot this] guide to sign GRUB. If you're using Syslinux, then secure boot should be automatically disabled when you enable legacy boot mode.

= Hardening =

* To harden, you should disable DMA[https://old.iseclab.org/papers/acsac2012dma.pdf] and install a hardened version of AES (TRESOR[https://www1.informatik.uni-erlangen.de/tresor] or Loop-Amnesia[http://moongate.ydns.eu/amnesia.html]) since by default cryptsetup with luks uses AES by default.
* Disable DMA in the BIOS and set the password for the BIOS according to Wikipedia.[https://en.wikipedia.org/wiki/DMA_attack]
* Blacklist kernel modules that use DMA and any unused expansion modules (FireWire, CardBus, ExpressCard, Thunderbolt, USB 3.0, PCI Express and hotplug modules) that use DMA.

= Mounting additional encrypted filesystems at boot =

If you would like other encrypted LUKS partitions to be decrypted and mounted automatically during boot, for example if you have <code>/home</code> on a separate physical drive, some extra steps are required.
{{Note|This does not apply for volumes
within your main encrypted partition <code>/dev/sda2</code>}}
For the purposes of these instructions we will say <code>/dev/sdb1</code> contains an LVM volume that should be mounted at <code>/home</code>.

Create a keyfile and add it to the LUKS partition:

<pre># dd bs=512 count=4 if=/dev/urandom of=/root/crypt-home-keyfile.bin
# cryptsetup luksAddKey /dev/sdb1 /root/crypt-home-keyfile.bin
</pre>

Alpine, like Gentoo, uses the <code>dmcrypt</code> service rather than <code>/etc/crypttab</code>. Add the following lines to <code>/etc/conf.d/dmcrypt</code>:

<pre>target=crypt-home
source='/dev/sdb1'
key='/root/crypt-home-keyfile.bin'
</pre>

Add an entry to <code>/etc/fstab</code>, changing <code>vg1</code> to the name of your LVM volume group:

<pre>/dev/vg1/home /home ext4 rw,relatime 0 2</pre>

Enable the dmcrypt and lvm services to start on boot:

<pre># rc-update add dmcrypt boot
# rc-update add lvm boot
</pre>

After a reboot the partition should be decrypted and mounted automatically.

= See also =
*[[Bootloaders]]
*[[Alpine setup scripts]]
*[[Installing on GPT LVM]]
*[[Setting up LVM on GPT-labeled disks]]
*[[Setting up disks manually]]
*https://wiki.gentoo.org/wiki/Syslinux
*https://wiki.gentoo.org/wiki/GRUB2
*https://wiki.archlinux.org/index.php/Syslinux
*https://wiki.archlinux.org/index.php/GRUB
*https://wiki.gentoo.org/wiki/Sakaki's_EFI_Install_Guide
*https://battlepenguin.com/tech/alpine-linux-with-full-disk-encryption/
*https://wiki.gentoo.org/wiki/Dm-crypt

[[Category:Storage]]
[[Category:Security]]

APKBUILD Reference

2021-11-29T11:49:31Z

Eddsalkield: Add riscv64 to arches

APKBUILDs are the scripts that are created in order to build Alpine packages using the [[abuild]] tool.

See [[aports]] for details on Alpine's official ports repository.

This page is intended to serve as a reference for creating APKBUILDs; if this is your first time creating a package for Alpine Linux, please see [[Creating an Alpine package]].

= Legend =
The following notes will assist you in understanding this document.

In description text:
* If a variable is not prefixed with a ''$'', it will be represented by italics (i.e., ''srcdir'' ).
* Functions will also be represented by italics, but will also end with a pair of parentheses (i.e., ''build()'' ).
* Shell commands will be represented <code>like this</code>.

= Variables =
{{Note|Variables that contain a path (e.g. ''$srcdir'' and ''$pkgdir'') should always be quoted using double quotes (i.e., ''"$srcdir"''). This is done to prevent things from breaking, should the user have the APKBUILD in a directory path that contains spaces.}}
{{Note|All arbitrary variable and function names should be prefixed with an underscore character ( _ ) to avoid name clashes with the internals of abuild (for example, ''_luaversions'').}}

== abuild-defined variables ==
The following variables are defined by abuild:

==== startdir ====
: The directory where the APKBUILD script is.
==== srcdir ====
: The directory where sources, from the ''source'' variable, are downloaded to and unpacked to.
==== pkgdir ====
: This directory should receive the files for the main package. For example, a normal [http://en.wikipedia.org/wiki/GNU_build_system autotools] package would have <code>make DESTDIR="$pkgdir" install</code> in the ''package()'' function.
==== subpkgdir ====
: This directory should receive the files for a subpackage. This variable should only be used from subpackage functions.
==== builddir ====
: This variable should point to the directory inside the ''srcdir'' where the main package source is unpacked. This is typically ''$srcdir/$pkgname-$pkgver''. It’s used by the default ''prepare()'' function as a working directory when applying patches.

== User-defined variables ==
The following variables should be defined by the user:
==== arch ====
: Package architecture(s) to build for. Can be one or several seperated by whitespace of: '''[[x86]], [[x86_64]], [[armv7]], [[armhf]], [[aarch64]], [[ppc64le]], [[s390x]], [[mips64]], [[riscv64]], all''', or '''noarch''', where '''all''' means all architectures, and '''noarch''' means it's architecture-independent (e.g., a pure-python package). Architectures can be negated using the ! character to exclude them from the list of supported architectures. E.g. '''arch="all !ppc64le"''' means that the package is allowed to be built on all architectures but the ppc64le architecture.
: {{Tip|To determine if your APKBUILD can use '''noarch''': First specify '''all''' and then build the package by executing <code>abuild -r</code>. Watch the output towards the end for warnings saying that '''noarch''' can be used. If the main package and all subpackages, if you have any subpackages, give a warning saying that '''noarch''' can be used, then you can use '''noarch'''.}}

==== depends ====
: Run-time dependency package(s) that are not shared-object dependencies. Shared objects dependencies are auto-detected and should not be specified here. To specify a conflicting package, add the package name prefixed with a '!'.

==== depends_dev ====
: Run-time dependency package(s) for the '''$pkgname-dev''' subpackage.

: {{Note|From ncopa on IRC: To find out if you need to add a package to depends_dev have a look at *requires* in usr/lib/pkgconfig/*.pc. With libtool it gets more complicated, but we should delete the .la files. Also check if there are any /usr/bin/*-configure #!/bin/bash #!/usr/bin/perl or Python. Sometimes scripts or similar are generated at build time (i.e autoconf automake) then you normally don't need add those to depends_dev. You can also just add all -dev makedepends to depends_dev but it will slow the build process a little bit (more build dependencies).}}

==== depends_doc ====
: Run-time dependency package(s) for the '''$pkgname-doc''' subpackage.

==== depends_openrc ====
: Run-time dependency package(s) for the '''$pkgname-openrc''' subpackage.

==== depends_libs ====
: Run-time dependency package(s) for the '''$pkgname-libs''' subpackage.

==== depends_static ====
: Run-time dependency package(s) for the '''$pkgname-static''' subpackage.

==== checkdepends ====
: Dependencies that are only required during the check phase, they are only installed if the check option is enabled

==== giturl ====
:Git repository from which <code>abuild checkout</code> checks out. You can checkout a specific branch in git by adding <code>-b $branch</code>.
==== install ====
: There are 6 different types of install scripts. Install scripts are named '''$pkgname.action''', where '''action''' can be: '''pre-install, post-install, pre-upgrade, post-upgrade, pre-deinstall''', or '''post-deinstall'''. For example, if ''pkgname'' is set to '''mypackage''' and ''install'' is set to '''$pkgname.post-install''', then a script named '''mypackage.post-install''' must exist along-side the APKBUILD.
<blockquote>{{Note|Always use <code>/bin/sh</code> for the command-line interpreter on the [http://en.wikipedia.org/wiki/Shebang_%28Unix%29 shebang line] of your install scripts.}}</blockquote>

The following are the different types of install scripts in detail:

===== $pkgname.pre-install =====
: This script is executed ''before installing'' the package. Typical use is when the package needs a group and a user to be created. For example:
<blockquote><pre>
#!/bin/sh

addgroup -S clamav 2>/dev/null
adduser -S -D -H -s /bin/false -G clamav -g clamav clamav 2>/dev/null

exit 0
</pre>
{{Note|If the script exits with a failure (e.g., if the user already exists), the package will not be installed and <code>apk</code> will exit with failure, hence the <code>exit 0</code> at the end.}}</blockquote>

===== $pkgname.post-install =====
: This script is executed ''after installing'' the package.

===== $pkgname.pre-upgrade =====
: This script is executed ''before upgrading/downgrading/reinstalling'' the package. Note that exiting with failure will not cause apk to exit with failure, but will mark the package as broken.

===== $pkgname.post-upgrade =====
: This script is executed ''after upgrading/downgrading/reinstalling'' the package.

===== $pkgname.pre-deinstall =====
: This script is executed ''before uninstalling'' the package.
: {{Note|If the script exits with failure, <code>apk</code> will not uninstall the package.}}

===== $pkgname.post-deinstall =====
: This script is executed ''after uninstalling'' the package.

==== install_if ====
:install_if can be used when a package needs to be installed when some packages are already installed or are in the dependency tree. It works in reverse to the ''recommends'' feature, that other package managers provide.

: Typically this is used in a subpackage that should provide files which make sense with another package. For example:
<blockquote><pre>
...
subpackages="$pkgname-bash-completion:bashcomp:noarch"
...
bashcomp() {
pkgdesc="Bash completions for $pkgname"
install_if="$pkgname=$pkgver-r$pkgrel bash-completion"

install -Dm644 "$builddir"/doc/bash_completion/aria2c \
"$subpkgdir"/usr/share/bash-completion/completions/_aria2c
}
</pre>
From the aria2c APKBUILD. Note that the custom bashcomp() function is only necessary, because the files are not in /usr/share/bash-completion.
</blockquote>

:In general, install_if should only be used with '''at least one versioned constraint'''. Otherwise, a package that was implicitly installed by install_if and then removed from the binary repositories, will not get purged with <code>apk upgrade</code>. [https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10720#note_121298]

==== license ====
: License(s) for the package, for example <code>GPL-3.0-or-later</code>, <code>BSD-2-Clause</code> or <code>MIT</code> [[Creating_an_Alpine_package#license|(details)]].

==== makedepends ====
: Build-time dependency package(s).
==== md5sums/sha256sums/sha512sums ====
: Checksums for the files/URLs listed in ''source''. The checksums are normally generated and updated by executing <code>abuild checksum</code> and should be the last item in the APKBUILD.

New packages should use only sha512sums.

==== options ====
: Build-time options for the package.

: {| class="wikitable"
! Option
! Description
|-
| <code>!archcheck</code>
| Do not try to verify that the architecture of the binary files is the same architecture as abuild should build for. One example where it makes sense to set this are packages with firmware files, that get executed on another CPU (such as WiFi firmware).
|-
| <code>!check</code>
| Do not try to run the <code>check()</code> function. Please always add a short comment after the <code>!check</code> about why it's disabled. [https://github.com/alpinelinux/aports/pull/2322#discussion_r142545300] Creating a very simple check function, that calls <code>program --version</code> is worse than disabling tests completely because it gives the false impression that the package is thoroughly tested with the testsuite from upstream. [https://github.com/alpinelinux/aports/pull/7326#discussion_r278797457]
|-
| <code>checkroot</code>
| Specifies that the package's test suite will be run in ''fakeroot''. This is necessary for some test suites which fail when run as non-root.
|-
| <code>net</code>
| Allows network access when run in ''rootbld''.
|-
| <code>!strip</code>
| Avoid stripping symbols from binaries.
|-
| <code>suid</code>
| Allow [https://en.wikipedia.org/wiki/Setuid setuid] binaries.
|-
| <code>!tracedeps</code>
| Do not automatically find dependencies (e.g. by using <code>ldd</code> to find dynamic libraries, which the resulting binary links against).
|-
| <code>chmod-clean</code>
| Make all files writable in the src/ directory. Useful for packages that make files read-only in the process of building packages (go modules).
|-
| <code>toolchain</code>
| Don't warn when g++ is in makedepends
|-
| <code>!dbg</code>
| Don't create debugging subpackage
|-
| <code>ldpath-recursive</code>
| Scan directories recursively when creating .so providers
|-
| <code>!spdx</code>
| Do not check if the license= field has a SPDX compliant license
|-
| <code>textrels</code>
| Don't error out when text relocations are found
|-
| <code>charset.alias</code>
| Don't error out if /usr/lib/charset.alias is found
|-
| <code>libtool</code>
| Don't delete libtool .la files
|-
| <code>!fhs</code>
| Don't enforce checks on path that follow the FHS
|}

==== pkgdesc ====
: A brief, one-line description of what the package does.

: Here's an example from the OpenSSH client package:
: <pre>pkgdesc="Port of OpenBSD's free SSH release - client"</pre>
==== pkggroups ====
: System group(s) to be created during build-time. System group(s) should also be created in the '''[[APKBUILD Reference#.24pkgname.pre-install|$pkgname.pre-install]]''' script, so that the system group(s) are also created prior to package installation for run-time use.
==== pkgname ====
: The name of the package. All letters should be lowercase.
: {{Note|When creating an APKBUILD of a module or library for another package, we use some common package prefixes, such as: ''lua-'', ''perl-'', ''php-'', and ''py-''. Search aports for other common prefixes.}}

==== pkgrel ====
: Alpine package release number. Starts at 0 (zero). Always increment ''pkgrel'' when making updates to an aport; reset ''pkgrel'' to 0 (zero) when incrementing ''pkgver''.
==== pkgusers ====
: System user(s) to be created during build-time. System user(s) should also be created in the '''[[APKBUILD Reference#.24pkgname.pre-install|$pkgname.pre-install]]''' script, so that the system user(s) are also created prior to package installation for run-time use.
==== pkgver ====
: The version of the software being packaged. Format for valid versions: <code>{digit}{.digit}...{letter}{_suf{#}}...{-r#}</code> [https://git.alpinelinux.org/cgit/apk-tools/tree/src/version.c#n17]
: A Suffix <code>suf</code> in the above format can be one of the following to indicate that the release is ''less recent'' than the version without the suffix: <code>alpha</code>, <code>beta</code>, <code>pre</code>, <code>rc</code> [https://git.alpinelinux.org/cgit/apk-tools/tree/src/version.c#n75]
: These are for indicating ''more recent'' releases: <code>cvs</code>, <code>svn</code>, <code>git</code>, <code>hg</code>, <code>p</code> [https://git.alpinelinux.org/cgit/apk-tools/tree/src/version.c#n76]
: All other suffices are invalid. To package a specific git commit, the date of the commit gets appended to the latest release, e.g. <code>1.0.0_git20180204</code>.

==== provides ====
: List of package names (and optionally version info) this package provides.

: If package with a version is provided (provides='foo=1.2') apk will consider it as an alternate name and it will automatically consider the package for installation by the alternate name, and conflict with other packages having the same name, or provides.

: If version is not provided (provides='foo'), apk will consider it as virtual package name. Several package with same non-versioned provides can be installed simultaneously. However, none of them will be installed by default when requested by the virtual name - instead, error message is given and user is asked to choose which package providing the virtual name should be installed.
==== provider_priority ====
: A numeric value which is used by apk-tools to break ties when choosing a virtual package to satisfy a dependency. Higher values have higher priority. The primary use case is to specify the primary package that satisfies a virtual (provider).
==== replaces ====
: Allow this package to be installed at the same time as the listed packages, even if they have conflicting files. The files from this package will override ("take over") the conflicting files.

: This can be used to override config files with "policy packages" [https://gitlab.alpinelinux.org/alpine/apk-tools/-/commit/89d003f8c2e5a92655ee778f7bfa5c0e85ddbed4].

: Another use case is renaming packages (or moving files from one package to another): "replaces" will avoid the file conflict error that apk reports if it happens to install the new package before uninstalling the old package [https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10724#note_132872].

: A common misconception is that "replaces" is used to replace packages (like in [https://wiki.archlinux.org/index.php/PKGBUILD#replaces PKGBUILD]). This is not the case, it is only for solving file conflicts. To let apk consider installing one package instead of another one, refer to [[#provides|provides]] (with the version).

==== replaces_priority ====
: The priority of the replaces. If multiple packages replace files of each other, then the package with the highest ''replaces_priority'' will win.

==== source ====
: The source variable is not only used to list the remote source files to fetch, it is also used to list the local files that abuild will need in order to build the apk. Examples of such local files include: init.d files, conf.d files, install files (see [[APKBUILD Reference#install|install variable]]), patches, and all other necessary files.

: Here are few things to note:

:* When you are finished adding local and/or remote files to ''source'', you can execute the following command to add their checksums to the APKBUILD file:
:: {{Cmd|abuild checksum}}
:: {{Note|When later updating the content of ''source'', or updating a file that is listed in ''source'', you must also update their checksums again with the same command.}}

:* When the remote file is hosted at SourceForge, it's best to specify the special mirrors link used by SourceForge:
:: <pre>http://downloads.sourceforge.net/software/software-$pkgver.tar.gz</pre>
:: (or similar depending on the package).

:* You can set target filename (eg 'save as...') by prefixing the URI with ''filename::''. This is useful when the remote filename is not specified in the URI (ie, does not end in '/software-1.0.tar.gz'), such as:
:: <pre>http://oss.example.org/?get=software&ver=1.0</pre>
:: or when the filename is braindead, like githubs' download tags:
:: <pre>https://github.com/software/software/archive/v$pkgver.tar.gz</pre>
:: The above two examples needs a target filename prefix:
:: <pre>$pkgname-$pkgver.tar.gz::http://oss.example.org/?get=software&ver=$pkgver</pre>
:: and:
:: <pre>$pkgname-$pkgver.tar.gz::https://github.com/software/software/archive/v$pkgver.tar.gz</pre>

:* abuild currently supports the following protocols for remote file retrieval:
:** http
:** https
:** ftp

:* abuild currently supports the following archive types/archive file extensions:
:** .tar (only in Alpine >= 2.5)
:** .tar.gz / .tgz
:** .tar.bz2
:** .tar.lz (only in Alpine >=3.7)
:** .tar.lzma
:** .tar.xz
:** .zip

:* <code>source</code> should only include variables that change often like <code>pkgver</code> or a commit ID. CI will warn you if you include <code>pkgname</code> in source. Other variables like for example <code>_pkgname</code> or <code>_pyname</code> do not belong in <code>source</code> either.

==== subpackages ====
: Subpackages built from this APKBUILD. abuild will parse this variable and try to find a subpackage split function. The split function must ''move'' files that do not belong in the main package, from ''$pkgdir'' to ''$subpkgdir''. Files and directories can also be ''copied'' from ''$startdir'' and ''$srcdir'' to ''$subpkgdir''.

: The split function can be specified in 1 of 3 different methods:
:# subpkgname:'''splitfunc'''
:# $pkgname-'''splitfunc'''
:# '''splitfunc'''

: {{Note|Split function names '''cannot''' use hyphens; use the first method above if the subpackage name contains a hyphen (-) character, like this: ''subpkg-name:subpkg_name'', where <code>subpkg-name</code> is the name of the '''subpackage''' and <code>subpkg_name</code> is the name of the '''subpackage's split function'''.}}

: {{Tip|For more information, see the [[APKBUILD_examples:Subpackages|Subpackages example]].}}

==== triggers ====
: Apk-tools can "monitor" directories and execute a trigger if any package installed/uninstalled any file in the monitored dir. The triggers are always executed after the apk action (install, uninstall, upgrade).

: The triggers are specified in the format: ''scriptname''=''pathlist'' where ''scriptname'' is the (sub)package name + .trigger suffix and pathlist is : separated list of the dirs to monitor.

: The '''triggers''' variable must include the triggers for subpackages too if they have any.

: It is possible to use wildcards (*) in the dir list.

==== url ====
: The homepage for the package. This is to help users find upstream documentation and other information regarding the package.

==== langdir ====
: Path to where the language files are located for the '''-lang''' subpackage, defaults to '''/usr/share/locale'''

==== pcprefix ====
: Prefix all provides derived from parsing pkg-config Requires: with the value in this variable, example: ''''pcprefix="foo:"''' will produce '''pc:foo:bar'''

==== sonameprefix ====
: Prefix all provides derived from parsing shared objects with the value in this variable, example: '''sonameprefix="foo"''' will produce '''so:foo:bar.so.X'''

= Functions =
{{Note|All functions that are not ''prepare()'', ''build()'', ''check()'' and ''package()'' should consider the current working directory as undefined, and should therefore use the [[APKBUILD Reference#abuild-defined_variables|abuild-defined directory variables]] to their advantage.}}

sanitycheck() -> clean()-> fetch() -> verify() -> unpack() -> prepare() -> mkusers() -> build() -> check() -> package() -> subpackages() -> language packs -> apk -> cleanup()

== abuild-defined functions ==
The following functions are provided by abuild and can be overridden, but it is strongly discouraged on code review for some functions:

==== fetch() ====
: Downloads remote sources listed in ''source'' to ''SRCDEST'' (''SRCDEST'' is configured in ''/etc/abuild.conf'') and creates symlinks in ''$srcdir''.
==== unpack() ====
: unpack() will call default_unpack().

: [https://github.com/alpinelinux/abuild/blob/v3.1.0/abuild.in#L403 default_unpack()] unpacks .tar, .tgz, .tar.gz, .tar.lz (only available in Alpine >=3.7), .tar.bz2, .tar.lzma, .tar.xz, and .zip archives from a symlink in ''$srcdir'' associated with ''$SRCDEST'' (or distfiles folder) resulting in an unpacked folder in ''$srcdir''.

==== dev() ====
: Subpackage function for the '''$pkgname-dev''' package is used to collect developer files and folders for use in other packages in the compilation process nothing more. Without specifying a custom ''dev()'' function, abuild will call its internal ''dev()'' function, which in turn calls default_dev().

: ''[https://github.com/alpinelinux/abuild/blob/v3.1.0/abuild.in#L1605 default_dev()]'' will move any ''include'' folder and folders containing ''*.[acho]'' (static archive, c source, c header file, object file), ''*.prl'' file extension patterns in ''"$pkgdir"/{lib,usr}'' to ''"$subpkgdir"/{lib,usr}'' recursively; and ''*.so'' files from ''"$pkgdir"/{lib,usr/lib}'' to ''"$subpkgdir"/{lib,usr/lib}''. It will also scan and move ''usr/{include,lib/{pkgconfig,cmake,qt*/mkspecs},share/{aclocal,gettext,vala/vapi,gir-[0-9]*,qt*/mkspecs},bin/*-config}}'' developer only folders in ''$pkgdir'' and transfer them to ''$subpkgdir''.

: In general, default_dev() will support packages that share pkg-config, C programming language API, shared and static libraries, Autotools, gettext, Vala programming language bindings, Python GObject introspection, a provided custom pkg-config like command (*-config), Qt, and CMake. If you have packages that have C++, other languages, other build system, etc; you need to manually move those developer files only if they are to be used in other packages.

: '''Important''': For default_dev() to be called as in no dev(), you need to explicitly add subpackages="$pkgname-dev".

==== doc() ====
: Subpackage function for the '''$pkgname-doc''' package whose job is only to collect documentation folders from $pkgdir nothing more. Without specifying a custom ''doc()'' function, abuild will call its internal ''doc()'' function, which in turn calls default_doc().

: ''[https://github.com/alpinelinux/abuild/blob/v3.1.0/abuild.in#L1519 default_doc()]'' will move ''"$pkgdir"/usr/share/{doc,man,info,html,sgml,licenses,gtk-doc,ri,help}'' to ''$subpkgdir''.

: Overriding this function is strongly discouraged. Packaging docs should be done in the package() function while letting abuild automatically collect the doc folders.

: '''Important''': For default_doc() to be called as in no doc(), you need to explicitly add subpackages="$pkgname-doc".

==== openrc() ====
: Subpackage function for the '''$pkgname-opernc''' package whose job is to collect OpenRC service files that are in /etc/init.d and /etc/conf.d.

: ''[https://github.com/alpinelinux/abuild/blob/v3.1.0/abuild.in#L1661 default_openrc()]'' will move ''"$pkgdir"/etc/{conf,init}.d'' to ''$subpkgdir''.

: Overriding this function is strongly discouraged. Packaging OpenRC service definitions should be in the package() function while letting abuild automatically collect the openrc folders.

: '''Important''': for default_openrc() to be called as in no openrc(), you need to explicitly add subpackages="$pkgname-openrc".

==== static() ====
: Subpackage function for the '''$pkgname-static''' package whose job is to collect static libraries that are stored in /lib and /usr/lib.

: ''[https://github.com/alpinelinux/abuild/blob/v3.4.0_rc4/abuild.in#L1748 default_static()]'' will move all static libraries (files ending with .a) from ''"$pkgdir"/lib'' and ''"$pkgdir"/usr/lib'' to their equivalents in ''$subpkgdir''.

: Overriding this function is strongly discouraged. Packaging static libraries should be done in the package() function while letting abuild automatically collect the static libraries.

: '''Important''': for default_static() to be called as in no static(), you need to explicitly add subpackages="$pkgname-static".

==== snapshot() ====
: '''Optional'''. For live APKBUILDs or those with a _cvs, _svn, _git, _hg in their version number, you should create a snapshot function only if there is no download link to an archive file (.zip, .tar.gz, ...) to the commit/hash/tag. The purpose of the snapshot function is to create an archive of the source code so that the package source code is deterministic, and it doesn't waste time to fetch the source code but bypasses the download step after snapshotting. Those that download the source code from a git repository will follow head or the latest change to the source code. It is better to archive the source code as a zip / tar.gz / tar.bz2 up to the commit or the tag which you are trying to build a package. If it is not deterministic or not every part of the code frozen in time for every dependency and the main project, then the patches will fail or the package may fail to compile when you revisit the package months or years to backport a patch.

: The default [https://github.com/alpinelinux/abuild/blob/v3.1.0/abuild.in#L2310 snapshot()] function has variables associated with it:
:* $disturl - the base-url of the place to autoupload the snapshot
:* $svnurl - Subversion repository
:* $giturl - Git repository

: The default snapshot() can only support one repository. It is better to override it if there are multiple repositories involved in your package. CVS, Mercurial (hg), and alternative version control systems must override the default snapshot().

: See [[APKBUILD_examples:Git_checkout]] to how to use it with git. It takes 2-3 general steps. Clone the repository; check it out at a specific revision/commit or tag; then you use an archiver to dump it in the ''$SRCDEST'' variable which points to the distfiles folder and the base path to the full path to the archive that you want to create. You do this for every internal dependency that the package pulls.

: After you have created your snapshot function, you use <code>abuild snapshot</code> to run it.

: The archives produced by the snapshot will be saved in ''/var/cache/distfiles'' or whatever you set for ''$SRCDEST''. You may need to create symlinks to the archive if the archive is not saved to the Alpine server.

: After you snapshot it, you need to produce the checksums with <code>abuild checksum</code> to use it in the APKBUILD creation process.

: This feature is available since Alpine >=2.6.

==== default_prepare() ====

: Before build preparation it handles set of patches inside <code>$srcdir</code> and prints failed ones.

== User-defined functions ==
The following functions should be defined by the user:

==== prepare() ====
: {{note|Please adjust old APKBUILDs, which still have a ''prepare()'' function that does the same as the ''default_prepare()'' when you edit them anyway.}}
: '''''Optional''.''' Used for build preparation: patches, etc, should be applied here. When you don't specify a custom ''prepare()'', the built-in ''default_prepare()'' from abuild will be used. It applies patches already (always prepare them in the <code>-p1</code> format), so '''usually it makes sense to not create a custom ''prepare()'' function at all!''' If you do create one, call ''default_prepare()'' inside it:

: Before default_prepare gets called, you can define ''patch_args'' to supply the argument to the patch command in global scope then throw away prepare() so it is unnecessary to use the old template code floating around to patch. patch_args and autopatching is only available in Alpine >=3.4. See [[Creating_an_Alpine_package#Patches]] to fix the patch that uses a different patch level (-pX).

<pre>
prepare() {
default_prepare
# your custom code here
}
</pre>

==== build() ====
: '''Required.''' This is the compilation stage. This function will be called as the current user (unless the ''package()'' function is missing - for compatibility reasons). If no compilation is needed, this function can contain a single line: <code>return 0</code>

: To enable or disable CFLAGS, CXXFLAGS, CMake with option, or configure option per arch, use the CARCH variable:
<pre>
local cmakeoptions=
case "$CARCH" in
aarch64*|arm*|ppc64le|x86|s390x) cmakeoptions="$cmakeoptions -DWITH_OPENMP=OFF" ;;
x86_64) cmakeoptions="$cmakeoptions -DWITH_OPENMP=ON" ;;
*) msg "Unable to determine architecture from (CARCH=$CARCH)" ; return 1 ;;
esac
</pre>
: The block can be used in other parts of the APKBUILD even in global.

==== check() ====
: '''Required if functionality exists.''' This function is called right after the build stage. It should check that the packaged thing is actually working, typically by running (integration) tests, if provided by upstream. If there’s no (easy) way how to test the package, you can declare that it does not want to use ''check()'' by adding "!check" into the ''options'' variable (<code>options="!check"</code>).

: default_check() does nothing. You need to manually explicitly call the unit tests or test suite yourself. When you run the test, the program should return with an exit code of 0, indicating the tests were a success. Unit tests or test suites will do feature tests, per function correctness check, fuzz testing, benchmarks.

: A package may also require additional testing frameworks packages that are external dependencies. You should add those to the ''checkdepends='' in Alpine >=3.6 or ''makedepends='' for older for backporters. If the testing framework is not available, you need to create a package for it. If it requires a specific version of a testing framework, consider making it an internal dependency or a new package with a package name containing the major and minor version number like the python packages.

: Generally speaking, you should define the check functions for libraries, large programs like web browsers, or compilers and interpreters, cryptographic/security/anonymity stuff, mission critical stuff, PCI compliance/money/accounting software, server software with a lot of stakeholders or consumers. Soon for the new policy change will have virtually '''all packages with testing capabilities be required to have a working and defined check() function'''.

: There are times when the unit tests do not work, just because the test itself is broken, new unimplemented feature, external factors not taken into consideration, unbundling path differences, breakage caused by ccache, missing test dependency or version mismatch dependency as in python2 vs python3, test scripts only work for particular language implementation like only supporting python2 but not python3 having used the 2to3 conversion script. If a unit test is known not to work, you may need to patch it to omit that test or fix it; but, certain tests should not be disabled if it is important. You may need to alter the references to uncompiled internal dependencies to work with the external dependencies instead. For ccache, you can either disable it or remove it from the PATH environmental variable before running tests.

{{Note|Tests for graphical applications and toolkits might work on a X11 user setup but will fail on the server unless run with xvfb-run.}}

: If you don't add the ''check()'' and the ''options='', this is what you will see:

>>> WARNING: py-webtest*: APKBUILD does not run any tests!
Alpine policy will soon require that packages have any relevant testsuites run during the build process.
To fix, either define a check() function, or declare !check in $options to indicate the package does not have a testsuite.

: If you do not do a check or disable it, you must state there is no testsuite in comment form (#) next to options="!check" for the code reviewers.

: To run test suite with autotools do:

make check

: To run the test suite with python setuptools:

python2 setup.py test
python3 setup.py test

: For python it should be '''test''' not check. Check for python setuptools will check the packaging metadata fields[https://docs.python.org/3/distutils/examples.html#checking-a-package] only but not run the unit tests. There should be verbose output also. The dependencies for the tests are found in test_require in the setup.py.

: If it says <code>Ran 0 tests in 0.000s</code> that is not acceptable. check() will say it was good but it is not actually correct. It needs to run the test suite with an alternative method like <code>tox -e py27,py36</code> if you see a tox.ini file.

: You want to do it for each implementation to ensure that the API calls are correct per implementation but ncopa said it was just fine with python3.

: If there is a circular dependency for the checkdepends=, you need to disable the check and put the reason next to <code>options="!check"</code> that there is a circular dependency. You should disable it for the package that package that is least important or least security risk. The other solution is to make the conflicting dependency an internal dependency but making sure that it doesn't pull it at check time. This way they can both preform tests properly.

==== package() ====
: '''Required.''' This is the packaging stage. Here, the built application and support files should be installed into '''$pkgdir'''. If this is a metapackage, this function can contain a single line: <code>mkdir -p "$pkgdir"</code>

{{Note|Building in fakeroot will reduce performance for parallel builds dramatically. It is for this reason that we split the build and package process into two separate functions.}}

= Examples =
The [[APKBUILD examples]] page will assist you in understanding how to create an APKBUILD.

= Version =

This document assumes abuild for Alpine Edge. For older releases of abuild, some of these features may not be available if you are using an older release. A link to the implementation is linked for researchers and backporters.

For more information see [[APKBUILD_versions]].

[[Category:Development]]

Creating an Alpine package

2021-11-25T19:48:38Z

Eddsalkield: /* Code review */ s/sudo/doas

{{TOC right}}

== Requirements ==

To build a package for Alpine Linux you need an Alpine Linux installation. Check the [[Installation]] page to see all available installation options.

== Setup your system and account ==
{{:Include:Setup_your_system_and_account_for_building_packages}}

== Getting some help ==

It might be wise to start by checking what the [[Abuild|abuild]] program can/cannot do.

{{Cmd|abuild -h}}

For real help, you can also go on OFTC's #alpine-devel on IRC.

A reference for APKBUILD files is available as a man page in the 'abuild-doc' package:

{{Cmd|man APKBUILD}}

== Creating an APKBUILD file ==

=== Use a template APKBUILD ===

To create the actual APKBUILD file {{Pkg|newapkbuild}} can serve you a template to start with. It will create a directory with the given package name, place an example/template APKBUILD file to the given directory, and fill some variables if those are provided. Please check the [[Package_policies| package policies]] page about naming details.

If you doubt to which repository your package belongs to you can safely use '''testing'''. Building package in your aports/testing directory is not mandatory but this way the package is already at the right place.

{{:Include:Newapkbuild}}

{{Note|On older Alpine systems, abuild -c -n ''packagename'' was the way to create APKBUILD files. The 'packagename' was a parameter to the -n option so order of -c and -n matters. }}

[[Abuild_and_Helpers#apkbuild-cpan|apkbuild-cpan]] simplifies the creation of perl packages from CPAN and [[Abuild_and_Helpers#apkbuild-pypi|apkbuild-pypi]] ease the generation of APKBUILD files for python packages from PyPi.

If you are creating a daemon package which needs initd scripts you can add the -c making it:

{{Cmd|newapkbuild -c ''packagename''}}

This will copy the sample initd and confd files to the build directory. 
A third file sample.install file will be copied as well (we will discuss this later on).

=== Modify your APKBUILD ===
Edit APKBUILD and fill in the needed info (especially pkgname, pkgver, pkgdesc, url, license, depends and source).

If you are going to use any of the variables for directories like $pkgdir, always make sure they are double quoted like:

"$pkgdir"/somedir

This will prevent issues with spaces/special characters in the future.

{{Note|If you like syntax highlighting we suggest you to install vim. We have setup vim to recognize the APKBUILD file as a bash scripts so its easier to read them.}}

=== APKBUILD variables/functions ===

==== source ====

The source variable is not only used to list the remote source files to fetch, it is also used to list the local files that abuild will need in order to build the apk. Examples of such local files include: init.d files, conf.d files, install files (see [[Creating an Alpine package#install|install variable]]), patches, and all other necessary files.

Here are few things to note:

* When you are finished adding local and/or remote files to ''source'', you can execute the following command to add their checksums to the APKBUILD file:
: {{cmd|abuild checksum}}
: {{Note|When later updating the content of ''source'', or updating a file that is listed in ''source'', you must also update their checksums again with the same command.}}

* When the remote file is hosted at SourceForge, it's best to specify the special mirrors link used by SourceForge:
: <pre>http://downloads.sourceforge.net/$pkgname/$pkgname-$pkgver.tar.gz</pre>
: (or similar depending on the package).

* When the remote filename is not specified in the URI (ie, does not end in '/software-1.0.tar.gz'), such as:
: <pre>http://oss.example.org/?get=software&ver=1.0</pre>
: You must prepend '${pkgname}-${pkgver}.tar.gz::' to the protocol, like so:
: <pre>source="${pkgname}-${pkgver}.tar.gz::http://oss.example.org/?get=software&ver=1.0"</pre>
: This causes the file to be saved as ''software-1.0.tar.gz'' where abuild can use it, instead of ''?get=software&ver=1.0'', where abuild cannot use it.

* Some projects didn't provide a release tarball. Beware that some git services (gitweg, cgit, …?) doesn’t provide ''stable'' tarballs, so when you point source to an tarball like <tt>http://repo.or.cz/w/gitstats.git/snapshot/ad7efbb9399e60cee6cb217c6b47e604174a8093.tar.gz</tt>, then you will run into issues because the checksum changes when downloading on the build system. This is not a problem on GitHub, GitLab and other decent services provides, they provide ''stable'' tarballs.

* abuild currently supports the following protocols for remote file retrieval:
** http
** https
** ftp



* abuild currently supports the following archive types/archive file extensions:
** .tar
** .tar.gz / .tgz
** .tar.bz2
** .tar.lz (only in Alpine >=3.7)
** .tar.lzma
** .tar.xz
** .zip

==== depends & makedepends ====

Depends are the actual running dependencies that a package would need when it is running. Makedepends are only needed when you are building a package. If you set a package in depends, you do not need to add it to makedepends as well. The best way to find out what the depends and makedepends of a package are is to [http://en.wikipedia.org/wiki/Rtfm RTFM].

No kidding, lots of important information can be found in the package INSTALL and README files (or the likes). Another good way is the run <code>./configure --help</code> from the source directory to see which options are needed for configure to finish without errors. If you do not yet have a source directory you can create one with the command:

{{Cmd|abuild unpack}}

Running <code>configure</code> will also show you how you can disable a specific option for this package. For instance, a good example is "--disable-nls" which will disable native language support and thus does not depend on gettext (libiconv, glib, ...).

Alpine likes to keep things small, so we try to disable as much as possible without losing too many features. The exact disable/enable options are decided by the package builder but please try to follow Alpine's design concept as much as possible.

An easy way of quickly finding out the build info for a package is to check Arch Linux (Alpine package management and build scripts are similar) or Gentoo Linux ebuilds (previous versions of Alpine were based on Gentoo).

* [https://gitweb.gentoo.org/repo/gentoo.git/tree/ Gentoo Ebuilds]
* [http://www.archlinux.org/packages/search/ Arch Linux packages] [https://aur.archlinux.org/ Arch Linux User Repository]

After the package is successfully compiled and created we should make sure it didn't link to any package that is not present in the <code>$depends</code> variable. We do this by using <code>scanelf</code>. If scanelf is not yet installed on your system you can do that by installing {{Pkg|pax-utils}}.

{{Cmd|scanelf -nR pkg}}

An example output of {{Pkg|libcurl}} would be:

ET_DYN libssl.so.0.9.8,libcrypto.so.0.9.8,libz.so.1,libc.so.0,ld-uClibc.so.0 pkg/usr/lib/libcurl.so.4.1.1

You can see the needed files and should be able to find out which file belongs to which package.

==== license ====

The '''license''' tag must reflect the license of the source code. Please check the source tarball for COPYING, LICENSE, or other files with names that indicates that it contains licensing information. Beside the license file most developer include headers in the source code files with licensing details.

If the license is on the [https://spdx.org/licenses/ SPDX License List] or [https://spdx.org/licenses/exceptions-index.html SPDX License Exceptions], use the identifier specified by SPDX.

If a package has a special/custom license or is not listed as [https://opensource.org/licenses/alphabetical OSI approved], use the identifier "custom". We additionally need to provide the license file with the release. Because we want to save space and don't like to have licenses all over our system we have decided to include the license in the doc subpackage. Please follow the following guidelines to add a proper license. Locate the license file inside the source package. Add the doc subpackage to the $subpackages variable as follows:

subpackages="$pkgname-doc"

Add a similar line to the following to your package() function, depending on the license description file:

install -Dm644 COPYING "$pkgdir"/usr/share/licenses/$pkgname/COPYING

If you follow these steps then abuild will automatically add the license to the package-doc apk for you.

{{Warning|It is not acceptable to package software with "unknown" license! If you can't find the license of the source code, please contact the author and ask them to specify the license. }}

==== arch ====

The package architecture(s) to build for. This can be one of: ''x86, x86_64, all,'' or ''noarch'', where ''all'' means all architectures, and ''noarch'' means it's architecture-independent (e.g., a pure-python package).
{{Tip|To determine if your APKBUILD can use ''noarch'', build the package for your architecture and then run "scanelf -R pkg" from the directory that the APKBUILD resides in, in order to scan for ELF files in the ''./pkg'' directory. If you do NOT get output from this, then ''noarch'' can be used.}}

==== url ====

Website address for the program. This is useful later on when either finding documentation or other information about the package.

==== pkgdesc ====

A brief, one line, description of what the package does. Useful for the package management system. It should start with a capital letter and does '''not''' end with a period.

Here is an example from apk_info for the OpenSSH client package:

pkgdesc="Port of OpenBSD's free SSH release - client"

==== pkgver ====

Provide the release number of the package you are building.

==== pkgrel ====

The $pkgrel versioning is made so that if you change something in your APKBUILD file without changing the actual $pkgver, you can increment pkgrel so apk tools will detect it as an update. For instance, if you forget to add a dependency, you can add it afterward and you can +1 pkgver so apk finds this update and adds the missing dependency. When there's an upstream version change, we reset the pkgrel to 0.

==== pkgname ====

The base name of the package you are creating. For Freeswitch 1.0.6, you would use "freeswitch"

==== install ====

There are 6 different kinds of install scripts. Each script is called with the $pkgname.''<action>'' where ''<action>'' is one of the following:

<dl>
<dt>$pkgname.pre-install
<dd>This script is executed before package is installed. Typical use is when package needs a group and a user to be created. For example:
<pre>
#!/bin/sh

addgroup -S clamav 2>/dev/null
adduser -S -D -H -s /bin/false -G clamav -g clamav clamav 2>/dev/null

exit 0
</pre>
Note the ''exit 0'' at the end. If the script exits with failure (if the user already exist), the package will not be installed and <code>apk add</code> will exit with failure.

<dt>$pkgname.post-install
<dd>This script is executed after the package is installed. Can be used to generate font cache and similar.

<dt>$pkgname.pre-upgrade
<dd>Same as pre-install but is executed before upgrading/downgrading/reinstalling an already installed package. Note that exiting with failure will not cause apk to exit with failure, but will mark the package as broken.

<dt>$pkgname.post-upgrade
<dd>Same as post-install but is executed after upgrading/downgrading/reinstalling an already installed package.

<dt>$pkgname.pre-deinstall
<dd>This script is executed before uninstalling a package. If script exits with failure apk will not uninstall the package.

<dt>$pkgname.post-deinstall
<dd>This script is executed after a package have been uninstalled. Can be used to update font caches and restore busybox links. For example:
<pre>
#!/bin/sh
busybox --install -s
</pre>

</dl>

If the package has a pre-install and post-install script the APKBUILD should have the ''install'' variable defined:
<pre>
...
install="$pkgname.pre-install $pkgname.post-install"

...
</pre>

==== subpackages ====

$subpackages are made to split up the normal "make install" into separate packages. The most common subpackages we use are doc and dev. Because we like to keep our target system small we move documentation and development files (only needed when building packages) into separate packages. To use the specific program a user only need to install the base apk without package-doc or package-dev, but if he wants to read the manual he will need to install package-doc.

The easiest way to find out if you need to use -dev and -doc is to first build the package without these options set and wait until the build finishes. When its finished you should have a pkg directory which is the fake root directory. Inside this directory you will see the structure as how it would be installed in / on the target system.

To see if you need the -dev package you can run the following cmd:

{{Cmd|find pkg/usr/ -name '*.[acho]' -o -name '*.la'}}

If this returns any files you need to include the -dev package.

 To see if you need the -doc package you can run the following cmd:

{{Cmd|find pkg/usr/share -name doc -o -name man -o -name info -o -name html -o -name sgml -o -name licenses}}

If this returns any directories you need to include the -doc package.

===== Custom subpackages =====

Some software additionally has non-essential files that do not qualify as either documentation or development content. These files should be placed in their own, specialized subpackage(s). Some packages include large test suites which are only needed in specific circumstances or binaries which have depends which we prefer not to install. To handle those we create our own package/function. In the APKBUILD below the build() function we create another function:

test() {
mkdir -p "$subpkgdir"/usr
mv "$pkgdir"/usr/package-test "$subpkgdir"/usr/
# or amove usr/package-test
}

We also need to add the package info to $subpackages variable:

subpackages="$pkgname-doc $pkgname-dev $pkgname-test"

After we finish building the package you should see another apk called packagename-test.apk which includes the files which we moved to the $subpkgdir dir.

The above mentioned variables can also be used in our custom function. If we want for instance to build the test() function with perl support we would add:

depends="perl"
makedepends="perl-dev"

If we would install the base package it would not install perl, but if we install the package-test package it would.

==== Patches ====

Please make sure you always submit human readable patches. Ways to create them are:

directory compare:

{{Cmd|diff -Nurp original_directory new_directory > filename.patch}}

file compare:

{{Cmd|diff -up original.file new.file > filename.patch}}

If a patch contains a completely new file but not *.rej or *.orig file, you need to add -N option to diff, but you may need to add exclusions with <code>--exclude PATTERN</code> so that you do not inadvertently add files. You may need to manually delete unwanted files inside the patch file.

Because multiple patches can patch the same file, they can change the offsets required by subsequent patches. To make sure we always patch in a specific way, we should number the patches as follows:

10-patch1.patch 20-patch2.patch 30-patch3.patch

This way we are always sure that patch 1 is applied first, and if we want to add additional patches between them we can use appropriate indexes (e.g. 11, 12, 21, 22).

Add the names of the patch files to the ''source'' variable. If you haven't declared a custom ''prepare'' function, no further action is necessary. Otherwise, be sure to call ''default_prepare'' in your ''prepare'' function. For example:

prepare() {
default_prepare

# do your stuff
}

Note: Some older packages contain a ''for'' loop in the ''prepare'' function to apply patches. This is not needed anymore, as patches are handled by ''default_prepare''.

In Alpine >=3.4 you can define patch_args to supply the patch level. This only works if all the patches have the same patch level. If there are a lot of patches from different sources, there is a good chance that you may need to edit them, as discussed below.

To automatically patch the package (available only in Alpine >=3.4) if it uses a patch level (-pX) other than the default (-p1), you need to carefully modify the patch. First, you'll need a text editor that does not automatically convert between Windows and Unix new lines (or, disable this feature) so that it preserves the old code. The next thing you'll need to do is modify the paths on "+++" and "---" lines in the .patch file. You can begin the path with a/ and b/ like shown below. Next, you need to adjust the paths so that the relative base path is from inside $builddir. Anything to the left of $builddir, including $builddir itself, needs to be removed from the path. So, if $builddir is /home/USER/aports/community/chromium/src/chromium-65, you need to erase it on the "+++" and "---" lines. Inside the chromium-65 folder you can see a src folder that has 3rdparty as a descendant. If a patch originally has a deeper patch level, you may need to fill in the missing portion of the path. For example, use the <code>find . -name "Assertions.cpp"</code> command to find the full path to the file relative to the base.

{{Cat|example.patch|<nowiki>
Author: John Doe <johndoe@mail.com>
URL: http://.....
Summary: Fixes musl compatibility
----
--- a/src/3rdparty/chromium/third_party/WebKit/Source/wtf/Assertions.cpp.orig
+++ b/src/3rdparty/chromium/third_party/WebKit/Source/wtf/Assertions.cpp
@@ -142,7 +142,7 @@
};

FrameToNameScope::FrameToNameScope(void* addr) : m_name(0), m_cxaDemangled(0) {
-#if OS(MACOSX) || (OS(LINUX) && !defined(__UCLIBC__))
+#if OS(MACOSX) || (OS(LINUX) && defined(__GLIBC__))
Dl_info info;
if (!dladdr(addr, &info) || !info.dli_sname)
return;
</nowiki>}}

Portions of the patch may be outdated, removed completely as in the source code file completely removed, or moved or renamed files. You need to delete that section of the patch or find where that section of code changed and re-diff it.

It is good etiquette to give credit at the top and the location of where you originally found them with notes.

Excluding patches with global variable resembling patch_opts is not available on Alpine. To exclude patches you need to create your own custom prepare().

If you have a monolithic patch where there are a bunch of patches in one big patch, you could use filterdiff which is available in the patchutils package.

Just do something like:

<pre>
makedepends="patchutils"

prepare() {
...
cd "$builddir"
filterdiff -x '*drivers/video/logo*' "$srcdir"/original.patch > "$builddir"/modified.patch
patch -p1 -i "$builddir"/modified.patch
}
</pre>

You need to put the wildcard pattern in single quotes for it to work.

==== Configure options ====

Alpine has some default configure options we set by default. We use /usr for prefix to make sure everything is installed with /usr in front of it. If you notice that anything is installed in the wrong directory please run {{Cmd|./configure --help}} and see if you can set the correct location.

We are not covering the depend switches here we have discussed this already in the depend section.

==== Make options ====

If you notice weird problems when compiling or installing the package with make/make install you could try to disable [http://www.gnu.org/software/make/manual/make.html#Parallel parallel] building/installing. A normal make line would be:

make

To disable parallel we use:

make -j1

We can use the same for make install.

Because we do not want to install the package in our build environment but we want to install it in a fake root directory we need to tell 'make install' to use another destination directory instead of '/'. We do this by setting a variable when we execute make install as followed:

make DESTDIR="$pkgdir" install

Please note that some Makefiles do not support this variable and will always install software in '/'. To make sure you do not mess up your build system NEVER run your build system as root but always use a custom user and doas when needed. If by accident the Makefile does not support DESTDIR variable it will fail to install in our build system system directories.

==== builddir ====
If you used <tt>newapkbuild</tt> to create your APKBUILD file, you must specify the path to your unpacked sources. Inside the sections during the prepare/build/install process ''builddir'' is used. Most of the time a combination of ''$srcdir'' and ''$pkgname-$pkgver'' will work. When not, check the /src directory or the source tarball for the right string. Especially when you are working with automatically generated tarballs (like from github and gitorious), this needs to be adjusted.

builddir="$srcdir"/$pkgname-$pkgver

==== Additional files ====

If you want/need to install additional files not mentioned above you can use the following cmd (this is an example of a conf file):

install -Dm644 doc/$pkgname.conf "$pkgdir"/etc/$pkgname.conf

== Build the package ==

If you did not already create the checksums as mentioned above you can do so now:

{{Cmd|cd $pkgname
abuild checksum}}

It's about time we build our package. Because a build system should never have all the package installed to prevent linking to packages we don't want it to link we use a abuild recursively with the '''-r''' switch. It will install all dependencies from your repository and builds it, afterwards it will uninstall all those depending packages again. You could also use the '''-R''' switch which would build your package including the dependency packages.

{{Cmd|abuild -r}}

== Testing the package locally ==

When it completes, your package will be found in a subfolder of <code>~/packages</code>. You may want to test it on your machine but only if the package is not a critical system package like musl or apk-tools package. To avoid borking your system (as in making it impossible to use <code>apk add</code> or to restore back the system and the compiler toolchain) for a critical system package, you should test on a chroot first before using it live.

The best way to test a package locally is to modify your <code>/etc/apk/repositories</code> so that it includes the indexes to your locally built packages - the directories that contain <code>ARCH/APKINDEX.tar.gz</code>. For example the <code>/etc/apk/repositories</code> below includes locally built packages in testing, community and main. To use this example change <code>USER</code> to your login name.

{{Cat|/etc/apk/repositories|/home/USER/packages/testing/
/home/USER/packages/community/
/home/USER/packages/main/
/media/sdc/apks
#http://dl-2.alpinelinux.org/alpine/v3.7/main
#http://dl-2.alpinelinux.org/alpine/v3.7/community
http://dl-2.alpinelinux.org/alpine/edge/main
http://dl-2.alpinelinux.org/alpine/edge/community
http://dl-2.alpinelinux.org/alpine/edge/testing
}}

If you prefer to test a package without changing any other configuration you can use the <code>-X, --repository</code> option to <code>apk</code>:

{{Cmd|doas apk add --repository /home/USER/packages/testing $pkgname}}

== Code review ==

To successfully have your package pass through code reviewers (as of Feb 18, 2018 are nmeum and jirutka on GitHub) and possible increased acceptance, the following conventions need to be followed:

# Custom global variables should be prefixed with underscore (_).
# Compact code as in merged commands, removed unused variables, removal of functions that do the same thing that are automatically handled by abuild.
# Versioning is done properly. For details see [[APKBUILD_Reference#pkgver]].
# Licensing is done properly. Remove unnecessary copying of licensing that is already OSI approved.
# Naming conventions rules for unofficial variables as in _gitrev is preferred over commit.
# Indent with tabs not spaces.
# Removal of explicit return 1. (They are still found the old APKBUILD files if you are learning but are now strongly discouraged.)
# Disabling check() requires either (1) a comment (#) stating next to options="!check" that there is no test suite/unit tests or (2) functioning working check() function.
# Explicit call to subpackages="$pkgname-doc" must be used instead of explicit gzip man page compression.
# Ideally, lines should be no more than 80 columns wide

Additionally, make sure to run the linter on your package:
{{Cmd|doas apk add atools
apkbuild-lint APKBUILD}}

For more information see [[Development using git:Quality assurance]] and [[Package_policies]].

== Commit your work ==

After you successfully build your package and properly followed the conventions and requirements in the code review section, you can submit your APKBUILD to Alpine's git repository.

Update your git repo, before adding new files:

{{Cmd|cd $aportsdir
git pull}}

This should pull all the changes made by others into your local git repo.

When you think you are ready you can add your files to git:

NOTE: when using our Gitlab instance, you can create MR's for each package. Please squash all commits related to the same package into a single one per MR.

{{Cmd|cd $aportsdir
git add testing/$pkgdir (include any other files needed for the build; $pkgname.install...)
git commit}}

Use the following commit message template for new aports (without the comments):

{{Cat|template|testing/$pkgname: new aport # this will be the subject line
# a blank line
$url # project homepage
$pkgdesc # one line description}}

Or you could add the following and <code>chmod +x ports/.git/hooks/prepare-commit-msg</code> to automatically generate commit message which the default aports/.githooks/ does not:

{{Cat|aports/.git/hooks/prepare-commit-msg|<nowiki>#!/bin/sh
case "$2,$3" in
,|template,)
if git diff-index --diff-filter=A --name-only --cached HEAD \
| grep -q '/APKBUILD$'; then
meta() { git diff --staged | grep "^+$1" | sed 's/.*="\?//;s/"$//';}
printf 'testing/%s: new aport\n\n%s\n%s\n' "$(meta pkgname)" \
"$(meta url)" "$(meta pkgdesc)" "$(cat $1)" > "$1"
else
printf '%s\n\n%s' `git diff-index --name-only --cached HEAD \
| sed -n 's/\/APKBUILD$//p;q'` "$(cat $1)" > "$1"
fi;;
esac</nowiki>}}

Now your changes are only available locally in your repository.

Because you do not have push rights to the Alpine aports repository you need to create a merge request to [https://gitlab.alpinelinux.org/alpine/aports Alpine's GitLab instance].

Alternatively you can also create a diff (patch) of the changes you made and send this patch to the
[https://lists.alpinelinux.org/~alpine/aports alpine-aports mailinglist].

To create a diff patch:

{{Cmd|git format-patch HEAD^}}

or if you have sprunge, you can create a link to your patch for convenience

{{Cmd|git format-patch HEAD^ --stdout <nowiki>|</nowiki> sprunge}}

== Travis CI and automated testing ==

Travis CI, as in continuous integration automated testing, isn't always required, but 99% of the time it is strongly encouraged to pass with a green checkmark. Passing Travis CI ensures that your package works on another machine and builds the image starting from nothing. One reason why your package fails to build on the remote server is that you may inadvertently add a package dependency as in creating multiple packages at the same time or forgot to remove a dependency and forgot to mark it as a makedepends.

When you submit your APKBUILD as a pull request, the Travis CI server will construct the build environment from [https://github.com/alpinelinux/aports/blob/master/.travis/install-alpine#L28 main] [https://github.com/alpinelinux/aports/blob/master/.travis/common.sh#L5 Edge] apks.

The environment is just like a boot into command line so it is minimal. Don't assume that you boot into X.

The server/configuration cannot do testing/check() testing on hardware accelerated OpenGL apps.

== Send a patch ==

[[Creating_patches#Only_the_last_commit_with_.27git_send-email.27|git send-email]] will do that for you.

== GitHub Tagging ==

If you see your pull requested labeled on GitHub this is what they mean:

*A-add - The pull requester wanted to add this brand new package.
*A-upgrade - The pull requester wanted to update the package.
*A-improve - The pull requester wanted to improve an existing package.
*A-fix - The pull requester wanted to fix a bug with the existing package.
*S-changes-requested - An admin wants you to add or remove a subpackage or fix something as in messy code.
*S-needs-review - An admin needs someone to do a code review on your package.
*S-broken - The package fails to build locally on the code reviewer machine.
*ci-malfunction - Travis CI doesn't work with this package as in exceeded time.

== See Also ==
* [[APKBUILD Reference]]
* [[APKBUILD examples]]
* [[Development using git]]
* [[Development using git:Quality assurance]]

[[category: Package Manager]]

Creating an Alpine package

2021-11-25T19:48:18Z

Eddsalkield: /* Testing the package locally */ s/sudo/doas

{{TOC right}}

== Requirements ==

To build a package for Alpine Linux you need an Alpine Linux installation. Check the [[Installation]] page to see all available installation options.

== Setup your system and account ==
{{:Include:Setup_your_system_and_account_for_building_packages}}

== Getting some help ==

It might be wise to start by checking what the [[Abuild|abuild]] program can/cannot do.

{{Cmd|abuild -h}}

For real help, you can also go on OFTC's #alpine-devel on IRC.

A reference for APKBUILD files is available as a man page in the 'abuild-doc' package:

{{Cmd|man APKBUILD}}

== Creating an APKBUILD file ==

=== Use a template APKBUILD ===

To create the actual APKBUILD file {{Pkg|newapkbuild}} can serve you a template to start with. It will create a directory with the given package name, place an example/template APKBUILD file to the given directory, and fill some variables if those are provided. Please check the [[Package_policies| package policies]] page about naming details.

If you doubt to which repository your package belongs to you can safely use '''testing'''. Building package in your aports/testing directory is not mandatory but this way the package is already at the right place.

{{:Include:Newapkbuild}}

{{Note|On older Alpine systems, abuild -c -n ''packagename'' was the way to create APKBUILD files. The 'packagename' was a parameter to the -n option so order of -c and -n matters. }}

[[Abuild_and_Helpers#apkbuild-cpan|apkbuild-cpan]] simplifies the creation of perl packages from CPAN and [[Abuild_and_Helpers#apkbuild-pypi|apkbuild-pypi]] ease the generation of APKBUILD files for python packages from PyPi.

If you are creating a daemon package which needs initd scripts you can add the -c making it:

{{Cmd|newapkbuild -c ''packagename''}}

This will copy the sample initd and confd files to the build directory. 
A third file sample.install file will be copied as well (we will discuss this later on).

=== Modify your APKBUILD ===
Edit APKBUILD and fill in the needed info (especially pkgname, pkgver, pkgdesc, url, license, depends and source).

If you are going to use any of the variables for directories like $pkgdir, always make sure they are double quoted like:

"$pkgdir"/somedir

This will prevent issues with spaces/special characters in the future.

{{Note|If you like syntax highlighting we suggest you to install vim. We have setup vim to recognize the APKBUILD file as a bash scripts so its easier to read them.}}

=== APKBUILD variables/functions ===

==== source ====

The source variable is not only used to list the remote source files to fetch, it is also used to list the local files that abuild will need in order to build the apk. Examples of such local files include: init.d files, conf.d files, install files (see [[Creating an Alpine package#install|install variable]]), patches, and all other necessary files.

Here are few things to note:

* When you are finished adding local and/or remote files to ''source'', you can execute the following command to add their checksums to the APKBUILD file:
: {{cmd|abuild checksum}}
: {{Note|When later updating the content of ''source'', or updating a file that is listed in ''source'', you must also update their checksums again with the same command.}}

* When the remote file is hosted at SourceForge, it's best to specify the special mirrors link used by SourceForge:
: <pre>http://downloads.sourceforge.net/$pkgname/$pkgname-$pkgver.tar.gz</pre>
: (or similar depending on the package).

* When the remote filename is not specified in the URI (ie, does not end in '/software-1.0.tar.gz'), such as:
: <pre>http://oss.example.org/?get=software&ver=1.0</pre>
: You must prepend '${pkgname}-${pkgver}.tar.gz::' to the protocol, like so:
: <pre>source="${pkgname}-${pkgver}.tar.gz::http://oss.example.org/?get=software&ver=1.0"</pre>
: This causes the file to be saved as ''software-1.0.tar.gz'' where abuild can use it, instead of ''?get=software&ver=1.0'', where abuild cannot use it.

* Some projects didn't provide a release tarball. Beware that some git services (gitweg, cgit, …?) doesn’t provide ''stable'' tarballs, so when you point source to an tarball like <tt>http://repo.or.cz/w/gitstats.git/snapshot/ad7efbb9399e60cee6cb217c6b47e604174a8093.tar.gz</tt>, then you will run into issues because the checksum changes when downloading on the build system. This is not a problem on GitHub, GitLab and other decent services provides, they provide ''stable'' tarballs.

* abuild currently supports the following protocols for remote file retrieval:
** http
** https
** ftp



* abuild currently supports the following archive types/archive file extensions:
** .tar
** .tar.gz / .tgz
** .tar.bz2
** .tar.lz (only in Alpine >=3.7)
** .tar.lzma
** .tar.xz
** .zip

==== depends & makedepends ====

Depends are the actual running dependencies that a package would need when it is running. Makedepends are only needed when you are building a package. If you set a package in depends, you do not need to add it to makedepends as well. The best way to find out what the depends and makedepends of a package are is to [http://en.wikipedia.org/wiki/Rtfm RTFM].

No kidding, lots of important information can be found in the package INSTALL and README files (or the likes). Another good way is the run <code>./configure --help</code> from the source directory to see which options are needed for configure to finish without errors. If you do not yet have a source directory you can create one with the command:

{{Cmd|abuild unpack}}

Running <code>configure</code> will also show you how you can disable a specific option for this package. For instance, a good example is "--disable-nls" which will disable native language support and thus does not depend on gettext (libiconv, glib, ...).

Alpine likes to keep things small, so we try to disable as much as possible without losing too many features. The exact disable/enable options are decided by the package builder but please try to follow Alpine's design concept as much as possible.

An easy way of quickly finding out the build info for a package is to check Arch Linux (Alpine package management and build scripts are similar) or Gentoo Linux ebuilds (previous versions of Alpine were based on Gentoo).

* [https://gitweb.gentoo.org/repo/gentoo.git/tree/ Gentoo Ebuilds]
* [http://www.archlinux.org/packages/search/ Arch Linux packages] [https://aur.archlinux.org/ Arch Linux User Repository]

After the package is successfully compiled and created we should make sure it didn't link to any package that is not present in the <code>$depends</code> variable. We do this by using <code>scanelf</code>. If scanelf is not yet installed on your system you can do that by installing {{Pkg|pax-utils}}.

{{Cmd|scanelf -nR pkg}}

An example output of {{Pkg|libcurl}} would be:

ET_DYN libssl.so.0.9.8,libcrypto.so.0.9.8,libz.so.1,libc.so.0,ld-uClibc.so.0 pkg/usr/lib/libcurl.so.4.1.1

You can see the needed files and should be able to find out which file belongs to which package.

==== license ====

The '''license''' tag must reflect the license of the source code. Please check the source tarball for COPYING, LICENSE, or other files with names that indicates that it contains licensing information. Beside the license file most developer include headers in the source code files with licensing details.

If the license is on the [https://spdx.org/licenses/ SPDX License List] or [https://spdx.org/licenses/exceptions-index.html SPDX License Exceptions], use the identifier specified by SPDX.

If a package has a special/custom license or is not listed as [https://opensource.org/licenses/alphabetical OSI approved], use the identifier "custom". We additionally need to provide the license file with the release. Because we want to save space and don't like to have licenses all over our system we have decided to include the license in the doc subpackage. Please follow the following guidelines to add a proper license. Locate the license file inside the source package. Add the doc subpackage to the $subpackages variable as follows:

subpackages="$pkgname-doc"

Add a similar line to the following to your package() function, depending on the license description file:

install -Dm644 COPYING "$pkgdir"/usr/share/licenses/$pkgname/COPYING

If you follow these steps then abuild will automatically add the license to the package-doc apk for you.

{{Warning|It is not acceptable to package software with "unknown" license! If you can't find the license of the source code, please contact the author and ask them to specify the license. }}

==== arch ====

The package architecture(s) to build for. This can be one of: ''x86, x86_64, all,'' or ''noarch'', where ''all'' means all architectures, and ''noarch'' means it's architecture-independent (e.g., a pure-python package).
{{Tip|To determine if your APKBUILD can use ''noarch'', build the package for your architecture and then run "scanelf -R pkg" from the directory that the APKBUILD resides in, in order to scan for ELF files in the ''./pkg'' directory. If you do NOT get output from this, then ''noarch'' can be used.}}

==== url ====

Website address for the program. This is useful later on when either finding documentation or other information about the package.

==== pkgdesc ====

A brief, one line, description of what the package does. Useful for the package management system. It should start with a capital letter and does '''not''' end with a period.

Here is an example from apk_info for the OpenSSH client package:

pkgdesc="Port of OpenBSD's free SSH release - client"

==== pkgver ====

Provide the release number of the package you are building.

==== pkgrel ====

The $pkgrel versioning is made so that if you change something in your APKBUILD file without changing the actual $pkgver, you can increment pkgrel so apk tools will detect it as an update. For instance, if you forget to add a dependency, you can add it afterward and you can +1 pkgver so apk finds this update and adds the missing dependency. When there's an upstream version change, we reset the pkgrel to 0.

==== pkgname ====

The base name of the package you are creating. For Freeswitch 1.0.6, you would use "freeswitch"

==== install ====

There are 6 different kinds of install scripts. Each script is called with the $pkgname.''<action>'' where ''<action>'' is one of the following:

<dl>
<dt>$pkgname.pre-install
<dd>This script is executed before package is installed. Typical use is when package needs a group and a user to be created. For example:
<pre>
#!/bin/sh

addgroup -S clamav 2>/dev/null
adduser -S -D -H -s /bin/false -G clamav -g clamav clamav 2>/dev/null

exit 0
</pre>
Note the ''exit 0'' at the end. If the script exits with failure (if the user already exist), the package will not be installed and <code>apk add</code> will exit with failure.

<dt>$pkgname.post-install
<dd>This script is executed after the package is installed. Can be used to generate font cache and similar.

<dt>$pkgname.pre-upgrade
<dd>Same as pre-install but is executed before upgrading/downgrading/reinstalling an already installed package. Note that exiting with failure will not cause apk to exit with failure, but will mark the package as broken.

<dt>$pkgname.post-upgrade
<dd>Same as post-install but is executed after upgrading/downgrading/reinstalling an already installed package.

<dt>$pkgname.pre-deinstall
<dd>This script is executed before uninstalling a package. If script exits with failure apk will not uninstall the package.

<dt>$pkgname.post-deinstall
<dd>This script is executed after a package have been uninstalled. Can be used to update font caches and restore busybox links. For example:
<pre>
#!/bin/sh
busybox --install -s
</pre>

</dl>

If the package has a pre-install and post-install script the APKBUILD should have the ''install'' variable defined:
<pre>
...
install="$pkgname.pre-install $pkgname.post-install"

...
</pre>

==== subpackages ====

$subpackages are made to split up the normal "make install" into separate packages. The most common subpackages we use are doc and dev. Because we like to keep our target system small we move documentation and development files (only needed when building packages) into separate packages. To use the specific program a user only need to install the base apk without package-doc or package-dev, but if he wants to read the manual he will need to install package-doc.

The easiest way to find out if you need to use -dev and -doc is to first build the package without these options set and wait until the build finishes. When its finished you should have a pkg directory which is the fake root directory. Inside this directory you will see the structure as how it would be installed in / on the target system.

To see if you need the -dev package you can run the following cmd:

{{Cmd|find pkg/usr/ -name '*.[acho]' -o -name '*.la'}}

If this returns any files you need to include the -dev package.

 To see if you need the -doc package you can run the following cmd:

{{Cmd|find pkg/usr/share -name doc -o -name man -o -name info -o -name html -o -name sgml -o -name licenses}}

If this returns any directories you need to include the -doc package.

===== Custom subpackages =====

Some software additionally has non-essential files that do not qualify as either documentation or development content. These files should be placed in their own, specialized subpackage(s). Some packages include large test suites which are only needed in specific circumstances or binaries which have depends which we prefer not to install. To handle those we create our own package/function. In the APKBUILD below the build() function we create another function:

test() {
mkdir -p "$subpkgdir"/usr
mv "$pkgdir"/usr/package-test "$subpkgdir"/usr/
# or amove usr/package-test
}

We also need to add the package info to $subpackages variable:

subpackages="$pkgname-doc $pkgname-dev $pkgname-test"

After we finish building the package you should see another apk called packagename-test.apk which includes the files which we moved to the $subpkgdir dir.

The above mentioned variables can also be used in our custom function. If we want for instance to build the test() function with perl support we would add:

depends="perl"
makedepends="perl-dev"

If we would install the base package it would not install perl, but if we install the package-test package it would.

==== Patches ====

Please make sure you always submit human readable patches. Ways to create them are:

directory compare:

{{Cmd|diff -Nurp original_directory new_directory > filename.patch}}

file compare:

{{Cmd|diff -up original.file new.file > filename.patch}}

If a patch contains a completely new file but not *.rej or *.orig file, you need to add -N option to diff, but you may need to add exclusions with <code>--exclude PATTERN</code> so that you do not inadvertently add files. You may need to manually delete unwanted files inside the patch file.

Because multiple patches can patch the same file, they can change the offsets required by subsequent patches. To make sure we always patch in a specific way, we should number the patches as follows:

10-patch1.patch 20-patch2.patch 30-patch3.patch

This way we are always sure that patch 1 is applied first, and if we want to add additional patches between them we can use appropriate indexes (e.g. 11, 12, 21, 22).

Add the names of the patch files to the ''source'' variable. If you haven't declared a custom ''prepare'' function, no further action is necessary. Otherwise, be sure to call ''default_prepare'' in your ''prepare'' function. For example:

prepare() {
default_prepare

# do your stuff
}

Note: Some older packages contain a ''for'' loop in the ''prepare'' function to apply patches. This is not needed anymore, as patches are handled by ''default_prepare''.

In Alpine >=3.4 you can define patch_args to supply the patch level. This only works if all the patches have the same patch level. If there are a lot of patches from different sources, there is a good chance that you may need to edit them, as discussed below.

To automatically patch the package (available only in Alpine >=3.4) if it uses a patch level (-pX) other than the default (-p1), you need to carefully modify the patch. First, you'll need a text editor that does not automatically convert between Windows and Unix new lines (or, disable this feature) so that it preserves the old code. The next thing you'll need to do is modify the paths on "+++" and "---" lines in the .patch file. You can begin the path with a/ and b/ like shown below. Next, you need to adjust the paths so that the relative base path is from inside $builddir. Anything to the left of $builddir, including $builddir itself, needs to be removed from the path. So, if $builddir is /home/USER/aports/community/chromium/src/chromium-65, you need to erase it on the "+++" and "---" lines. Inside the chromium-65 folder you can see a src folder that has 3rdparty as a descendant. If a patch originally has a deeper patch level, you may need to fill in the missing portion of the path. For example, use the <code>find . -name "Assertions.cpp"</code> command to find the full path to the file relative to the base.

{{Cat|example.patch|<nowiki>
Author: John Doe <johndoe@mail.com>
URL: http://.....
Summary: Fixes musl compatibility
----
--- a/src/3rdparty/chromium/third_party/WebKit/Source/wtf/Assertions.cpp.orig
+++ b/src/3rdparty/chromium/third_party/WebKit/Source/wtf/Assertions.cpp
@@ -142,7 +142,7 @@
};

FrameToNameScope::FrameToNameScope(void* addr) : m_name(0), m_cxaDemangled(0) {
-#if OS(MACOSX) || (OS(LINUX) && !defined(__UCLIBC__))
+#if OS(MACOSX) || (OS(LINUX) && defined(__GLIBC__))
Dl_info info;
if (!dladdr(addr, &info) || !info.dli_sname)
return;
</nowiki>}}

Portions of the patch may be outdated, removed completely as in the source code file completely removed, or moved or renamed files. You need to delete that section of the patch or find where that section of code changed and re-diff it.

It is good etiquette to give credit at the top and the location of where you originally found them with notes.

Excluding patches with global variable resembling patch_opts is not available on Alpine. To exclude patches you need to create your own custom prepare().

If you have a monolithic patch where there are a bunch of patches in one big patch, you could use filterdiff which is available in the patchutils package.

Just do something like:

<pre>
makedepends="patchutils"

prepare() {
...
cd "$builddir"
filterdiff -x '*drivers/video/logo*' "$srcdir"/original.patch > "$builddir"/modified.patch
patch -p1 -i "$builddir"/modified.patch
}
</pre>

You need to put the wildcard pattern in single quotes for it to work.

==== Configure options ====

Alpine has some default configure options we set by default. We use /usr for prefix to make sure everything is installed with /usr in front of it. If you notice that anything is installed in the wrong directory please run {{Cmd|./configure --help}} and see if you can set the correct location.

We are not covering the depend switches here we have discussed this already in the depend section.

==== Make options ====

If you notice weird problems when compiling or installing the package with make/make install you could try to disable [http://www.gnu.org/software/make/manual/make.html#Parallel parallel] building/installing. A normal make line would be:

make

To disable parallel we use:

make -j1

We can use the same for make install.

Because we do not want to install the package in our build environment but we want to install it in a fake root directory we need to tell 'make install' to use another destination directory instead of '/'. We do this by setting a variable when we execute make install as followed:

make DESTDIR="$pkgdir" install

Please note that some Makefiles do not support this variable and will always install software in '/'. To make sure you do not mess up your build system NEVER run your build system as root but always use a custom user and doas when needed. If by accident the Makefile does not support DESTDIR variable it will fail to install in our build system system directories.

==== builddir ====
If you used <tt>newapkbuild</tt> to create your APKBUILD file, you must specify the path to your unpacked sources. Inside the sections during the prepare/build/install process ''builddir'' is used. Most of the time a combination of ''$srcdir'' and ''$pkgname-$pkgver'' will work. When not, check the /src directory or the source tarball for the right string. Especially when you are working with automatically generated tarballs (like from github and gitorious), this needs to be adjusted.

builddir="$srcdir"/$pkgname-$pkgver

==== Additional files ====

If you want/need to install additional files not mentioned above you can use the following cmd (this is an example of a conf file):

install -Dm644 doc/$pkgname.conf "$pkgdir"/etc/$pkgname.conf

== Build the package ==

If you did not already create the checksums as mentioned above you can do so now:

{{Cmd|cd $pkgname
abuild checksum}}

It's about time we build our package. Because a build system should never have all the package installed to prevent linking to packages we don't want it to link we use a abuild recursively with the '''-r''' switch. It will install all dependencies from your repository and builds it, afterwards it will uninstall all those depending packages again. You could also use the '''-R''' switch which would build your package including the dependency packages.

{{Cmd|abuild -r}}

== Testing the package locally ==

When it completes, your package will be found in a subfolder of <code>~/packages</code>. You may want to test it on your machine but only if the package is not a critical system package like musl or apk-tools package. To avoid borking your system (as in making it impossible to use <code>apk add</code> or to restore back the system and the compiler toolchain) for a critical system package, you should test on a chroot first before using it live.

The best way to test a package locally is to modify your <code>/etc/apk/repositories</code> so that it includes the indexes to your locally built packages - the directories that contain <code>ARCH/APKINDEX.tar.gz</code>. For example the <code>/etc/apk/repositories</code> below includes locally built packages in testing, community and main. To use this example change <code>USER</code> to your login name.

{{Cat|/etc/apk/repositories|/home/USER/packages/testing/
/home/USER/packages/community/
/home/USER/packages/main/
/media/sdc/apks
#http://dl-2.alpinelinux.org/alpine/v3.7/main
#http://dl-2.alpinelinux.org/alpine/v3.7/community
http://dl-2.alpinelinux.org/alpine/edge/main
http://dl-2.alpinelinux.org/alpine/edge/community
http://dl-2.alpinelinux.org/alpine/edge/testing
}}

If you prefer to test a package without changing any other configuration you can use the <code>-X, --repository</code> option to <code>apk</code>:

{{Cmd|doas apk add --repository /home/USER/packages/testing $pkgname}}

== Code review ==

To successfully have your package pass through code reviewers (as of Feb 18, 2018 are nmeum and jirutka on GitHub) and possible increased acceptance, the following conventions need to be followed:

# Custom global variables should be prefixed with underscore (_).
# Compact code as in merged commands, removed unused variables, removal of functions that do the same thing that are automatically handled by abuild.
# Versioning is done properly. For details see [[APKBUILD_Reference#pkgver]].
# Licensing is done properly. Remove unnecessary copying of licensing that is already OSI approved.
# Naming conventions rules for unofficial variables as in _gitrev is preferred over commit.
# Indent with tabs not spaces.
# Removal of explicit return 1. (They are still found the old APKBUILD files if you are learning but are now strongly discouraged.)
# Disabling check() requires either (1) a comment (#) stating next to options="!check" that there is no test suite/unit tests or (2) functioning working check() function.
# Explicit call to subpackages="$pkgname-doc" must be used instead of explicit gzip man page compression.
# Ideally, lines should be no more than 80 columns wide

Additionally, make sure to run the linter on your package:
{{Cmd|sudo apk add atools
apkbuild-lint APKBUILD}}

For more information see [[Development using git:Quality assurance]] and [[Package_policies]].

== Commit your work ==

After you successfully build your package and properly followed the conventions and requirements in the code review section, you can submit your APKBUILD to Alpine's git repository.

Update your git repo, before adding new files:

{{Cmd|cd $aportsdir
git pull}}

This should pull all the changes made by others into your local git repo.

When you think you are ready you can add your files to git:

NOTE: when using our Gitlab instance, you can create MR's for each package. Please squash all commits related to the same package into a single one per MR.

{{Cmd|cd $aportsdir
git add testing/$pkgdir (include any other files needed for the build; $pkgname.install...)
git commit}}

Use the following commit message template for new aports (without the comments):

{{Cat|template|testing/$pkgname: new aport # this will be the subject line
# a blank line
$url # project homepage
$pkgdesc # one line description}}

Or you could add the following and <code>chmod +x ports/.git/hooks/prepare-commit-msg</code> to automatically generate commit message which the default aports/.githooks/ does not:

{{Cat|aports/.git/hooks/prepare-commit-msg|<nowiki>#!/bin/sh
case "$2,$3" in
,|template,)
if git diff-index --diff-filter=A --name-only --cached HEAD \
| grep -q '/APKBUILD$'; then
meta() { git diff --staged | grep "^+$1" | sed 's/.*="\?//;s/"$//';}
printf 'testing/%s: new aport\n\n%s\n%s\n' "$(meta pkgname)" \
"$(meta url)" "$(meta pkgdesc)" "$(cat $1)" > "$1"
else
printf '%s\n\n%s' `git diff-index --name-only --cached HEAD \
| sed -n 's/\/APKBUILD$//p;q'` "$(cat $1)" > "$1"
fi;;
esac</nowiki>}}

Now your changes are only available locally in your repository.

Because you do not have push rights to the Alpine aports repository you need to create a merge request to [https://gitlab.alpinelinux.org/alpine/aports Alpine's GitLab instance].

Alternatively you can also create a diff (patch) of the changes you made and send this patch to the
[https://lists.alpinelinux.org/~alpine/aports alpine-aports mailinglist].

To create a diff patch:

{{Cmd|git format-patch HEAD^}}

or if you have sprunge, you can create a link to your patch for convenience

{{Cmd|git format-patch HEAD^ --stdout <nowiki>|</nowiki> sprunge}}

== Travis CI and automated testing ==

Travis CI, as in continuous integration automated testing, isn't always required, but 99% of the time it is strongly encouraged to pass with a green checkmark. Passing Travis CI ensures that your package works on another machine and builds the image starting from nothing. One reason why your package fails to build on the remote server is that you may inadvertently add a package dependency as in creating multiple packages at the same time or forgot to remove a dependency and forgot to mark it as a makedepends.

When you submit your APKBUILD as a pull request, the Travis CI server will construct the build environment from [https://github.com/alpinelinux/aports/blob/master/.travis/install-alpine#L28 main] [https://github.com/alpinelinux/aports/blob/master/.travis/common.sh#L5 Edge] apks.

The environment is just like a boot into command line so it is minimal. Don't assume that you boot into X.

The server/configuration cannot do testing/check() testing on hardware accelerated OpenGL apps.

== Send a patch ==

[[Creating_patches#Only_the_last_commit_with_.27git_send-email.27|git send-email]] will do that for you.

== GitHub Tagging ==

If you see your pull requested labeled on GitHub this is what they mean:

*A-add - The pull requester wanted to add this brand new package.
*A-upgrade - The pull requester wanted to update the package.
*A-improve - The pull requester wanted to improve an existing package.
*A-fix - The pull requester wanted to fix a bug with the existing package.
*S-changes-requested - An admin wants you to add or remove a subpackage or fix something as in messy code.
*S-needs-review - An admin needs someone to do a code review on your package.
*S-broken - The package fails to build locally on the code reviewer machine.
*ci-malfunction - Travis CI doesn't work with this package as in exceeded time.

== See Also ==
* [[APKBUILD Reference]]
* [[APKBUILD examples]]
* [[Development using git]]
* [[Development using git:Quality assurance]]

[[category: Package Manager]]

Creating an Alpine package

2021-11-25T19:47:50Z

Eddsalkield: /* Make options */ s/sudo/doas

{{TOC right}}

== Requirements ==

To build a package for Alpine Linux you need an Alpine Linux installation. Check the [[Installation]] page to see all available installation options.

== Setup your system and account ==
{{:Include:Setup_your_system_and_account_for_building_packages}}

== Getting some help ==

It might be wise to start by checking what the [[Abuild|abuild]] program can/cannot do.

{{Cmd|abuild -h}}

For real help, you can also go on OFTC's #alpine-devel on IRC.

A reference for APKBUILD files is available as a man page in the 'abuild-doc' package:

{{Cmd|man APKBUILD}}

== Creating an APKBUILD file ==

=== Use a template APKBUILD ===

To create the actual APKBUILD file {{Pkg|newapkbuild}} can serve you a template to start with. It will create a directory with the given package name, place an example/template APKBUILD file to the given directory, and fill some variables if those are provided. Please check the [[Package_policies| package policies]] page about naming details.

If you doubt to which repository your package belongs to you can safely use '''testing'''. Building package in your aports/testing directory is not mandatory but this way the package is already at the right place.

{{:Include:Newapkbuild}}

{{Note|On older Alpine systems, abuild -c -n ''packagename'' was the way to create APKBUILD files. The 'packagename' was a parameter to the -n option so order of -c and -n matters. }}

[[Abuild_and_Helpers#apkbuild-cpan|apkbuild-cpan]] simplifies the creation of perl packages from CPAN and [[Abuild_and_Helpers#apkbuild-pypi|apkbuild-pypi]] ease the generation of APKBUILD files for python packages from PyPi.

If you are creating a daemon package which needs initd scripts you can add the -c making it:

{{Cmd|newapkbuild -c ''packagename''}}

This will copy the sample initd and confd files to the build directory. 
A third file sample.install file will be copied as well (we will discuss this later on).

=== Modify your APKBUILD ===
Edit APKBUILD and fill in the needed info (especially pkgname, pkgver, pkgdesc, url, license, depends and source).

If you are going to use any of the variables for directories like $pkgdir, always make sure they are double quoted like:

"$pkgdir"/somedir

This will prevent issues with spaces/special characters in the future.

{{Note|If you like syntax highlighting we suggest you to install vim. We have setup vim to recognize the APKBUILD file as a bash scripts so its easier to read them.}}

=== APKBUILD variables/functions ===

==== source ====

The source variable is not only used to list the remote source files to fetch, it is also used to list the local files that abuild will need in order to build the apk. Examples of such local files include: init.d files, conf.d files, install files (see [[Creating an Alpine package#install|install variable]]), patches, and all other necessary files.

Here are few things to note:

* When you are finished adding local and/or remote files to ''source'', you can execute the following command to add their checksums to the APKBUILD file:
: {{cmd|abuild checksum}}
: {{Note|When later updating the content of ''source'', or updating a file that is listed in ''source'', you must also update their checksums again with the same command.}}

* When the remote file is hosted at SourceForge, it's best to specify the special mirrors link used by SourceForge:
: <pre>http://downloads.sourceforge.net/$pkgname/$pkgname-$pkgver.tar.gz</pre>
: (or similar depending on the package).

* When the remote filename is not specified in the URI (ie, does not end in '/software-1.0.tar.gz'), such as:
: <pre>http://oss.example.org/?get=software&ver=1.0</pre>
: You must prepend '${pkgname}-${pkgver}.tar.gz::' to the protocol, like so:
: <pre>source="${pkgname}-${pkgver}.tar.gz::http://oss.example.org/?get=software&ver=1.0"</pre>
: This causes the file to be saved as ''software-1.0.tar.gz'' where abuild can use it, instead of ''?get=software&ver=1.0'', where abuild cannot use it.

* Some projects didn't provide a release tarball. Beware that some git services (gitweg, cgit, …?) doesn’t provide ''stable'' tarballs, so when you point source to an tarball like <tt>http://repo.or.cz/w/gitstats.git/snapshot/ad7efbb9399e60cee6cb217c6b47e604174a8093.tar.gz</tt>, then you will run into issues because the checksum changes when downloading on the build system. This is not a problem on GitHub, GitLab and other decent services provides, they provide ''stable'' tarballs.

* abuild currently supports the following protocols for remote file retrieval:
** http
** https
** ftp



* abuild currently supports the following archive types/archive file extensions:
** .tar
** .tar.gz / .tgz
** .tar.bz2
** .tar.lz (only in Alpine >=3.7)
** .tar.lzma
** .tar.xz
** .zip

==== depends & makedepends ====

Depends are the actual running dependencies that a package would need when it is running. Makedepends are only needed when you are building a package. If you set a package in depends, you do not need to add it to makedepends as well. The best way to find out what the depends and makedepends of a package are is to [http://en.wikipedia.org/wiki/Rtfm RTFM].

No kidding, lots of important information can be found in the package INSTALL and README files (or the likes). Another good way is the run <code>./configure --help</code> from the source directory to see which options are needed for configure to finish without errors. If you do not yet have a source directory you can create one with the command:

{{Cmd|abuild unpack}}

Running <code>configure</code> will also show you how you can disable a specific option for this package. For instance, a good example is "--disable-nls" which will disable native language support and thus does not depend on gettext (libiconv, glib, ...).

Alpine likes to keep things small, so we try to disable as much as possible without losing too many features. The exact disable/enable options are decided by the package builder but please try to follow Alpine's design concept as much as possible.

An easy way of quickly finding out the build info for a package is to check Arch Linux (Alpine package management and build scripts are similar) or Gentoo Linux ebuilds (previous versions of Alpine were based on Gentoo).

* [https://gitweb.gentoo.org/repo/gentoo.git/tree/ Gentoo Ebuilds]
* [http://www.archlinux.org/packages/search/ Arch Linux packages] [https://aur.archlinux.org/ Arch Linux User Repository]

After the package is successfully compiled and created we should make sure it didn't link to any package that is not present in the <code>$depends</code> variable. We do this by using <code>scanelf</code>. If scanelf is not yet installed on your system you can do that by installing {{Pkg|pax-utils}}.

{{Cmd|scanelf -nR pkg}}

An example output of {{Pkg|libcurl}} would be:

ET_DYN libssl.so.0.9.8,libcrypto.so.0.9.8,libz.so.1,libc.so.0,ld-uClibc.so.0 pkg/usr/lib/libcurl.so.4.1.1

You can see the needed files and should be able to find out which file belongs to which package.

==== license ====

The '''license''' tag must reflect the license of the source code. Please check the source tarball for COPYING, LICENSE, or other files with names that indicates that it contains licensing information. Beside the license file most developer include headers in the source code files with licensing details.

If the license is on the [https://spdx.org/licenses/ SPDX License List] or [https://spdx.org/licenses/exceptions-index.html SPDX License Exceptions], use the identifier specified by SPDX.

If a package has a special/custom license or is not listed as [https://opensource.org/licenses/alphabetical OSI approved], use the identifier "custom". We additionally need to provide the license file with the release. Because we want to save space and don't like to have licenses all over our system we have decided to include the license in the doc subpackage. Please follow the following guidelines to add a proper license. Locate the license file inside the source package. Add the doc subpackage to the $subpackages variable as follows:

subpackages="$pkgname-doc"

Add a similar line to the following to your package() function, depending on the license description file:

install -Dm644 COPYING "$pkgdir"/usr/share/licenses/$pkgname/COPYING

If you follow these steps then abuild will automatically add the license to the package-doc apk for you.

{{Warning|It is not acceptable to package software with "unknown" license! If you can't find the license of the source code, please contact the author and ask them to specify the license. }}

==== arch ====

The package architecture(s) to build for. This can be one of: ''x86, x86_64, all,'' or ''noarch'', where ''all'' means all architectures, and ''noarch'' means it's architecture-independent (e.g., a pure-python package).
{{Tip|To determine if your APKBUILD can use ''noarch'', build the package for your architecture and then run "scanelf -R pkg" from the directory that the APKBUILD resides in, in order to scan for ELF files in the ''./pkg'' directory. If you do NOT get output from this, then ''noarch'' can be used.}}

==== url ====

Website address for the program. This is useful later on when either finding documentation or other information about the package.

==== pkgdesc ====

A brief, one line, description of what the package does. Useful for the package management system. It should start with a capital letter and does '''not''' end with a period.

Here is an example from apk_info for the OpenSSH client package:

pkgdesc="Port of OpenBSD's free SSH release - client"

==== pkgver ====

Provide the release number of the package you are building.

==== pkgrel ====

The $pkgrel versioning is made so that if you change something in your APKBUILD file without changing the actual $pkgver, you can increment pkgrel so apk tools will detect it as an update. For instance, if you forget to add a dependency, you can add it afterward and you can +1 pkgver so apk finds this update and adds the missing dependency. When there's an upstream version change, we reset the pkgrel to 0.

==== pkgname ====

The base name of the package you are creating. For Freeswitch 1.0.6, you would use "freeswitch"

==== install ====

There are 6 different kinds of install scripts. Each script is called with the $pkgname.''<action>'' where ''<action>'' is one of the following:

<dl>
<dt>$pkgname.pre-install
<dd>This script is executed before package is installed. Typical use is when package needs a group and a user to be created. For example:
<pre>
#!/bin/sh

addgroup -S clamav 2>/dev/null
adduser -S -D -H -s /bin/false -G clamav -g clamav clamav 2>/dev/null

exit 0
</pre>
Note the ''exit 0'' at the end. If the script exits with failure (if the user already exist), the package will not be installed and <code>apk add</code> will exit with failure.

<dt>$pkgname.post-install
<dd>This script is executed after the package is installed. Can be used to generate font cache and similar.

<dt>$pkgname.pre-upgrade
<dd>Same as pre-install but is executed before upgrading/downgrading/reinstalling an already installed package. Note that exiting with failure will not cause apk to exit with failure, but will mark the package as broken.

<dt>$pkgname.post-upgrade
<dd>Same as post-install but is executed after upgrading/downgrading/reinstalling an already installed package.

<dt>$pkgname.pre-deinstall
<dd>This script is executed before uninstalling a package. If script exits with failure apk will not uninstall the package.

<dt>$pkgname.post-deinstall
<dd>This script is executed after a package have been uninstalled. Can be used to update font caches and restore busybox links. For example:
<pre>
#!/bin/sh
busybox --install -s
</pre>

</dl>

If the package has a pre-install and post-install script the APKBUILD should have the ''install'' variable defined:
<pre>
...
install="$pkgname.pre-install $pkgname.post-install"

...
</pre>

==== subpackages ====

$subpackages are made to split up the normal "make install" into separate packages. The most common subpackages we use are doc and dev. Because we like to keep our target system small we move documentation and development files (only needed when building packages) into separate packages. To use the specific program a user only need to install the base apk without package-doc or package-dev, but if he wants to read the manual he will need to install package-doc.

The easiest way to find out if you need to use -dev and -doc is to first build the package without these options set and wait until the build finishes. When its finished you should have a pkg directory which is the fake root directory. Inside this directory you will see the structure as how it would be installed in / on the target system.

To see if you need the -dev package you can run the following cmd:

{{Cmd|find pkg/usr/ -name '*.[acho]' -o -name '*.la'}}

If this returns any files you need to include the -dev package.

 To see if you need the -doc package you can run the following cmd:

{{Cmd|find pkg/usr/share -name doc -o -name man -o -name info -o -name html -o -name sgml -o -name licenses}}

If this returns any directories you need to include the -doc package.

===== Custom subpackages =====

Some software additionally has non-essential files that do not qualify as either documentation or development content. These files should be placed in their own, specialized subpackage(s). Some packages include large test suites which are only needed in specific circumstances or binaries which have depends which we prefer not to install. To handle those we create our own package/function. In the APKBUILD below the build() function we create another function:

test() {
mkdir -p "$subpkgdir"/usr
mv "$pkgdir"/usr/package-test "$subpkgdir"/usr/
# or amove usr/package-test
}

We also need to add the package info to $subpackages variable:

subpackages="$pkgname-doc $pkgname-dev $pkgname-test"

After we finish building the package you should see another apk called packagename-test.apk which includes the files which we moved to the $subpkgdir dir.

The above mentioned variables can also be used in our custom function. If we want for instance to build the test() function with perl support we would add:

depends="perl"
makedepends="perl-dev"

If we would install the base package it would not install perl, but if we install the package-test package it would.

==== Patches ====

Please make sure you always submit human readable patches. Ways to create them are:

directory compare:

{{Cmd|diff -Nurp original_directory new_directory > filename.patch}}

file compare:

{{Cmd|diff -up original.file new.file > filename.patch}}

If a patch contains a completely new file but not *.rej or *.orig file, you need to add -N option to diff, but you may need to add exclusions with <code>--exclude PATTERN</code> so that you do not inadvertently add files. You may need to manually delete unwanted files inside the patch file.

Because multiple patches can patch the same file, they can change the offsets required by subsequent patches. To make sure we always patch in a specific way, we should number the patches as follows:

10-patch1.patch 20-patch2.patch 30-patch3.patch

This way we are always sure that patch 1 is applied first, and if we want to add additional patches between them we can use appropriate indexes (e.g. 11, 12, 21, 22).

Add the names of the patch files to the ''source'' variable. If you haven't declared a custom ''prepare'' function, no further action is necessary. Otherwise, be sure to call ''default_prepare'' in your ''prepare'' function. For example:

prepare() {
default_prepare

# do your stuff
}

Note: Some older packages contain a ''for'' loop in the ''prepare'' function to apply patches. This is not needed anymore, as patches are handled by ''default_prepare''.

In Alpine >=3.4 you can define patch_args to supply the patch level. This only works if all the patches have the same patch level. If there are a lot of patches from different sources, there is a good chance that you may need to edit them, as discussed below.

To automatically patch the package (available only in Alpine >=3.4) if it uses a patch level (-pX) other than the default (-p1), you need to carefully modify the patch. First, you'll need a text editor that does not automatically convert between Windows and Unix new lines (or, disable this feature) so that it preserves the old code. The next thing you'll need to do is modify the paths on "+++" and "---" lines in the .patch file. You can begin the path with a/ and b/ like shown below. Next, you need to adjust the paths so that the relative base path is from inside $builddir. Anything to the left of $builddir, including $builddir itself, needs to be removed from the path. So, if $builddir is /home/USER/aports/community/chromium/src/chromium-65, you need to erase it on the "+++" and "---" lines. Inside the chromium-65 folder you can see a src folder that has 3rdparty as a descendant. If a patch originally has a deeper patch level, you may need to fill in the missing portion of the path. For example, use the <code>find . -name "Assertions.cpp"</code> command to find the full path to the file relative to the base.

{{Cat|example.patch|<nowiki>
Author: John Doe <johndoe@mail.com>
URL: http://.....
Summary: Fixes musl compatibility
----
--- a/src/3rdparty/chromium/third_party/WebKit/Source/wtf/Assertions.cpp.orig
+++ b/src/3rdparty/chromium/third_party/WebKit/Source/wtf/Assertions.cpp
@@ -142,7 +142,7 @@
};

FrameToNameScope::FrameToNameScope(void* addr) : m_name(0), m_cxaDemangled(0) {
-#if OS(MACOSX) || (OS(LINUX) && !defined(__UCLIBC__))
+#if OS(MACOSX) || (OS(LINUX) && defined(__GLIBC__))
Dl_info info;
if (!dladdr(addr, &info) || !info.dli_sname)
return;
</nowiki>}}

Portions of the patch may be outdated, removed completely as in the source code file completely removed, or moved or renamed files. You need to delete that section of the patch or find where that section of code changed and re-diff it.

It is good etiquette to give credit at the top and the location of where you originally found them with notes.

Excluding patches with global variable resembling patch_opts is not available on Alpine. To exclude patches you need to create your own custom prepare().

If you have a monolithic patch where there are a bunch of patches in one big patch, you could use filterdiff which is available in the patchutils package.

Just do something like:

<pre>
makedepends="patchutils"

prepare() {
...
cd "$builddir"
filterdiff -x '*drivers/video/logo*' "$srcdir"/original.patch > "$builddir"/modified.patch
patch -p1 -i "$builddir"/modified.patch
}
</pre>

You need to put the wildcard pattern in single quotes for it to work.

==== Configure options ====

Alpine has some default configure options we set by default. We use /usr for prefix to make sure everything is installed with /usr in front of it. If you notice that anything is installed in the wrong directory please run {{Cmd|./configure --help}} and see if you can set the correct location.

We are not covering the depend switches here we have discussed this already in the depend section.

==== Make options ====

If you notice weird problems when compiling or installing the package with make/make install you could try to disable [http://www.gnu.org/software/make/manual/make.html#Parallel parallel] building/installing. A normal make line would be:

make

To disable parallel we use:

make -j1

We can use the same for make install.

Because we do not want to install the package in our build environment but we want to install it in a fake root directory we need to tell 'make install' to use another destination directory instead of '/'. We do this by setting a variable when we execute make install as followed:

make DESTDIR="$pkgdir" install

Please note that some Makefiles do not support this variable and will always install software in '/'. To make sure you do not mess up your build system NEVER run your build system as root but always use a custom user and doas when needed. If by accident the Makefile does not support DESTDIR variable it will fail to install in our build system system directories.

==== builddir ====
If you used <tt>newapkbuild</tt> to create your APKBUILD file, you must specify the path to your unpacked sources. Inside the sections during the prepare/build/install process ''builddir'' is used. Most of the time a combination of ''$srcdir'' and ''$pkgname-$pkgver'' will work. When not, check the /src directory or the source tarball for the right string. Especially when you are working with automatically generated tarballs (like from github and gitorious), this needs to be adjusted.

builddir="$srcdir"/$pkgname-$pkgver

==== Additional files ====

If you want/need to install additional files not mentioned above you can use the following cmd (this is an example of a conf file):

install -Dm644 doc/$pkgname.conf "$pkgdir"/etc/$pkgname.conf

== Build the package ==

If you did not already create the checksums as mentioned above you can do so now:

{{Cmd|cd $pkgname
abuild checksum}}

It's about time we build our package. Because a build system should never have all the package installed to prevent linking to packages we don't want it to link we use a abuild recursively with the '''-r''' switch. It will install all dependencies from your repository and builds it, afterwards it will uninstall all those depending packages again. You could also use the '''-R''' switch which would build your package including the dependency packages.

{{Cmd|abuild -r}}

== Testing the package locally ==

When it completes, your package will be found in a subfolder of <code>~/packages</code>. You may want to test it on your machine but only if the package is not a critical system package like musl or apk-tools package. To avoid borking your system (as in making it impossible to use <code>apk add</code> or to restore back the system and the compiler toolchain) for a critical system package, you should test on a chroot first before using it live.

The best way to test a package locally is to modify your <code>/etc/apk/repositories</code> so that it includes the indexes to your locally built packages - the directories that contain <code>ARCH/APKINDEX.tar.gz</code>. For example the <code>/etc/apk/repositories</code> below includes locally built packages in testing, community and main. To use this example change <code>USER</code> to your login name.

{{Cat|/etc/apk/repositories|/home/USER/packages/testing/
/home/USER/packages/community/
/home/USER/packages/main/
/media/sdc/apks
#http://dl-2.alpinelinux.org/alpine/v3.7/main
#http://dl-2.alpinelinux.org/alpine/v3.7/community
http://dl-2.alpinelinux.org/alpine/edge/main
http://dl-2.alpinelinux.org/alpine/edge/community
http://dl-2.alpinelinux.org/alpine/edge/testing
}}

If you prefer to test a package without changing any other configuration you can use the <code>-X, --repository</code> option to <code>apk</code>:

{{Cmd|sudo apk add --repository /home/USER/packages/testing $pkgname}}

== Code review ==

To successfully have your package pass through code reviewers (as of Feb 18, 2018 are nmeum and jirutka on GitHub) and possible increased acceptance, the following conventions need to be followed:

# Custom global variables should be prefixed with underscore (_).
# Compact code as in merged commands, removed unused variables, removal of functions that do the same thing that are automatically handled by abuild.
# Versioning is done properly. For details see [[APKBUILD_Reference#pkgver]].
# Licensing is done properly. Remove unnecessary copying of licensing that is already OSI approved.
# Naming conventions rules for unofficial variables as in _gitrev is preferred over commit.
# Indent with tabs not spaces.
# Removal of explicit return 1. (They are still found the old APKBUILD files if you are learning but are now strongly discouraged.)
# Disabling check() requires either (1) a comment (#) stating next to options="!check" that there is no test suite/unit tests or (2) functioning working check() function.
# Explicit call to subpackages="$pkgname-doc" must be used instead of explicit gzip man page compression.
# Ideally, lines should be no more than 80 columns wide

Additionally, make sure to run the linter on your package:
{{Cmd|sudo apk add atools
apkbuild-lint APKBUILD}}

For more information see [[Development using git:Quality assurance]] and [[Package_policies]].

== Commit your work ==

After you successfully build your package and properly followed the conventions and requirements in the code review section, you can submit your APKBUILD to Alpine's git repository.

Update your git repo, before adding new files:

{{Cmd|cd $aportsdir
git pull}}

This should pull all the changes made by others into your local git repo.

When you think you are ready you can add your files to git:

NOTE: when using our Gitlab instance, you can create MR's for each package. Please squash all commits related to the same package into a single one per MR.

{{Cmd|cd $aportsdir
git add testing/$pkgdir (include any other files needed for the build; $pkgname.install...)
git commit}}

Use the following commit message template for new aports (without the comments):

{{Cat|template|testing/$pkgname: new aport # this will be the subject line
# a blank line
$url # project homepage
$pkgdesc # one line description}}

Or you could add the following and <code>chmod +x ports/.git/hooks/prepare-commit-msg</code> to automatically generate commit message which the default aports/.githooks/ does not:

{{Cat|aports/.git/hooks/prepare-commit-msg|<nowiki>#!/bin/sh
case "$2,$3" in
,|template,)
if git diff-index --diff-filter=A --name-only --cached HEAD \
| grep -q '/APKBUILD$'; then
meta() { git diff --staged | grep "^+$1" | sed 's/.*="\?//;s/"$//';}
printf 'testing/%s: new aport\n\n%s\n%s\n' "$(meta pkgname)" \
"$(meta url)" "$(meta pkgdesc)" "$(cat $1)" > "$1"
else
printf '%s\n\n%s' `git diff-index --name-only --cached HEAD \
| sed -n 's/\/APKBUILD$//p;q'` "$(cat $1)" > "$1"
fi;;
esac</nowiki>}}

Now your changes are only available locally in your repository.

Because you do not have push rights to the Alpine aports repository you need to create a merge request to [https://gitlab.alpinelinux.org/alpine/aports Alpine's GitLab instance].

Alternatively you can also create a diff (patch) of the changes you made and send this patch to the
[https://lists.alpinelinux.org/~alpine/aports alpine-aports mailinglist].

To create a diff patch:

{{Cmd|git format-patch HEAD^}}

or if you have sprunge, you can create a link to your patch for convenience

{{Cmd|git format-patch HEAD^ --stdout <nowiki>|</nowiki> sprunge}}

== Travis CI and automated testing ==

Travis CI, as in continuous integration automated testing, isn't always required, but 99% of the time it is strongly encouraged to pass with a green checkmark. Passing Travis CI ensures that your package works on another machine and builds the image starting from nothing. One reason why your package fails to build on the remote server is that you may inadvertently add a package dependency as in creating multiple packages at the same time or forgot to remove a dependency and forgot to mark it as a makedepends.

When you submit your APKBUILD as a pull request, the Travis CI server will construct the build environment from [https://github.com/alpinelinux/aports/blob/master/.travis/install-alpine#L28 main] [https://github.com/alpinelinux/aports/blob/master/.travis/common.sh#L5 Edge] apks.

The environment is just like a boot into command line so it is minimal. Don't assume that you boot into X.

The server/configuration cannot do testing/check() testing on hardware accelerated OpenGL apps.

== Send a patch ==

[[Creating_patches#Only_the_last_commit_with_.27git_send-email.27|git send-email]] will do that for you.

== GitHub Tagging ==

If you see your pull requested labeled on GitHub this is what they mean:

*A-add - The pull requester wanted to add this brand new package.
*A-upgrade - The pull requester wanted to update the package.
*A-improve - The pull requester wanted to improve an existing package.
*A-fix - The pull requester wanted to fix a bug with the existing package.
*S-changes-requested - An admin wants you to add or remove a subpackage or fix something as in messy code.
*S-needs-review - An admin needs someone to do a code review on your package.
*S-broken - The package fails to build locally on the code reviewer machine.
*ci-malfunction - Travis CI doesn't work with this package as in exceeded time.

== See Also ==
* [[APKBUILD Reference]]
* [[APKBUILD examples]]
* [[Development using git]]
* [[Development using git:Quality assurance]]

[[category: Package Manager]]

Include:Setup your system and account for building packages

2021-11-25T19:46:54Z

Eddsalkield: Use doas instead of sudo

The {{Pkg|alpine-sdk}} is a metapackage that pulls in the most essential packages used to build new packages. We'll also install doas to perform superuser operations, and nano to allow us to edit text:

{{Cmd|apk add alpine-sdk doas nano}}

This would be a good time to [[Setting_up_a_new_user|create a normal user account for you to work in]]. To make life easier later, it's a good idea to add this user to the wheel group; operations that require superuser privileges can now be done with doas.

The [[Aports_tree|aports tree]] is in git so before we clone the it, let's configure git.

{{Cmd|git config --global user.name "Your Full Name"
git config --global user.email "your@email.address"}}

Read carefully [[Development using git]] to grasp basic Git operations and how to configure for sending email patches.

Now we can clone the [[Aports_tree|aports tree]].

{{Cmd|git clone https://gitlab.alpinelinux.org/alpine/aports}}

Before we start creating or modifying [[APKBUILD_Reference|APKBUILD]] files, we need to setup abuild for our system and user. Edit the file {{Path|abuild.conf}} to your requirements:

{{Cmd|doas nano /etc/abuild.conf}}

Most of the defaults can be left alone, unless you are developing for a custom platform, in which case the comments in the file should guide you. The one field to edit is PACKAGER, so that you can get credit (or blame) for packages you create.

To use 'abuild -r' command to install dependency packages automatically.
{{Cmd|doas addgroup <yourusername> abuild}}

We also need to prepare the location where the build process caches files when they are downloaded. By default this is {{Path|/var/cache/distfiles/}}. To create this directory and ensure that it is writeable, enter the following commands:

{{Cmd|doas mkdir -p /var/cache/distfiles
doas chmod a+w /var/cache/distfiles}}

As an alternative to the second command, you can add yourself to the abuild group:

{{Cmd|doas chgrp abuild /var/cache/distfiles
doas chmod g+w /var/cache/distfiles}}

{{Note|Remember to logout and login again for the group change to have effect.}}

The last step is to configure the security keys with the [[Abuild-keygen|abuild-keygen]] script for [[Abuild|abuild]] with the command:

{{Cmd|abuild-keygen -a -i}}

[[Category:Development]]

Setting up a new user

2021-11-25T19:37:40Z

Eddsalkield: /* Creating a new user */

The <code>root</code> account should be used only for local administrative purposes that require elevated access permissions.

This page shows how to create non-privileged user accounts. i.e. those used for daily work, including desktop use and remote logins.

= Overview =

Creating user accounts provides users with their own $HOME directory and allows you (the root user) to limit the access those user accounts have to the operating system configuration files.

Using them increases security, because they limit possible actions and thus possible damage (even from accidental errors).

= Creating a new user =

{{Warning|If using a '''"diskless" or "data" disk mode''' installation, it's important to make the <code>/home</code> directory persistent.
 
* Either the <code>/home</code> filesystem needs to be mounted from a writable partition, or
* the /home directories have to be added to the lbu backup, and a new local backup needs to be committed after creating the user:
{{Cmd| # lbu include /home
# lbu commit
}} (Not recommended, as reverting to an older .apkovl will also revert the files in /home).
}}

Regular user accounts can be created with:
{{Cmd|# adduser [-g "<Full Name>"] <username>}}

By default, adduser will:
* prompt you to set a password for the new user
* create a home directory in {{Path|/home/<username>}}
* set the shell to the one used by the <code>root</code> account (ash by default)
* assign user ID and group ID starting at 1000
* set the GECOS (full name) field to "Linux User,,,"

{{Tip|The optional <code>-g "<Full Name>"</code> above sets the GECOS field.
This can be very useful to specify. Setting this string - at least equal to the username - makes the user distinguishable, e.g. when they are listed at the login screen of a display manager.
}}

'''Only''' if <code>elogind</code> is not being used and running, then X users would need to be added to the video and input groups to be able to work with a graphical display.
adduser 'UserName' video
adduser 'UserName' input

'''If a user ''really must'' be allowed to have access to the root account''', the <username> can be added to the wheel group, <code>doas</code> ("do as") may be installed, and the group "wheel" can be allowed to become root:
adduser -g "<username>" <username>
adduser <username> wheel
apk add doas
apk add nano
nano /etc/doas.conf

Ensure that this file contains
permit persist :wheel

{{Warning|It's recommended to '''not''' run complete applications, like editors, as root just to modify administrative files.
 
* Many desktop environments and file browsers support using <code>admin:///</code> in their address bars, to access files through a local gvfs-admin mount
* [https://github.com/AN3223/scripts/blob/master/doasedit <code>doasedit</code>] or <code>sudoedit</code>([https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.15.0#Move_from_sudo_to_doas being deprecated in favour of <code>doas</code>]) enables starting an editor with a temporary copy of a file, which overwrites the original file after the user modifies and saves it. For example, <code>sudoedit /etc/apk/lbu.conf</code>
}}
The <code>sudo</code> package is an alternative to using the BSD-like <code>doas</code>, but is a much larger package.
It may be used as follows: adding a custom user configuration file to avoid having to deal with manually changing configuration files later during package upgrades.
apk add sudo
NEWUSER='yourUserName'
adduser -d "${NEWUSER}" $NEWUSER
echo "$NEWUSER ALL=(ALL) ALL" > /etc/sudoers.d/$NEWUSER && chmod 0440 /etc/sudoers.d/$NEWUSER

The new user gets listed in

{{Cat|/etc/passwd|root:x:0:0:root:/root:/bin/ash
.
.
.
<username>:x:1000:1000:Linux User,,,:/home/<username>:/bin/ash}}

Now you should be able to issue the command <code>exit</code> and login to the new account.

= Options =

=== adduser ===

Usage (from "man busybox"):

<pre><nowiki>adduser [OPTIONS] USER [GROUP]

Create new user, or add USER to GROUP

-h --home DIR Home directory
-g --gecos GECOS GECOS field
-s --shell SHELL Login shell named SHELL by example /bin/bash
-G --ingroup GRP Group (by name)
-S --system Create a system user
-D --disabled-password Don't assign a password, so cannot login
-H --no-create-home Don't create home directory
-u --uid UID User id
-k SKEL Skeleton directory (/etc/skel)
</nowiki></pre>

{{Tip|Multi-user collaboration
If <nowiki>--ingroup</nowiki> isn't set, (default) the new user is assigned a new GID that matches the UID. If the GID corresponding to a provided UID already exists, adduser will fail.

This ensures new users default to having a "user's private group" (UPG) as primary group. These allow the system to use a permission umask (002), which creates new files automatically as group-writable, but only by the user's private group. In special set-group-id (collaboration) directories, new files can be automatically created writable by the directory's group.
}}

=== addgroup ===

Usage (from "man busybox"):

<pre><nowiki>addgroup [-g GID] [-S] [USER] GROUP

Create a group or add a user to a group

-g --gid GID Group id
-s --system Create a system group
</nowiki></pre>

= Legacy =

=== Common permission groups ===

(Taken from https://git.alpinelinux.org/alpine-baselayout/tree/group)

* '''disk''':x:6:root,adm needed only for use vith virtual machines and access to other partitions.
* '''lp''':x:7:lp needed for printing services and printers management.
* '''wheel''':x:10:root Administrator group, members can use <code>sudo</code> to run commands as root if enabled in the sudo configuration.
* '''floppy''':x:11:root Backward compatible group. Use only if access to special external devices is needed.
* '''audio''':x:18: Needed for audio listening and management of sound volume as normal user.
* '''cdrom''':x:19: For access to CD/DVD/BR writers and mounting DVD, BR or CD rom disk as normal user.
* '''dialout''':x:20:root Needed for dialing private connections and use of modems as normal user.
* '''tape''':x:26:root Needed if you're planning to use special devices for backup. Rare. Ususally used only on servers.
* '''video''':x:27:root For usage of cameras, more than one GPU special features, as normal user.
* '''netdev''':x:28: For network connections management as normal user.
* '''kvm''':x:34:kvm Only if a normal user will manage virtual machines via a GUI. Rare. Ususally used only on servers.
* '''games''':x:35: Needed if you want to play games. Especially if sharing scores between users.
* '''cdrw''':x:80: Needed to write RW-DVD, RW-BR or RW-CD disk on a disk writing device.
* '''apache''':x:81: Needed if you do development as normal user and want to publish locally on web server.
* '''usb''':x:85: Needed to access to special usb devices. Deprecated group.
* '''users''':x:100:games Needed if you plan to use common files for all users. Mandatory for desktop usage.

= Old newbie notes =

=== User creation and defaults ===

The following commands will set up root environment login, then assign a new password:

<pre><nowiki>
cat > /root/.cshrc << EOF
unsetenv DISPLAY || true
HISTCONTROL=ignoreboth
EOF

cp /root/.cshrc /root/.profile

echo "secret_new_root_password" | chpasswd
</nowiki></pre>

By default, remote management cannot be done directly with the root account. Because of SSH security we need to set up a remote connection account that will be used to switch to the root user via the su command, once connected.

Here's an example: create user named "remote" and a user named "general". We will set up a hardened, limited, user environment and create those two users:

<pre><nowiki>
mkdir -p /etc/skel/

cat > /etc/skel/.logout << EOF
history -c
/bin/rm -f /opt/remote/.mysql_history
/bin/rm -f /opt/remote/.history
/bin/rm -f /opt/remote/.bash_history
EOF

cat > /etc/skel/.cshrc << EOF
set autologout = 30
set prompt = "$ "
set history = 0
set ignoreeof
EOF

cp /etc/skel/.cshrc /etc/skel/.profile

adduser -D --home /opt/remote --shell /bin/ash remote

echo "secret_new_remote_user_password" | chpasswd

adduser -D --shell /bin/bash general

echo "secret_new_general_user_password" | chpasswd
</nowiki></pre>

{{Tip|"'''general'''" is the name of the user. That name MUST contain ONLY lowercase letters, NO spaces and NO symbols}}

Note that those users are created with minimal privilege settings.

== User management and system access ==

By default, a newly created user will not have enough privileges for most desktop purposes.

To add newly created users to groups that may come in handy for desktop useage, you run this command as root:

<pre><nowiki>
for u in $(ls /home); do for g in disk lp floppy audio cdrom dialout video netdev games users; do addgroup $u $g; done;done
</nowiki></pre>

Setting up a new user

2021-11-25T19:31:34Z

Eddsalkield: Specify that sudo is being deprecated in favour of doas

The <code>root</code> account should be used only for local administrative purposes that require elevated access permissions.

This page shows how to create non-privileged user accounts. i.e. those used for daily work, including desktop use and remote logins.

= Overview =

Creating user accounts provides users with their own $HOME directory and allows you (the root user) to limit the access those user accounts have to the operating system configuration files.

Using them increases security, because they limit possible actions and thus possible damage (even from accidental errors).

= Creating a new user =

{{Warning|If using a '''"diskless" or "data" disk mode''' installation, it's important to make the <code>/home</code> directory persistent.
 
* Either the <code>/home</code> filesystem needs to be mounted from a writable partition, or
* the /home directories have to be added to the lbu backup, and a new local backup needs to be committed after creating the user:
{{Cmd| # lbu include /home
# lbu commit
}} (Not recommended, as reverting to an older .apkovl will also revert the files in /home).
}}

Regular user accounts can be created with:
{{Cmd|# adduser [-g "<Full Name>"] <username>}}

By default, adduser will:
* prompt you to set a password for the new user
* create a home directory in {{Path|/home/<username>}}
* set the shell to the one used by the <code>root</code> account (ash by default)
* assign user ID and group ID starting at 1000
* set the GECOS (full name) field to "Linux User,,,"

{{Tip|The optional <code>-g "<Full Name>"</code> above sets the GECOS field.
This can be very useful to specify. Setting this string - at least equal to the username - makes the user distinguishable, e.g. when they are listed at the login screen of a display manager.
}}

'''Only''' if <code>elogind</code> is not being used and running, then X users would need to be added to the video and input groups to be able to work with a graphical display.
adduser 'UserName' video
adduser 'UserName' input

'''If a user ''really must'' be allowed to have access to the root account''', the <username> can be added to the wheel group, <code>doas</code> ("do as") may be installed, and the group "wheel" can be allowed to become root:
adduser -g "<username>" <username>
adduser <username> wheel
apk add doas
apk add nano
nano /etc/doas.conf

{{Warning|It's recommended to '''not''' run complete applications, like editors, as root just to modify administrative files.
 
* Many desktop environments and file browsers support using <code>admin:///</code> in their address bars, to access files through a local gvfs-admin mount
* [https://github.com/AN3223/scripts/blob/master/doasedit <code>doasedit</code>] or <code>sudoedit</code>([https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.15.0#Move_from_sudo_to_doas being deprecated in favour of <code>doas</code>]) enables starting an editor with a temporary copy of a file, which overwrites the original file after the user modifies and saves it. For example, <code>sudoedit /etc/apk/lbu.conf</code>
}}
The <code>sudo</code> package is an alternative to using the BSD-like <code>doas</code>, but is a much larger package.
It may be used as follows: adding a custom user configuration file to avoid having to deal with manually changing configuration files later during package upgrades.
apk add sudo
NEWUSER='yourUserName'
adduser -d "${NEWUSER}" $NEWUSER
echo "$NEWUSER ALL=(ALL) ALL" > /etc/sudoers.d/$NEWUSER && chmod 0440 /etc/sudoers.d/$NEWUSER

The new user gets listed in

{{Cat|/etc/passwd|root:x:0:0:root:/root:/bin/ash
.
.
.
<username>:x:1000:1000:Linux User,,,:/home/<username>:/bin/ash}}

Now you should be able to issue the command <code>exit</code> and login to the new account.

= Options =

=== adduser ===

Usage (from "man busybox"):

<pre><nowiki>adduser [OPTIONS] USER [GROUP]

Create new user, or add USER to GROUP

-h --home DIR Home directory
-g --gecos GECOS GECOS field
-s --shell SHELL Login shell named SHELL by example /bin/bash
-G --ingroup GRP Group (by name)
-S --system Create a system user
-D --disabled-password Don't assign a password, so cannot login
-H --no-create-home Don't create home directory
-u --uid UID User id
-k SKEL Skeleton directory (/etc/skel)
</nowiki></pre>

{{Tip|Multi-user collaboration
If <nowiki>--ingroup</nowiki> isn't set, (default) the new user is assigned a new GID that matches the UID. If the GID corresponding to a provided UID already exists, adduser will fail.

This ensures new users default to having a "user's private group" (UPG) as primary group. These allow the system to use a permission umask (002), which creates new files automatically as group-writable, but only by the user's private group. In special set-group-id (collaboration) directories, new files can be automatically created writable by the directory's group.
}}

=== addgroup ===

Usage (from "man busybox"):

<pre><nowiki>addgroup [-g GID] [-S] [USER] GROUP

Create a group or add a user to a group

-g --gid GID Group id
-s --system Create a system group
</nowiki></pre>

= Legacy =

=== Common permission groups ===

(Taken from https://git.alpinelinux.org/alpine-baselayout/tree/group)

* '''disk''':x:6:root,adm needed only for use vith virtual machines and access to other partitions.
* '''lp''':x:7:lp needed for printing services and printers management.
* '''wheel''':x:10:root Administrator group, members can use <code>sudo</code> to run commands as root if enabled in the sudo configuration.
* '''floppy''':x:11:root Backward compatible group. Use only if access to special external devices is needed.
* '''audio''':x:18: Needed for audio listening and management of sound volume as normal user.
* '''cdrom''':x:19: For access to CD/DVD/BR writers and mounting DVD, BR or CD rom disk as normal user.
* '''dialout''':x:20:root Needed for dialing private connections and use of modems as normal user.
* '''tape''':x:26:root Needed if you're planning to use special devices for backup. Rare. Ususally used only on servers.
* '''video''':x:27:root For usage of cameras, more than one GPU special features, as normal user.
* '''netdev''':x:28: For network connections management as normal user.
* '''kvm''':x:34:kvm Only if a normal user will manage virtual machines via a GUI. Rare. Ususally used only on servers.
* '''games''':x:35: Needed if you want to play games. Especially if sharing scores between users.
* '''cdrw''':x:80: Needed to write RW-DVD, RW-BR or RW-CD disk on a disk writing device.
* '''apache''':x:81: Needed if you do development as normal user and want to publish locally on web server.
* '''usb''':x:85: Needed to access to special usb devices. Deprecated group.
* '''users''':x:100:games Needed if you plan to use common files for all users. Mandatory for desktop usage.

= Old newbie notes =

=== User creation and defaults ===

The following commands will set up root environment login, then assign a new password:

<pre><nowiki>
cat > /root/.cshrc << EOF
unsetenv DISPLAY || true
HISTCONTROL=ignoreboth
EOF

cp /root/.cshrc /root/.profile

echo "secret_new_root_password" | chpasswd
</nowiki></pre>

By default, remote management cannot be done directly with the root account. Because of SSH security we need to set up a remote connection account that will be used to switch to the root user via the su command, once connected.

Here's an example: create user named "remote" and a user named "general". We will set up a hardened, limited, user environment and create those two users:

<pre><nowiki>
mkdir -p /etc/skel/

cat > /etc/skel/.logout << EOF
history -c
/bin/rm -f /opt/remote/.mysql_history
/bin/rm -f /opt/remote/.history
/bin/rm -f /opt/remote/.bash_history
EOF

cat > /etc/skel/.cshrc << EOF
set autologout = 30
set prompt = "$ "
set history = 0
set ignoreeof
EOF

cp /etc/skel/.cshrc /etc/skel/.profile

adduser -D --home /opt/remote --shell /bin/ash remote

echo "secret_new_remote_user_password" | chpasswd

adduser -D --shell /bin/bash general

echo "secret_new_general_user_password" | chpasswd
</nowiki></pre>

{{Tip|"'''general'''" is the name of the user. That name MUST contain ONLY lowercase letters, NO spaces and NO symbols}}

Note that those users are created with minimal privilege settings.

== User management and system access ==

By default, a newly created user will not have enough privileges for most desktop purposes.

To add newly created users to groups that may come in handy for desktop useage, you run this command as root:

<pre><nowiki>
for u in $(ls /home); do for g in disk lp floppy audio cdrom dialout video netdev games users; do addgroup $u $g; done;done
</nowiki></pre>

Creating an Alpine package

2021-11-23T13:13:15Z

Eddsalkield: Specify the "custom" license identifier

{{TOC right}}

== Requirements ==

To build a package for Alpine Linux you need an Alpine Linux installation. Check the [[Installation]] page to see all available installation options.

== Setup your system and account ==
{{:Include:Setup_your_system_and_account_for_building_packages}}

== Getting some help ==

It might be wise to start by checking what the [[Abuild|abuild]] program can/cannot do.

{{Cmd|abuild -h}}

For real help, you can also go on OFTC's #alpine-devel on IRC.

A reference for APKBUILD files is available as a man page in the 'abuild-doc' package:

{{Cmd|man APKBUILD}}

== Creating an APKBUILD file ==

=== Use a template APKBUILD ===

To create the actual APKBUILD file {{Pkg|newapkbuild}} can serve you a template to start with. It will create a directory with the given package name, place an example/template APKBUILD file to the given directory, and fill some variables if those are provided. Please check the [[Package_policies| package policies]] page about naming details.

If you doubt to which repository your package belongs to you can safely use '''testing'''. Building package in your aports/testing directory is not mandatory but this way the package is already at the right place.

{{:Include:Newapkbuild}}

{{Note|On older Alpine systems, abuild -c -n ''packagename'' was the way to create APKBUILD files. The 'packagename' was a parameter to the -n option so order of -c and -n matters. }}

[[Abuild_and_Helpers#apkbuild-cpan|apkbuild-cpan]] simplifies the creation of perl packages from CPAN and [[Abuild_and_Helpers#apkbuild-pypi|apkbuild-pypi]] ease the generation of APKBUILD files for python packages from PyPi.

If you are creating a daemon package which needs initd scripts you can add the -c making it:

{{Cmd|newapkbuild -c ''packagename''}}

This will copy the sample initd and confd files to the build directory. 
A third file sample.install file will be copied as well (we will discuss this later on).

=== Modify your APKBUILD ===
Edit APKBUILD and fill in the needed info (especially pkgname, pkgver, pkgdesc, url, license, depends and source).

If you are going to use any of the variables for directories like $pkgdir, always make sure they are double quoted like:

"$pkgdir"/somedir

This will prevent issues with spaces/special characters in the future.

{{Note|If you like syntax highlighting we suggest you to install vim. We have setup vim to recognize the APKBUILD file as a bash scripts so its easier to read them.}}

=== APKBUILD variables/functions ===

==== source ====

The source variable is not only used to list the remote source files to fetch, it is also used to list the local files that abuild will need in order to build the apk. Examples of such local files include: init.d files, conf.d files, install files (see [[Creating an Alpine package#install|install variable]]), patches, and all other necessary files.

Here are few things to note:

* When you are finished adding local and/or remote files to ''source'', you can execute the following command to add their checksums to the APKBUILD file:
: {{cmd|abuild checksum}}
: {{Note|When later updating the content of ''source'', or updating a file that is listed in ''source'', you must also update their checksums again with the same command.}}

* When the remote file is hosted at SourceForge, it's best to specify the special mirrors link used by SourceForge:
: <pre>http://downloads.sourceforge.net/$pkgname/$pkgname-$pkgver.tar.gz</pre>
: (or similar depending on the package).

* When the remote filename is not specified in the URI (ie, does not end in '/software-1.0.tar.gz'), such as:
: <pre>http://oss.example.org/?get=software&ver=1.0</pre>
: You must prepend '${pkgname}-${pkgver}.tar.gz::' to the protocol, like so:
: <pre>source="${pkgname}-${pkgver}.tar.gz::http://oss.example.org/?get=software&ver=1.0"</pre>
: This causes the file to be saved as ''software-1.0.tar.gz'' where abuild can use it, instead of ''?get=software&ver=1.0'', where abuild cannot use it.

* Some projects didn't provide a release tarball. Beware that some git services (gitweg, cgit, …?) doesn’t provide ''stable'' tarballs, so when you point source to an tarball like <tt>http://repo.or.cz/w/gitstats.git/snapshot/ad7efbb9399e60cee6cb217c6b47e604174a8093.tar.gz</tt>, then you will run into issues because the checksum changes when downloading on the build system. This is not a problem on GitHub, GitLab and other decent services provides, they provide ''stable'' tarballs.

* abuild currently supports the following protocols for remote file retrieval:
** http
** https
** ftp



* abuild currently supports the following archive types/archive file extensions:
** .tar
** .tar.gz / .tgz
** .tar.bz2
** .tar.lz (only in Alpine >=3.7)
** .tar.lzma
** .tar.xz
** .zip

==== depends & makedepends ====

Depends are the actual running dependencies that a package would need when it is running. Makedepends are only needed when you are building a package. If you set a package in depends, you do not need to add it to makedepends as well. The best way to find out what the depends and makedepends of a package are is to [http://en.wikipedia.org/wiki/Rtfm RTFM].

No kidding, lots of important information can be found in the package INSTALL and README files (or the likes). Another good way is the run <code>./configure --help</code> from the source directory to see which options are needed for configure to finish without errors. If you do not yet have a source directory you can create one with the command:

{{Cmd|abuild unpack}}

Running <code>configure</code> will also show you how you can disable a specific option for this package. For instance, a good example is "--disable-nls" which will disable native language support and thus does not depend on gettext (libiconv, glib, ...).

Alpine likes to keep things small, so we try to disable as much as possible without losing too many features. The exact disable/enable options are decided by the package builder but please try to follow Alpine's design concept as much as possible.

An easy way of quickly finding out the build info for a package is to check Arch Linux (Alpine package management and build scripts are similar) or Gentoo Linux ebuilds (previous versions of Alpine were based on Gentoo).

* [https://gitweb.gentoo.org/repo/gentoo.git/tree/ Gentoo Ebuilds]
* [http://www.archlinux.org/packages/search/ Arch Linux packages] [https://aur.archlinux.org/ Arch Linux User Repository]

After the package is successfully compiled and created we should make sure it didn't link to any package that is not present in the <code>$depends</code> variable. We do this by using <code>scanelf</code>. If scanelf is not yet installed on your system you can do that by installing {{Pkg|pax-utils}}.

{{Cmd|scanelf -nR pkg}}

An example output of {{Pkg|libcurl}} would be:

ET_DYN libssl.so.0.9.8,libcrypto.so.0.9.8,libz.so.1,libc.so.0,ld-uClibc.so.0 pkg/usr/lib/libcurl.so.4.1.1

You can see the needed files and should be able to find out which file belongs to which package.

==== license ====

The '''license''' tag must reflect the license of the source code. Please check the source tarball for COPYING, LICENSE, or other files with names that indicates that it contains licensing information. Beside the license file most developer include headers in the source code files with licensing details.

If the license is on the [https://spdx.org/licenses/ SPDX License List] or [https://spdx.org/licenses/exceptions-index.html SPDX License Exceptions], use the identifier specified by SPDX.

If a package has a special/custom license or is not listed as [https://opensource.org/licenses/alphabetical OSI approved], use the identifier "custom". We additionally need to provide the license file with the release. Because we want to save space and don't like to have licenses all over our system we have decided to include the license in the doc subpackage. Please follow the following guidelines to add a proper license. Locate the license file inside the source package. Add the doc subpackage to the $subpackages variable as follows:

subpackages="$pkgname-doc"

Add a similar line to the following to your package() function, depending on the license description file:

install -Dm644 COPYING "$pkgdir"/usr/share/licenses/$pkgname/COPYING

If you follow these steps then abuild will automatically add the license to the package-doc apk for you.

{{Warning|It is not acceptable to package software with "unknown" license! If you can't find the license of the source code, please contact the author and ask them to specify the license. }}

==== arch ====

The package architecture(s) to build for. This can be one of: ''x86, x86_64, all,'' or ''noarch'', where ''all'' means all architectures, and ''noarch'' means it's architecture-independent (e.g., a pure-python package).
{{Tip|To determine if your APKBUILD can use ''noarch'', build the package for your architecture and then run "scanelf -R pkg" from the directory that the APKBUILD resides in, in order to scan for ELF files in the ''./pkg'' directory. If you do NOT get output from this, then ''noarch'' can be used.}}

==== url ====

Website address for the program. This is useful later on when either finding documentation or other information about the package.

==== pkgdesc ====

A brief, one line, description of what the package does. Useful for the package management system. It should start with a capital letter and does '''not''' end with a period.

Here is an example from apk_info for the OpenSSH client package:

pkgdesc="Port of OpenBSD's free SSH release - client"

==== pkgver ====

Provide the release number of the package you are building.

==== pkgrel ====

The $pkgrel versioning is made so that if you change something in your APKBUILD file without changing the actual $pkgver, you can increment pkgrel so apk tools will detect it as an update. For instance, if you forget to add a dependency, you can add it afterward and you can +1 pkgver so apk finds this update and adds the missing dependency. When there's an upstream version change, we reset the pkgrel to 0.

==== pkgname ====

The base name of the package you are creating. For Freeswitch 1.0.6, you would use "freeswitch"

==== install ====

There are 6 different kinds of install scripts. Each script is called with the $pkgname.''<action>'' where ''<action>'' is one of the following:

<dl>
<dt>$pkgname.pre-install
<dd>This script is executed before package is installed. Typical use is when package needs a group and a user to be created. For example:
<pre>
#!/bin/sh

addgroup -S clamav 2>/dev/null
adduser -S -D -H -s /bin/false -G clamav -g clamav clamav 2>/dev/null

exit 0
</pre>
Note the ''exit 0'' at the end. If the script exits with failure (if the user already exist), the package will not be installed and <code>apk add</code> will exit with failure.

<dt>$pkgname.post-install
<dd>This script is executed after the package is installed. Can be used to generate font cache and similar.

<dt>$pkgname.pre-upgrade
<dd>Same as pre-install but is executed before upgrading/downgrading/reinstalling an already installed package. Note that exiting with failure will not cause apk to exit with failure, but will mark the package as broken.

<dt>$pkgname.post-upgrade
<dd>Same as post-install but is executed after upgrading/downgrading/reinstalling an already installed package.

<dt>$pkgname.pre-deinstall
<dd>This script is executed before uninstalling a package. If script exits with failure apk will not uninstall the package.

<dt>$pkgname.post-deinstall
<dd>This script is executed after a package have been uninstalled. Can be used to update font caches and restore busybox links. For example:
<pre>
#!/bin/sh
busybox --install -s
</pre>

</dl>

If the package has a pre-install and post-install script the APKBUILD should have the ''install'' variable defined:
<pre>
...
install="$pkgname.pre-install $pkgname.post-install"

...
</pre>

==== subpackages ====

$subpackages are made to split up the normal "make install" into separate packages. The most common subpackages we use are doc and dev. Because we like to keep our target system small we move documentation and development files (only needed when building packages) into separate packages. To use the specific program a user only need to install the base apk without package-doc or package-dev, but if he wants to read the manual he will need to install package-doc.

The easiest way to find out if you need to use -dev and -doc is to first build the package without these options set and wait until the build finishes. When its finished you should have a pkg directory which is the fake root directory. Inside this directory you will see the structure as how it would be installed in / on the target system.

To see if you need the -dev package you can run the following cmd:

{{Cmd|find pkg/usr/ -name '*.[acho]' -o -name '*.la'}}

If this returns any files you need to include the -dev package.

 To see if you need the -doc package you can run the following cmd:

{{Cmd|find pkg/usr/share -name doc -o -name man -o -name info -o -name html -o -name sgml -o -name licenses}}

If this returns any directories you need to include the -doc package.

===== Custom subpackages =====

Some software additionally has non-essential files that do not qualify as either documentation or development content. These files should be placed in their own, specialized subpackage(s). Some packages include large test suites which are only needed in specific circumstances or binaries which have depends which we prefer not to install. To handle those we create our own package/function. In the APKBUILD below the build() function we create another function:

test() {
mkdir -p "$subpkgdir"/usr
mv "$pkgdir"/usr/package-test "$subpkgdir"/usr/
# or amove usr/package-test
}

We also need to add the package info to $subpackages variable:

subpackages="$pkgname-doc $pkgname-dev $pkgname-test"

After we finish building the package you should see another apk called packagename-test.apk which includes the files which we moved to the $subpkgdir dir.

The above mentioned variables can also be used in our custom function. If we want for instance to build the test() function with perl support we would add:

depends="perl"
makedepends="perl-dev"

If we would install the base package it would not install perl, but if we install the package-test package it would.

==== Patches ====

Please make sure you always submit human readable patches. Ways to create them are:

directory compare:

{{Cmd|diff -Nurp original_directory new_directory > filename.patch}}

file compare:

{{Cmd|diff -up original.file new.file > filename.patch}}

If a patch contains a completely new file but not *.rej or *.orig file, you need to add -N option to diff, but you may need to add exclusions with <code>--exclude PATTERN</code> so that you do not inadvertently add files. You may need to manually delete unwanted files inside the patch file.

Because multiple patches can patch the same file, they can change the offsets required by subsequent patches. To make sure we always patch in a specific way, we should number the patches as follows:

10-patch1.patch 20-patch2.patch 30-patch3.patch

This way we are always sure that patch 1 is applied first, and if we want to add additional patches between them we can use appropriate indexes (e.g. 11, 12, 21, 22).

Add the names of the patch files to the ''source'' variable. If you haven't declared a custom ''prepare'' function, no further action is necessary. Otherwise, be sure to call ''default_prepare'' in your ''prepare'' function. For example:

prepare() {
default_prepare

# do your stuff
}

Note: Some older packages contain a ''for'' loop in the ''prepare'' function to apply patches. This is not needed anymore, as patches are handled by ''default_prepare''.

In Alpine >=3.4 you can define patch_args to supply the patch level. This only works if all the patches have the same patch level. If there are a lot of patches from different sources, there is a good chance that you may need to edit them, as discussed below.

To automatically patch the package (available only in Alpine >=3.4) if it uses a patch level (-pX) other than the default (-p1), you need to carefully modify the patch. First, you'll need a text editor that does not automatically convert between Windows and Unix new lines (or, disable this feature) so that it preserves the old code. The next thing you'll need to do is modify the paths on "+++" and "---" lines in the .patch file. You can begin the path with a/ and b/ like shown below. Next, you need to adjust the paths so that the relative base path is from inside $builddir. Anything to the left of $builddir, including $builddir itself, needs to be removed from the path. So, if $builddir is /home/USER/aports/community/chromium/src/chromium-65, you need to erase it on the "+++" and "---" lines. Inside the chromium-65 folder you can see a src folder that has 3rdparty as a descendant. If a patch originally has a deeper patch level, you may need to fill in the missing portion of the path. For example, use the <code>find . -name "Assertions.cpp"</code> command to find the full path to the file relative to the base.

{{Cat|example.patch|<nowiki>
Author: John Doe <johndoe@mail.com>
URL: http://.....
Summary: Fixes musl compatibility
----
--- a/src/3rdparty/chromium/third_party/WebKit/Source/wtf/Assertions.cpp.orig
+++ b/src/3rdparty/chromium/third_party/WebKit/Source/wtf/Assertions.cpp
@@ -142,7 +142,7 @@
};

FrameToNameScope::FrameToNameScope(void* addr) : m_name(0), m_cxaDemangled(0) {
-#if OS(MACOSX) || (OS(LINUX) && !defined(__UCLIBC__))
+#if OS(MACOSX) || (OS(LINUX) && defined(__GLIBC__))
Dl_info info;
if (!dladdr(addr, &info) || !info.dli_sname)
return;
</nowiki>}}

Portions of the patch may be outdated, removed completely as in the source code file completely removed, or moved or renamed files. You need to delete that section of the patch or find where that section of code changed and re-diff it.

It is good etiquette to give credit at the top and the location of where you originally found them with notes.

Excluding patches with global variable resembling patch_opts is not available on Alpine. To exclude patches you need to create your own custom prepare().

If you have a monolithic patch where there are a bunch of patches in one big patch, you could use filterdiff which is available in the patchutils package.

Just do something like:

<pre>
makedepends="patchutils"

prepare() {
...
cd "$builddir"
filterdiff -x '*drivers/video/logo*' "$srcdir"/original.patch > "$builddir"/modified.patch
patch -p1 -i "$builddir"/modified.patch
}
</pre>

You need to put the wildcard pattern in single quotes for it to work.

==== Configure options ====

Alpine has some default configure options we set by default. We use /usr for prefix to make sure everything is installed with /usr in front of it. If you notice that anything is installed in the wrong directory please run {{Cmd|./configure --help}} and see if you can set the correct location.

We are not covering the depend switches here we have discussed this already in the depend section.

==== Make options ====

If you notice weird problems when compiling or installing the package with make/make install you could try to disable [http://www.gnu.org/software/make/manual/make.html#Parallel parallel] building/installing. A normal make line would be:

make

To disable parallel we use:

make -j1

We can use the same for make install.

Because we do not want to install the package in our build environment but we want to install it in a fake root directory we need to tell 'make install' to use another destination directory instead of '/'. We do this by setting a variable when we execute make install as followed:

make DESTDIR="$pkgdir" install

Please note that some Makefiles do not support this variable and will always install software in '/'. To make sure you do not mess up your build system NEVER run your build system as root but always use a custom user and sudo when needed. If by accident the Makefile does not support DESTDIR variable it will fail to install in our build system system directories.

==== builddir ====
If you used <tt>newapkbuild</tt> to create your APKBUILD file, you must specify the path to your unpacked sources. Inside the sections during the prepare/build/install process ''builddir'' is used. Most of the time a combination of ''$srcdir'' and ''$pkgname-$pkgver'' will work. When not, check the /src directory or the source tarball for the right string. Especially when you are working with automatically generated tarballs (like from github and gitorious), this needs to be adjusted.

builddir="$srcdir"/$pkgname-$pkgver

==== Additional files ====

If you want/need to install additional files not mentioned above you can use the following cmd (this is an example of a conf file):

install -Dm644 doc/$pkgname.conf "$pkgdir"/etc/$pkgname.conf

== Build the package ==

If you did not already create the checksums as mentioned above you can do so now:

{{Cmd|cd $pkgname
abuild checksum}}

It's about time we build our package. Because a build system should never have all the package installed to prevent linking to packages we don't want it to link we use a abuild recursively with the '''-r''' switch. It will install all dependencies from your repository and builds it, afterwards it will uninstall all those depending packages again. You could also use the '''-R''' switch which would build your package including the dependency packages.

{{Cmd|abuild -r}}

== Testing the package locally ==

When it completes, your package will be found in a subfolder of <code>~/packages</code>. You may want to test it on your machine but only if the package is not a critical system package like musl or apk-tools package. To avoid borking your system (as in making it impossible to use <code>apk add</code> or to restore back the system and the compiler toolchain) for a critical system package, you should test on a chroot first before using it live.

The best way to test a package locally is to modify your <code>/etc/apk/repositories</code> so that it includes the indexes to your locally built packages - the directories that contain <code>ARCH/APKINDEX.tar.gz</code>. For example the <code>/etc/apk/repositories</code> below includes locally built packages in testing, community and main. To use this example change <code>USER</code> to your login name.

{{Cat|/etc/apk/repositories|/home/USER/packages/testing/
/home/USER/packages/community/
/home/USER/packages/main/
/media/sdc/apks
#http://dl-2.alpinelinux.org/alpine/v3.7/main
#http://dl-2.alpinelinux.org/alpine/v3.7/community
http://dl-2.alpinelinux.org/alpine/edge/main
http://dl-2.alpinelinux.org/alpine/edge/community
http://dl-2.alpinelinux.org/alpine/edge/testing
}}

If you prefer to test a package without changing any other configuration you can use the <code>-X, --repository</code> option to <code>apk</code>:

{{Cmd|sudo apk add --repository /home/USER/packages/testing $pkgname}}

== Code review ==

To successfully have your package pass through code reviewers (as of Feb 18, 2018 are nmeum and jirutka on GitHub) and possible increased acceptance, the following conventions need to be followed:

# Custom global variables should be prefixed with underscore (_).
# Compact code as in merged commands, removed unused variables, removal of functions that do the same thing that are automatically handled by abuild.
# Versioning is done properly. For details see [[APKBUILD_Reference#pkgver]].
# Licensing is done properly. Remove unnecessary copying of licensing that is already OSI approved.
# Naming conventions rules for unofficial variables as in _gitrev is preferred over commit.
# Indent with tabs not spaces.
# Removal of explicit return 1. (They are still found the old APKBUILD files if you are learning but are now strongly discouraged.)
# Disabling check() requires either (1) a comment (#) stating next to options="!check" that there is no test suite/unit tests or (2) functioning working check() function.
# Explicit call to subpackages="$pkgname-doc" must be used instead of explicit gzip man page compression.
# Ideally, lines should be no more than 80 columns wide

Additionally, make sure to run the linter on your package:
{{Cmd|sudo apk add atools
apkbuild-lint APKBUILD}}

For more information see [[Development using git:Quality assurance]] and [[Package_policies]].

== Commit your work ==

After you successfully build your package and properly followed the conventions and requirements in the code review section, you can submit your APKBUILD to Alpine's git repository.

Update your git repo, before adding new files:

{{Cmd|cd $aportsdir
git pull}}

This should pull all the changes made by others into your local git repo.

When you think you are ready you can add your files to git:

NOTE: when using our Gitlab instance, you can create MR's for each package. Please squash all commits related to the same package into a single one per MR.

{{Cmd|cd $aportsdir
git add testing/$pkgdir (include any other files needed for the build; $pkgname.install...)
git commit}}

Use the following commit message template for new aports (without the comments):

{{Cat|template|testing/$pkgname: new aport # this will be the subject line
# a blank line
$url # project homepage
$pkgdesc # one line description}}

Or you could add the following and <code>chmod +x ports/.git/hooks/prepare-commit-msg</code> to automatically generate commit message which the default aports/.githooks/ does not:

{{Cat|aports/.git/hooks/prepare-commit-msg|<nowiki>#!/bin/sh
case "$2,$3" in
,|template,)
if git diff-index --diff-filter=A --name-only --cached HEAD \
| grep -q '/APKBUILD$'; then
meta() { git diff --staged | grep "^+$1" | sed 's/.*="\?//;s/"$//';}
printf 'testing/%s: new aport\n\n%s\n%s\n' "$(meta pkgname)" \
"$(meta url)" "$(meta pkgdesc)" "$(cat $1)" > "$1"
else
printf '%s\n\n%s' `git diff-index --name-only --cached HEAD \
| sed -n 's/\/APKBUILD$//p;q'` "$(cat $1)" > "$1"
fi;;
esac</nowiki>}}

Now your changes are only available locally in your repository.

Because you do not have push rights to the Alpine aports repository you need to create a merge request to [https://gitlab.alpinelinux.org/alpine/aports Alpine's GitLab instance].

Alternatively you can also create a diff (patch) of the changes you made and send this patch to the
[https://lists.alpinelinux.org/~alpine/aports alpine-aports mailinglist].

To create a diff patch:

{{Cmd|git format-patch HEAD^}}

or if you have sprunge, you can create a link to your patch for convenience

{{Cmd|git format-patch HEAD^ --stdout <nowiki>|</nowiki> sprunge}}

== Travis CI and automated testing ==

Travis CI, as in continuous integration automated testing, isn't always required, but 99% of the time it is strongly encouraged to pass with a green checkmark. Passing Travis CI ensures that your package works on another machine and builds the image starting from nothing. One reason why your package fails to build on the remote server is that you may inadvertently add a package dependency as in creating multiple packages at the same time or forgot to remove a dependency and forgot to mark it as a makedepends.

When you submit your APKBUILD as a pull request, the Travis CI server will construct the build environment from [https://github.com/alpinelinux/aports/blob/master/.travis/install-alpine#L28 main] [https://github.com/alpinelinux/aports/blob/master/.travis/common.sh#L5 Edge] apks.

The environment is just like a boot into command line so it is minimal. Don't assume that you boot into X.

The server/configuration cannot do testing/check() testing on hardware accelerated OpenGL apps.

== Send a patch ==

[[Creating_patches#Only_the_last_commit_with_.27git_send-email.27|git send-email]] will do that for you.

== GitHub Tagging ==

If you see your pull requested labeled on GitHub this is what they mean:

*A-add - The pull requester wanted to add this brand new package.
*A-upgrade - The pull requester wanted to update the package.
*A-improve - The pull requester wanted to improve an existing package.
*A-fix - The pull requester wanted to fix a bug with the existing package.
*S-changes-requested - An admin wants you to add or remove a subpackage or fix something as in messy code.
*S-needs-review - An admin needs someone to do a code review on your package.
*S-broken - The package fails to build locally on the code reviewer machine.
*ci-malfunction - Travis CI doesn't work with this package as in exceeded time.

== See Also ==
* [[APKBUILD Reference]]
* [[APKBUILD examples]]
* [[Development using git]]
* [[Development using git:Quality assurance]]

[[category: Package Manager]]

PipeWire

2021-11-03T23:31:15Z

Eddsalkield: Add troubleshooting section for when `pw-cat -p --list-targets` shows no targets

{{Draft|The instructions below have not been thoroughly tested and may break things.}}

[https://pipewire.org/ PipeWire] is a multimedia processing engine that aims to improve audio and video handling on Linux.

== Prerequisites ==

=== Audio Group ===

When elogind is not available, the user has to be added to the <code>audio</code> group. The user must log in for this to take effect.

<pre>
# addgroup <user> audio
</pre>

=== D-Bus ===

PipeWire requires a running [https://www.freedesktop.org/wiki/Software/dbus/ D-Bus] session. If you use a full desktop environment this will probably be started automatically, but with minimal window managers it must be done manually.

<pre>
# apk add dbus dbus-openrc dbus-x11
# rc-service dbus start
# rc-update add dbus default
</pre>

Then use <code>dbus-launch</code> whenever you start an X or Wayland session. For example:
<pre>
$ dbus-launch --exit-with-session sway
</pre>

=== XDG_RUNTIME_DIR ===

If you are not using a Desktop Manager, ensure that your <code>XDG_RUNTIME_DIR</code> is set to a user-writable location. By default for pulseaudio this is {{Path|/run/user/1000/}} or {{Path|/tmp}}. If this is not set, pipewire will create a directory in your home folder instead, called <code>~/pulse</code>, and on attempting to run Pavucontrol or pactl, you will get the following error:

<pre>
$ pactl list
Connection failure: Connection refused
pa_context_connect() failed: Connection refused
</pre>

== Installation and configuration ==

<pre>
# apk add pipewire
</pre>

Create custom configuration file in {{Path|/etc/pipewire/pipewire.conf}}:

<pre>
# mkdir /etc/pipewire
# cp /usr/share/pipewire/pipewire.conf /etc/pipewire/
</pre>

Uncomment the following line in {{Path|/etc/pipewire/pipewire.conf}}:

<pre>
{ path = "/usr/bin/pipewire-media-session" args = "" }
</pre>

Enable the <code>snd_seq</code> kernel module for ALSA support.

<pre>
# modprobe snd_seq
# echo snd_seq >> /etc/modules
</pre>

=== ALSA ===

If you use neither Jack nor PulseAudio and you don't intend to.

<pre>
# touch /etc/pipewire/media-session.d/with-alsa
</pre>

=== PulseAudio ===

PipeWire can run a [https://www.freedesktop.org/wiki/Software/PulseAudio/ PulseAudio] daemon which should allow all existing PulseAudio applications to be used with the PipeWire backend.

<pre>
# apk add pipewire-pulse
</pre>

Uncomment the following line in {{Path|/etc/pipewire/pipewire.conf}}:

<pre>
{ path = "/usr/bin/pipewire" args = "-c pipewire-pulse.conf" }
</pre>

It should be automatically enabled.

=== JACK ===

If you will be using PipeWire for [https://jackaudio.org/ JACK] applications install the required package and make system wide links to the PipeWire replacement JACK libraries (I have not had success using <code>pw-jack</code>). You will not need to start a JACK server.

<pre>
# apk add pipewire-jack
# ln -sf /usr/lib/pipewire-0.3/jack/libjackserver.so.0 /usr/lib/libjackserver.so.0
# ln -sf /usr/lib/pipewire-0.3/jack/libjacknet.so.0 /usr/lib/libjacknet.so.0
# ln -sf /usr/lib/pipewire-0.3/jack/libjack.so.0 /usr/lib/libjack.so.0
</pre>

{{Note|These symlinks might be overwritten during updates.}}

=== Video ===

Video should work out-of-the-box with v4l2 devices (e.g. a lot of webcams) and [https://gstreamer.freedesktop.org/ GStreamer] applications.

=== Bluetooth headset ===

Requires <code>pipewire-spa-bluez</code> package in addition to <code>pipewire-pulseaudio</code> daemon to be installed.

=== Automatic bluetooth profile selection ===

To automatically switch between HSP/HFP and A2DP profiles when an input stream is detected, set the bluez5.autoswitch-profile property to true:
<pre>
/etc/pipewire/media-session.d/bluez-monitor.conf

...
rules = [
{
...
actions = {
update-props = {
...
bluez5.autoswitch-profile = true
...
</pre>

=== Screen sharing on Wayland ===

You will need the right [https://github.com/flatpak/xdg-desktop-portal xdg-desktop-portal] backend for your desktop environment. Screen sharing is known to work on:
* GNOME with <code>xdg-desktop-portal-gtk</code>
* KDE Plasma with <code>xdg-desktop-portal-kde</code> and Firefox
* Sway with <code>xdg-desktop-portal-wlr</code> and Firefox

== Usage ==

Start the PipeWire media server. You'll probably get quite a few errors but just ignore them for now.

<pre>
$ pipewire
</pre>

In a different terminal window check the default output device. I don't yet know how this default can be changed for all applications, so you'd better hope it's right!

<pre>
# apk add pipewire-tools
$ pw-cat -p --list-targets
</pre>

Test sound is working using an audio file in a format supported by [http://www.mega-nerd.com/libsndfile/ libsndfile] (e.g. flac, opus, ogg, wav).

<pre>
$ pw-cat -p test.flac
</pre>

If you have a microphone test audio recording is working.

<pre>
$ pw-cat -r --list-targets
$ pw-cat -r recording.flac
(Speak for a while then stop it with Ctrl+c)
$ pw-cat -p recording.flac
</pre>

Test PulseAudio clients using a media player (most use PulseAudio) and if you use JACK test that too:

<pre>
# apk add jack-example-clients
$ jack_simple_client
</pre>

You should hear a sustained beep.

If you are happy everything is working, make PipeWire start automatically when your X or Wayland session starts. For example, you could add the <code>pipewire</code> command to <code>~/.xinitrc</code> or your window manager's config file.

== Troubleshooting ==

=== `pw-cat -p --list-targets` shows no targets ===

First, check whether ALSA knows about your sound card:

<pre>
aplay -l
</pre>

If sound devices are found, the issue is with your pipewire configuration. Consider double-checking the instructions above.

Otherwise, your sound card may not be supported in the version of the Linux Kernel you're running. You should search online for fixes relating to your current kernel version and the codec of your sound card. You can find each of these with:

<pre>
uname -r
cat /proc/asound/card0/codec* | grep Codec
</pre>

== See Also ==

* [https://gitlab.freedesktop.org/pipewire/pipewire PipeWire source repository]
* [https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/home PipeWire Wiki]
* [https://wiki.archlinux.org/index.php/PipeWire PipeWire on the ArchWiki]
* [https://wiki.gentoo.org/wiki/Pipewire PipeWire on the Gentoo Wiki]

[[Category:Multimedia]]

PipeWire

2021-11-03T23:23:23Z

Eddsalkield: Add instructions on enabling pulseaudio-server

{{Draft|The instructions below have not been thoroughly tested and may break things.}}

[https://pipewire.org/ PipeWire] is a multimedia processing engine that aims to improve audio and video handling on Linux.

== Prerequisites ==

=== Audio Group ===

When elogind is not available, the user has to be added to the <code>audio</code> group. The user must log in for this to take effect.

<pre>
# addgroup <user> audio
</pre>

=== D-Bus ===

PipeWire requires a running [https://www.freedesktop.org/wiki/Software/dbus/ D-Bus] session. If you use a full desktop environment this will probably be started automatically, but with minimal window managers it must be done manually.

<pre>
# apk add dbus dbus-openrc dbus-x11
# rc-service dbus start
# rc-update add dbus default
</pre>

Then use <code>dbus-launch</code> whenever you start an X or Wayland session. For example:
<pre>
$ dbus-launch --exit-with-session sway
</pre>

=== XDG_RUNTIME_DIR ===

If you are not using a Desktop Manager, ensure that your <code>XDG_RUNTIME_DIR</code> is set to a user-writable location. By default for pulseaudio this is {{Path|/run/user/1000/}} or {{Path|/tmp}}. If this is not set, pipewire will create a directory in your home folder instead, called <code>~/pulse</code>, and on attempting to run Pavucontrol or pactl, you will get the following error:

<pre>
$ pactl list
Connection failure: Connection refused
pa_context_connect() failed: Connection refused
</pre>

== Installation and configuration ==

<pre>
# apk add pipewire
</pre>

Create custom configuration file in {{Path|/etc/pipewire/pipewire.conf}}:

<pre>
# mkdir /etc/pipewire
# cp /usr/share/pipewire/pipewire.conf /etc/pipewire/
</pre>

Uncomment the following line in {{Path|/etc/pipewire/pipewire.conf}}:

<pre>
{ path = "/usr/bin/pipewire-media-session" args = "" }
</pre>

Enable the <code>snd_seq</code> kernel module for ALSA support.

<pre>
# modprobe snd_seq
# echo snd_seq >> /etc/modules
</pre>

=== ALSA ===

If you use neither Jack nor PulseAudio and you don't intend to.

<pre>
# touch /etc/pipewire/media-session.d/with-alsa
</pre>

=== PulseAudio ===

PipeWire can run a [https://www.freedesktop.org/wiki/Software/PulseAudio/ PulseAudio] daemon which should allow all existing PulseAudio applications to be used with the PipeWire backend.

<pre>
# apk add pipewire-pulse
</pre>

Uncomment the following line in {{Path|/etc/pipewire/pipewire.conf}}:

<pre>
{ path = "/usr/bin/pipewire" args = "-c pipewire-pulse.conf" }
</pre>

It should be automatically enabled.

=== JACK ===

If you will be using PipeWire for [https://jackaudio.org/ JACK] applications install the required package and make system wide links to the PipeWire replacement JACK libraries (I have not had success using <code>pw-jack</code>). You will not need to start a JACK server.

<pre>
# apk add pipewire-jack
# ln -sf /usr/lib/pipewire-0.3/jack/libjackserver.so.0 /usr/lib/libjackserver.so.0
# ln -sf /usr/lib/pipewire-0.3/jack/libjacknet.so.0 /usr/lib/libjacknet.so.0
# ln -sf /usr/lib/pipewire-0.3/jack/libjack.so.0 /usr/lib/libjack.so.0
</pre>

{{Note|These symlinks might be overwritten during updates.}}

=== Video ===

Video should work out-of-the-box with v4l2 devices (e.g. a lot of webcams) and [https://gstreamer.freedesktop.org/ GStreamer] applications.

=== Bluetooth headset ===

Requires <code>pipewire-spa-bluez</code> package in addition to <code>pipewire-pulseaudio</code> daemon to be installed.

=== Automatic bluetooth profile selection ===

To automatically switch between HSP/HFP and A2DP profiles when an input stream is detected, set the bluez5.autoswitch-profile property to true:
<pre>
/etc/pipewire/media-session.d/bluez-monitor.conf

...
rules = [
{
...
actions = {
update-props = {
...
bluez5.autoswitch-profile = true
...
</pre>

=== Screen sharing on Wayland ===

You will need the right [https://github.com/flatpak/xdg-desktop-portal xdg-desktop-portal] backend for your desktop environment. Screen sharing is known to work on:
* GNOME with <code>xdg-desktop-portal-gtk</code>
* KDE Plasma with <code>xdg-desktop-portal-kde</code> and Firefox
* Sway with <code>xdg-desktop-portal-wlr</code> and Firefox

== Usage ==

Start the PipeWire media server. You'll probably get quite a few errors but just ignore them for now.

<pre>
$ pipewire
</pre>

In a different terminal window check the default output device. I don't yet know how this default can be changed for all applications, so you'd better hope it's right!

<pre>
# apk add pipewire-tools
$ pw-cat -p --list-targets
</pre>

Test sound is working using an audio file in a format supported by [http://www.mega-nerd.com/libsndfile/ libsndfile] (e.g. flac, opus, ogg, wav).

<pre>
$ pw-cat -p test.flac
</pre>

If you have a microphone test audio recording is working.

<pre>
$ pw-cat -r --list-targets
$ pw-cat -r recording.flac
(Speak for a while then stop it with Ctrl+c)
$ pw-cat -p recording.flac
</pre>

Test PulseAudio clients using a media player (most use PulseAudio) and if you use JACK test that too:

<pre>
# apk add jack-example-clients
$ jack_simple_client
</pre>

You should hear a sustained beep.

If you are happy everything is working, make PipeWire start automatically when your X or Wayland session starts. For example, you could add the <code>pipewire</code> command to <code>~/.xinitrc</code> or your window manager's config file.

== See Also ==

* [https://gitlab.freedesktop.org/pipewire/pipewire PipeWire source repository]
* [https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/home PipeWire Wiki]
* [https://wiki.archlinux.org/index.php/PipeWire PipeWire on the ArchWiki]
* [https://wiki.gentoo.org/wiki/Pipewire PipeWire on the Gentoo Wiki]

[[Category:Multimedia]]

PipeWire

2021-11-03T21:18:22Z

Eddsalkield: Correct argument order of addgroup command

{{Draft|The instructions below have not been thoroughly tested and may break things.}}

[https://pipewire.org/ PipeWire] is a multimedia processing engine that aims to improve audio and video handling on Linux.

== Prerequisites ==

=== Audio Group ===

When elogind is not available, the user has to be added to the <code>audio</code> group. The user must log in for this to take effect.

<pre>
# addgroup <user> audio
</pre>

=== D-Bus ===

PipeWire requires a running [https://www.freedesktop.org/wiki/Software/dbus/ D-Bus] session. If you use a full desktop environment this will probably be started automatically, but with minimal window managers it must be done manually.

<pre>
# apk add dbus dbus-openrc dbus-x11
# rc-service dbus start
# rc-update add dbus default
</pre>

Then use <code>dbus-launch</code> whenever you start an X or Wayland session. For example:
<pre>
$ dbus-launch --exit-with-session sway
</pre>

=== XDG_RUNTIME_DIR ===

If you are not using a Desktop Manager, ensure that your <code>XDG_RUNTIME_DIR</code> is set to a user-writable location. By default for pulseaudio this is {{Path|/run/user/1000/}} or {{Path|/tmp}}. If this is not set, pipewire will create a directory in your home folder instead, called <code>~/pulse</code>, and on attempting to run Pavucontrol or pactl, you will get the following error:

<pre>
$ pactl list
Connection failure: Connection refused
pa_context_connect() failed: Connection refused
</pre>

== Installation and configuration ==

<pre>
# apk add pipewire
</pre>

Create custom configuration file in {{Path|/etc/pipewire/pipewire.conf}}:

<pre>
# mkdir /etc/pipewire
# cp /usr/share/pipewire/pipewire.conf /etc/pipewire/
</pre>

Uncomment the following line in {{Path|/etc/pipewire/pipewire.conf}}:

<pre>
{ path = "/usr/bin/pipewire-media-session" args = "" }
</pre>

Enable the <code>snd_seq</code> kernel module for ALSA support.

<pre>
# modprobe snd_seq
# echo snd_seq >> /etc/modules
</pre>

=== ALSA ===

If you use neither Jack nor PulseAudio and you don't intend to.

<pre>
# touch /etc/pipewire/media-session.d/with-alsa
</pre>

=== PulseAudio ===

PipeWire can run a [https://www.freedesktop.org/wiki/Software/PulseAudio/ PulseAudio] daemon which should allow all existing PulseAudio applications to be used with the PipeWire backend.

<pre>
# apk add pipewire-pulse
</pre>

It should be automatically enabled.

=== JACK ===

If you will be using PipeWire for [https://jackaudio.org/ JACK] applications install the required package and make system wide links to the PipeWire replacement JACK libraries (I have not had success using <code>pw-jack</code>). You will not need to start a JACK server.

<pre>
# apk add pipewire-jack
# ln -sf /usr/lib/pipewire-0.3/jack/libjackserver.so.0 /usr/lib/libjackserver.so.0
# ln -sf /usr/lib/pipewire-0.3/jack/libjacknet.so.0 /usr/lib/libjacknet.so.0
# ln -sf /usr/lib/pipewire-0.3/jack/libjack.so.0 /usr/lib/libjack.so.0
</pre>

{{Note|These symlinks might be overwritten during updates.}}

=== Video ===

Video should work out-of-the-box with v4l2 devices (e.g. a lot of webcams) and [https://gstreamer.freedesktop.org/ GStreamer] applications.

=== Bluetooth headset ===

Requires <code>pipewire-spa-bluez</code> package in addition to <code>pipewire-pulseaudio</code> daemon to be installed.

=== Automatic bluetooth profile selection ===

To automatically switch between HSP/HFP and A2DP profiles when an input stream is detected, set the bluez5.autoswitch-profile property to true:
<pre>
/etc/pipewire/media-session.d/bluez-monitor.conf

...
rules = [
{
...
actions = {
update-props = {
...
bluez5.autoswitch-profile = true
...
</pre>

=== Screen sharing on Wayland ===

You will need the right [https://github.com/flatpak/xdg-desktop-portal xdg-desktop-portal] backend for your desktop environment. Screen sharing is known to work on:
* GNOME with <code>xdg-desktop-portal-gtk</code>
* KDE Plasma with <code>xdg-desktop-portal-kde</code> and Firefox
* Sway with <code>xdg-desktop-portal-wlr</code> and Firefox

== Usage ==

Start the PipeWire media server. You'll probably get quite a few errors but just ignore them for now.

<pre>
$ pipewire
</pre>

In a different terminal window check the default output device. I don't yet know how this default can be changed for all applications, so you'd better hope it's right!

<pre>
# apk add pipewire-tools
$ pw-cat -p --list-targets
</pre>

Test sound is working using an audio file in a format supported by [http://www.mega-nerd.com/libsndfile/ libsndfile] (e.g. flac, opus, ogg, wav).

<pre>
$ pw-cat -p test.flac
</pre>

If you have a microphone test audio recording is working.

<pre>
$ pw-cat -r --list-targets
$ pw-cat -r recording.flac
(Speak for a while then stop it with Ctrl+c)
$ pw-cat -p recording.flac
</pre>

Test PulseAudio clients using a media player (most use PulseAudio) and if you use JACK test that too:

<pre>
# apk add jack-example-clients
$ jack_simple_client
</pre>

You should hear a sustained beep.

If you are happy everything is working, make PipeWire start automatically when your X or Wayland session starts. For example, you could add the <code>pipewire</code> command to <code>~/.xinitrc</code> or your window manager's config file.

== See Also ==

* [https://gitlab.freedesktop.org/pipewire/pipewire PipeWire source repository]
* [https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/home PipeWire Wiki]
* [https://wiki.archlinux.org/index.php/PipeWire PipeWire on the ArchWiki]
* [https://wiki.gentoo.org/wiki/Pipewire PipeWire on the Gentoo Wiki]

[[Category:Multimedia]]