Alpine Linux - User contributions [en]

How to setup a Alpine Linux mirror

2026-03-09T21:37:00Z

Ikke: Update mirror stats, split table in 2

== Introduction ==
This document describes how to set up an Alpine Linux mirror and make it available via http and rsync.

We will:
* create the dir where we have the mirror
* set up a cron job to sync with master mirror every hour
* set up lighttpd for http access
* set up rsync so other mirrors can rsync from you

Make sure that you have enough disk space.

Current (2026-03-09) disk usage in GB:

{|class="wikitable"
!edge
!v3.0
!v3.1
!v3.2
!v3.3
!v3.4
!v3.5
!v3.6
!v3.7
!v3.8
!v3.9
!v3.10
!v3.11
!v3.12
!v3.13
!v3.14
!v3.15
!v3.16
|-
|594
|17
|18
|15
|20
|24
|27
|44
|43
|59
|73
|91
|126
|148
|156
|181
|194
|209
|}

{| class="wikitable"
!v3.17
!v3.18
!v3.19
!v3.20
!v3.21
!v3.22
!v3.23
!total
|-
|240
|290
|313
|480
|477
|451
|509
|'''4798'''
|}

Script used to calculate the size:

<pre>
#!/bin/sh

total=0
dest="$(mktemp -d)"

for dir in edge v3.0 v3.1 v3.2 v3.3 v3.4 v3.5 v3.6 v3.7 v3.8 v3.9 v3.10 v3.11 v3.12 v3.13 v3.14 v3.15 v3.16 v3.17 v3.18 v3.19 v3.20 v3.21 v3.22 v3.23; do
old_total="$total"
src="rsync://rsync.alpinelinux.org/alpine/$dir/"
size=$(rsync -a -n --stats "$src" "$dest" | grep '^Total file size' | tr -d ',' | awk '{ print $4 }')
total=$(( old_total + size ))
echo "$dir: $size" | awk '{ print $1 sprintf("%.1f", $2/1073741824) }'
done

echo "total: $total" | awk '{ print $1 sprintf("%.1f", $2/1073741824) }'
rm -r "$dest"
</pre>

== Setting up the cron job ==
Install rsync which will be used to sync from the master mirror.
{{Cmd|apk add rsync}}

Save the following file as ''/etc/periodic/hourly/alpine-mirror''
<pre>
#!/bin/sh

# make sure we never run 2 rsync at the same time
lockfile="/tmp/alpine-mirror.lock"
if [ -z "$flock" ] ; then
exec env flock=1 flock -n $lockfile "$0" "$@"
fi

src=rsync://rsync.alpinelinux.org/alpine/
dest=/var/www/localhost/htdocs/alpine/

# uncomment this to exclude old v2.x branches
#exclude="--exclude v2.*"

mkdir -p "$dest"
/usr/bin/rsync \
--archive \
--update \
--hard-links \
--delete \
--delete-after \
--delay-updates \
--timeout=600 \
$exclude \
"$src" "$dest"

</pre>

(or use [https://gist.github.com/jirutka/288c6fff7c0b8a835d143686207316be this script])

Make it executable:
{{Cmd|<nowiki>chmod +x /etc/periodic/hourly/alpine-mirror</nowiki>}}

Now it will sync every hour. (given cron runs)

== Setting up HTTP access via lighttpd ==

Install the lighttpd server
{{Cmd|apk add lighttpd}}

Enable dir listings by uncommenting the following line in ''/etc/lighttpd/lighttpd.conf'':
dir-listing.activate = "enable"

Also set cache-control to force cache revalidate every 30 mins. Uncomment mod_setenv in ''/etc/lighttpd/lighttpd.conf'':
"mod_setenv",

Add also the following lines to ''/etc/lighttpd/lighttpd.conf'':
setenv.add-response-header += (
"Cache-Control" => "must-revalidate"
)

Start lighttpd and make it start at boot:
{{Cmd|rc-service lighttpd start
rc-update add lighttpd}}

{{Note|You may wish to consider [[Darkhttpd]] as an alternative to [[Lighttpd]]

If so, simply install, start and auto-start the webserver:

{{Cmd|apk add darkhttpd && rc-service darkhttpd start && rc-update add darkhttpd}}

Darkhttpd will, by default, offer directory listings and serve data from /var/www/localhost/htdocs/

See the main article on [[Darkhttpd]] for more configuration options}}

== Setting up rsyncd ==
Add the following lines to ''/etc/rsyncd.conf'':
<pre>
[alpine]
path = /var/www/localhost/htdocs/alpine
comment = My Alpine Linux Mirror
</pre>

Optionally set a bandwidth limit in ''/etc/conf.d/rsyncd''. In this example we limit to 500Kbytes/s (approx 5Mbit/s)
<pre>
RSYNC_OPTS="--bwlimit=500"
</pre>

== Mirror statistics ==

Simple bandwidth statistics can be generated with vnstat.

{{Cmd|apk add vnstat}}

edit /etc/vnstat.conf and replace the interface name with the appropriate one.

Start vnstatd

{{Cmd|rc-service vnstatd start }}

copy the following script to /etc/periodic/15min/stats and make sure your crond is running.
please not that heredoc should be tab indented or the script will fail. A working copy can be found here: https://tpaste.us/RrMv

<pre>
#!/bin/sh

output="/var/www/localhost/htdocs/.stats"
nic="eth0"

generate_index() {
cat <<-EOF
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta http-equiv="cache-control" content=no-cache">
<meta http-equiv="refresh" content="3000">
<title>Alpine Linux mirror statistics</title>
</head>
<body>
<table border="0">
<tr><td><img src="summary.png" alt="summary"></td><td><img src="hours.png" alt="hours"></td></tr>
<tr><td rowspan="2"><img src="days.png" alt="days"></td><td><img src="top10.png" alt="top10"></td></tr>
<tr><td><img src="months.png" alt="months"></td></tr>
</table>
</body>
</html>
EOF
}

if [ ! -f "$output"/index.html ]; then
mkdir -p $output
generate_index > "$output"/index.html
fi

for type in hours days months top10 summary hsummary vsummary; do
vnstati --${type} -i $nic -o $output/${type}.png
done
</pre>

== Update mirror from mqtt ==

If you want your mirror to be really uptodate compared to our master mirror you can subscribe to Alpine Linux message server "msg.alpinelinux.org" and check for upload messages.
Add mqtt-exec to be able to execute processes when specific topics are being send.

{{Cmd| apk add mqtt-exec}}

mqtt-exec supports running multiple time so we need to setup a specific config.

{{Cmd| ln -s mqtt-exec /etc/init.d/mqtt-exec.sync-mirror}}

{{Cmd| ln -s mqtt-exec /etc/conf.d/mqtt-exec.sync-mirror}}

edit /etc/conf.d/mqtt-exec.sync-mirror

<pre>
mqtt_topics="rsync/rsync.alpinelinux.org/#"
exec_user="buildozer"
exec_command="/usr/local/bin/sync-mirror"
</pre>

Copy the following file to /usr/local/bin/sync-mirror and make it executable (dont forget to update the variables).

<pre>
#!/bin/sh

src="rsync://rsync.alpinelinux.org/alpine/"
dest="/var/www/localhost/htdocs/alpine/"
lock="/tmp/sync-mirror.lock"
topic="$1"
dir="$2"

[ -z "$flock" ] && exec env flock=1 flock $lock $0 "$@"

if [ -n "$dir" ] && [ -d "$dest/${dir%/*}" ]; then
logger "Syncing directory: $dir"
src="${src}${dir%/}/"
dest="${dest}${dir%/}/"
else
logger "Syncing all directories"
fi

/usr/bin/rsync \
--archive \
--update \
--verbose \
--progress \
--timeout=600 \
--delay-updates \
--delete-after \
"$src" \
"$dest"
</pre>

And finally start mqtt-exec and let it listen on msg.alpinelinux.org

{{Cmd|rc-service mqtt-exec.sync-mirror start}}

To make sure you are not missing any packages (in case something goes wrong with MQTT subscription) you can periodically sync all directories by adding the script to cron.

{{Cmd|ln -s /usr/local/bin/sync-mirror /etc/periodic/hourly/sync-mirror}}

Now watch your syslog as it should tell you when it will update directories in your local mirror.

== Partial mirror using nginx ==

For a private mirror it might make sense to sync only the newest versions or some architectures of Alpine to save space, but if you ''do'' point an old Alpine version to your mirror they should still be able to install packages. We can achieve this by using nginx to serve the mirrored content and redirect all requests with 404 errors to a public mirror.

Let's assume you chose to only mirror Alpine versions up from v3.13. If a client asks your mirror for v.3.10 it should redirect to another mirror.

Your nginx config server block should look something like this:

<pre>
server {
listen 80;
server_name alpine.mydomain.local;
root /data/alpine; # point to where your alpine mirror is located. make sure nginx is allowed to read it
autoindex on; # Enable indexing

error_page 404 = @alpinemirror;

location @alpinemirror
{
return 302 http://dl-cdn.alpinelinux.org/alpine$request_uri;
}
}
</pre>

The corresponding sync script could look something like this:

<pre>
#!/bin/sh

# make sure we never run 2 rsync at the same time
lockfile="/tmp/alpine-mirror.lock"
if [ -z "$flock" ] ; then
exec env flock=1 flock -n $lockfile "$0" "$@"
fi

src=rsync://rsync.alpinelinux.org/alpine/
dest=/data/alpine/

exclude="--exclude v2.* --exclude v3.0 --exclude v3.1 --exclude v3.2 --exclude v3.3 --exclude v3.4 --exclude v3.5 --exclude v3.6 --exclude v3.7 --exclude v3.8 --exclude v3.9 --exclude v3.10 --exclude v3.11 --exclude v3.12"

mkdir -p "$dest"
/usr/bin/rsync -vvv \
--archive \
--update \
--hard-links \
--delete \
--delete-after \
--delete-excluded \
--delay-updates \
--timeout=600 \
$exclude \
"$src" "$dest"
</pre>

[[Category:Server]]
[[Category:Package Manager]]

Draft Release Notes for Alpine 3.24.0

2026-02-15T14:29:24Z

Ikke:

As always, make sure to read [[Upgrading Alpine to a new major release]] when upgrading to a new release.

If you experience any issues with the upgrade, please let us know and file an issue in our repositories.

{{Note|Alpine 3.24 is WIP, see https://gitlab.alpinelinux.org/groups/alpine/-/milestones/27 for important changes. For the latest release 3.23, look at [[Release Notes for Alpine 3.23.0]].}}

== Important changes ==

=== /usr merge ===

New installations can opt-in to being /usr-merged, by setting the <code>BOOTSTRAP_USR_MERGED</code> environment variable to <code>1</code> before running <code>setup-disk</code>. Manual migration is also possible by installing the <code>merge-usr</code> package and running its binary as root. For more details see the [https://alpinelinux.org/posts/2025-10-01-usr-merge.html official announcement].

== Significant changes ==

=== GTK+ 3.0 moved to community ===

{{Note|TODO}}

=== gdk-pixbuf uses glycin/glycin loaders got split ===

{{Note|TODO}}

=== Python setuptools 82.0.0 removed pkg_resources ===

py3-setuptools has been upgraded to 82.0.0, [https://setuptools.pypa.io/en/latest/history.html#v82-0-0 which removed pkg_resources]. Any project that still depends on it will no longer work and should migrate to its successors.

== Note-worthy updates ==

As always, many packages were upgraded. Make sure to read the individual release notes of the projects you use.

* BIRD TODO
* busybox TODO
* Deno TODO
* ffmpeg TODO
* GCC TODO
* GNOME TODO
* Go TODO
* ISC BIND TODO
* ISC Kea TODO
* KDE Plasma TODO
* Linux TODO
* LLVM TODO
* LXQt TODO
* .NET TODO
* nginx TODO
* NodeJS TODO (LTS)
* OpenJDK TODO
* PHP TODO
* Qt TODO
* Ruby TODO
* Rust TODO
* wlroots TODO
* zigbee2mqtt TODO

=== COSMIC 1 ===

This release makes the COSMIC desktop available in community as {{pkg|cosmic*}} including {{pkg|xdg-desktop-portal-cosmic*}}.

=== qemu-binfmt service deprecated ===

The <code>qemu-binfmt</code> service from the package <code>qemu-openrc</code> is deprecated, in favor of <code>binfmt.d</code> config files from user mode qemu packages (eg. <code>qemu-aarch64 qemu-x86_64</code>) combined with the <code>binfmt</code> service.

If you are using <code>qemu-binfmt</code>, run:
{{Cmd|# rc-update del qemu-binfmt && rc-update add binfmt}}

Contrary to the behavior of <code>qemu-binfmt</code>, the new default configuration prevents setuid programs from granting privileges. If you need to execute setuid programs via qemu:

* make sure you understand the implications: with this configuration, any user with execute access to any foreign-architecture setuid binary can execute arbitrary code with the privileges of that binary
* if you accept the risks, copy <code>/usr/lib/binfmt.d/qemu-*.conf</code> to <code>/etc/binfmt.d</code>, edit to add the <code>C</code> flag, and restart binfmt.

See [https://docs.kernel.org/admin-guide/binfmt-misc.html Kernel admin guide - binfmt] for more information about the <code>C</code> (<code>credentials</code>) flag.

== Significant removals ==



=== py3-six ===

{{Note|TODO https://gitlab.alpinelinux.org/alpine/aports/-/work_items/17822}}

=== More GTK 2 removals ===

{{Note|TODO}}

=== More Qt5 removals ===

{{Note|TODO}}

<hr><center>[[Release Notes for Alpine 3.23.0|← Previous page: Release Notes for Alpine 3.23.0]]</center>

[[Category:News]]

Dynamic Multipoint VPN (DMVPN)

2025-08-21T12:42:31Z

Ikke: Mark page as obsolete / outdated

{{Obsolete|Information is outdated. See https://gitlab.alpinelinux.org/alpine/dmvpn-tools}}

{{TOC right}}

https://alpinelinux.org/about under '''Why the Name Alpine?''' states:

''The first open-source implementation of Cisco's DMVPN, called OpenNHRP, was written for Alpine Linux.''[https://web.archive.org/web/20110508001131/https://alpinelinux.org/about]

So the aim of this document is to be the reference Linux DMVPN setup, with all the networking services needed for the clients that will use the DMVPN (DNS, firewall, etc.). [[Small Office Services]] offers additional services such as DHCP for clients, http proxying, and a basic SIP telephone system.

= Terminology =
;NBMA: ''Non-Broadcast Multi-Access'' network as described in [https://datatracker.ietf.org/doc/html/rfc2332 RFC 2332]

;Hub: the ''Next Hop Server'' (NHS) performing the Next Hop Resolution Protocol service within the NBMA cloud.

;Spoke: the ''Next Hop Resolution Protocol Client'' (NHC) which initiates NHRP requests of various types in order to obtain access to the NHRP service.

{{Tip|At the time of this writing the recommended Alpine version for building a DMVPN should be at minimum 2.4.11. Don't use 2.5.x, or 2.6.0 since the kernel has in-tunnel IP fragmentation issues. Alpine 3.0 has also a Musl issue in getprotobyname(). Alpine 2.7.x has been thoroughly tested and 3.0.3 hasn't shown any issue so far.}}

{{Note|This document assumes that all Alpine installations are run in [[Installation#Basics|diskless mode]] and that the configuration is saved on USB key}}

= Hardware =
If you need gigabits throughput you should go for a processor with [https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-encryption-standard-instructions-aes-ni.html AES-NI] and [https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sha-extensions.html SHA Extensions].

= Extract Certificates =
We will use certificates for DMVPN and for OpenVPN (RoadWarrior clients). If you are in need to generate your own certificates, please see [[Generating_SSL_certs_with_ACF]]. You should use a separate machine for this purpose. If you downloaded the certificates on a Windows machine, you may use [https://winscp.net/eng/download.php WinSCP] to copy them on the DMVPN box.

Here are the general purpose instruction for extracting certificates from pfx files:

{{Cmd|openssl pkcs12 -in cert.pfx -cacerts -nokeys -out cacert.pem
openssl pkcs12 -in cert.pfx -nocerts -nodes -out serverkey.pem
openssl pkcs12 -in cert.pfx -nokeys -clcerts -out cert.pem
}}

Set appropriate permission for your certificate files:

{{Cmd|chmod 600 *.pem *.pfx}}

= Spoke Node =
A local spoke node network has support for multiple ISP connections, along with redundant layer 2 switches. At least one 802.1q capable switch is required, and a second is optional for redundancy purposes. The typical spoke node network looks like:

[[File:DMVPN-Spoke.png]]

== Boot Alpine USB ==
Follow the instructions on [[Create_a_Bootable_USB]] about how to create a bootable USB.

== Alpine Setup ==
We will setup the network interfaces as follows:

{|class="wikitable"
!'''Interface'''
!'''Description'''
!'''Subnet'''
|-
|bond0.3
|Management
|10.1.0.129/26
|-
|bond0.101
|LAN
|10.1.0.0/25
|-
|bond0.256
|Internet from ISP1
|Allocated from ISP
|-
|bond0.257
|Internet from ISP2
|Allocated from ISP
|-
|bond0.620
|Transit between wifi proxy and dmvpn spoke node
|10.1.0.252/30
|-
|bond0.701
|WiFi clients (no access to DMVPN network)
|172.17.48.0/24
|-
|bond0.1101
|Voice
|10.2.0.0/24
|}

{{Cmd|setup-alpine}}

{|class="wikitable"
!'''You will be prompted something like this...'''
!'''Suggestion on what you could enter...'''
|-
|<code>Select keyboard layout [none]:</code>
|''Type an appropriate layout for you''
|-
|<code>Select variant:</code>
|''Type an appropriate layout for you (if prompted)''
|-
|<code>Enter system hostname (short form, e.g. 'foo') [localhost]:</code>
|''Enter the hostname, e.g.'' '''vpnc'''
|-
|<code>Available interfaces are: eth0<br>Enter '?' for help on bridges, bonding and vlans.<br>Which one do you want to initialize? (or '?' done')</code>
|''Enter'' '''bond0.101'''
|-
|<code>Available bond slaves are: eth0 eth1<br>Which slave(s) do you want to add to bond0? (or 'done') [eth0]</code>
|'''eth0 eth1'''
|-
|<code>IP address for bond0? (or 'dhcp', 'none', '?') [none]:</code>
|''Press Enter confirming 'none'''
|-
|<code>IP address for bond0.101? (or 'dhcp', 'none', '?') [dhcp]:</code>
|''Enter the IP address of your LAN interface, e.g.'' '''10.1.0.1'''
|-
|<code>Netmask? [255.255.255.0]:</code>
|''Press Enter confirming '255.255.255.0' or type another appropriate subnet mask''
|-
|<code>Gateway? (or 'none') [none]:</code>
|''Press Enter confirming 'none'''
|-
|<code>Do you want to do any manual network configuration? [no]</code>
|'''yes'''
|-
|''Make a copy of the bond0.101 configuration for bond0.620, bond0.701, bond0.1101, bond0.256 and bond0.257 (optional) interfaces.<br>Don't forget to add a gateway and a metric value for ISP interfaces when multiple gateways are set.<br>Save and close the file (:wq)''
|-
|<code>DNS domain name? (e.g. 'bar.com') []:</code>
|''Enter the domain name of your intranet, e.g.,'' '''example.net'''
|-
|<code>DNS nameservers(s)? []:</code>
|'''8.8.8.8 8.8.4.4''' (we will change them later)
|-
|<code>Changing password for root<br>New password:</code>
|''Enter a secure password for the console''
|-
|<code>Retype password:</code>
|''Retype the above password''
|-
|<code>Which timezone are you in? ('?' for list) [UTC]:</code>
|''Press Enter confirming 'UTC'''
|-
|<code>HTTP/FTP proxy URL? (e.g. '<nowiki>http://proxy:8080</nowiki>', or 'none') [none]</code>
|''Press Enter confirming 'none'''
|-
|<code>Enter mirror number (1-9) or URL to add (or r/f/e/done) [f]:</code>
|''Select a mirror close to you and press Enter''
|-
|<code>Which SSH server? ('openssh', 'dropbear' or 'none') [openssh]:</code>
|''Press Enter confirming 'openssh'''
|-
|<code>Which NTP client to run? ('openntpd', 'chrony' or 'none') [chrony]:</code>
|''Press Enter confirming 'chrony'''
|-
|<code>Which disk(s) would you like to use? (or '?' for help or 'none') [none]:</code>
|''Press Enter confirming 'none' or type 'none' if needed''
|-
|<code>Enter where to store configs ('floppy', 'usb' or 'none') [usb]:</code>
|''Press Enter confirming 'usb'''
|-
|<code>Enter apk cache directory (or '?' or 'none') [/media/usb/cache]:</code>
|''Press Enter confirming '/media/usb/cache'''
|}

== Networking ==
Update the networking configuration.

With your favorite editor open <code>/etc/network/interfaces</code> and add interfaces:

{{cat|/etc/network/interfaces|
...

auto bond0.101
iface bond0.101 inet static
address 10.1.0.1
netmask 255.255.255.192

auto bond0.620
iface bond0.620 inet static
address 10.1.0.253
netmask 255.255.255.252

auto bond0.701
iface bond0.101 inet static
address 172.17.48.1
netmask 255.255.255.0

auto bond0.1101
iface bond0.101 inet static
address 10.2.0.1
netmask 255.255.255.0

auto bond0.256
iface bond0.256 inet static
address <%ISP1_IP_ADDRESS%>
netmask <%ISP1_NETMASK%>

auto bond0.257
iface bond0.257 inet static
address <%ISP2_IP_ADDRESS%>
netmask <%ISP2_NETMASK%>
}}

== Bonding ==
Update the bonding configuration.

With your favorite editor open <code>/etc/network/interfaces</code> and add <code>bond-mode</code>, <code>bond-miimon</code> and <code>bond-updelay</code> parameters to the <code>bond0</code> stanza:

{{cat|/etc/network/interfaces|
auto bond0
iface bond0 inet manual
bond-slaves eth0 eth1
bond-mode balance-tlb
bond-miimon 100
bond-updelay 500
...
}}

Bring up the new bonding settings:

{{Cmd|ifdown bond0
ifup bond0}}

== Physically install ==
At this point, you're ready to connect the VPN Spoke Node to the network if you haven't already done so. Please set up an 802.1q capable switch with the VLANs listed in AlpineSetup section. Once done, tag all of the VLANs on one port. Connect that port to <code>eth0</code>. Then, connect your first ISP's CPE to a switchport with VLAN 256 untagged.

== SSH ==
Remove password authentication and DNS reverse lookup:

{{Cmd|sed -i "s/.PasswordAuthentication yes/PasswordAuthentication no/" /etc/ssh/sshd_config
sed -i "s/.UseDNS yes/UseDNS no/" /etc/ssh/sshd_config}}

Restart ssh:
{{Cmd|rc-service sshd restart}}

== NTP server ==
In order to have attached devices syncing their time agains this host, we need to do some modifications to chrony config.<BR>
Add '<code>allow all</code>' to the end of the '<code>/etc/chrony/chrony.conf</code>' so the file looks something like this:

{{cat|/etc/chrony/chrony.conf|
server pool.ntp.org
initstepslew 10 pool.ntp.org
commandkey 10
keyfile /etc/chrony/chrony.keys
driftfile /etc/chrony/chrony.drift
allow all
}}

Restart chronyd for the changes to take effect
{{cmd|rc-service chronyd restart}}

== Recursive DNS ==
Install package(s):

{{Cmd|apk add -U unbound}}

With your favorite editor open <code>/etc/unbound/unbound.conf</code> and add the following configuration. If you have a domain that you want unbound to resolve but is internal to your network only, the stub-zone stanza is present:

{{cat|/etc/unbound/unbound.conf|
server:
verbosity: 1
interface: 10.1.0.1
do-ip4: yes
do-ip6: no
do-udp: yes
do-tcp: yes
do-daemonize: yes
access-control: 10.1.0.0/16 allow
access-control: 127.0.0.0/8 allow

do-not-query-localhost: no

root-hints: "/etc/unbound/root.hints"

stub-zone:
name: "location1.example.net"
stub-addr: 10.1.0.2

stub-zone:
name: "example.net"
stub-addr: 172.16.255.1
stub-addr: 172.16.255.2
stub-addr: 172.16.255.3
stub-addr: 172.16.255.4
stub-addr: 172.16.255.5
stub-addr: 172.16.255.7

stub-zone:
name: "example2.net"
stub-addr: 172.16.255.1
stub-addr: 172.16.255.2
stub-addr: 172.16.255.3
stub-addr: 172.16.255.4
stub-addr: 172.16.255.5
stub-addr: 172.16.255.7
}}

Start unbound and start using unbound on this host:

{{Cmd|rc-service unbound start
rc-update add unbound
echo nameserver 10.1.0.1 > /etc/resolv.conf}}

== GRE Tunnel ==
With your favorite editor open <code>/etc/network/interfaces</code> and add the following:

{{cat|/etc/network/interfaces|<nowiki>
auto gre1
iface gre1 inet static
pre-up ip tunnel add $IFACE mode gre ttl 64 tos inherit key 12.34.56.78 || true
address 172.16.1.1
netmask 255.255.0.0
post-down ip tunnel del $IFACE || true
</nowiki>}}

Bring up the new <code>gre1</code> interface:

{{Cmd|ifup gre1}}

== IPSEC ==
Install package(s):

{{Cmd|apk add ipsec-tools}}

With your favorite editor create <code>/etc/ipsec.conf</code> and set the content to the following:

{{cat|/etc/ipsec.conf|
spdflush;
spdadd 0.0.0.0/0 0.0.0.0/0 gre -P out ipsec esp/transport//require;
spdadd 0.0.0.0/0 0.0.0.0/0 gre -P in ipsec esp/transport//require;
}}

Create missing directory:

{{Cmd|mkdir /etc/racoon/}}

Extract your pfx into <code>/etc/racoon</code>, using the filenames '''<code>ca.pem</code>''', '''<code>cert.pem</code>''', and '''<code>key.pem</code>''' (see [[Dynamic_Multipoint_VPN_%28DMVPN%29#Extract_Certificates|instructions above]] for command).

With your favorite editor create <code>/etc/racoon/racoon.conf</code> and set the content to the following:

{{cat|/etc/racoon/racoon.conf|
path certificate "/etc/racoon/";
remote anonymous {
exchange_mode main;
lifetime time 2 hour;
certificate_type x509 "/etc/racoon/cert.pem" "/etc/racoon/key.pem";
ca_type x509 "/etc/racoon/ca.pem";
my_identifier asn1dn;
nat_traversal on;
script "/etc/opennhrp/racoon-ph1dead.sh" phase1_dead;
dpd_delay 120;
proposal {
encryption_algorithm aes 256;
hash_algorithm sha1;
authentication_method rsasig;
dh_group modp4096;
}
proposal {
encryption_algorithm aes 256;
hash_algorithm sha1;
authentication_method rsasig;
dh_group 2;
}
}

sainfo anonymous {
pfs_group 2;
lifetime time 2 hour;
encryption_algorithm aes 256;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;
}
}}

Edit <code>/etc/conf.d/racoon</code> and unset <code>RACOON_PSK_FILE</code>:

{{cat|/etc/conf.d/racoon|
...
RACOON_PSK_FILE{{=}}
...
}}

Start service(s):

{{Cmd|rc-service racoon start
rc-update add racoon}}

== Next Hop Resolution Protocol (NHRP) ==
Install package(s):

{{Cmd|apk add opennhrp}}

With your favorite editor open <code>/etc/opennhrp/opennhrp.conf</code> and change the content to the following:

{{cat|/etc/opennhrp/opennhrp.conf|
interface gre1
dynamic-map 172.16.0.0/16 hub.example.com
shortcut
redirect
non-caching

interface bond0.8
shortcut-destination

interface bond0.64
shortcut-destination

interface bond0.620
shortcut-destination
}}

You must have a DNS A record ''<code>hub.example.com</code>'' for each hub node IP address.

With your favorite editor open <code>/etc/opennhrp/opennhrp-script</code> and change the content to the following:

{{cat|/etc/opennhrp/opennhrp-script|<nowiki>#!/bin/sh

MYAS=$(sed -n 's/router bgp $\d*$/\1/p' < /etc/quagga/bgpd.conf)

case $1 in
interface-up)
echo "Interface $NHRP_INTERFACE is up"
if [ "$NHRP_INTERFACE" = "gre1" ]; then
ip route flush proto 42 dev $NHRP_INTERFACE
ip neigh flush dev $NHRP_INTERFACE

vtysh -d bgpd \
-c "configure terminal" \
-c "router bgp $MYAS" \
-c "no neighbor core" \
-c "neighbor core peer-group"
fi
;;
peer-register)
;;
peer-up)
if [ -n "$NHRP_DESTMTU" ]; then
ARGS=`ip route get $NHRP_DESTNBMA from $NHRP_SRCNBMA | head -1`
ip route add $ARGS proto 42 mtu $NHRP_DESTMTU
fi
echo "Create link from $NHRP_SRCADDR ($NHRP_SRCNBMA) to $NHRP_DESTADDR ($NHRP_DESTNBMA)"
racoonctl establish-sa -w isakmp inet $NHRP_SRCNBMA $NHRP_DESTNBMA || exit 1
racoonctl establish-sa -w esp inet $NHRP_SRCNBMA $NHRP_DESTNBMA gre || exit 1
;;
peer-down)
echo "Delete link from $NHRP_SRCADDR ($NHRP_SRCNBMA) to $NHRP_DESTADDR ($NHRP_DESTNBMA)"
racoonctl delete-sa isakmp inet $NHRP_SRCNBMA $NHRP_DESTNBMA
ip route del $NHRP_DESTNBMA src $NHRP_SRCNBMA proto 42
;;
nhs-up)
echo "NHS UP $NHRP_DESTADDR"
(
flock -x 200
vtysh -d bgpd \
-c "configure terminal" \
-c "router bgp $MYAS" \
-c "neighbor $NHRP_DESTADDR remote-as 65000" \
-c "neighbor $NHRP_DESTADDR peer-group core" \
-c "exit" \
-c "exit" \
-c "clear bgp $NHRP_DESTADDR"
) 200>/var/lock/opennhrp-script.lock
;;
nhs-down)
(
flock -x 200
vtysh -d bgpd \
-c "configure terminal" \
-c "router bgp $MYAS" \
-c "no neighbor $NHRP_DESTADDR"
) 200>/var/lock/opennhrp-script.lock
;;
route-up)
echo "Route $NHRP_DESTADDR/$NHRP_DESTPREFIX is up"
ip route replace $NHRP_DESTADDR/$NHRP_DESTPREFIX proto 42 via $NHRP_NEXTHOP dev $NHRP_INTERFACE
ip route flush cache
;;
route-down)
echo "Route $NHRP_DESTADDR/$NHRP_DESTPREFIX is down"
ip route del $NHRP_DESTADDR/$NHRP_DESTPREFIX proto 42
ip route flush cache
;;
esac

exit 0
</nowiki>}}

Make it executable and start service(s):

{{Cmd|chmod +x /etc/opennhrp/opennhrp-script
rc-service opennhrp start
rc-update add opennhrp}}

== BGP ==
Install package(s):

{{Cmd|apk add quagga
touch /etc/quagga/zebra.conf}}

With your favorite editor open <code>/etc/quagga/bgpd.conf</code> and change the content to the following (replace <code>strongpassword</code> with a password of your choice and <code>%HUB_GRE_IP%</code> with the '''Hub''' node GRE IP address):
* Add the line <code>neighbor %HUB_GRE_IP% remote-as 65000</code> for each '''Hub''' host you have in your NBMA cloud.

{{cat|/etc/quagga/bgpd.conf|
password strongpassword
enable password strongpassword
log syslog

access-list 1 remark Command line access authorized IP
access-list 1 permit 127.0.0.1
line vty
access-class 1

hostname vpnc.example.net

router bgp 65001
bgp router-id 172.16.1.1
network 10.1.0.0/16
neighbor %HUB_GRE_IP% remote-as 65000
neighbor %HUB_GRE_IP% remote-as 65000
...
}}

Start service(s):

{{Cmd|rc-service bgpd start
rc-update add bgpd}}

== OpenVPN ==
Install package(s):

{{Cmd|echo tun >> /etc/modules
modprobe tun
apk add openvpn openssl
openssl dhparam -out /etc/openvpn/dh1024.pem 1024}}

Configure openvpn:

{{cat|/etc/openvpn/openvpn.conf|
dev tun
proto udp
port 1194

server 10.1.128.0 255.255.255.0
push "route 10.0.0.0 255.0.0.0"
push "dhcp-option DNS 10.1.0.1"

tls-server
ca /etc/openvpn/cacert.pem
cert /etc/openvpn/servercert.pem
key /etc/openvpn/serverkey.pem

crl-verify /etc/openvpn/crl.pem

dh /etc/openvpn/dh1024.pem

persist-key
persist-tun

keepalive 10 120

comp-lzo

status /var/log/openvpn.status
mute 20
verb 3
}}

Start service(s):

{{Cmd|rc-service openvpn start
rc-update add openvpn}}

== Firewall ==
Install package(s):

{{Cmd|apk add awall}}

Enable IP forwarding:

{{Cmd|sysctl -w net.ipv4.ip_forward{{=}}1
sed -i 's/.*net\.ipv4\.ip_forward.*$/net.ipv4.ip_forward {{=}} 1/g' /etc/sysctl.conf}}

With your favorite editor, edit the following files and set their contents as follows:

{{cat|/etc/awall/optional/params.json|
{
"description": "params",

"variable": {
"B_IF": "bond0.8",
"C_IF": "bond0.64",
"DE_IF": "bond0.620",
"ISP1_IF": "bond0.256",
"ISP2_IF": "bond0.257"
}
}
}}

{{cat|/etc/awall/optional/internet-host.json|
{
"description": "Internet host",

"import": "params",

"zone": {
"E": { "iface": [ "$ISP1_IF", "$ISP2_IF" ] },
"ISP1": { "iface": "$ISP1_IF" },
"ISP2": { "iface": "$ISP2_IF" }
},

"filter": [
{
"in": "E",
"service": "ping",
"action": "accept",
"flow-limit": { "count": 10, "interval": 6 }
},
{
"in": "E",
"out": "_fw",
"service": [ "ssh", "https" ],
"action": "accept",
"conn-limit": { "count": 3, "interval": 60 }
},

{
"in": "_fw",
"out": "E",
"service": [ "dns", "http", "ntp" ],
"action": "accept"
},
{
"in": "_fw",
"service": [ "ping", "ssh" ],
"action": "accept"
}
]
}
}}

{{cat|/etc/awall/optional/openvpn.json|
{
"description": "OpenVPN support",

"import": "internet-host",

"service": {
"openvpn": { "proto": "udp", "port": 1194 }
},

"filter": [
{ "in": "E", "out": "_fw", "service": "openvpn", "action": "accept" }
]
}
}}

{{cat|/etc/awall/optional/clampmss.json|
{
"description": "Deal with ISPs afraid of ICMP",

"import": "internet-host",

"clamp-mss": [ { "out": "E" } ]
}
}}

{{cat|/etc/awall/optional/mark.json|
{
"description": "Mark traffic based on ISP",

"import": [ "params", "internet-host" ],

"route-track": [
{ "out": "ISP1", "mark": 1 },
{ "out": "ISP2", "mark": 2 }
]
}
}}

{{cat|/etc/awall/optional/dmvpn.json|
{
"description": "DMVPN router",

"import": "internet-host",

"variable": {
"A_ADDR": [ "10.0.0.0/8", "172.16.0.0/16" ]
},

"zone": {
"A": { "addr": "$A_ADDR", "iface": "gre1" }
},

"filter": [
{ "in": "E", "out": "_fw", "service": "ipsec", "action": "accept" },
{ "in": "_fw", "out": "E", "service": "ipsec", "action": "accept" },
{
"in": "E",
"out": "_fw",
"ipsec": "in",
"service": "gre",
"action": "accept"
},
{
"in": "_fw",
"out": "E",
"ipsec": "out",
"service": "gre",
"action": "accept"
},

{ "in": "_fw", "out": "A", "service": "bgp", "action": "accept" },
{ "in": "A", "out": "_fw", "service": "bgp", "action": "accept"},
{ "out": "E", "dest": "$A_ADDR", "action": "reject" }
]
}
}}

{{cat|/etc/awall/optional/vpnc.json|
{
"description": "VPNc",

"import": [ "params", "internet-host", "dmvpn" ],

"zone": {
"B": { "iface": "$B_IF" },
"C": { "iface": "$C_IF" },
"DE": { "iface": "$DE_IF" }

},

"policy": [
{ "in": "A", "action": "accept" },
{ "in": "B", "out": "A", "action": "accept" },
{ "in": "C", "out": [ "A", "E" ], "action": "accept" },
{ "in": "DE", "out": "E", "action": "accept" },
{ "in": "E", "action": "drop" },
{ "in": "_fw", "out": "A", "action": "accept" }
],

"snat": [
{ "out": "E" }
],

"filter": [
{
"in": "A",
"out": "_fw",
"service": [ "ping", "ssh", "http", "https" ],
"action": "accept"
},

{
"in": [ "B", "C" ],
"out": "_fw",
"service": [ "dns", "ntp", "http", "https", "ssh" ],
"action": "accept"
},

{
"in": "_fw",
"out": [ "B", "C" ],
"service": [ "dns", "ntp" ],
"action": "accept"
},

{
"in": [ "A", "B", "C" ],
"out": "_fw",
"proto": "icmp",
"action": "accept"
},

{
"out": "DE",
"service": [ "ssh", "http", "https", "ping" ],
"action": "accept"
}

]
}
}}

Activate the firewall:

{{Cmd|modprobe ip_tables
modprobe iptable_nat
awall enable clampmss
awall enable openvpn
awall enable vpnc
awall activate -f
rc-update add iptables}}

== ISP Failover ==
Install package(s):

{{Cmd|apk add pingu
echo -e "1\tisp1">> /etc/iproute2/rt_tables
echo -e "2\tisp2">> /etc/iproute2/rt_tables}}

Configure pingu to monitor our <code>bond0.256</code> and <code>bond0.257</code> interfaces in <code>/etc/pingu/pingu.conf</code>. Add the hosts to monitor for ISP failover to <code>/etc/pingu/pingu.conf</code> and bind to primary ISP. We also set the ping timeout to 4 seconds.:

{{cat|/etc/pingu/pingu.conf|
timeout 4
required 2
retry 11

interface bond0.256 {
# route-table must correspond with mark in /etc/awall/optional/mark.json
route-table 1
fwmark 1
rule-priority 20000
# google dns
ping 8.8.8.8
# opendns
ping 208.67.222.222
}

interface bond0.257 {
# route-table must correspond with mark in /etc/awall/optional/mark.json
route-table 2
fwmark 2
rule-priority 20000
}
}}

Make sure we can reach the public IP from our LAN by adding static route rules for our private net(s). Edit <code>/etc/pingu/route-rules</code>:

{{cat|/etc/pingu/route-rules|
to 10.0.0.0/8 table main prio 1000
to 172.16.0.0/12 table main prio 1000
}}

Start service(s):

{{Cmd|rc-service pingu start
rc-update add pingu}}

Now, if both hosts stop responding to pings, ISP-1 will be considered down and all gateways via bond0.256 will be removed from main route table. Note that the gateway will not be removed from the route table '1'. This is so we can continue try ping via <code>bond0.256</code> so we can detect that the ISP is back online. When ISP starts working again, the gateways will be added back to main route table again.

== Commit Configuration ==
Commit configuration:

{{Cmd|lbu ci}}

= Hub Node =
We will document only what changes from the Spoke node setup.

== Routing Tables ==
<pre>
echo -e "42\tnhrp_shortcut\n43\tnhrp_mtu\n44\tquagga\n>> /etc/iproute2/rt_tables
</pre>

Add the following "up" commands:
{{cat|/etc/network/interfaces|
auto gre1
...
up ip rule add lookup nhrp_shortcut pref 11000
up ip rule add lookup quagga pref 11001
up ip rule add lookup nhrp_mtu pref 11999
}}

== NHRP ==
With your favorite editor open <code>/etc/opennhrp/opennhrp.conf</code> on Hub 2 and set the content as follows:

{{cat|/etc/opennhrp/opennhrp.conf|
interface gre1
map %Hub1_GRE_IP%/%MaskBit% hub1.example.org
route-table 44
shortcut
redirect
non-caching
}}

Do the same on Hub 1 adding the data relative to Hub 2.

With your favorite editor open <code>/etc/opennhrp/opennhrp-script</code> and set the content as follows:

<pre>
#!/bin/sh
case $1 in
interface-up)
ip route flush proto 42 dev $NHRP_INTERFACE
ip neigh flush dev $NHRP_INTERFACE
;;
peer-register)
CERT=`racoonctl get-cert inet $NHRP_SRCNBMA $NHRP_DESTNBMA | openssl x509 -inform der -text -noout | egrep -o "/OU=[^/]*(/[0-9]+)?" | cut -b 5-`
if [ -z "`echo "$CERT" | grep "^GRE=$NHRP_DESTADDR"`" ]; then
logger -t opennhrp-script -p auth.err "GRE registration of $NHRP_DESTADDR to $NHRP_DESTNBMA DENIED"
exit 1
fi
logger -t opennhrp-script -p auth.info "GRE registration of $NHRP_DESTADDR to $NHRP_DESTNBMA authenticated"

(
flock -x 200

AS=`echo "$CERT" | grep "^AS=" | cut -b 4-`
vtysh -d bgpd -c "configure terminal" \
-c "router bgp 65000" \
-c "neighbor $NHRP_DESTADDR remote-as $AS" \
-c "neighbor $NHRP_DESTADDR peer-group leaf" \
-c "neighbor $NHRP_DESTADDR prefix-list net-$AS-in in"

SEQ=5
(echo "$CERT" | grep "^NET=" | cut -b 5-) | while read NET; do
vtysh -d bgpd -c "configure terminal" \
-c "ip prefix-list net-$AS-in seq $SEQ permit $NET le 26"
SEQ=$(($SEQ+5))
done
) 200>/var/lock/opennhrp-script.lock
;;
peer-up)
echo "Create link from $NHRP_SRCADDR ($NHRP_SRCNBMA) to $NHRP_DESTADDR ($NHRP_DESTNBMA)"
racoonctl establish-sa -w isakmp inet $NHRP_SRCNBMA $NHRP_DESTNBMA || exit 1
racoonctl establish-sa -w esp inet $NHRP_SRCNBMA $NHRP_DESTNBMA gre || exit 1

CERT=`racoonctl get-cert inet $NHRP_SRCNBMA $NHRP_DESTNBMA | openssl x509 -inform der -text -noout | egrep -o "/OU=[^/]*(/[0-9]+)?" | cut -b 5-`
if [ -z "`echo "$CERT" | grep "^GRE=$NHRP_DESTADDR"`" ]; then
logger -p daemon.err "GRE mapping of $NHRP_DESTADDR to $NHRP_DESTNBMA DENIED"
exit 1
fi

if [ -n "$NHRP_DESTMTU" ]; then
ARGS=`ip route get $NHRP_DESTNBMA from $NHRP_SRCNBMA | head -1`
ip route add $ARGS proto 42 mtu $NHRP_DESTMTU table nhrp_mtu
fi
;;
peer-down)
echo "Delete link from $NHRP_SRCADDR ($NHRP_SRCNBMA) to $NHRP_DESTADDR ($NHRP_DESTNBMA)"
if [ "$NHRP_PEER_DOWN_REASON" != "lower-down" ]; then
racoonctl delete-sa isakmp inet $NHRP_SRCNBMA $NHRP_DESTNBMA
fi
ip route del $NHRP_DESTNBMA src $NHRP_SRCNBMA proto 42 table nhrp_mtu
;;
route-up)
echo "Route $NHRP_DESTADDR/$NHRP_DESTPREFIX is up"
ip route replace $NHRP_DESTADDR/$NHRP_DESTPREFIX proto 42 via $NHRP_NEXTHOP dev $NHRP_INTERFACE table nhrp_shortcut
ip route flush cache
;;
route-down)
echo "Route $NHRP_DESTADDR/$NHRP_DESTPREFIX is down"
ip route del $NHRP_DESTADDR/$NHRP_DESTPREFIX proto 42 table nhrp_shortcut
ip route flush cache
;;
esac

exit 0
</pre>

== BGP ==
With your favorite editor open <code>/etc/quagga/bgpd.conf</code> on Hub 2 and set the content as follows:

{{cat|/etc/quagga/bgpd.conf|
password zebra
enable password zebra
log syslog

router bgp 65000
bgp router-id %Hub2_GRE_IP%
bgp deterministic-med
network %GRE_NETWORK%/%MASK_BITS%
neighbor hub peer-group
neighbor hub next-hop-self
neighbor hub route-map CORE-IN in
neighbor spoke peer-group
neighbor spoke passive
neighbor spoke next-hop-self
neighbor %Spoke1_GRE_IP% remote-as 65001
neighbor %Spoke1_GRE_IP% peer-group spoke
neighbor %Spoke1_GRE_IP% prefix-list net-65001-in in
...
...
...

neighbor hub remote-as 65000
neighbor %Hub1_GRE_IP% peer-group core

ip prefix-list net-65001-in seq 5 permit 10.1.0.0/16 le 26
...

route-map CORE-IN permit 10
set metric +100
}}

Add the lines <code>neighbor %Spoke1_GRE_IP%...</code> for each spoke node you have. Do the same on Hub 1, changing the relevant data for Hub 2.

= Troubleshooting the DMVPN =
== Broken [https://wikipedia.org/wiki/Path_MTU_Discovery Path MTU Discovery (PMTUD)] ==
ISPs afraid of ICMP (which is somehow legitimate) often just blindly add <code>no ip unreachables</code> in their router interfaces, effectively creating a [https://wikipedia.org/wiki/Black_hole_%28networking%29 blackhole router] that breaks PMTUD, since ICMP Type 3 Code 4 packets (Fragmentation Needed) are dropped. PMTUD is needed by ISAKMP that runs on UDP (TCP works because it uses CLAMPMSS).

For technical details see https://packetlife.net/blog/2008/oct/9/disabling-unreachables-breaks-pmtud/

PMTUD could also be broken due to badly configured DSL modem/routers or bugged firmware. Turning off the firewall on modem itself or any VPN passthrough functionality it may help.

You can easily detect which host is the blackhole router by pinging with DF bit set and with packets of standard MTU size, each hop given in your traceroute to destination:

{{Cmd|ping -M do -s 1472 %IP%}}
{{Note|"-M do" requires GNU ping, present in <code>iputils</code> package}}

If you don't get a response back (either Echo-Response or Fragmentation-Needed) there's firewall dropping ICMP packets. If it answers to normal ping packets (DF bit cleared), most likely you have hit a blackhole router.

== Kernel and NHRP Routing Cache Issues ==
{{Todo|...}}

[[category: VPN]]

User:Deleted user

2025-06-10T15:22:44Z

Ikke: Blanked the page

User:Deleted user

2025-06-10T15:17:44Z

Ikke: Ikke moved page User:Casiobearing to User:Deleted user: Automatically moved page while merging the account "Casiobearing" to "Deleted user"

Please delete my account

OpenRC

2025-03-25T17:39:02Z

Ikke: Clarify status of user services, add `-p` flag to mkdir.

Alpine Linux uses [https://github.com/OpenRC/ openrc] for its init system. The init system manages the services, startup and shutdown of your computer.

Refer to the excellent guide [https://docs.alpinelinux.org/user-handbook/0.1a/Working/openrc.html working with OpenRC] from Alpine Linux documentation project to learn the basics quickly. Refer [[Writing Init Scripts]] and [[Multiple Instances of Services|Multiple instances of services]] pages for more advanced information.

== Quickstart ==

{|align="center" style="width:100%; border:1px #0771a6 solid; background:#f9f9f9; text-align:left; border-collapse:collapse;"
|- style="background:#333333; color:#ffffff; font-size: 0.9em; text-align:center;"
| width="50%" |Action
| |Command
|-
|- style="background:#333333; color:#ffffff; font-size: 0.9em; text-align:center;"
| colspan="3" | '''Managing a service - start,stop and restart'''
|-
| Start <serviceName> now || {{ic|rc-service <serviceName> start}}
|-
| Stop <serviceName> now || {{ic|rc-service <serviceName> stop}}
|-
| Restart <serviceName> now || {{ic|rc-service <serviceName> restart}}
|-
|- style="background:#333333; color:#ffffff; font-size: 0.9em; text-align:center;"
| colspan="3" | '''Adding and removing service from runlevels'''
|-
| Add <serviceName> to <runlevel> || {{ic|rc-update add <serviceName> <runlevel>}}
|-
| Remove <serviceName> from <runlevel> || {{ic|rc-update del <serviceName> <runlevel>}}
|-
|- style="background:#333333; color:#ffffff; font-size: 0.9em; text-align:center;"
| colspan="3" | ''' Check services in a runlevel and their status'''
|- style="background:#333333; color:#ffffff; font-size: 0.9em; text-align:center;"
|-
| To check status of <serviceName> || {{ic|rc-service <serviceName> status}}
|-
| To view services configured at <runlevel> || {{ic|rc-update show <runlevel>}}
|-
| To view currently active runlevels and state of services || {{ic|rc-status}}
|-
|- style="background:#333333; color:#ffffff; font-size: 0.9em; text-align:center;"
| colspan="3" | ''' Check and manage runlevels'''
|- style="background:#333333; color:#ffffff; font-size: 0.9em; text-align:center;"
|-
| To view available runlevels || {{ic|rc-status -l}}
|-
| To change to a different <runlevel> || {{ic|openrc <runlevel>}}
|-
| To add <s-runlevel> as a stacked <runlevel> || {{ic|rc-update add -s <s-runlevel> <runlevel>}}
|}

== Runlevels ==

A runlevel is basically a collection of services that needs to be started. Instead of random numbers they are named, and users can create their own if needed. The default startup uses the runlevels sysinit, boot, and default, in that order. Shutdown uses the shutdown runlevel.

The available runlevels are:
* '''default''' - Used if no runlevel is specified. (This is generally the runlevel you want to add services to.)
* '''hotplugged'''
* '''manual'''

The special runlevels are:

* '''sysinit''' - Brings up system specific stuff such as <code>/dev</code>, <code>/proc</code> and optionally <code>/sys</code> for Linux based systems. It also mounts <code>/lib/rc/init.d</code> as a ramdisk using tmpfs where available unless <code>/</code> is mounted rw at boot. <code>'''rc'''</code> uses <code>/lib/rc/init.d</code> to hold state information about the services it runs. sysinit always runs when the host first starts and should not be run again.
* '''boot''' - Generally the only services you should add to the boot runlevel are those which deal with the mounting of filesystems, set the initial state of attached peripherals and logging. Hotplugged services are added to the boot runlevel by the system. All services in the boot and sysinit runlevels are automatically included in all other runlevels except for those listed here.
* '''single''' - Stops all services except for those in the sysinit runlevel.
* '''reboot''' - Changes to the shutdown runlevel and then reboots the host.
* '''shutdown''' - Changes to the shutdown runlevel and then halts the host.

=== Stacked runlevels ===

Runlevel "inheritance" is acheived through [https://docs.alpinelinux.org/user-handbook/0.1a/Working/openrc.html#_runlevel_stacking runlevel stacking]. For more detailed information, refer [https://wiki.gentoo.org/wiki/OpenRC/Stacked%20runlevel Gentoo wiki].

== Configuration ==

System-wide configuration file for OpenRC is {{Path|/etc/rc.conf}}.

If the setting {{Codeline|rc_parallel{{=}}"YES"}} is configured, the OpenRC system tries to start services in parallel for a slight speed improvement. This setting however comes with a message from openRC developers:{{Warning|whilst we have improved parallel, it can still potentially lock the boot process. Don't file bugs about this.}} To improve boot times, consider the idea suggested in the [[#Preventing slow services from delaying boot|preventing slow services]] from delaying boot section.

=== cgroups v2 ===

Since {{pkg|openrc}} 0.51 cgroups v2, or "unified", is the default. You can enable hybrid cgroups v1 & v2 by editing {{Path|/etc/rc.conf}} and setting <code>rc_cgroup_mode="hybrid"</code>.

Then you should run {{Cmd|# rc-service cgroups start}}
to take effect and {{Cmd|# rc-update add cgroups}}
to auto mount the cgroup filesystem on boot.

== User services ==

{{Note|Currently User services are experimental and available in [[Repositories#Edge|edge]] version only}}

OpenRC supports managing services for users. The [[XDG_RUNTIME_DIR]] variable must be set before calling {{Codeline|openrc --user}}, as it's used to store state for openrc itself and the services it runs.

For many [[wayland]] user services, a custom GUI runlevel needs to be created.
The below example shows how this is done for {{pkg|wlsunset}} package. wlsunset provides an OpenRC user services.
In order to use this service, the following steps need to be performed:

In order to create this runlevel,run the following commands:{{Cmd|$ mkdir -p "${XDG_CONFIG_HOME:-$HOME/.config}/rc/runlevels/gui
$ rc-update --user --stack add default gui}}

Enable the wlsunset service by adding it to this runlevel:{{Cmd|$ rc-update add -U wlsunset gui}}

Next, allow propagation of the WAYLAND_DISPLAY environment variable by adding the following lines to file {{path|${XDG_CONFIG_HOME:-$HOME/.config}/rc/rc.conf}} as follows:{{Cat|rc.conf|<nowiki>rc_env_allow="WAYLAND_DISPLAY"</nowiki>}}

Finally, make sure to start services from the GUI runlevel from your Wayland compositor in its configuration file (i.e. after WAYLAND_DISPLAY is set) by
adding the following lines to the startup file of your compositor.
openrc --user gui

== Preventing slow services from delaying boot ==

Services that take a while to start will block the boot process until they complete. E.g.: <code>iwd</code> and <code>networking</code> might delay startup of an interactive system rather than start in the background.

This can be remedied as per Patrycja's blog post titled [https://ptrcnull.me/posts/openrc-async-services/ OpenRC: Start services after login prompt]. This solution makes use of [[#Stacked runlevels|stacked runlevels]].

{{Warning|If the file {{Path|'''/etc/inittab'''}} is edited wrongly, the system may not boot. Take backup and learn how to restore using rescue disk before proceeding.}}
* Create a custom runlevel (name is “async” here, but it doesn’t matter) {{Cmd|# mkdir /etc/runlevels/async}}

* Add default as a stacked runlevel {{Cmd|# rc-update add -s default async}}

* Remove slow services from default and add them to async {{Cmd|<nowiki># rc-update del chronyd
# rc-update add chronyd async </nowiki>}}

* Add changing of runlevel to async by adding the line '''::once:/sbin/openrc async''' to {{Path|/etc/inittab}} file as follows: {{Cat|/etc/inittab|<nowiki>...
::wait:/sbin/openrc default
::once:/sbin/openrc async -q

# Set up a couple of getty's
tty1::respawn:/sbin/getty 38400 tty1
...</nowiki>}}
After rebooting, services from async will start separately. This change does not affect other services that start from Default runlevel and they may still block agetty from running due to the wait label.

== Command usage ==

Usage: rc-update [options] add <service> [<runlevel>...]
or: rc-update [options] del <service> [<runlevel>...]
or: rc-update [options] [show [<runlevel>...]]
Options: [ asuChqVv ]
-a, --all Process all runlevels
-s, --stack Stack a runlevel instead of a service
-u, --update Force an update of the dependency tree
-h, --help Display this help output
-C, --nocolor Disable color output
-V, --version Display software version
-v, --verbose Run verbosely
-q, --quiet Run quietly (repeat to suppress errors)

Usage: rc-status [options] [-f ini] <runlevel>...
or: rc-status [options] [-f ini] [-a | -c | -l | -m | -r | -s | -u]
Options: [ acf:lmrsSuChqVv ]
-a, --all Show services from all run levels
-c, --crashed Show crashed services
-f, --format <arg> format status to be parsable (currently arg must be ini)
-l, --list Show list of run levels
-m, --manual Show manually started services
-r, --runlevel Show the name of the current runlevel
-s, --servicelist Show service list
-S, --supervised show supervised services
-u, --unused Show services not assigned to any runlevel
-h, --help Display this help output
-C, --nocolor Disable color output
-V, --version Display software version
-v, --verbose Run verbosely
-q, --quiet Run quietly (repeat to suppress errors)

Usage: rc-service [options] [-i] <service> <cmd>...
or: rc-service [options] -e <service>
or: rc-service [options] -l
or: rc-service [options] -r <service>
Options: [ cdDe:ilr:INsSZChqVv ]
-d, --debug set xtrace when running the command
-D, --nodeps ignore dependencies
-e, --exists <arg> tests if the service exists or not
-c, --ifcrashed if the service is crashed run the command
-i, --ifexists if the service exists run the command
-I, --ifinactive if the service is inactive run the command
-N, --ifnotstarted if the service is not started run the command
-s, --ifstarted if the service is started run the command
-S, --ifstopped if the service is stopped run the command
-l, --list list all available services
-r, --resolve <arg> resolve the service name to an init script
-Z, --dry-run dry run (show what would happen)
-h, --help Display this help output
-C, --nocolor Disable color output
-V, --version Display software version
-v, --verbose Run verbosely
-q, --quiet Run quietly (repeat to suppress errors)

Usage: openrc [options] [<runlevel>]
Options: [ a:no:s:SChqVv ]
-n, --no-stop do not stop any services
-o, --override <arg> override the next runlevel to change into
when leaving single user or boot runlevels
-s, --service <arg> runs the service specified with the rest
of the arguments
-S, --sys output the RC system type, if any
-h, --help Display this help output
-C, --nocolor Disable color output
-V, --version Display software version
-v, --verbose Run verbosely
-q, --quiet Run quietly (repeat to suppress errors)

Reboot/Halt/Poweroff: (And their equivalent from traditional GNU/Linux systems):{{Cmd|<nowiki># reboot # ⇔ shutdown now -r
# halt # ⇔ shutdown now -H
# poweroff # ⇔ shutdown now -P</nowiki>}}

== Troubleshooting ==

Whenever a openRC service fails to run, to troubleshoot enable debugging option and run the command.

For example, if running the command {{ic|rc-service greetd start}} causes greetd service to immediately crash, then alter the command to enable and view the debug:{{Cmd|# rc-service -d greetd restart}}

== See also ==

* [[Writing Init Scripts]]
* [[Multiple Instances of Services]]
* [https://github.com/OpenRC/openrc/blob/master/user-guide.md OpenRC user Guide]
* [https://github.com/OpenRC/openrc/blob/master/service-script-guide.md OpenRC Service Script Writing Guide]
* [https://wiki.gentoo.org/wiki/OpenRC Gentoo Wiki]
* [https://wiki.archlinux.org/title/OpenRC ArchWiki]
* [https://wiki.postmarketos.org/wiki/OpenRC PostmarketOS Wiki]
* [https://ptrcnull.me/posts/openrc-async-services/ Start services after login prompt]

[[Category:Booting]]
[[Category:System Administration]]
[[Category:Services]]

Creating an Alpine package

2025-02-24T17:19:40Z

Ikke:

{{TOC right}}
This page documents the procedure to create and submit new package in Alpine Linux.

== Overview ==

This is a brief list of the steps to create and submit new package in Alpine Linux. Please see the rest of this wiki for details on the steps.

# Create an account on https://gitlab.alpinelinux.org
# [[Include:Setup your system and account for building packages |Setup the build environment]].
# Fork the [https://gitlab.alpinelinux.org/alpine/aports aports repository] and [[Git#Cloning_your_forked_repository|clone your fork]] .
# Set git pull.rebase=true, Configure your [[Git#Configure_your_global_git_config|git username and email]].
# Create and switch to a new branch (don't use master).
# Add a new directory under testing that is your new package name.
# Add your APKBUILD file.
# Run abuild checksum
# Make sure you run the apkbuild-lint and aport -r and there are no warnings.
# Commit your APKBUILD with the commit message: 'testing/packagename: new aport'
# Push your changes to your fork on https://gitlab.alpinelinux.org/alpine.
# Create a merge request.

== Requirements ==

[[Include:Setup your system and account for building packages|Setup your system and account]] for building packages in Alpine Linux. If you do not have Alpine Linux already, refer to [[Setting up the build environment]].

== Getting help ==
{{Seealso|Abuild and Helpers}}
The {{pkg|abuild}} package provides scripts necessary for creating packages for Alpine Linux. It implements functionality for building packages as well as additional commands and options for package maintenance. It might be wise to start by checking what the [[Abuild and Helpers|abuild]] program can/cannot do.{{Cmd|abuild -h}}

For realtime help, you can also go on #alpine-devel on [[IRC]].

A reference for APKBUILD files is available as [[APKBUILD Reference]] wiki page or a man page in the {{pkg|abuild-doc}} package:{{Cmd|man APKBUILD}}

== Creating an APKBUILD file ==

=== Use a template APKBUILD ===

Alpine Linux has the following tools to create a template APKBUILD file.

==== newapkbuild ====
{{:Include:Newapkbuild}}

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.

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).

==== apkbuild-cpan ====
{{:Include:apkbuild-cpan}}

==== apkbuild-pypi ====
{{:Include:apkbuild-pypi}}

=== 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>https://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 [https://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]
* [https://archlinux.org/packages/?q=search Arch Linux packages] [https://aur.archlinux.org/ Arch Linux User Repository]

==== 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.

Note that some licenses have additional requirements that should be adhered to. The <code>MIT</code> license for example has the requirement:

<blockquote>
The above copyright notice and this permission notice (including the next paragraph) shall be included in all copies or substantial portions of the Software.
</blockquote>

This means that we need to include the license as shipped with the project.

Known licenses that require this:

* <code>MIT</code>
* <code>ISC</code>

If a package has a special/custom license or is not listed as [https://opensource.org/licenses/alphabetical OSI approved], use the identifier "custom". In that case we need to provide the license file with the package as well.

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:

{{Cmd|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.

<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. For example, can be used to restore busybox links:
<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.

<br> 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 [https://www.gnu.org/software/make/manual/make.html#Parallel parallel] building/installing. A normal make line would be:

{{Cmd|make}}

To disable parallel we use:

{{Cmd|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:

{{Cmd|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.

<pre>
builddir="$srcdir"/$pkgname-$pkgver
</pre>

==== 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):

{{Cmd|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.

{{Cmd|abuild -r}}

See also [[Abuild_and_Helpers|Abuild and Helpers]].

== 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/main/
/home/USER/packages/community/
https://dl-cdn.alpinelinux.org/alpine/edge/main
https://dl-cdn.alpinelinux.org/alpine/edge/community
https://dl-cdn.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]].
Also check out [https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/COMMITSTYLE.md?ref_type=heads aports/COMMITSTYLE.md] and [https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/CODINGSTYLE.md?ref_type=heads aports/CODINGSTYLE.md]

== 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}}

== Automated flagging of outdated ports ==
Consider adding your port to [https://release-monitoring.org/ Anitya], so it will be flagged as outdated
as soon as a new stable version is released by upstream.

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

[[category: Development ]] [[category: Package Manager]]

Creating an Alpine package

2025-02-24T17:13:37Z

Ikke:

Help:Editing

2025-01-10T06:58:21Z

Ikke: Update from User:Prabuanand/Editing

{{TOC right}}

An edit can contribute whole new paragraphs or pages of information, or it can be as simple as fixing a typo or a spelling mistake. Make sure you are always aiming to do something which ''improves'' the contents of the wiki.

Before [[#Steps to edit wiki|editing]] or [[#Creating pages|creating pages]] refer [[Alpine Linux:Wiki etiquette|Wiki etiquette]], [[Help:Reading]] and [[Help:Style]] pages for an overview of the common conventions followed in Alpine Linux wiki.

{{Tip|To experiment with editing, please use the [[sandbox]]. For a quick overview of wiki markup, see [[Help:Cheatsheet]].}}

For additional reference, use the help pages of [http://www.mediawiki.org/wiki/Help:Contents MediaWiki] and [http://en.wikipedia.org/wiki/Help:Wiki_markup Wikipedia], as this wiki is also powered by [[MediaWiki]].

== Steps to edit wiki ==

# Click the <code>Edit</code> page tab at the top of the page. Make changes to the text. When you need to use some type of formatting, such as for new headings or bolding of text, you do this using wiki syntax or the buttons in the edit toolbar above the editing zone.
# Before you save a change, you must enter a short note in the <code>Summary</code> box describing your changes.
# Mark the edit as minor by checking the <code>This is a minor edit</code> box if the edit is fixing a typo or a spelling mistake.
# It's a good idea to use the <code>Show preview</code> button to see what your change will look like, before you save it. It's good to get into the habit of eliminating mistakes in your own work, by using a preview before saving, rather than saving, then having to do ''another'' edit just to make one or more minor corrections.
# Another option is the <code>Show changes</code> button which allows you to see the differences between the current version and the edited version.
# Click the <code>Save Changes</code> button to save changes. If unsatisfied, click Cancel instead and redo again.

== Creating pages ==

{{Note|Pay proper attention to name your page as it appears as Title or Heading1 of the page and changing the page name in Wiki is not trivial. Users new to Wiki are advised to use [[#Temporary pages|Temporary pages]].}}

=== Starting a page ===

There are 2 ways to start a new page:
# Create a <code><nowiki>[[Title for new page]]</nowiki></code> link on an existing page and click save. Open the page again and click on the red colored <u style="color:#ba0000">Title for new page</u> link to take you to the edit page of the new page. (Recommended)
# Type the URL for new page with proper <code><nowiki>[[Title for new page]]</nowiki></code> into the address bar. For example: <code><nowiki>http://wiki.alpinelinux.org/wiki/Title_for_new_page</nowiki></code>.

In both the above cases, simply type your text in the new page, save and the new page will be created. New pages should be assigned at least one [[#categories|catgeory]]. Tutorials should also be added to [[Tutorials and Howtos]], or if it concerns Alpine development, to [[Developer Documentation]].

===Temporary pages ===

If you wish to create a temporary page, please use a subpage of your User namespace. For example: [[Special:MyPage/Temporary page|User:Username/Temporary page]]. This helps to keep the main namespace tidy and prevents the pages from turning up in normal searches (the User namespace is not searched by default).

=== Moving or renaming pages ===

* If the move might be controversial, [[#move|propose it first]] and try to resolve any disagrements on the discussion page.
* The new name must either not exist as a page, or exist as a redirect page with only 1 entry in its page history.
* Use the "What links here" link in the sidebar, and be sure to update all links to internal page targets. If this isn't done, double redirects are created. (That's where a redirect leads to a redirect, and in such cases only the first redirect is followed automatically.)
* In the default wiki skin, the link to Move pages (and also to Watch them) is in the popup menu between "View history" and the Search box.
* Always move the discussion page, too, unless you have a very good reason for not doing so.

=== Deleting pages ===

Only administrators can delete pages. Other users should instead use <code>{{lb}}Delete{{rb}}</code> to [[#delete|propose the page for deletion]]. (''Don't'' clear the page's content except where it's obviously spam.)


</dl>

== Formatting==

=== Inline elements ===
* ''<nowiki>''italic''</nowiki>'' or use <i><i></i> or <em><em></em> or {font-style:italic} in a style attribute
* '''<nowiki>'''bold'''</nowiki>''' or use <b><b></b> or <strong><strong></strong> or {font-weight:bold} in a style attribute


* <small><small></small> or use {font-size:smaller} in a style attribute
* <big><big></big> or use {font-size:larger} in a style attribute (invalid in HTML5)
* <sup><sup></sup> or use {vertical-align:super} in a style attribute
* <sub><sub></sub> or use {vertical-align:sub} in a style attribute


* <font> is deprecated; use {font-size:10pt; color:red; font-family:"Courier"} in a style attribute
* <nowiki><span style="</nowiki><span style="color:gray">color:gray</span>">
* <nowiki><span style="</nowiki><span style="color:white; background:red;">color:white; background:red</span>">
* <u><u></u> or use <ins><ins></ins> or {text-decoration:underline} in a style attribute (<u> is valid in HTML5 but not HTML4/strict; <ins> can also be a block element)
* <s><s></s> or use <del><del></del> or {text-decoration:line-through} in a style attribute (<s> is valid in HTML5 but not HTML4/strict; <del> can also be a block element)


* <code><code></code> uses {font-family:monospace;} (<tt> is invalid in HTML5)
*: <code><var>markup</var> and → entities are still honored</code>
*: See also [[#inlinecode|below]]
* <kbd><kbd></kbd> and <samp><samp></samp>
* <var><var></var> and <dfn><dfn></dfn>
* <cite><cite></cite>
* <q><q></q>

* <nowiki>{{Hint|</nowiki>{{Hint|term|explanation}}<nowiki>|explanation}}</nowiki>
* <nowiki>{{Path|</nowiki>{{Path|/a/path/name}}<nowiki>}}</nowiki>
* {{Lb}}Key| {{Key|Ctrl}}{{Rb}}+{{Lb}}Key| {{Key|C}}{{Rb}}

* Here is one line, followed by <br /><br /> and another line.

* Here is .

* [[HTML Entities]]

=== Headings ===

An article with 4 or more headings automatically creates a table of contents. You can force a table of contents (or fine-tune its placement) by inserting <nowiki>__TOC__</nowiki>. You can suppress the table of contents by inserting <nowiki>__NOTOC__</nowiki>.

Start headings at level 2, and don't skip levels. First-level headings are not allowed, their formatting is reserved for the article title.

<pre>== Heading2 ==</pre>


<pre>=== Heading3 ===</pre>


<pre>==== Heading4 ====</pre>



=== Lists ===

<pre>
# Here is a numbered list item.
## Doubly-numbered
#* Numbered and bulleted.

* Here is a bulleted list item.
** Doubly-bulleted
*# Bulleted and numbered.
*# Another item.
</pre>

will produce:
# Here is a numbered list item.
## Doubly-numbered
#* Numbered and bulleted.

* Here is a bulleted list item.
** Doubly-bulleted
*# Bulleted and numbered.
*# Another item.

Blank lines, or non-bulleted/numbered lines, end the lists. You can also code a list manually, which gives you more flexibility with multi-line entries and styling:
<pre>
<ol start=2>
<li>Ordered list item
<li value=4>Another item
<li type="disc"><p>A third item</p><p>Next line</p>
</ol>
</pre>

and similarly for <code><ul></code>. Closing <code></li></code> tags are permitted but not necessary.

Each of these:
<pre>
;item: Body text

{{Define|item|Body text}}

<dl>
<dt>item
<dd>Body text
</dl>
</pre>

will produce:
;item: Body text

The second markup option also wraps a <code><nowiki><span id="item"></nowiki></code> around the block. Note that with the third option, you shouldn't use closing <code></dt></code> or <code></dd></code> tags.

=== Indenting ===

<b>:</b> Simply indented text (on left side only).

<blockquote>This is a blockquote.
It collapses whitespace, and indents on both sides.</blockquote>

will produce:
: Simply indented text (on left side only).

<blockquote>This is a blockquote.
It collapses whitespace, and indents on both sides.</blockquote>



=== Displaying code ===

<dl>
<dt id="inlinecode">Inline code
<dd>Use <code><code></code> for styling, and <code><nowiki></code> to suppress markup. If you use both, they must appear in that order. <code><nowiki></code> converts → entities and collapses whitespace (even multiple <code>\n</code>s), but ignores all <nowiki>'''wiki'''</nowiki> and <code><span style="color:green"></code>HTML<code></span></code> <nowiki>[[markup]]</nowiki>.

<dt>User input
<dd>{{Cmd|{{lb}}[[Template:Cmd|Cmd]]{{!}}a <var><var>command</var></var> to try{{rb}}}}
This is a block-level equivalent for the inline HTML element <code><kbd></code>. Note that wiki markup is still honored in the command text; but whitespace is not collapsed. [[#cat|See below]] for how to escape some special characters.

<dt>Command output; or shell sessions that intermix prompts, user input, and command output; or segments of files
<dd>Use space-indented blocks or <code><pre></code>:
<pre>
Every line
begins with '''a space'''.

<pre>
Lines aren't
indented with '''a space.'''
</pre>

<nowiki>Only first
line begins with '''a space'''.</nowiki>
</pre>

will produce:

Every line
begins with '''a space'''.

<pre>
Lines aren't
indented with '''a space.'''
</pre>

<nowiki>Only first
line begins with '''a space'''.</nowiki>

All of these render as styled blocks, in monospace, and don't collapse whitespace. They are block-level equivalents for the inline HTML elements <code><samp></code> or <code><code></code>.

All of these markup options convert → entities. The first also processes <nowiki>'''wiki''' and <span style="color:green">HTML</span> [[markup]]</nowiki>.

The second and the third don't; and they give equivalent presentations. With the third option, lines after the first should not be space-prefixed; the block will extend to the closing <code></nowiki></code>.

<dt id="cat">File contents
<dd><pre>
{{Cat|/path/to/file|body '''text''' <br /> more
Second line.}}
</pre>

will produce:
{{Cat|/path/to/file|body '''text''' <br /> more
Second line.}}
Note that wiki and HTML markup in the file contents aren't converted, though entities still are. You must escape characters as follows:
: {{=}} not inside [[..]] use &#61; or {{lb}}{{=}}{{rb}}
: {{!}} not inside [[..]] use &#124; or {{lb}}!{{rb}}
: {{lb}} use &#123; twice or {{lb}}lb{{rb}}
: {{rb}} use &#125; twice or {{lb}}rb{{rb}}
: unmatched [[ use &#91; twice
: unmatched ]] use &#93; twice
: # at start of line use &#35;
: * at start of line use &#42;

As an alternative to all of these escapes, you could instead wrap the body in <nowiki> tags.

<dt>Block-level code with no additional styling
<dd><pre>
<p style="white-space:pre; font-family:monospace;">One line.
Second line.
</p></pre>
will produce:
<p style="white-space:pre; font-family:monospace;">One line.
Second line.
</p>
This would be the behavior of HTML's <code><pre></code> without any styling. To wrap to screen width, use {white-space:pre-wrap} in a style attribute.


</dl>

=== Tables ===

Tables may be created in wiki pages. As a general rule, it is best to avoid using a table unless you need one as table markup often complicates page editing.

==== Simple table ====

In wikitext editor, place the caret where you want to insert a table. Then, in the toolbar, press “Advanced”, then choose Table button. A dialog opens.

From the dialog, you can choose whether to enable a table header row, to stylize the table with border and to make the table sortable. A preview example is displayed. You can also set row and column counts you need. Then, press “Insert” button.
<pre>{| class="wikitable"
|+ Optional Caption text
|-
! Header 1 !! Header 2 !! Header 3
|-
| 1.1 || 1.2 || 1.3
|-
| 2.1 || 2.2 || 2.3
|-
| 3.1 || 3.2 || 3.3
|}
</pre>


{| class="wikitable"
|+ Optional Caption text
|-
! Header 1
! Header 2
! Header 3
|-
| 1.1
| 1.2
| 1.3
|-
| 2.1
| 2.2
| 2.3
|-
| 3.1
| 3.2
| 3.3
|}

==== Advanced table ====

You can add HTML attributes to tables. CSS style attributes can be added with or without other HTML attributes. Table alignment is achieved by using CSS. For more information, refer official mediawiki guide on [http://www.mediawiki.org/wiki/Help:Tables tables]:

<pre>
{| border="1" style="width:75%; height:200px" 
|+ The table's caption
|-
! width=100px | Advanced Table !! columnlabel 1
! columnlabel 2 !! columnlabel 3
|-
! rowlabel1
| Cell 1.1 || Cell 1.2 || Cell 1.3
|- style="height:100px; background:none" 
! align=right style="width:200px" | rowlabel2
| style="background:red; color:white" | Cell 2.1
| colspan=2 align=center | Cell 2.2 & 2.3
|- valign=top 
! rowspan=2 | rowlabel 3 & 4
| Cell 3.1 || Cell 3.2 || Cell 3.3
|-
| Cell 4.1 || Cell 4.2 || Cell 4.3
|}
</pre>

{| border="1" style="width:75%; height:200px" 
|+ The table's caption
|-
! width=100px | Advanced Table !! columnlabel 1
! columnlabel 2 !! columnlabel 3
|-
! rowlabel1
| Cell 1.1 || Cell 1.2 || Cell 1.3
|- style="height:100px; background:none" 
! align=right style="width:200px" | rowlabel2
| style="background:red; color:white" | Cell 2.1
| colspan=2 align=center | Cell 2.2 & 2.3
|- valign=top 
! rowspan=2 | rowlabel 3 & 4
| Cell 3.1 || Cell 3.2 || Cell 3.3
|-
| Cell 4.1 || Cell 4.2 || Cell 4.3
|}

=== Images ===

Basic example is given below. For more information, refer official mediawiki guide on [https://www.mediawiki.org/wiki/Help:Images Images]

<pre>[[File:Alpinelinux 01.png|right|thumb|100px|Caption text]]</pre> will produce:

[[File:Alpinelinux 01.png|right|thumb|100px|Caption text]]
{{Clear}}
Options can appear in any order:
* <i>Caption text</i> defaults to filename; to wholly suppress, use <code><span title=""></span></code>
* '''alt='''<i>text</i>
* Size can be [<i>width</i>][<b>x</b><i>height</i>]<b>px</b>
* '''page='''<i>number</i>, for PDF images
* rendered inline, Caption shows as hover text: '''frameless''', and/or '''border'''
** rendered inline, on separate line: '''none'''
** Valign for inline images, defaults to middle: '''middle|baseline|sub|super|top|text-top|bottom|text-bottom'''
** Text flow can be stopped by placing <nowiki>{{Clear}}</nowiki>  before the text that should start below the floating image
** '''link='''<i>URL</i>|<i>pagetitle</i>|<i>blank</i>, only for inline images
* rendered floating, defaults to right align, Caption displayed below image: '''thumb''', '''thumb='''<i>alternate filename</i>, '''frame''' (ignores size options)
** rendered floating, defaults to thumb: '''left|right|center'''

To instead link to the file, you need to add a colon: [[:File:Alpinelinux 01.png]].

=== Signature ===
{{Main|Help:Signature}}
In Talk pages, sign and date your posts. Adding <nowiki>--~~~~</nowiki> gives a signature and timestamp: --[[User:Dubiousjim|Dubiousjim]] 10:00, 4 March 2012 (UTC)

=== Other elements===
Create HRs like this:
<pre>----</pre> ----

== Links ==

Links are used to reference pages within this wiki, other Alpine Linux websites, or external websites.

=== Internal links ===

A valid Internal link or wikilink <code><nowiki>[[Kernels|Linux Kernel wiki page]]</nowiki></code> will produce:[[Kernels|Linux Kernel wiki page]].

When you preview or save your changes, you will see a link that can be followed to the target page. If the page exists the link is displayed in blue (like the word "Linux Kernel wiki page" above); if the page does not exist, the link appears red. Following such a "redlink" to a missing page (whether or not it is actually red) will usually enable the user to create the page.

=== Special links ===

For official packages in [[Repositories]]:

Using <code><nowiki>{{Pkg|gtk+2.0}}</nowiki></code> will produce: {{Pkg|gtk+2.0}}.

For existing [https://gitlab.alpinelinux.org/alpine/aports/ Issues in aports]:

Using <code><nowiki>{{Issue|279}}</nowiki></code> will produce: {{Issue|279}}.
The issue's description can be included as an optional second argument.

For existing [https://gitlab.alpinelinux.org/alpine/aports/ Merge Requests in aports]:

Using <code><nowiki>{{MR|73024|Description}}</nowiki></code> will produce: {{MR|73024|Description}}.
Here the MR's description has been included as an optional second argument.

===External links===

Link to an external website <code><nowiki>[http://www.example.org/ an external link]</nowiki></code> will produce: [http://www.example.org/ an external link].

If no link text is supplied <code><nowiki>[http://www.example.org/]</nowiki></code> will produce: [http:///www.example.org]. To avoid this, omit brackets and use <code><nowiki>http://www.example.org/</nowiki></code> to produce: http://www.example.org/.

For displaying an external URL without hyperlink use <code><nowiki><nowiki>http://www.example.org/</nowiki></nowiki></code> to produce <nowiki>http://www.example.org</nowiki>.


== Categories ==

<div id="categories">
Categories provide automatic indexes that are useful as tables of contents. These tags create links at the bottom of the page that take you to the list of all pages in that category, which makes it easy to browse related articles.

Every page should be assigned at least one [[Special:Categories|Category]], by placing the following '''at the bottom of the page''':<br>
<code><nowiki>[[Category:Category name]]</nowiki></code>

Always us one of the existing category from among the [[Special:Categories|list of categories in this Wiki]] before creating a new category. To refer an existing category in your wiki page, for example to link [[:Category:kernel]] use <code><nowiki>[[:Category:kernel]]</nowiki></code>
</div>

== Redirect ==

A redirect page should contain only:
<pre>#REDIRECT [[pagename]]</pre>

== Transclusion ==

When same content needs to be included in multiple page, use [[Alpine_Linux:Glossary#transclusion|transclusion]]. This helps when updating same content in multiple documents without having to edit those documents separately.

To include a page (e.g. "Daily driver guide"), a colon (:) must be added in front of the name: <nowiki>{{:Daily driver guide}}</nowiki>

Refer to the list of [[Special:MostTranscludedPages|transcluded pages]] in wiki.

== Templates ==

Templates are standard wiki pages whose content is designed to be transcluded inside other pages. [[Help:Template]] page provides information about designing templates. Templates can be inserted into an article to aid in formatting content.

Refer full [[Special:AllPages/Template:|list of templates]] defined in this Wiki.

The following Message box templates provide additional emphasis to the reader.

{{Warning|<nowiki>{{Warning|Write your Warning here.}}</nowiki>}}
{{Note|<nowiki>{{Note|Write your Note here.}}</nowiki>}}
{{Tip|<nowiki>{{Tip|Write your Tip here.}}</nowiki>}}
{{Todo|<nowiki>{{Todo|Write your Todo here.}}</nowiki>}}
{{Box|Heading:|<nowiki>{{Box|Heading:|Body}}</nowiki>}}
{{Box|Heading:|<nowiki>{{Box|Heading:|Body then border-color then background-color|#DF0000|#FFDFDF}}</nowiki>|#DF0000|#FFDFDF}}

The following Message box templates contain a specific message about a specific issue with a page or section in Wiki.

<div id="delete">
{{lb}}[[Template:Delete|Delete]]|Message.}}
will produce:

<center>
{|style="width: 48em; padding:2px; margin:0; margin-bottom:10px; background-color:#f1f1de; border:1px solid #cc9; -moz-border-radius-bottomright: 0.5em; -moz-border-radius-bottomleft: 1em; border-radius-bottomright: 0.5em; border-radius-bottomleft: 1em; -webkit-border-bottom-right-radius: 0.5em; -webkit-border-bottom-left-radius: 1em;"
|<div style="font-size: 1.5em; font-weight:bold; text-align:center;"> [[Image:Tango-user-trash-full.png|48px|left|link=]] This material is proposed for deletion ... </div><p style="text-align: center; font-size: 87%;">Message.
([[{{TALKPAGENAME}}|Discuss]])<br />Make sure no other pages link here and check the page's history before deleting.</p>
|}</center>

{{lb}}[[Template:Obsolete|Obsolete]]|Alternate message.}}
will produce:

<center>
{|style="width: 48em; padding:2px; margin:0; margin-bottom:10px; background-color:#f1f1de; border:1px solid #cc9; -moz-border-radius-bottomright: 0.5em; -moz-border-radius-bottomleft: 1em; border-radius-bottomright: 0.5em; border-radius-bottomleft: 1em; -webkit-border-bottom-right-radius: 0.5em; -webkit-border-bottom-left-radius: 1em;"
|<div style="font-size: 1.5em; font-weight:bold; text-align:center;"> [[Image:Out_of_date_clock_icon.svg‎|54px|left|link=]] This material is obsolete ... </div><p style="text-align: center; font-size: 87%;">Alternate message.
([[{{TALKPAGENAME}}|Discuss]])</p>
|}</center>

{{lb}}[[Template:Merge|Merge]]|Page to merge with|Additional message.}}
will produce:

<center>
{|style="width: 48em; padding:2px; margin:0; margin-bottom:10px; background-color:#f6f6f6; border:1px solid #aaa; -moz-border-radius-bottomright: 0.5em; -moz-border-radius-bottomleft: 1em; border-radius-bottomright: 0.5em; border-radius-bottomleft: 1em; -webkit-border-bottom-right-radius: 0.5em; -webkit-border-bottom-left-radius: 1em;"
|<div style="font-size: 1.5em; font-weight:bold; text-align:center;"> [[Image:Tango-two-arrows.png‎|75px|left|link=]] This material is proposed for merging ... </div><p style="text-align: center; font-size: 87%;">It should be merged with [[Page to merge with]].{{Ifn|Additional message.| Additional message.}}
([[{{TALKPAGENAME}}|Discuss]])</p>
|}</center>

<div id="move">
{{lb}}[[Template:Move|Move]]|New page name|Reason.}}
will produce:

<center>
{|style="width: 48em; padding:2px; margin:0; margin-bottom:10px; background-color:#f6f6f6; border:1px solid #aaa; -moz-border-radius-bottomright: 0.5em; -moz-border-radius-bottomleft: 1em; border-radius-bottomright: 0.5em; border-radius-bottomleft: 1em; -webkit-border-bottom-right-radius: 0.5em; -webkit-border-bottom-left-radius: 1em;"
|<div style="font-size: 1.5em; font-weight:bold; text-align:center;"> [[Image:Tango-go-next.png‎|48px|left|link=]] This page is proposed for moving ... </div><p style="text-align: center; font-size: 87%;">It should be renamed to [[New page name]]. Reason.
([[{{TALKPAGENAME}}|Discuss]])</p>
|}</center>
</div>

{{lb}}[[Template:Draft|Draft]]|Alternate message.}}
will produce:

<center>
{|style="width: 48em; padding:2px; margin:0; margin-bottom:10px; background-color:#f6f6f6; border:1px solid #aaa; -moz-border-radius-bottomright: 0.5em; -moz-border-radius-bottomleft: 1em; border-radius-bottomright: 0.5em; border-radius-bottomleft: 1em; -webkit-border-bottom-right-radius: 0.5em; -webkit-border-bottom-left-radius: 1em;"
|<div style="font-size: 1.5em; font-weight:bold; text-align:center;"> [[Image:Underconstruction_clock_icon_gray.svg‎|64px|left|link=]] This material is work-in-progress ... </div><p style="text-align: center; font-size: 87%;">Alternate message.<br /><i>(Last edited by
{{REVISIONUSER}} on {{REVISIONDAY}} {{Month|{{REVISIONMONTH}}}} {{REVISIONYEAR}}.)</i></p>
|}</center>

{{lb}}[[Template:Expand|Expand]]|Alternate message.}}
will produce:

<center>
{|style="width: 48em; padding:2px; margin:0; margin-bottom:10px; background-color:#f6f6f6; border:1px solid #aaa; -moz-border-radius-bottomright: 0.5em; -moz-border-radius-bottomleft: 1em; border-radius-bottomright: 0.5em; border-radius-bottomleft: 1em; -webkit-border-bottom-right-radius: 0.5em; -webkit-border-bottom-left-radius: 1em;"
|<div style="font-size: 1.5em; font-weight:bold; text-align:center;"> [[Image:Tango-view-fullscreen.png‎|48px|left|link=]] This material needs expanding ... </div><p style="text-align: center; font-size: 87%;">Alternate message.</p>
|}</center>

{{lb}}[[Template:Style|Style]]|Alternate message.}}
will produce:

<center>
{|style="width: 48em; padding:2px; margin:0; margin-bottom:10px; background-color:#f6f6f6; border:1px solid #aaa; -moz-border-radius-bottomright: 0.5em; -moz-border-radius-bottomleft: 1em; border-radius-bottomright: 0.5em; border-radius-bottomleft: 1em; -webkit-border-bottom-right-radius: 0.5em; -webkit-border-bottom-left-radius: 1em;"
|<div style="font-size: 1.5em; font-weight:bold; text-align:center;"> [[Image:Tango-edit-clear.png‎|48px|left|link=]] This material needs wiki syntax or style improvements ... </div><p style="text-align: center; font-size: 87%;">Alternate message.</p>
|}</center>

== See also ==

* [[How to write a HOWTO]]
* http://en.wikipedia.org/wiki/Help:Wiki_markup
* http://www.mediawiki.org/wiki/Help:Formatting
* [http://www.mediawiki.org/wiki/Help:Contents MediaWiki's User Manual]
* http://en.wikipedia.org/wiki/Help:HTML_in_wikitext

[[Category:Wiki]]

VLAN

2024-12-10T11:53:05Z

Ikke: Add warning about information being outdated

{{Obsolete|The information is outdated and is not suitable for systems using ifupdown-ng. Installing the vlan package may prevent your network from being configured correctly}}

This article shows how to configure a network interface as an IEEE 802.1q VLAN trunk.

__TOC__

==Installation==
First, install the ''vlan'' package. This will give you support for VLANs in the {{path|/etc/network/interfaces}} file.
{{Cmd|apk add {{pkg|vlan|arch=}}}}

{{Warning|Installing the vlan package may result in ifupdown-ng being replaced by busybox-ifupdown. If you use ifupdown-ng specific config, this may prevent your network from being configured properly.}}
==Configuration==
Edit the {{path|/etc/network/interfaces}} file:
<pre>
auto eth0.8
iface eth0.8 inet static
address 192.168.0.2
netmask 255.255.255.0
gateway 192.168.0.1
vlan-raw-device eth0
vlan_id 8

</pre>
With the ''vlan'' package installed, {{ic|ifup}} will find the trailing .8 in eth0.8 and will create a VLAN interface with vid 8 over eth0.

Alternatively with vlan8 over eth0:
<pre>
auto vlan8
iface vlan8 inet static
address 192.168.0.2
netmask 255.255.255.0
gateway 192.168.0.1
vlan-raw-device eth0
</pre>

A static IP address was used in the examples shown above, but DHCP can be used as well.

== Example with bridges associated with VLANs over bonding with differing MTUs on the various VLANs ==
This serves as an example of some of the more complicated networking possible. Particularly, this would work well for a hypervisor attached to a dedicated storage VLAN. Less complicated implementations can be achieved by merely removing the non-applicable parts.
<pre>
auto lo
iface lo inet loopback

auto bond0
iface bond0 inet manual
bond_slaves eth0 eth1
bond_mode 802.3ad
bond_miimon 100
bond_xmit_hash_policy layer2+3
post-up ip link set dev bondi0 mtu 9000

iface bond0.1

auto br1
iface br1
address 192.168.1.196/24
gateway 192.168.1.1
bridge_ports bond0.1
bridge_stp off
bridge_fd 0.0
post-up ip link set dev bond0.1 mtu 1500

iface bond0.10 inet manual

auto br10
iface br10 inet static
address 192.168.10.1/24
bridge_ports bond0.10
bridge_stp off
bridge_fd 0.0
</pre>

== Example with two interfaces on the same adapter. One with VLAN and one without ==

Since Linux doesn't allow multiple default gateways we need to use a second routing table using iproute2

{{Cmd|apk add {{pkg|iproute2|arch=}}}}

Then we'll add two new routing tables to the config file. One for each network

{{Cmd|echo "1 rt1" >> /etc/iproute2/rt_tables;echo "2 rt2" >> /etc/iproute2/rt_tables;}}

Now we need to edit {{path|/etc/network/interfaces}}

<pre>
auto lo
iface lo inet loopback

# the native interface without a VLAN (also called untagged)

auto eth0
iface eth0
address 192.168.1.100/24
gateway 192.168.1.1
post-up ip route add 192.168.1.0/24 dev eth0 src 192.168.1.100 table rt1
post-up ip route add default via 192.168.1.1 dev eth0 table rt1 # the actual gateway for this interface
post-up ip rule add from 192.168.1.100/32 table rt1
post-up ip rule add to 192.168.1.100/32 table rt1

# second interface with the vlan tag 5
auto eth0.5
iface eth0.5
address 192.168.5.100/24
post-up ip route add 192.168.5.0/24 dev eth0.5 src 192.168.5.100 table rt2
post-up ip route add default via 192.168.5.1 dev eth0.5 table rt2 # the actual gateway for this interface
post-up ip rule add from 192.168.5.100/32 table rt2
post-up ip rule add to 192.168.5.100/32 table rt2
</pre>

Note that if you want to add a third interface this way, you'll have to add another routing table

[[Category:Networking]]

User:-anthumchris-/kernel/howto

2024-12-03T16:21:13Z

Ikke: Ikke moved page User:-anthumchris-/kernel/howto to User:Anthumchris/kernel/howto: Automatically moved page while renaming the user "-anthumchris-" to "Anthumchris"

#REDIRECT [[User:Anthumchris/kernel/howto]]

User:Anthumchris:How to build the Alpine Linux kernel

2024-12-03T16:21:13Z

Ikke: Ikke moved page User:-anthumchris-/kernel/howto to User:Anthumchris/kernel/howto: Automatically moved page while renaming the user "-anthumchris-" to "Anthumchris"

== How To Do Something ==

Summarize your article here so readers can decide
quickly whether to read it.

== Before You Start Title ==
Your readers might need to get ready before they can do the work.
If so explain those prerequisites first. This section might alternatively
contain background information readers need to know before they can make
sense of your example or carry out your instructions.

== Doing Something Title ==
Write the steps of how to do something in this section.
If possible, show an example first, then tell your readers the steps.
Break this procedure into separate procedures to avoid more than
about 7-9 steps per procedure.

INSERT GREAT EXAMPLE HERE

#Answer the following three questions, at least in your head.
##What do I explain how to do?
##How do I do that?
##What do HOWTO readers already know about doing that?
#Write up a good example. This ensures you can do it.
#Write up the steps to do it.
#Write the background info/prerequisites readers need.
#Write the summary.
#Clean up your work.
# Add relevant category to your page, as every page should be assigned at least one Category.
#Revise, revise, revise.

== See Also ==
If you ought to point your readers to related information
they no doubt need but that does not fit in your HOWTO, add links here.

User:-anthumchris-

2024-12-03T16:21:13Z

Ikke: Ikke moved page User:-anthumchris- to User:Anthumchris: Automatically moved page while renaming the user "-anthumchris-" to "Anthumchris"

#REDIRECT [[User:Anthumchris]]

User:Anthumchris

2024-12-03T16:21:13Z

Ikke: Ikke moved page User:-anthumchris- to User:Anthumchris: Automatically moved page while renaming the user "-anthumchris-" to "Anthumchris"

⚠️ requesting username change to "anthumchris" 16:19 GMT
<hr>

👨‍💻 [https://gitlab.alpinelinux.org/anthumchris/ gitlab.alpinelinux.org/anthumchris]

Release Notes for Alpine 3.21.0

2024-10-05T20:13:25Z

Ikke: Ikke moved page Release Notes for Alpine 3.21.0 to Draft Release Notes for Alpine 3.21.0: Calling it release notes is confusing since it's not released yet

== Highlights ==

* Go 1.23.1
* Rust 1.81
* GNOME 47
* KDE Plasma 6.1.5
* LXQt 2.0.0
* GCC 14.2.0

== OpenSSH ==

{{Note|TODO: Remove this section if https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/68589 gets merged before 3.21 is released }}

You need to restart your sshd service!

Since the <code>9.8_p1</code> release, openssh-server is now split into two binaries, sshd and sshd-session. With this change sshd needs to be restarted to be able to accept new connections.

Since managing services has always been out-of-scope for apk, we will NOT do the following for you:

<code>
rc-service --ifstarted sshd restart
</code>

== GNOME 47 ==

GNOME 47 made it into Alpine 3.21. Everything should work as expected. Make sure you read the GNOME 47 release notes: https://release.gnome.org/47/

== LXQt 2.0.0 ==

LXQt has been updated to release 2.0.
* It now uses Qt6
* Many parts of LXQt are now wayland ready¹, but wayland ports of the following are pending: {{pkg|screengrab}}, {{pkg|lxqt-globalkeys}}, LXQt Panel's task-bar² and keyboard indicator, some input settings, and settings of monitor, power button, and screen locker.
* LXQt Panel has a new default application menu called Fancy Menu.
¹ [https://github.com/lxqt/lxqt-wayland-session lxqt-wayland-session] has not been released or packaged yet, but most folks wanting to test on wayland will want to use it.<br>
² Most folks testing LXQt on wayland are using {{pkg|waybar}} temporarily until the task-bar is ported.

== Jellyfin ==

Jellyfin now uses the recommended fork of ffmpeg called <code>jellyfin-ffmpeg</code> by default. If you want to change that, take a look at the <code>ffmpegpath</code> variable in <code>/etc/conf.d/jellyfin</code>. ([https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/69924 !69924])

== Bats ==

"main/bats" was renamed to "main/bats-core". Now there is a meta package "community/bats" which contains:

* bats-core
* bats-file
* bats-support
* bats-assert

Creating an Alpine package

2024-09-30T05:33:38Z

Ikke: /* license */ Add list of known licenses that require copyright notice to be included

{{TOC right}}
== Overview ==

This is a brief list of the steps to add a new package. Details are below, but a NB can miss a few steps.

# Create an account on https://gitlab.alpinelinux.org
# [[Abuild_and_Helpers#Setting_up_the_build_environment|Setup the build environment for aports]].
# Fork the [https://gitlab.alpinelinux.org/alpine/aports aports repository].
# Clone your new fork.
# Set git pull.rebase=true, set your username and email.
# Create and switch to a new branch (don't use master).
# Add a new directory under testing that is your new package name.
# Add your APKBUILD file.
# Run abuild checksum
# Make sure you run the apkbuild-lint and aport -r and there are no warnings.
# Commit your APKBUILD with the commit message: 'testing/packagename: new aport'
# Push your changes to your fork on https://gitlab.alpinelinux.org/alpine.
# Create a merge request.

Please see the rest of this wiki for details on the steps above.

== 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 ==
{{:Setup_your_system_and_account_for_building_packages}}

== Getting some help ==

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

{{Cmd|abuild -h}}

For real help, you can also go on #alpine-devel on [[IRC]].

A reference for APKBUILD files is available as [[APKBUILD Reference]] wiki page or a man page in the 'abuild-doc' package:

{{Cmd|man APKBUILD}}

== Creating an APKBUILD file ==

=== Use a template APKBUILD ===

The newapkbuild tool, which is installed as part of the {{Pkg|abuild}} package, can create you a new APKBUILD 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.

{{:Abuild and Helpers}}

{{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.<BR>
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>https://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 [https://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]
* [https://archlinux.org/packages/?q=search Arch Linux packages] [https://aur.archlinux.org/ Arch Linux User Repository]

==== 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.

Note that some licenses have additional requirements that should be adhered to. The <code>MIT</code> license for example has the requirement:

<blockquote>
The above copyright notice and this permission notice (including the next paragraph) shall be included in all copies or substantial portions of the Software.
</blockquote>

This means that we need to include the license as shipped with the project.

Known licenses that require this:

* <code>MIT</code>
* <code>ISC</code>

If a package has a special/custom license or is not listed as [https://opensource.org/licenses/alphabetical OSI approved], use the identifier "custom". In that case we need to provide the license file with the package as well.

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:

{{Cmd|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.

<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. For example, can be used to restore busybox links:
<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.

<br> 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 [https://www.gnu.org/software/make/manual/make.html#Parallel parallel] building/installing. A normal make line would be:

{{Cmd|make}}

To disable parallel we use:

{{Cmd|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:

{{Cmd|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.

<pre>
builddir="$srcdir"/$pkgname-$pkgver
</pre>

==== 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):

{{Cmd|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.

{{Cmd|abuild -r}}

See also [[Abuild_and_Helpers|Abuild and Helpers]].

== 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/main/
/home/USER/packages/community/
https://dl-cdn.alpinelinux.org/alpine/edge/main
https://dl-cdn.alpinelinux.org/alpine/edge/community
https://dl-cdn.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]].
Also check out [https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/COMMITSTYLE.md?ref_type=heads aports/COMMITSTYLE.md] and [https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/CODINGSTYLE.md?ref_type=heads aports/CODINGSTYLE.md]

== 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}}

== Automated flagging of outdated ports ==
Consider adding your port to [https://release-monitoring.org/ Anitya], so it will be flagged as outdated
as soon as a new stable version is released by upstream.

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

[[category: Package Manager]]

MediaWiki:Copyright

2024-07-27T03:27:08Z

Ikke:

<div align="right"><div id="footer-inner">
<p><a href="https://wiki.alpinelinux.org/wiki/Alpine_Linux:Privacy_policy#License">© Original authors / CC-BY-SA-4.0</a>
</div></div>

Alpine Linux:Privacy policy

2024-07-27T03:26:19Z

Ikke:

__NOTOC__
This site does not collect personal information about you. The web server does collect your web browser identification, IP address, and other non-personally identifiable information. We use this information to improve the site, provide aggregated statistics, and improve the Alpine Linux hosting platform. This information will not be sold, traded, or rented under any circumstances.

=License=

== Pages created before 2022-01-12 00:00:00 UTC ==

All content is copyrighted by the original authors. It may not be republished in any form without prior permission.

== Pages created after 2022-01-12 00:00:00 UTC ==

Contributions are licensed as [https://creativecommons.org/licenses/by-sa/4.0/ CC-BY-SA-4.0]

If you agree that your contributed content is re-licensed, please send an reply to [https://lists.alpinelinux.org/~alpine/devel/%3CCH58XEZPYFYT.1MV854Y4P2Q2O%40taiga%3E this e-mail] or a new e-mail to ~alpine/devel@lists.alpinelinux.org with the following content:

<pre>
I, <your name>, hereby re-license my contributions to the Alpine Linux
wiki hosted at wiki.alpinelinux.org under the username <your wiki username>
under the terms of the CC-BY-SA 4.0 license.
</pre>

=Site Information=
This website is hosted in an Alpine Linux LXC container, running lighttpd and php (fastcgi). The web content is maintained using [[Special:Version|MediaWiki]].

MediaWiki:Copyright

2024-07-27T03:25:11Z

Ikke:

<div align="right"><div id="footer-inner">
<p><a href="https://wiki.alpinelinux.org/wiki/Alpine_Linux:Privacy_policy#License">© Individual authors / CC-BY-SA-4.0</a>
</div></div>

MediaWiki:Copyright

2024-07-27T03:22:02Z

Ikke:

Template:Pkg

2024-05-28T19:07:51Z

Ikke: Correct the description for the branch parameter

<noinclude>{{Template}}
An inline link to search for given packages in the Package Browser.

=== Usage ===
<pre>{{Pkg|package|branch=|repo=|arch=|maintainer=}}</pre>

{{define|package|The package name to search for.
:Special characters in the package name will automatically be urlencoded. "*" and "?" can be used as wildcards.
:This argument is required, if you're not using it, use the "*" wildcard.}}
{{define|branch{{=}}|The branch of alpine to search (e.g. "3.19" or "edge"), defaults to "edge" if unset.}}
{{define|repo{{=}}|The repository to search (main, community, or testing). If unspecified all repositories will be searched.}}
{{define|arch{{=}}|The architecture to search (x86_64, x86, aarch64, armhf, ppc64le, s390x, armv7, or risc64). Defaults to x86_64 if unset.
:Pass this parameter with no value (i.e. "arch{{=}}") to search all arches.}}
{{define|maintainer{{=}}|Search for packages with a certain maintainer. (e.g. "None" to search for unmaintained packages) If unspecified packages from all maintainers will be searched}}

=== Examples ===
Search for gtk+2.0 under the edge branch on the x86_64 architecture:
<pre>{{Pkg|gtk+2.0}}</pre>
will produce:
{{Pkg|gtk+2.0}}

Search for all gtk packages under the edge branch on the x86_64 architecture:
<pre>{{Pkg|gtk*}}</pre>
will produce:
{{Pkg|gtk*}}

Search for ALSA-related packages under the 3.19 branch on the x86 (i.e. i686) architecture:
<pre>{{Pkg|*alsa*|branch=v3.19|arch=x86}}</pre>
will produce:
{{Pkg|*alsa*|branch=v3.19|arch=x86}}

</noinclude><includeonly>{{#if:{{{1|}}} | <span class="plainlinks" style="font-family: monospace, Courier;font-size:10pt;">[https://pkgs.alpinelinux.org/packages?name={{urlencode:{{{1}}}}}&branch={{urlencode:{{ #if: {{{branch|}}} | {{{branch}}} | edge}}}}&repo={{urlencode:{{ #if: {{{repo|}}} | {{{repo}}}}}}}&arch={{urlencode:{{ #ifeq: {{{arch|+}}} | {{{arch|-}}} | {{{arch}}} | x86_64 }}}}&maintainer={{urlencode:{{ #if: {{{maintainer|}}} | {{{maintainer}}}}}}} {{{1}}}]</span> | <span class="error">First parameter cannot be undefined or empty in template: <b>Template:Pkg</b></span>}}</includeonly>

Template:AlpineLatest

2024-05-23T20:34:43Z

Ikke: Alpine 3.20 is released

<noinclude>{{Template}}
</noinclude>3.20.0

Release Notes for Alpine 3.20.0

2024-02-15T18:51:56Z

Ikke: Update cause of issues

== Base System ==

=== grub 2.12 ===

When upgrading existing installations using grub on UEFI systems, make sure to update the installed bootloader before rebooting, otherwise your machine might not boot.

The problem is that grub added new configuration that executes <code>fwsetup --is-supported</code>. The problem is that grub 2.06 does not supported the <code>--is-supported<code> argument yet, causing grub to unconditionally try to reboot into firmware.

Here is an example assuming the default setup. Don't blindly copy this examples but verify what's applicable to your system.

==== EFI ====

{{Cmd|
# grub-install --target{{=}}<var>$target</var> --efi-directory{{=}}<var>$efi_directory</var> \
--bootloader-id{{=}}alpine --boot-directory{{=}}/boot --no-nvram
# install -D <var>$efi_directory</var>/EFI/alpine/grub<var>$fwa</var>.efi <var>$efi_directory</var>/EFI/boot/boot<var>$fwa</var>.efi

}}

; target : The relevant [https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-disk.in#L320-324 target] for your system
; efi_directory : Either {{Path|/boot/efi}} or {{Path|/boot}}. Run <code>awk '$2 ~ /boot/ && $3 ~ /fat|msdos/ { print $2 }' /proc/mounts</code> to confirm.
; fwa : The respective [https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-disk.in#L320-324 firmware architecture] for your system

==== Short-term work-around ====

A short-term work-around to get the system bootable again is to restore the backup configuration:

{{Cmd|cp /boot/grub/grub.cfg.back /boot/grub.cfg }}

This should allow you to boot the system again to fix it permanently. This will be reverted again when either grub or the kernel is updated again.

This will only work if <code>update-grub</code> has not been executed any more since the upgrade to grub 2.12.

Release Notes for Alpine 3.20.0

2024-02-04T12:34:54Z

Ikke: Clarify when the work-around works\

== Base System ==

=== grub 2.12 ===

When upgrading existing installations using grub on UEFI systems, make sure to update the installed bootloader before rebooting, otherwise your machine might not boot.

The problem is that grub added a new module called `bli`, and the updated grub configuration refers to that module, causing grub to fail on boot.

Here is an example assuming the default setup. Don't blindly copy this examples but verify what's applicable to your system.

==== EFI ====

{{Cmd|
# grub-install --target{{=}}<var>$target</var> --efi-directory{{=}}<var>$efi_directory</var> \
--bootloader-id{{=}}alpine --boot-directory{{=}}/boot --no-nvram
# install -D <var>$efi_directory</var>/EFI/alpine/grub<var>$fwa</var>.efi <var>$efi_directory</var>/EFI/boot/boot<var>$fwa</var>.efi

}}

; target : The relevant [https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-disk.in#L320-324 target] for your system
; efi_directory : Either {{Path|/boot/efi}} or {{Path|/boot}}. Run <code>awk '$2 ~ /boot/ && $3 ~ /fat|msdos/ { print $2 }' /proc/mounts</code> to confirm.
; fwa : The respective [https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-disk.in#L320-324 firmware architecture] for your system

==== Short-term work-around ====

A short-term work-around to get the system bootable again is to restore the backup configuration:

{{Cmd|cp /boot/grub/grub.cfg.back /boot/grub.cfg }}

This should allow you to boot the system again to fix it permanently. This will be reverted again when either grub or the kernel is updated again.

This will only work if <code>update-grub</code> has not been executed any more since the upgrade to grub 2.12.

Release Notes for Alpine 3.20.0

2024-02-04T12:10:59Z

Ikke:

== Base System ==

=== grub 2.12 ===

When upgrading existing installations using grub on UEFI systems, make sure to update the installed bootloader before rebooting, otherwise your machine might not boot.

The problem is that grub added a new module called `bli`, and the updated grub configuration refers to that module, causing grub to fail on boot.

Here is an example assuming the default setup. Don't blindly copy this examples but verify what's applicable to your system.

==== EFI ====

{{Cmd|
# grub-install --target{{=}}<var>$target</var> --efi-directory{{=}}<var>$efi_directory</var> \
--bootloader-id{{=}}alpine --boot-directory{{=}}/boot --no-nvram
# install -D <var>$efi_directory</var>/EFI/alpine/grub<var>$fwa</var>.efi <var>$efi_directory</var>/EFI/boot/boot<var>$fwa</var>.efi

}}

; target : The relevant [https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-disk.in#L320-324 target] for your system
; efi_directory : Either {{Path|/boot/efi}} or {{Path|/boot}}. Run <code>awk '$2 ~ /boot/ && $3 ~ /fat|msdos/ { print $2 }' /proc/mounts</code> to confirm.
; fwa : The respective [https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-disk.in#L320-324 firmware architecture] for your system

==== Short-term work-around ====

A short-term work-around to get the system bootable again is to restore the backup configuration:

{{Cmd|cp /boot/grub/grub.cfg.back /boot/grub.cfg }}

This should allow you to boot the system again to fix it permanently. This will be reverted again when either grub or the kernel is updated again.

Release Notes for Alpine 3.20.0

2024-01-19T18:22:36Z

Ikke: Remove bios, since irrelevant and add more details.

== Base System ==

=== grub 2.12 ===

When upgrading existing installations using grub on UEFI systems, make sure to update the installed bootloader before rebooting, otherwise your machine might not boot.

The problem is that grub added a new module called `bli`, and the updated grub configuration refers to that module, causing grub to fail on boot.

Here is an example assuming the default setup. Don't blindly copy this examples but verify what's applicable to your system.

==== EFI ====

{{Cmd|
# grub-install --target{{=}}<var>$target</var> --efi-directory{{=}}<var>$efi_directory</var> \
--bootloader-id{{=}}alpine --boot-directory{{=}}/boot --no-nvram
# install -D <var>$efi_directory</var>/EFI/alpine/grub<var>$fwa</var>.efi <var>$efi_directory</var>/EFI/boot/boot<var>$fwa</var>.efi

}}

; target : The relevant [https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-disk.in#L320-324 target] for your system
; efi_directory : Either {{Path|/boot/efi}} or {{Path|/boot}}. Run <code>awk '$2 ~ /boot/ && $3 ~ /fat|msdos/ { print $2 }' /proc/mounts</code> to confirm.
; fwa : The respective [https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-disk.in#L320-324 firmware architecture] for your system

==== Shot-term work-around ====

A short-term work-around to get the system bootable again is to restore the backup configuration:

{{Cmd cp /boot/grub/grub.cfg.back /boot/grub.cfg }}

This should allow you to boot the system again to fix it permanently. This will be reverted again when either grub or the kernel is updated again.

Template:Pkg

2024-01-09T21:38:23Z

Ikke: Support branch and arch arguments (author: zcrayfish)

<noinclude>{{Template}}
An inline link to search for given packages in the Package Browser.

=== Usage ===
<pre>{{Pkg|package|branch=|repo=|arch=|maintainer=}}</pre>

{{define|package|The package name to search for.
:Special characters in the package name will automatically be urlencoded. "*" and "?" can be used as wildcards.
:This argument is required, if you're not using it, use the "*" wildcard.}}
{{define|branch{{=}}|The branch of alpine to search (e.g. "3.19" or "edge"), defaults to "edge" if unset.
:Pass this parameter with no value (i.e. "branch{{=}}") to search all branches}}
{{define|repo{{=}}|The repository to search (main, community, or testing). If unspecified all repositories will be searched.}}
{{define|arch{{=}}|The architecture to search (x86_64, x86, aarch64, armhf, ppc64le, s390x, armv7, or risc64). Defaults to x86_64 if unset.
:Pass this parameter with no value (i.e. "arch{{=}}") to search all arches.}}
{{define|maintainer{{=}}|Search for packages with a certain maintainer. (e.g. "None" to search for unmaintained packages) If unspecified packages from all maintainers will be searched}}

=== Examples ===
Search for gtk+2.0 under the edge branch on the x86_64 architecture:
<pre>{{Pkg|gtk+2.0}}</pre>
will produce:
{{Pkg|gtk+2.0}}

Search for all gtk packages under the edge branch on the x86_64 architecture:
<pre>{{Pkg|gtk*}}</pre>
will produce:
{{Pkg|gtk*}}

Search for ALSA-related packages under the 3.19 branch on the x86 (i.e. i686) architecture:
<pre>{{Pkg|*alsa*|branch=v3.19|arch=x86}}</pre>
will produce:
{{Pkg|*alsa*|branch=v3.19|arch=x86}}

</noinclude><includeonly>{{#if:{{{1|}}} | <span class="plainlinks" style="font-family: monospace, Courier;font-size:10pt;">[https://pkgs.alpinelinux.org/packages?name={{urlencode:{{{1}}}}}&branch={{urlencode:{{ #if: {{{branch|}}} | {{{branch}}} | edge}}}}&repo={{urlencode:{{ #if: {{{repo|}}} | {{{repo}}}}}}}&arch={{urlencode:{{ #ifeq: {{{arch|+}}} | {{{arch|-}}} | {{{arch}}} | x86_64 }}}}&maintainer={{urlencode:{{ #if: {{{maintainer|}}} | {{{maintainer}}}}}}} {{{1}}}]</span> | <span class="error">First parameter cannot be undefined or empty in template: <b>Template:Pkg</b></span>}}</includeonly>

Release Notes for Alpine 3.20.0

2024-01-07T10:26:55Z

Ikke: Remove stray " (thanks shinobi5747485)

== Base System ==

=== grub 2.12 ===

When upgrading existing installations using grub, make sure to update the installed bootloader before rebooting, otherwise your machine might not boot.

Here are some examples for various situations assuming default setups. Don't blindly copy these examples but verify what's applicable to your system.

Afterwards, run the <code>update-grub</code> command to update the grub configuration:

{{Cmd|# update-grub}}

==== BIOS ====

For BIOS systems (x86 or x86_64)

{{Cmd|# grub-install --boot-directory{{=}}/boot --target{{=}}i386-pc <var>$disk</var>}}

; disk : The block device grub has been installed to.

==== EFI ====

{{Cmd|
# grub-install --target{{=}}<var>$target</var> --efi-directory{{=}}<var>$efi_directory</var> \
--bootloader-id{{=}}alpine --boot-directory{{=}}/boot --no-nvram
# install -D <var>$efi_directory</var>/EFI/alpine/grub<var>$fwa</var>.efi <var>$efi_directory</var>/EFI/boot/boot<var>$fwa</var>.efi

}}

; target : The relevant [https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-disk.in#L320-324 target] for your system
; efi_directory : Either {{Path|/boot/efi}} or {{Path|/boot}}. Run <code>awk '$2 ~ /boot/ && $3 ~ /fat|msdos/ { print $2 }' /proc/mounts</code> to confirm.
; fwa : The respective [https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-disk.in#L320-324 firmware architecture] for your system

Release Notes for Alpine 3.20.0

2024-01-06T12:19:47Z

Ikke:

== Base System ==

=== grub 2.12 ===

When upgrading existing installations using grub, make sure to update the installed bootloader before rebooting, otherwise your machine might not boot.

Here are some examples for various situations assuming default setups. Don't blindly copy these examples but verify what's applicable to your system.

Afterwards, run the <code>update-grub</code> command to update the grub configuration:

{{Cmd|# update-grub}}

==== BIOS ====

For BIOS systems (x86 or x86_64)

{{Cmd|# grub-install --boot-directory{{=}}/boot --target{{=}}i386-pc <var>$disk</var>}}

; disk : The block device grub has been installed to.

==== EFI ====

{{Cmd|
# grub-install --target{{=}}<var>$target</var> --efi-directory{{=}}"<var>$efi_directory</var>" \
--bootloader-id{{=}}alpine --boot-directory{{=}}"/boot --no-nvram
# install -D <var>$efi_directory</var>/EFI/alpine/grub<var>$fwa</var>.efi <var>$efi_directory</var>/EFI/boot/boot<var>$fwa</var>.efi

}}

; target : The relevant [https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-disk.in#L320-324 target] for your system
; efi_directory : Either {{Path|/boot/efi}} or {{Path|/boot}}. Run <code>awk '$2 ~ /boot/ && $3 ~ /fat|msdos/ { print $2 }' /proc/mounts</code> to confirm.
; fwa : The respective [https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-disk.in#L320-324 firmware architecture] for your system

Release Notes for Alpine 3.20.0

2024-01-06T12:01:15Z

Ikke:

== Base System ==

=== grub 2.12 ===

When upgrading existing installations using grub, make sure to update the installed bootloader before rebooting, otherwise your machine might not boot.

Here are some examples for various situations assuming default setups. Don't blindly copy these examples but verify what's applicable to your system.

Afterwards, run the <code>update-grub</code> command to update the grub configuration:

{{Cmd|# update-grub}}

==== BIOS ====

For BIOS systems (x86 or x86_64)

{{Cmd|# grub-install --boot-directory{{=}}/boot --target{{=}}i386-pc <var>$disk</var>}}

; disk : The block device grub has been installed to.

==== EFI ====

{{Cmd|
# grub-install --target{{=}}<var>$target</var> --efi-directory{{=}}"<var>$efi_directory</var>" \
--bootloader-id{{=}}alpine --boot-directory{{=}}"/boot --no-nvram
# install -D <var>$efi_directory</var>/EFI/alpine/grub<var>$fwa</var>.efi <var>$efi_directory</var>/EFI/boot/boot<var>$fwa</var>.efi

}}

; target : The relevant [https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-disk.in#L320-324 target] for your system
; efi_directory : Either {{Path|/boot/efi}} or {{Path|/boot}}
; fwa : The respective [https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-disk.in#L320-324 firmware architecture] for your system

Release Notes for Alpine 3.20.0

2024-01-06T11:57:53Z

Ikke:

== Base System ==

=== grub 2.12 ===

When upgrading existing installations using grub, make sure to update the installed bootloader before rebooting, otherwise your machine might not boot.

Here are some examples for various situations assuming default setups. Don't blindly copy these examples but verify what's applicable to your system.

Afterwards, run the <code>update-grub</code> command to update the grub configuration:

{{Cmd|# update-grub}}

==== BIOS ====

For BIOS systems (x86 or x86_64)

{{Cmd|# grub-install --boot-directory{{=}}/boot --target{{=}}i386-pc <var>$disk</var>}}

; disk : The block device grub has been installed to.

==== EFI ====

{{Cmd|
# grub-install --target{{=}}<var>$target</var> --efi-directory{{=}}"<var>$efi_directory</var>" \
--bootloader-id{{=}}alpine --boot-directory{{=}}"/boot --no-nvram
# install -D <var>$efi_directory</var>/EFI/alpine/grub<var>$fwa</var>.efi <var>$efi_directory</var>/EFI/boot/boot<var>$fwa</var>.efi

}}

; target : The relevant [https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-disk.in?ref%20type=heads target] for your system
; efi_directory : Either {{Path|/boot/efi}} or {{Path|/boot}}
; fwa : The respective [https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-disk.in?ref%20type=heads firmware architecture] for your system

Release Notes for Alpine 3.20.0

2024-01-05T23:54:13Z

Ikke:

== Base System ==

=== grub 2.12 ===

When upgrading existing installations using grub, make sure to update the installed bootloader before rebooting, otherwise your machine might not boot.

Here are some examples for various situations assuming default setups. Don't blindly copy these examples but verify what's applicable to your system.

==== BIOS ====

For BIOS systems (x86 or x86_64)

{{Cmd|# grub-install --boot-directory{{=}}/boot --target{{=}}i386-pc <var>$disk</var>}}

; disk : The block device grub has been installed to.

==== EFI ====

{{Cmd|
# grub-install --target{{=}}<var>$target</var> --efi-directory{{=}}"<var>$efi_directory</var>" \
--bootloader-id{{=}}alpine --boot-directory{{=}}"/boot --no-nvram
# install -D <var>$efi_directory</var>/EFI/alpine/grub<var>$fwa</var>.efi <var>$efi_directory</var>/EFI/boot/boot<var>$fwa</var>.efi

}}

; target : The relevant [https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-disk.in?ref%20type=heads target] for your system
; efi_directory : Either {{Path|/boot/efi}} or {{Path|/boot}}
; fwa : The respective [https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-disk.in?ref%20type=heads firmware architecture] for your system

Release Notes for Alpine 3.20.0

2024-01-05T23:33:15Z

Ikke: Created page with "== Base System == === grub 2.12 === When upgrading existing installations using grub, make sure to update the installed bootloader before rebooting, otherwise your machine might not boot. Here are some examples for various situations assuming default setups. Don't blindly copy these examples but verify what's applicable to your system. ==== BIOS ==== For BIOS systems (x86 or x86_64) {{Cmd|# grub-install --boot-directory{{=}}/boot --target{{=}}i386-pc <var>disk</va..."

Category:Articles for deletion

2023-12-21T13:05:57Z

Ikke:

Articles that are proposed to be deleted

Category:Articles for deletion

2023-12-21T13:03:48Z

Ikke: Created page with "Articles that are marked to be deleted"

Articles that are marked to be deleted

Template:Delete

2023-12-21T12:56:44Z

Ikke: Add category 'Articles for deletion'

<noinclude>{{Template}}
This template proposes a page or section for deletion.

=== Usage ===
Only administrators can delete pages. Other users should instead use this template to propose a page for deletion. It can also be used to propose one section of a larger page for deletion.

You should cite a brief reason in the first argument, and can expand in the article's discussion page. Don't clear the page's content except where it's obviously spam.

<pre>{{Delete|Reason.}}</pre>

Users are welcome to argue against deletion. You can override the default discussion page with a second argument to the template:

<pre>{{Delete|Reason.|Talk:Alternative Page}}</pre>

Flagged pages can be found in [[Special:WhatLinksHere/Template:Delete]].

=== Example ===

<pre>{{Delete|Message.}}</pre>

will produce:
<center>
{|style="width: 48em; padding:2px; margin:0; margin-bottom:10px; background-color:#f1f1de; border:1px solid #cc9; -moz-border-radius-bottomright: 0.5em; -moz-border-radius-bottomleft: 1em; border-radius-bottomright: 0.5em; border-radius-bottomleft: 1em; -webkit-border-bottom-right-radius: 0.5em; -webkit-border-bottom-left-radius: 1em;"
|<div style="font-size: 1.5em; font-weight:bold; text-align:center;"> [[Image:Tango-user-trash-full.png|48px|left|link=]] This material is proposed for deletion ... </div><p style="text-align: center; font-size: 87%;">Message.
([[{{TALKPAGENAME}}|Discuss]])<br />Make sure [[Special:WhatLinksHere/{{FULLPAGENAME}}|no other pages link here]] and check [[Special:PageHistory/{{FULLPAGENAME}}|the page's history]] before deleting.</p>
|}</center>

<hr>

</noinclude><includeonly><center>
{|style="width: 48em; padding:2px; margin:0; margin-bottom:10px; background-color:#f1f1de; border:1px solid #cc9; -moz-border-radius-bottomright: 0.5em; -moz-border-radius-bottomleft: 1em; border-radius-bottomright: 0.5em; border-radius-bottomleft: 1em; -webkit-border-bottom-right-radius: 0.5em; -webkit-border-bottom-left-radius: 1em;"
|<div style="font-size: 1.5em; font-weight:bold; text-align:center;"> [[Image:Tango-user-trash-full.png|48px|left|link=]] This material is proposed for deletion ... </div><p style="text-align: center; font-size: 87%;">{{{1|}}}
([[{{{2|{{TALKPAGENAME}}}}}|Discuss]])<br />Make sure [[Special:WhatLinksHere/{{FULLPAGENAME}}|no other pages link here]] and check [[Special:PageHistory/{{FULLPAGENAME}}|the page's history]] before deleting.</p>
|}</center>[[Category:Articles for deletion]]</includeonly>

Template:Delete

2023-12-21T12:55:07Z

Ikke: Add links to

Template:AlpineLatest

2023-12-08T06:22:53Z

Ikke:

<noinclude>{{Template}}
</noinclude>3.19.0

Release Notes for Alpine 3.19.0

2023-12-07T13:51:07Z

Ikke: /* HashiCorp packages */ gramatical fix (software is uncountable)

== Base System ==

=== iptables-nft ===

The <code>/sbin/iptables{,-save,-restore}</code> symlinks now point to xtables-nft-multi instead of xtables-legacy-multi. This means they use the nftables kernel backend instead of the legacy iptables one.

Since the new iptables- binaries also don't use the iptables backend, to work with any existing rules and save them, you need to install {{pkg|iptables-legacy}} and use <code>iptables-legacy-save</code>.

Because mixing backends is not supported, you should reboot your system if you have to use the iptables commands after upgrading.

=== netns ===

The OpenRC package contains a patch to make it possible to start most services in netns namespaces. See also [[Netns|netns]].

== Others ==

=== HashiCorp packages ===

Due to [https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license the relicensing of HashiCorp software] to [https://spdx.org/licenses/BUSL-1.1.html BUSL-1.1], a non-Open-Source license, the following software has been removed from Alpine:

* Consul
* Nomad
* Packer
* Terraform
* Vault

Our discussion on the topic can be found [https://gitlab.alpinelinux.org/alpine/aports/-/issues/15193 here].

{{pkg|opentofu}}, a fork of Terraform, is available in our testing repository for users of our rolling release, edge.

=== Java 21 ===

The latest LTS java release, openjdk21, is now available in the community repository.

=== KDE ===

KDE Applications have been upgraded from 23.04.x to 23.08.x. KDE Frameworks have been upgraded from 5.105.0 to 5.112.0.
Note that the KDE Frameworks packages have been renamed to add a 5 suffix in preparation for the upcoming KDE 6 release in the next Alpine release. Everything should automatically be upgraded properly but if problems occur make sure to check if the right renamed packages are installed.

=== GNOME ===

GNOME packages have been updated to 45. As part of that release, Cheese has been replaced by Snapshot, and Eye of GNOME by Loupe as the default apps for taking and seeing pictures, respectively. In additions, GNOME Photos was dropped as being mostly unmaintained.

=== Yggdrasil v0.5 ===

{{pkg|yggdrasil}} was upgraded to 0.5.x and the new routing scheme is incompatible with previous versions. "Nodes running this new version '''will not''' be able to peer with earlier versions of Yggdrasil" ([https://github.com/yggdrasil-network/yggdrasil-go/releases/tag/v0.5.0 v0.5.0 release notes], [https://yggdrasil-network.github.io/2023/10/22/upcoming-v05-release.html v0.5 blog post]).

=== GNU C Library Compatibility Layer ===

<code>libc6-compat</code> [https://git.alpinelinux.org/aports/commit/?h=3.19-stable&id=1a122638315d6fe7908de9c34d3ac06eae76917a was removed] in favor of {{pkg|gcompat}} from Adélie Linux.

=== ifupdown ===

The <code>ifupdown</code> aport ('''not''' {{pkg|busybox-ifupdown}}) was unmaintained and removed in favor of the preferred {{pkg|ifupdown-ng}}.

== Upgrades ==

* Linux 6.6
* GCC 13
* LLVM 17
* Kea 2.4
* Xen 4.18
* Git 2.43
* Perl 5.38
* PHP 8.3
* PostgreSQL 16
* SQLite 3.44
* Redis 7.2
* Node.js (lts) 20.10
* Node.js (current) 21.4
* QEMU 8.1
* Ceph 18.2
* GNOME 45
* LXQt 1.4
* wlroots 0.17
* Go 1.21
* Rust 1.72
* Crystal 1.10
* Racket 8.11
* ECL 23.9.9
* Erlang 26
* zlib 1.3
* libsodium 1.0.19
* ICU 74.1
* Protobuf 24.4
* fmt 10
* PipeWire 1.0.0

== Raspberry pi ==

[https://pkgs.alpinelinux.org/packages?name=linux-rpi&branch=edge linux-rpi] package has been simplified: there is now a single kernel flavor for each architecture. Previous [https://pkgs.alpinelinux.org/packages?name=linux-rpi2&branch=v3.18 linux-rpi2] and [https://pkgs.alpinelinux.org/packages?name=linux-rpi4&branch=v3.18 linux-rpi4] kernel packages are therefore replaced by [https://pkgs.alpinelinux.org/packages?name=linux-rpi&branch=edge linux-rpi].<br>
{{Path|config.txt}} file is now generated by [https://pkgs.alpinelinux.org/packages?name=raspberrypi-bootloader-common&branch=edge raspberrypi-bootloader-common].

[[Category:News]]

Creating an Alpine package

2023-11-13T21:44:54Z

Ikke: Explain that certain licenses have additional requirements

{{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 #alpine-devel on [[IRC]].

A reference for APKBUILD files is available as [[APKBUILD Reference]] wiki page or 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.<BR>
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>https://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 [https://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]
* [https://archlinux.org/packages/?q=search Arch Linux packages] [https://aur.archlinux.org/ Arch Linux User Repository]

==== 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.

Note that some licenses have additional requirements that should be adhered to. The <code>MIT</code> license for example has the requirement:

<blockquote>
The above copyright notice and this permission notice (including the next paragraph) shall be included in all copies or substantial portions of the Software.
</blockquote>

This means that we need to include the license as shipped with the project.

If a package has a special/custom license or is not listed as [https://opensource.org/licenses/alphabetical OSI approved], use the identifier "custom". In that case we need to provide the license file with the package as well.

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:

{{Cmd|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.

<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. For example, can be used to restore busybox links:
<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.

<br> 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 [https://www.gnu.org/software/make/manual/make.html#Parallel parallel] building/installing. A normal make line would be:

{{Cmd|make}}

To disable parallel we use:

{{Cmd|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:

{{Cmd|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.

<pre>
builddir="$srcdir"/$pkgname-$pkgver
</pre>

==== 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):

{{Cmd|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.

{{Cmd|abuild -r}}

See also [[Abuild_and_Helpers|Abuild and Helpers]].

== 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/main/
/home/USER/packages/community/
https://dl-cdn.alpinelinux.org/alpine/edge/main
https://dl-cdn.alpinelinux.org/alpine/edge/community
https://dl-cdn.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]].
Also check out [https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/COMMITSTYLE.md?ref_type=heads aports/COMMITSTYLE.md] and [https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/CODINGSTYLE.md?ref_type=heads aports/CODINGSTYLE.md]

== 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}}

== Automated flagging of outdated ports ==
Consider adding your port to [https://release-monitoring.org/ Anitya], so it will be flagged as outdated
as soon as a new stable version is released by upstream.

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

[[category: Package Manager]]

Template:AlpineLatest

2023-09-28T14:48:06Z

Ikke: Bump to 3.18.4

<noinclude>{{Template}}
</noinclude>3.18.4

How to setup a Alpine Linux mirror

2023-07-06T13:37:03Z

Ikke:

== Introduction ==
This document describes how to set up an Alpine Linux mirror and make it available via http and rsync.

We will:
* create the dir where we have the mirror
* set up a cron job to sync with master mirror every hour
* set up lighttpd for http access
* set up rsync so other mirrors can rsync from you

Make sure that you have enough disk space.

Current (2023-07-06) disk usage in GB:

{|class="wikitable"
!edge
!v3.0
!v3.1
!v3.2
!v3.3
!v3.4
!v3.5
!v3.6
!v3.7
!v3.8
!v3.9
!v3.10
!v3.11
!v3.12
!v3.13
!v3.14
!v3.15
!v3.16
!v3.17
!v3.18

!total
|-
|348
|17
|18
|15
|21
|25
|27
|45
|43
|59
|73
|92
|126
|148
|156
|181
|186
|195
|214
|242

|'''2222'''
|}

Script used to calculate the size:

<pre>
#!/bin/sh

total=0
dest="$(mktemp -d)"

for dir in edge v3.0 v3.1 v3.2 v3.3 v3.4 v3.5 v3.6 v3.7 v3.8 v3.9 v3.10 v3.11 v3.12 v3.13 v3.14 v3.15 v3.16 v3.17 v3.18; do
old_total="$total"
src="rsync://rsync.alpinelinux.org/alpine/$dir/"
size=$(rsync -a -n --stats "$src" "$dest" | grep '^Total file size' | tr -d ',' | awk '{ print $4 }')
total=$(( old_total + size ))
echo "$dir: $size" | awk '{ print $1 sprintf("%.1f", $2/1073741824) }'
done

echo "total: $total" | awk '{ print $1 sprintf("%.1f", $2/1073741824) }'
rm -r "$dest"
</pre>

== Setting up the cron job ==
Install rsync which will be used to sync from the master mirror.
{{Cmd|apk add rsync}}

Save the following file as ''/etc/periodic/hourly/alpine-mirror''
<pre>
#!/bin/sh

# make sure we never run 2 rsync at the same time
lockfile="/tmp/alpine-mirror.lock"
if [ -z "$flock" ] ; then
exec env flock=1 flock -n $lockfile "$0" "$@"
fi

src=rsync://rsync.alpinelinux.org/alpine/
dest=/var/www/localhost/htdocs/alpine/

# uncomment this to exclude old v2.x branches
#exclude="--exclude v2.*"

mkdir -p "$dest"
/usr/bin/rsync \
--archive \
--update \
--hard-links \
--delete \
--delete-after \
--delay-updates \
--timeout=600 \
$exclude \
"$src" "$dest"

</pre>

(or use [https://gist.github.com/jirutka/288c6fff7c0b8a835d143686207316be this script])

Make it executable:
{{Cmd|<nowiki>chmod +x /etc/periodic/hourly/alpine-mirror</nowiki>}}

Now it will sync every hour. (given cron runs)

== Setting up HTTP access via lighttpd ==

Install the lighttpd server
{{Cmd|apk add lighttpd}}

Enable dir listings by uncommenting the following line in ''/etc/lighttpd/lighttpd.conf'':
dir-listing.activate = "enable"

Also set cache-control to force cache revalidate every 30 mins. Uncomment mod_setenv in ''/etc/lighttpd/lighttpd.conf'':
"mod_setenv",

Add also the following lines to ''/etc/lighttpd/lighttpd.conf'':
setenv.add-response-header += (
"Cache-Control" => "must-revalidate"
)

Start lighttpd and make it start at boot:
{{Cmd|rc-service lighttpd start
rc-update add lighttpd}}

{{Note|You may wish to consider [[Darkhttpd]] as an alternative to [[Lighttpd]]

If so, simply install, start and auto-start the webserver:

{{Cmd|apk add darkhttpd && rc-service darkhttpd start && rc-update add darkhttpd}}

Darkhttpd will, by default, offer directory listings and serve data from /var/www/localhost/htdocs/

See the main article on [[Darkhttpd]] for more configuration options}}

== Setting up rsyncd ==
Add the following lines to ''/etc/rsyncd.conf'':
<pre>
[alpine]
path = /var/www/localhost/htdocs/alpine
comment = My Alpine Linux Mirror
</pre>

Optionally set a bandwidth limit in ''/etc/conf.d/rsyncd''. In this example we limit to 500Kbytes/s (approx 5Mbit/s)
<pre>
RSYNC_OPTS="--bwlimit=500"
</pre>

== Mirror statistics ==

Simple bandwidth statistics can be generated with vnstat.

{{Cmd|apk add vnstat}}

edit /etc/vnstat.conf and replace the interface name with the appropriate one.

Start vnstatd

{{Cmd|/etc/init.d/vnstatd start }}

copy the following script to /etc/periodic/15min/stats and make sure your crond is running.
please not that heredoc should be tab indented or the script will fail. A working copy can be found here: http://tpaste.us/RrMv

<pre>
#!/bin/sh

output="/var/www/localhost/htdocs/.stats"
nic="eth0"

generate_index() {
cat <<-EOF
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta http-equiv="cache-control" content=no-cache">
<meta http-equiv="refresh" content="3000">
<title>Alpine Linux mirror statistics</title>
</head>
<body>
<table border="0">
<tr><td><img src="summary.png" alt="summary"></td><td><img src="hours.png" alt="hours"></td></tr>
<tr><td rowspan="2"><img src="days.png" alt="days"></td><td><img src="top10.png" alt="top10"></td></tr>
<tr><td><img src="months.png" alt="months"></td></tr>
</table>
</body>
</html>
EOF
}

if [ ! -f "$output"/index.html ]; then
mkdir -p $output
generate_index > "$output"/index.html
fi

for type in hours days months top10 summary hsummary vsummary; do
vnstati --${type} -i $nic -o $output/${type}.png
done
</pre>

== Update mirror from mqtt ==

If you want your mirror to be really uptodate compared to our master mirror you can subscribe to Alpine Linux message server "msg.alpinelinux.org" and check for upload messages.
Add mqtt-exec to be able to execute processes when specific topics are being send.

{{Cmd| apk add mqtt-exec}}

mqtt-exec supports running multiple time so we need to setup a specific config.

{{Cmd| ln -s /etc/init.d/mqtt-exec /etc/init.d/mqtt-exec.sync-mirror}}

{{Cmd| ln -s /etc/conf.d/mqtt-exec /etc/conf.d/mqtt-exec.sync-mirror}}

edit /etc/conf.d/mqtt-exec.sync-mirror

<pre>
mqtt_topics="rsync/rsync.alpinelinux.org/#"
exec_user="buildozer"
exec_command="/usr/local/bin/sync-mirror"
</pre>

Copy the following file to /usr/local/bin/sync-mirror and make it executable (dont forget to update the variables).

<pre>
#!/bin/sh

src="rsync://rsync.alpinelinux.org/alpine/"
dest="/var/www/localhost/htdocs/alpine/"
lock="/tmp/sync-mirror.lock"
topic="$1"
dir="$2"

[ -z "$flock" ] && exec env flock=1 flock $lock $0 "$@"

if [ -n "$dir" ] && [ -d "$dest/${dir%/*}" ]; then
logger "Syncing directory: $dir"
src="${src}${dir%/}/"
dest="${dest}${dir%/}/"
else
logger "Syncing all directories"
fi

/usr/bin/rsync \
--archive \
--update \
--verbose \
--progress \
--timeout=600 \
--delay-updates \
--delete-after \
"$src" \
"$dest"
</pre>

And finally start mqtt-exec and let it listen on msg.alpinelinux.org

{{Cmd|/etc/init.d/mqtt-exec.sync-mirror start}}

To make sure you are not missing any packages (in case something goes wrong with MQTT subscription) you can periodically sync all directories by adding the script to cron.

{{Cmd|ln -s /usr/local/bin/sync-mirror /etc/periodic/hourly/sync-mirror}}

Now watch your syslog as it should tell you when it will update directories in your local mirror.

== Partial mirror using nginx ==

For a private mirror it might make sense to sync only the newest versions of Alpine to save space, but if you ''do'' point an old Alpine version to your mirror they should still be able to install packages. We can achieve this by using nginx to serve the mirrored content and use regex location matching to redirect requests to a public mirror.

Let's assume you chose to only mirror Alpine versions up from v3.13. If a client asks your mirror for v.3.10 it should redirect to another mirror.

Your nginx config server block should look something like this:

<pre>
server {
listen 80;
server_name alpine.mydomain.local;
root /data/alpine; # point to where your alpine mirror is located. make sure nginx is allowed to read it
autoindex on; # Enable indexing

# the following location block will match for v3.0 to v3.12
# and will forward it to dl-4.alpinelinux.org.
location ~* /(v3\.([1-9]|1[012]))$
{
return 302 http://dl-cdn.alpinelinux.org/alpine$request_uri;
}
}
</pre>

The corresponding sync script could look something like this:

<pre>
#!/bin/sh

# make sure we never run 2 rsync at the same time
lockfile="/tmp/alpine-mirror.lock"
if [ -z "$flock" ] ; then
exec env flock=1 flock -n $lockfile "$0" "$@"
fi

src=rsync://rsync.alpinelinux.org/alpine/
dest=/data/alpine/

exclude="--exclude v2.* --exclude v3.0 --exclude v3.1 --exclude v3.2 --exclude v3.3 --exclude v3.4 --exclude v3.5 --exclude v3.6 --exclude v3.7 --exclude v3.8 --exclude v3.9 --exclude v3.10 --exclude v3.11 --exclude v3.12"

mkdir -p "$dest"
/usr/bin/rsync -vvv \
--archive \
--update \
--hard-links \
--delete \
--delete-after \
--delete-excluded \
--delay-updates \
--timeout=600 \
$exclude \
"$src" "$dest"
</pre>

[[Category:Server]]
[[Category:Package Manager]]

How to setup a Alpine Linux mirror

2023-07-06T13:35:42Z

Ikke: Update mirror sizes

== Introduction ==
This document describes how to set up an Alpine Linux mirror and make it available via http and rsync.

We will:
* create the dir where we have the mirror
* set up a cron job to sync with master mirror every hour
* set up lighttpd for http access
* set up rsync so other mirrors can rsync from you

Make sure that you have enough disk space.

Current (2023-01-13) disk usage in GB:

{|class="wikitable"
!edge
!v3.0
!v3.1
!v3.2
!v3.3
!v3.4
!v3.5
!v3.6
!v3.7
!v3.8
!v3.9
!v3.10
!v3.11
!v3.12
!v3.13
!v3.14
!v3.15
!v3.16
!v3.17
!v3.18

!total
|-
|348
|17
|18
|15
|21
|25
|27
|45
|43
|59
|73
|92
|126
|148
|156
|181
|186
|195
|214
|242

|'''2222'''
|}

Script used to calculate the size:

<pre>
#!/bin/sh

total=0
dest="$(mktemp -d)"

for dir in edge v3.0 v3.1 v3.2 v3.3 v3.4 v3.5 v3.6 v3.7 v3.8 v3.9 v3.10 v3.11 v3.12 v3.13 v3.14 v3.15 v3.16 v3.17 v3.18; do
old_total="$total"
src="rsync://rsync.alpinelinux.org/alpine/$dir/"
size=$(rsync -a -n --stats "$src" "$dest" | grep '^Total file size' | tr -d ',' | awk '{ print $4 }')
total=$(( old_total + size ))
echo "$dir: $size" | awk '{ print $1 sprintf("%.1f", $2/1073741824) }'
done

echo "total: $total" | awk '{ print $1 sprintf("%.1f", $2/1073741824) }'
rm -r "$dest"
</pre>

== Setting up the cron job ==
Install rsync which will be used to sync from the master mirror.
{{Cmd|apk add rsync}}

Save the following file as ''/etc/periodic/hourly/alpine-mirror''
<pre>
#!/bin/sh

# make sure we never run 2 rsync at the same time
lockfile="/tmp/alpine-mirror.lock"
if [ -z "$flock" ] ; then
exec env flock=1 flock -n $lockfile "$0" "$@"
fi

src=rsync://rsync.alpinelinux.org/alpine/
dest=/var/www/localhost/htdocs/alpine/

# uncomment this to exclude old v2.x branches
#exclude="--exclude v2.*"

mkdir -p "$dest"
/usr/bin/rsync \
--archive \
--update \
--hard-links \
--delete \
--delete-after \
--delay-updates \
--timeout=600 \
$exclude \
"$src" "$dest"

</pre>

(or use [https://gist.github.com/jirutka/288c6fff7c0b8a835d143686207316be this script])

Make it executable:
{{Cmd|<nowiki>chmod +x /etc/periodic/hourly/alpine-mirror</nowiki>}}

Now it will sync every hour. (given cron runs)

== Setting up HTTP access via lighttpd ==

Install the lighttpd server
{{Cmd|apk add lighttpd}}

Enable dir listings by uncommenting the following line in ''/etc/lighttpd/lighttpd.conf'':
dir-listing.activate = "enable"

Also set cache-control to force cache revalidate every 30 mins. Uncomment mod_setenv in ''/etc/lighttpd/lighttpd.conf'':
"mod_setenv",

Add also the following lines to ''/etc/lighttpd/lighttpd.conf'':
setenv.add-response-header += (
"Cache-Control" => "must-revalidate"
)

Start lighttpd and make it start at boot:
{{Cmd|rc-service lighttpd start
rc-update add lighttpd}}

{{Note|You may wish to consider [[Darkhttpd]] as an alternative to [[Lighttpd]]

If so, simply install, start and auto-start the webserver:

{{Cmd|apk add darkhttpd && rc-service darkhttpd start && rc-update add darkhttpd}}

Darkhttpd will, by default, offer directory listings and serve data from /var/www/localhost/htdocs/

See the main article on [[Darkhttpd]] for more configuration options}}

== Setting up rsyncd ==
Add the following lines to ''/etc/rsyncd.conf'':
<pre>
[alpine]
path = /var/www/localhost/htdocs/alpine
comment = My Alpine Linux Mirror
</pre>

Optionally set a bandwidth limit in ''/etc/conf.d/rsyncd''. In this example we limit to 500Kbytes/s (approx 5Mbit/s)
<pre>
RSYNC_OPTS="--bwlimit=500"
</pre>

== Mirror statistics ==

Simple bandwidth statistics can be generated with vnstat.

{{Cmd|apk add vnstat}}

edit /etc/vnstat.conf and replace the interface name with the appropriate one.

Start vnstatd

{{Cmd|/etc/init.d/vnstatd start }}

copy the following script to /etc/periodic/15min/stats and make sure your crond is running.
please not that heredoc should be tab indented or the script will fail. A working copy can be found here: http://tpaste.us/RrMv

<pre>
#!/bin/sh

output="/var/www/localhost/htdocs/.stats"
nic="eth0"

generate_index() {
cat <<-EOF
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta http-equiv="cache-control" content=no-cache">
<meta http-equiv="refresh" content="3000">
<title>Alpine Linux mirror statistics</title>
</head>
<body>
<table border="0">
<tr><td><img src="summary.png" alt="summary"></td><td><img src="hours.png" alt="hours"></td></tr>
<tr><td rowspan="2"><img src="days.png" alt="days"></td><td><img src="top10.png" alt="top10"></td></tr>
<tr><td><img src="months.png" alt="months"></td></tr>
</table>
</body>
</html>
EOF
}

if [ ! -f "$output"/index.html ]; then
mkdir -p $output
generate_index > "$output"/index.html
fi

for type in hours days months top10 summary hsummary vsummary; do
vnstati --${type} -i $nic -o $output/${type}.png
done
</pre>

== Update mirror from mqtt ==

If you want your mirror to be really uptodate compared to our master mirror you can subscribe to Alpine Linux message server "msg.alpinelinux.org" and check for upload messages.
Add mqtt-exec to be able to execute processes when specific topics are being send.

{{Cmd| apk add mqtt-exec}}

mqtt-exec supports running multiple time so we need to setup a specific config.

{{Cmd| ln -s /etc/init.d/mqtt-exec /etc/init.d/mqtt-exec.sync-mirror}}

{{Cmd| ln -s /etc/conf.d/mqtt-exec /etc/conf.d/mqtt-exec.sync-mirror}}

edit /etc/conf.d/mqtt-exec.sync-mirror

<pre>
mqtt_topics="rsync/rsync.alpinelinux.org/#"
exec_user="buildozer"
exec_command="/usr/local/bin/sync-mirror"
</pre>

Copy the following file to /usr/local/bin/sync-mirror and make it executable (dont forget to update the variables).

<pre>
#!/bin/sh

src="rsync://rsync.alpinelinux.org/alpine/"
dest="/var/www/localhost/htdocs/alpine/"
lock="/tmp/sync-mirror.lock"
topic="$1"
dir="$2"

[ -z "$flock" ] && exec env flock=1 flock $lock $0 "$@"

if [ -n "$dir" ] && [ -d "$dest/${dir%/*}" ]; then
logger "Syncing directory: $dir"
src="${src}${dir%/}/"
dest="${dest}${dir%/}/"
else
logger "Syncing all directories"
fi

/usr/bin/rsync \
--archive \
--update \
--verbose \
--progress \
--timeout=600 \
--delay-updates \
--delete-after \
"$src" \
"$dest"
</pre>

And finally start mqtt-exec and let it listen on msg.alpinelinux.org

{{Cmd|/etc/init.d/mqtt-exec.sync-mirror start}}

To make sure you are not missing any packages (in case something goes wrong with MQTT subscription) you can periodically sync all directories by adding the script to cron.

{{Cmd|ln -s /usr/local/bin/sync-mirror /etc/periodic/hourly/sync-mirror}}

Now watch your syslog as it should tell you when it will update directories in your local mirror.

== Partial mirror using nginx ==

For a private mirror it might make sense to sync only the newest versions of Alpine to save space, but if you ''do'' point an old Alpine version to your mirror they should still be able to install packages. We can achieve this by using nginx to serve the mirrored content and use regex location matching to redirect requests to a public mirror.

Let's assume you chose to only mirror Alpine versions up from v3.13. If a client asks your mirror for v.3.10 it should redirect to another mirror.

Your nginx config server block should look something like this:

<pre>
server {
listen 80;
server_name alpine.mydomain.local;
root /data/alpine; # point to where your alpine mirror is located. make sure nginx is allowed to read it
autoindex on; # Enable indexing

# the following location block will match for v3.0 to v3.12
# and will forward it to dl-4.alpinelinux.org.
location ~* /(v3\.([1-9]|1[012]))$
{
return 302 http://dl-cdn.alpinelinux.org/alpine$request_uri;
}
}
</pre>

The corresponding sync script could look something like this:

<pre>
#!/bin/sh

# make sure we never run 2 rsync at the same time
lockfile="/tmp/alpine-mirror.lock"
if [ -z "$flock" ] ; then
exec env flock=1 flock -n $lockfile "$0" "$@"
fi

src=rsync://rsync.alpinelinux.org/alpine/
dest=/data/alpine/

exclude="--exclude v2.* --exclude v3.0 --exclude v3.1 --exclude v3.2 --exclude v3.3 --exclude v3.4 --exclude v3.5 --exclude v3.6 --exclude v3.7 --exclude v3.8 --exclude v3.9 --exclude v3.10 --exclude v3.11 --exclude v3.12"

mkdir -p "$dest"
/usr/bin/rsync -vvv \
--archive \
--update \
--hard-links \
--delete \
--delete-after \
--delete-excluded \
--delay-updates \
--timeout=600 \
$exclude \
"$src" "$dest"
</pre>

[[Category:Server]]
[[Category:Package Manager]]

VLAN

2023-05-03T21:15:55Z

Ikke:

This article shows how to configure a network interface as an IEEE 802.1q VLAN trunk.

__TOC__

{{Note| Alpine Linux v2.4 or later is required}}
==Installation==
First, install the ''vlan'' package. This will give you support for vlans in the ''/etc/network/interfaces'' file.
{{Cmd|apk add vlan}}

==Configuration==
Edit the ''/etc/network/interfaces'' file:
<pre>
auto eth0.8
iface eth0.8
address 192.168.0.2/24
gateway 192.168.0.1
vlan-raw-device eth0
vlan_id 8

</pre>
With the ''vlan'' package installed, ifup will find the trailing .8 in eth0.8 and will create a vlan interface with vid 8 over eth0.

Alternativly with vlan8 over eth0:
<pre>
auto vlan8
iface vlan8
address 192.168.0.2/24
gateway 192.168.0.1
vlan-raw-device eth0
</pre>

A static ip address was used in the examples shown above, but dhcp can be used as well.

== Example with bridges associated with VLANs over bonding with differing MTUs on the various VLANs ==
This serves as an example of some of the more complicated networking possible. Particularly, this would work well for a hypervisor attached to a dedicated storage VLAN. Less complicated implementations can be achieved by merely removing the non-applicable parts.
<pre>
auto lo
iface lo inet loopback

auto bond0
iface bond0 inet manual
bond_slaves eth0 eth1
bond_mode 802.3ad
bond_miimon 100
bond_xmit_hash_policy layer2+3
post-up ip link set dev bondi0 mtu 9000

iface bond0.1

auto br1
iface br1
address 192.168.1.196/24
gateway 192.168.1.1
bridge_ports bond0.1
bridge_stp off
bridge_fd 0.0
post-up ip link set dev bond0.1 mtu 1500

iface bond0.10 inet manual

auto br10
iface br10 inet static
address 192.168.10.1/24
bridge_ports bond0.10
bridge_stp off
bridge_fd 0.0
</pre>

== Example with two interfaces on the same adapter. One with vlan and one without ==

Since linux doesn't allow multiple default gateways we need to use a second routing table using iproute2

{{Cmd|apk add iproute2}}

Then we'll add two new routig tables to the config file. One for each network

{{Cmd|echo "1 rt1" >> /etc/iproute2/rt_tables;echo "2 rt2" >> /etc/iproute2/rt_tables;}}

Now we need to edit /etc/network/interfaces

<pre>
auto lo
iface lo inet loopback

# the native interface without a vlan (also called untagged)

auto eth0
iface eth0
address 192.168.1.100/24
gateway 192.168.1.1
post-up ip route add 192.168.1.0/24 dev eth0 src 192.168.1.100 table rt1
post-up ip route add default via 192.168.1.1 dev eth0 table rt1 # the actual gateway for this interface
post-up ip rule add from 192.168.1.100/32 table rt1
post-up ip rule add to 192.168.1.100/32 table rt1

# second interface with the vlan tag 5
auto eth0.5
iface eth0.5
address 192.168.5.100/24
post-up ip route add 192.168.5.0/24 dev eth0.5 src 192.168.5.100 table rt2
post-up ip route add default via 192.168.5.1 dev eth0.5 table rt2 # the actual gateway for this interface
post-up ip rule add from 192.168.5.100/32 table rt2
post-up ip rule add to 192.168.5.100/32 table rt2
</pre>

Note that if you want to add a third interface this way, you'll have to add another routing table

[[Category:Networking]]

VLAN

2023-05-03T19:39:51Z

Ikke: Modernize examples for ifupdown-ng

Release Notes for Alpine 3.18.0

2022-12-14T18:53:30Z

Ikke:

* python 3.11 https://docs.python.org/3/whatsnew/3.11.html
* linux-lts 6.1 https://lkml.org/lkml/2022/12/11/206

Release Notes for Alpine 3.18.0

2022-12-14T18:52:54Z

Ikke:

- python 3.11 https://docs.python.org/3/whatsnew/3.11.html
- linux-lts 6.1 https://lkml.org/lkml/2022/12/11/206

Creating an Alpine package

2022-11-26T12:47:52Z

Ikke: /* Testing the package locally */ Update repositories

{{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 [[APKBUILD Reference]] wiki page or 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.<BR>
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]

==== 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.

<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. For example, can be used to restore busybox links:
<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.

<br> 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.

{{Cmd|abuild -r}}

See also [[Abuild_and_Helpers|Abuild and Helpers]].

== 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/main/
/home/USER/packages/community/
https://dl-cdn.alpinelinux.org/alpine/edge/main
https://dl-cdn.alpinelinux.org/alpine/edge/community
https://dl-cdn.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}}

== Send a patch ==

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

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

[[category: Package Manager]]

Alpine Linux:Contribute

2022-11-18T11:42:32Z

Ikke: Remove old bugs e-mail address

[[Image:kuser.png|left|link=]]
__NOTOC__
There are many ways that ''you'' can contribute. Whether you are a normal user, a geek, or a hardcore developer, the one and most important thing you can do is to actually '''use''' Alpine Linux.

The list below explains some of the ways that you can contribute.

= Contribute quality =
* Submit '''[https://gitlab.alpinelinux.org/alpine/aports/issues bug reports]'''.
* Suggest new '''[https://gitlab.alpinelinux.org/alpine features/ideas]''' (Previously: '''[[Project:Ideas|features/ideas]]''' and '''[[FAQ#Can_you_build_an_apk_package_for_....3F|packages]]''')
* Submit new '''[[Creating_an_Alpine_package|packages]]''' that you've created, or '''[[Development using git|patches]]''' to existing packages. For more information about developing on Alpine Linux, read our [[Developer Documentation]].
* Submit '''[[Special:NewFiles|artwork]]''' (icons, backgrounds, logos)
* Correct '''spelling and grammar''' mistakes in the documentation
* Help '''[[Project:Wiki_maintenance|maintain]]''' the wiki

= Contribute documentation =
* Help write good '''[[Tutorials_and_Howtos|documentation]]'''
* '''Translate''' the documentation (and program texts) into another language
* '''Proofread''' existing documentation, follow the examples, and make corrections
* Create diagrams, '''screenshots''', and graphics for the documentation
* Develop style, formatting, spelling, and grammar conventions for documenters
* Expand the '''[[Glossary]]''' of technical terms (so non-geeks can understand)
* Convert documentation into more formats

= Contribute support =
* '''Answer questions''' on the wiki, [[mailing lists]], [[IRC]] channels and [http://stackoverflow.com/questions/tagged/alpine StackOverflow]
* Contribute to (or start) an online support group
* Post a tutorial or other to https://asciinema.org
* Write '''HOWTOs''' and post them in the [[Tutorials and Howtos]] or your own blog

= Contribute projects =
* [[Wishlist]]

= Contribute publicity =
{{Tip|As Alpine Linux gets more popular, there will be more people wanting to contribute.}}
* '''[[Project:Listings|Link to]]''' the Alpine Linux web site
* Write '''reviews'''
* Convince people to choose Open Source products when possible
* Write about new ways of using an Open Source application

= Contribute appreciation =
* Be '''polite''' when reporting bugs or asking for new features; after all, the developers have no obligation to do it
* '''Express''' your appreciation to developers (through [[Mailing_lists|e-mail]], [https://gitlab.alpinelinux.org/alpine/aports/issues bug reports], and [[Alpine Linux:IRC|IRC]])
* Send the programmers post cards
* Give the project or [[Alpine_Linux:Developers|a developer a donation/gift]] (some have wish lists for this)
* Contribute to [https://www.patreon.com/musl musl libc development].

Alpine Linux:Wiki maintenance

2022-09-18T13:26:05Z

Ikke: Fix links for 'pagest that' (thanks sliwkr)

== [[Special:SpecialPages|Special Pages]] ==

"Hey, [[User:Dubiousjim/Special|where did the link to the SpecialPages in the Sidebar go]]?"

Click the header above to go to the original page.

== Pages ==
* [[Special:NewPages|New]] or [[Special:PrefixIndex|all]]  pages
* Most:  [[Special:MostLinkedPages|linked-to]] [[Special:MostRevisions|revised]] pages
* Redirects: [[Special:ListRedirects|all]] [[Special:BrokenRedirects|broken]] [[Special:DoubleRedirects|double]]
* [[Special:LinkSearch|What pages link to offsite url]] ___?
* Pages that:
** [[Special:WhatLinksHere/Template:Delete|are proposed for deletion]] ([[Special:Nuke|bulk delete]])
** [[Special:WhatLinksHere/Template:Obsolete|are obsolete]]
** [[Special:WhatLinksHere/Template:Merge|are proposed for merging]] ([[Special:MergeHistory|merge histories]])
** [[Special:WhatLinksHere/Template:Move|are proposed for moving]]
** [[Special:WhatLinksHere/Template:Draft|are drafts]]
** [[Special:WhatLinksHere/Template:Expand|need expanding]] ([[Special:ShortPages|short pages]])
** [[Special:WhatLinksHere/Template:Style|need style improvements]]
** [[Special:UncategorizedPages|have no category]]
** [[Special:LonelyPages|are orphaned]]
** [[Special:WantedPages|are wanted]]
** [[Special:ProtectedPages|are protected]] ([[Special:PagesWithProp|other properties]])
** [[Special:DeadendPages|have no links to other pages]]

== Files/Images ==
* [[Special:NewFiles|New]] or [[Special:ListFiles|all]] files
* Files that:
** [[Special:UncategorizedFiles|have no category]]
** [[Special:UnusedFiles|are orphaned]]
** [[Special:WantedFiles|are wanted]]
** [[Special:ListDuplicatedFiles|are duplicates]]

== Templates ==
* [[Special:MostTranscludedPages|Used]] or [[Special:AllPages/Template:|all]] templates
* Templates that:
** [[Special:UnusedTemplates|are unused]]
** [[Special:WantedTemplates|are wanted]]
* [[Special:ExpandTemplates|Sandbox]]

== Categories ==
* Categories that:
** [[Special:AllPages/Category:|are described]]
** [[Special:Categories|are used]]
** [[Special:UnusedCategories|are unused]]
** [[Special:WantedCategories|are wanted]]

* Uncategorized: [[Special:UncategorizedPages|pages]] [[Special:UncategorizedFiles|files]]

== Wanted and Orphaned ==
* Wanted: [[Special:WantedPages|pages]] [[Special:WantedFiles|files]] [[Special:WantedTemplates|templates]] [[Special:WantedCategories|categories]]
* Orphaned: [[Special:LonelyPages|pages]] [[Special:UnusedFiles|files]]
* Unused: [[Special:UnusedTemplates|templates]] [[Special:UnusedCategories|categories]]

== Other ==

* [[Special:ActiveUsers|Active]] or [[Special:ListUsers|all]] users
* [[Special:ListGroupRights|User privileges]]
* [[Project:Developers|Developers]]
* [[Special:ComparePages|Compare pages]]

* Wiki [[Special:Log|logs]] [[:Category:Wiki|help]] | [[Special:Version|version]] [https://www.mediawiki.org/wiki/Help:Contents userman] ([https://meta.wikimedia.org/wiki/Help:Contents older]) [https://www.mediawiki.org/wiki/Manual:Contents adminman]
* Project [[Project:Overview|overview]] [[Alpine Linux:Releases|releases]] [http://pkgs.alpinelinux.org/packages packages] [[Special:AllPages/Alpine Linux:|pages]] [[glossary]]
* Project [http://alpinelinux.org/ news] [http://git.alpinelinux.org/ git] [http://bugs.alpinelinux.org/?query_id=15 bugs] [http://bugs.alpinelinux.org/projects/alpine/activity activity]

* [http://bugs.alpinelinux.org/projects/alpine/roadmap Roadmap] | Older ideas: [[Talk:Tutorials_and_Howtos|1]] [[Wishlist|2]] [[Project:Ideas|3]]

[[Category:Wiki]]