Alpine Linux - User contributions [en]

Wireless AP with udhcpd and NAT

2022-10-03T05:27:07Z

Anjanmomi: fix command formatting

[[Category:Networking]]
Setting up a wireless AP with udhcpd and NAT

(based largely on the [http://elinux.org/RPI-Wireless-Hotspot raspberry pi wireless router howto])

= Dependencies =

Install the hostapd access point software, busybox-extras (for the udhcpd DHCP server),
and the iptables firewall manager.

{{Cmd|apk add hostapd busybox-extras iptables}}

If you want to connect clients to the internet, you need to provide some way
of redirecting traffic from the AP to the internet.
There are two main possibilities:
*A bridge
*Network Address Translation

If you use a bridge and get your IP via DHCP, you may have a hard time
configuring it such that the bridge gets an IP address without screwing up your
local internet connection.

This guide only covers NAT. See [[Bridge]] for more info.

= Configure hostapd =
You need to write a configuration file. Alpine ships with a sample file in
/etc/hostapd/hostapd.conf, but it didn't work for me (possibly because I
used a pre-wireless-N card, supported by ath5k?).

Here's a sample based on something that did work for me
(I've changed ssid & wpa_passphrase):
ctrl_interface=/var/run/hostapd
ctrl_interface_group=0
interface=wlan0
driver=nl80211
logger_syslog=-1
logger_syslog_level=2
logger_stdout=-1
logger_stdout_level=2
ssid=alpine-test
hw_mode=g
channel=6
max_num_sta=32
rts_threshold=2347
fragm_threshold=2346
macaddr_acl=0
auth_algs=3
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=supertopsecret
wpa_key_mgmt=WPA-PSK WPA-PSK-SHA256
wpa_pairwise=TKIP CCMP

Change "interface" to match your wireless interface.
Change "ssid" and "wpa_passphrase" as necessary.
Set "wpa" to 3 if you want plain wpa and wpa2. or 1 for plain WPA1 only.

The example in the package uses wpa_psk_file (needed for WPS) instead of a
static passphrase. That does not enable WPS.

You may want to change the channel to avoid collisions with other local APs.
Unfortunately, the automatic channnel selection (channel=0) is *not*
currently enabled at compile time, so we can't use it. Scan for channels
in use with {{Cmd|iwlist wlan0 scanning}} or equivalent, before setup.

max_num_sta sets a limit on the number of clients that can connect to your AP.
Set it higher than you think you might have, but not much higher.

If you don't put this in /etc/hostapd/hostapd.conf, you will need to change
the CONFIGS line in /etc/conf.d/hostapd to point at it.
I prefer doing that, so that the default is available for reference.

= Configure udhcpd =

Edit /etc/udhcpd.conf.
The default is very well-commented, but not really ready to use.
Here's a skeleton, loosely based on mine:
start 192.168.2.2
end 192.168.2.254
max_leases 64
interface wlan0
static_lease 00:1b:de:ad:be:ef 192.168.2.100
opt dns 192.168.0.1 8.8.8.8
opt subnet 255.255.255.0
opt router 192.168.2.1
opt lease 864000

Note the following:
*max_leases should be set to at least as many clients as you might have in the lifetime of a lease. If you have any clients connecting via bridges, note that the bridge itself gets a DHCP address.
*interface is the interface clients will be connecting to (wlan0 or your wireless interface in this example)
*router should be the static IP address you assign to your wireless interface.
*start and end should be within the same subnet as the IP address you configure wlan0 with, but the address for wlan0 should be outside the range.
(e.g. 192.168.2.1 and 192.168.2.255 are both suitable for the router address)
*set the DNS option to point to any nameservers you want. You can repeat it, but the limit is 3 nameservers.
*static_lease takes two arguments: a MAC address designating a specific network adaptor, and the IP address that should be assigned to it.
It can be repeated multiple times, to assign different addresses to different users.
This comes in handy for printers, if you can trust network users to not do MAC spoofing.

= Configure iptables =

I used raw iptables, configuring it thus:
{{Cmd|iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i eth0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i wlan0 -o eth0 -j ACCEPT}}
# this saves the state in a location the service can restore it from
<code>
service iptables save
</code>

= Test =
<code>
/etc/init.d/hostapd start

/etc/init.d/udhcpd start

sysctl net.ipv4.ip_forward=1
</code>
and try connecting from another computer.

= Make the changes permanent =

{{Cmd|rc-update add hostapd
rc-update add udhcpd
rc-update add sysctl}}

== Configuring ifup ==
Now, the odd parts:
iptables tries to set net.ipv4.ip_forward to 1 when it's started, but in
my experience, this is not reliable.
You do *not* want to enable the "iptables" service. It starts before
networking, and may result in your wireless interface not getting configured.
(Apparently, ifup thinks that wlan0 is up and skips it. This was not something I expected, but it's the only explanation I have for how things worked...)

Rather, modify /etc/network/interfaces, commenting out any configuration for
your wireless interface. Then add:

<pre>
auto wlan0
iface wlan0 inet static
address 192.168.2.1
netmask 255.255.255.0
up /etc/init.d/iptables start
up sysctl net.ipv4.ip_forward=1
down /etc/init.d/iptables stop
</pre>

(It's possible to set up everything so that hostapd and udhcpd get
started and stopped from the wlan0 stanza. I didn't bother doing that.)

= Finishing touches =

(See [[Setting_up_a_ssh-server]] for alternatives and more information)
Add dropbear SSH server, configure it to run on only the wireless interface:
{{Cmd|setup-sshd -c dropbear}}
edit /etc/conf.d/dropbear to add

DROPBEAR_OPTS="-p 192.168.2.1:22"

(assuming the wireless interface has the IP address 192.168.2.1 and you
want SSH on port 22).
This is optional, but if you're using a wireless router it helps to be able
to administer it, and listening on all addresses is rather risky.

= Things this doesn't cover but it would be nice to =
*Some way to get more entropy (see [[Entropy_and_randomness]])
*DNS server, publishing device names ([[TinyDNS_Format]] looks most useful)
*use awall instead of raw iptables (and/or switch to nftables)
*[[Setup-acf]] to manage the router
This would require:
**acf-core, acf-alpine-conf, acf-apk-tools
**acf-iptables, or acf-awall + rewrite
**acf-ssh + switch to openssh, or new acf-dropbear
**acf-dhcp + switch to dhcp, or new acf-udhcpd
**new acf-hostapd (probably hardest part!)
**acf-tinydns after adding tinydns

APKBUILD Reference

2022-09-20T03:53:04Z

Anjanmomi: document ~ and >= for $pkgname and $pkgver

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

addgroup -S clamav 2>/dev/null
adduser -S -D -H -s /sbin/nologin -G clamav -g clamav clamav 2>/dev/null

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

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

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

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

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

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

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

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

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

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

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

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

New packages should use only sha512sums.

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

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

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

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

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

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

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

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

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

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

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

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

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

: Here are few things to note:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

: This feature is available since Alpine >=2.6.

==== default_prepare() ====

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

: To run test suite with autotools do:

make check

: To run the test suite with python setuptools:

python2 setup.py test
python3 setup.py test

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

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

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

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

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

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

= Special Operators =

== $pkgname~$pkgver ==

Specifies a required <code>$pkgver</code> for [[apk]] to satisfy the <code>$pkgname</code> requirement. <code>~</code> ignores revisions of the package version. For example <code>superd~0.6</code> in <code>$depends</code> will ensure superd with package version 0.6 is installed as a run-time dependency for the package.

== $pkgname>=$pkgver ==

Specifies the installed package version must be greater than or equal to <code>$pkgver</code> for [[apk]] to satisfy the <code>$pkgname</code> requirement.

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

= Version =

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

For more information see [[APKBUILD_versions]].

[[Category:Development]]

NetworkManager

2022-08-20T14:33:04Z

Anjanmomi: Add nm-applet not authorized to control networking

[https://networkmanager.dev/ NetworkManager] is a program that provides automatic detection and configuration for systems to connect to networks.

== Installation ==

{{Cmd|# apk add {{Pkg|networkmanager}}}}

 

NetworkManager comes with a command line interface and a curses-based interface, <code>nmcli</code> and <code>nmtui</code> respectively or you can use a additional gui interface:

* {{Pkg|plasma-nm}} for Plasma integration and applet
* {{Pkg|network-manager-applet}} for a GTK system tray applet

 

After installation start NetworkManager:
{{Cmd|# rc-service networkmanager start}}

 

Also your user needs to be in the <code>plugdev</code> group:
{{Cmd|# adduser <YourUsername> plugdev}}

{{Note|you will need to log out for the new group to take effect}}

 

== Wireless networks ==

==== wpa_supplicant backend ====

{{Todo|([[KDE|KDE Plasma]] Desktop) find out if it is possible to prevent requesting the password for '''KDE Wallet''' on login}}

* Follow: [[Wi-Fi#wpa_supplicant]] and [[Wi-Fi#Automatic_Configuration_on_System_Boot]]
{{Note|{{Pkg|wpa_supplicant}} configuration might not be required, if it isnt it may be a good idea to have it setup just as a fallback}}

 

Now open <code>/etc/NetworkManager/NetworkManager.conf</code> in a text editor and change it to something like this:

{{Cat|/etc/NetworkManager/NetworkManager.conf|<nowiki>[main]
dhcp=internal
plugins=ifupdown,keyfile

[ifupdown]
managed=true

[device]
wifi.scan-rand-mac-address=yes
wifi.backend=wpa_supplicant</nowiki>}}

{{Note|if these options dont work on your system you can change them as necessary}}

 

Now you need to stop conflicting services:

{{Cmd|# rc-service networking stop}}
{{Cmd|# rc-service wpa_supplicant stop}}

 

Now restart NetworkManager:

{{Cmd|# rc-service networkmanager restart}}

 

Now connect to a network using one of the interfaces mentioned in [[NetworkManager#Installation|Installation]]

 

If that connects and stays connected with no issues enable the <code>networkmanager</code> service and disable the <code>networking</code> and <code>wpa_supplicant</code> boot services:

{{Cmd|# rc-update add networkmanager}}
{{Cmd|# rc-update del networking boot}}
{{Cmd|# rc-update del wpa_supplicant boot}}

 

==== iwd backend ====

NetworkManager supports wireless networks through {{Pkg|iwd}}, however, consider [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues?scope=all&utf8=%E2%9C%93&state=opened&search=iwd existing issues] before using it. After installation, enable the server and restart NetworkManager:
<pre>
rc-service iwd start
rc-service networkmanager restart
</pre>

To use {{Pkg|iwd}} though, you've have to edit NetworkManager's configuration because it still defaults to {{Pkg|wpa_supplicant}} instead. Add the following to {{Path|/etc/NetworkManager/NetworkManager.conf}}:

<pre>
[device]
wifi.backend=iwd
</pre>

 

== VPN support ==
Since version 1.16, NetworkManager has support for Wireguard[https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/NEWS?id=1.16.0].

Support for other VPN types is provided by plugins. They are provided in the following packages:
* {{Pkg|networkmanager-openvpn}} for OpenVPN

== nm-applet ==
=== not authorized to control networking ===

You can enable all users to edit connections without adding polkit.
First, make the <code>conf.d</code> directory for networkmanager:

{{Cmd|# mkdir -p /etc/NetworkManager/conf.d}}

Then, add following content to <code>/etc/NetworkManager/conf.d/any-user.conf</code>:

<pre>
[main]
auth-polkit=false
</pre>

Finally, restart networkmanager:

{{Cmd|# /etc/init.d/networkmanager restart}}

[[Category:Networking]]

Include:Setup your system and account for building packages

2021-12-11T20:12:34Z

Anjanmomi: recommend users use doas with abuild-keygen

The {{Pkg|alpine-sdk}} is a metapackage that pulls in the most essential packages used to build new packages. We'll also install doas to perform superuser operations, and nano to allow us to edit text:

{{Cmd|apk add alpine-sdk doas nano}}

This would be a good time to [[Setting_up_a_new_user|create a normal user account for you to work in]]. To make life easier later, it's a good idea to add this user to the wheel group; operations that require superuser privileges can now be done with doas.

The [[Aports_tree|aports tree]] is in git so before we clone the it, let's configure git.

{{Cmd|git config --global user.name "Your Full Name"
git config --global user.email "your@email.address"}}

Read carefully [[Development using git]] to grasp basic Git operations and how to configure for sending email patches.

Now we can clone the [[Aports_tree|aports tree]].

{{Cmd|git clone https://gitlab.alpinelinux.org/alpine/aports}}

Before we start creating or modifying [[APKBUILD_Reference|APKBUILD]] files, we need to setup abuild for our system and user. Edit the file {{Path|abuild.conf}} to your requirements:

{{Cmd|doas nano /etc/abuild.conf}}

Most of the defaults can be left alone, unless you are developing for a custom platform, in which case the comments in the file should guide you. The one field to edit is PACKAGER, so that you can get credit (or blame) for packages you create.

To use 'abuild -r' command to install dependency packages automatically.
{{Cmd|doas addgroup <yourusername> abuild}}

We also need to prepare the location where the build process caches files when they are downloaded. By default this is {{Path|/var/cache/distfiles/}}. To create this directory and ensure that it is writeable, enter the following commands:

{{Cmd|doas mkdir -p /var/cache/distfiles
doas chmod a+w /var/cache/distfiles}}

As an alternative to the second command, you can add yourself to the abuild group:

{{Cmd|doas chgrp abuild /var/cache/distfiles
doas chmod g+w /var/cache/distfiles}}

{{Note|Remember to logout and login again for the group change to have effect.}}

The last step is to configure the security keys with the [[Abuild-keygen|abuild-keygen]] script for [[Abuild|abuild]] with the command:

{{Cmd|SUDO=doas abuild-keygen -a -i}}

[[Category:Development]]

PipeWire

2021-12-02T01:12:36Z

Anjanmomi: package name is pipewire-pulse not pipewire-pulseaudio

{{Draft|The instructions below have not been thoroughly tested and may break things.}}

[https://pipewire.org/ PipeWire] is a multimedia processing engine that aims to improve audio and video handling on Linux.

== Prerequisites ==

=== Audio Group ===

When elogind is not available, the user has to be added to the <code>audio</code> group. The user must log in for this to take effect.

<pre>
# addgroup <user> audio
</pre>

=== D-Bus ===

PipeWire requires a running [https://www.freedesktop.org/wiki/Software/dbus/ D-Bus] session. If you use a full desktop environment this will probably be started automatically, but with minimal window managers it must be done manually.

<pre>
# apk add dbus dbus-openrc dbus-x11
# rc-service dbus start
# rc-update add dbus default
</pre>

Then use <code>dbus-launch</code> whenever you start an X or Wayland session. For example:
<pre>
$ dbus-launch --exit-with-session sway
</pre>

=== XDG_RUNTIME_DIR ===

If you are not using a Desktop Manager, ensure that your <code>XDG_RUNTIME_DIR</code> is set to a user-writable location. By default for pulseaudio this is {{Path|/run/user/1000/}} or {{Path|/tmp}}. If this is not set, pipewire will create a directory in your home folder instead, called <code>~/pulse</code>, and on attempting to run Pavucontrol or pactl, you will get the following error:

<pre>
$ pactl list
Connection failure: Connection refused
pa_context_connect() failed: Connection refused
</pre>

== Installation and configuration ==

<pre>
# apk add pipewire wireplumber
</pre>

{{Note|Using [https://gitlab.freedesktop.org/pipewire/wireplumber WirePlumber] rather than the pipewire-media-session (which comes with pipewire) is [https://gitlab.freedesktop.org/pipewire/media-session/-/blob/master/README.md recommended] but not required.}}

Create a custom configuration file in {{Path|/etc/pipewire/pipewire.conf}}:

<pre>
# mkdir /etc/pipewire
# cp /usr/share/pipewire/pipewire.conf /etc/pipewire/
</pre>

Add the following line to the <code>context.exec</code> section at the bottom of {{Path|/etc/pipewire/pipewire.conf}}:

<pre>
{ path = "wireplumber" args = "" }
</pre>

Enable the <code>snd_seq</code> kernel module for ALSA support.

<pre>
# modprobe snd_seq
# echo snd_seq >> /etc/modules
</pre>

=== ALSA ===

If you use neither Jack nor PulseAudio and you don't intend to.

<pre>
# touch /etc/pipewire/media-session.d/with-alsa
</pre>

=== PulseAudio ===

PipeWire can run a [https://www.freedesktop.org/wiki/Software/PulseAudio/ PulseAudio] daemon which should allow all existing PulseAudio applications to be used with the PipeWire backend.

<pre>
# apk add pipewire-pulse
</pre>

Uncomment the following line in {{Path|/etc/pipewire/pipewire.conf}}:

<pre>
{ path = "/usr/bin/pipewire" args = "-c pipewire-pulse.conf" }
</pre>

It should be automatically enabled.

=== JACK ===

If you will be using PipeWire for [https://jackaudio.org/ JACK] applications install the required package and make system wide links to the PipeWire replacement JACK libraries (I have not had success using <code>pw-jack</code>). You will not need to start a JACK server.

<pre>
# apk add pipewire-jack
# ln -sf /usr/lib/pipewire-0.3/jack/libjackserver.so.0 /usr/lib/libjackserver.so.0
# ln -sf /usr/lib/pipewire-0.3/jack/libjacknet.so.0 /usr/lib/libjacknet.so.0
# ln -sf /usr/lib/pipewire-0.3/jack/libjack.so.0 /usr/lib/libjack.so.0
</pre>

{{Note|These symlinks might be overwritten during updates.}}

=== Video ===

Video should work out-of-the-box with v4l2 devices (e.g. a lot of webcams) and [https://gstreamer.freedesktop.org/ GStreamer] applications.

=== Bluetooth headset ===

Requires <code>pipewire-spa-bluez</code> package in addition to <code>pipewire-pulse</code> daemon to be installed.

=== Automatic bluetooth profile selection ===

To automatically switch between HSP/HFP and A2DP profiles when an input stream is detected, set the bluez5.autoswitch-profile property to true:
<pre>
/etc/pipewire/media-session.d/bluez-monitor.conf

...
rules = [
{
...
actions = {
update-props = {
...
bluez5.autoswitch-profile = true
...
</pre>

=== Screen sharing on Wayland ===

You will need the right [https://github.com/flatpak/xdg-desktop-portal xdg-desktop-portal] backend for your desktop environment. Screen sharing is known to work on:
* GNOME with <code>xdg-desktop-portal-gtk</code>
* KDE Plasma with <code>xdg-desktop-portal-kde</code> and Firefox
* Sway with <code>xdg-desktop-portal-wlr</code> and Firefox

== Usage ==

Start the PipeWire media server. You'll probably get quite a few errors but just ignore them for now.

<pre>
$ pipewire
</pre>

In a different terminal window check the default output device. I don't yet know how this default can be changed for all applications, so you'd better hope it's right!

<pre>
# apk add pipewire-tools
$ pw-cat -p --list-targets
</pre>

Test sound is working using an audio file in a format supported by [http://www.mega-nerd.com/libsndfile/ libsndfile] (e.g. flac, opus, ogg, wav).

<pre>
$ pw-cat -p test.flac
</pre>

If you have a microphone test audio recording is working.

<pre>
$ pw-cat -r --list-targets
$ pw-cat -r recording.flac
(Speak for a while then stop it with Ctrl+c)
$ pw-cat -p recording.flac
</pre>

Test PulseAudio clients using a media player (most use PulseAudio) and if you use JACK test that too:

<pre>
# apk add jack-example-clients
$ jack_simple_client
</pre>

You should hear a sustained beep.

If you are happy everything is working, make PipeWire start automatically when your X or Wayland session starts. For example, you could add the <code>pipewire</code> command to <code>~/.xinitrc</code> or your window manager's config file.

== Troubleshooting ==

=== `pw-cat -p --list-targets` shows no targets ===

First, check whether ALSA knows about your sound card:

<pre>
aplay -l
</pre>

If sound devices are found, the issue is with your pipewire configuration. Consider double-checking the instructions above.

Otherwise, your sound card may not be supported in the version of the Linux Kernel you're running. You should search online for fixes relating to your current kernel version and the codec of your sound card. You can find each of these with:

<pre>
uname -r
cat /proc/asound/card0/codec* | grep Codec
</pre>

== See Also ==

* [https://gitlab.freedesktop.org/pipewire/pipewire PipeWire source repository]
* [https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/home PipeWire Wiki]
* [https://wiki.archlinux.org/index.php/PipeWire PipeWire on the ArchWiki]
* [https://wiki.gentoo.org/wiki/Pipewire PipeWire on the Gentoo Wiki]

[[Category:Multimedia]]

How to get regular stuff working

2020-07-02T05:22:07Z

Anjanmomi: man package is now mandoc

== Man pages ==

Not all man-pages are in Alpine, but this will get you most of the way there:

'''apk add mandoc man-pages mdocml-apropos less less-doc'''
'''export PAGER=less'''

The above only provides ''core'' man pages. Other packages typically don't include their own man pages (nor other documentation). Rather, they provide an associated package that carries such stuff. For example:

$ '''apk add curl'''
$ '''man curl'''
man: No entry for curl in the manual.
$ '''apropos curl | wc -l'''
0 ''After adding curl, there are no man pages''
$ '''apk add curl-doc'''
(1/1) Installing curl-doc (7.52.1-r2)
Executing mdocml-apropos-1.13.3-r6.trigger
OK: 60 MiB in 31 packages
$ '''apropos curl | wc -l'''
366 ''Now, with curl-doc installed, there's a boatload of pages!''

'''NOTE:''' Not all packages separate out their documentation, but it is the ''Alpine Way'' (e.g. small footprint). Some packages don't provide any installable documentation at all, neither within themselves nor an associated doc packages. Further, appending "-doc" is merely a convention. In fact, the core man documentations are in man-pages (as in the ''apk add ...'' command, above). To find the right documentation package, try something like:

$ '''apk search gcc | grep ^gcc'''
gcc-objc-5.3.0-r0
gcc-gnat-5.3.0-r0
gcc-5.3.0-r0
gcc-java-5.3.0-r0
gcc-doc-5.3.0-r0 ''Here it is!''

'''FINALLY:''' If you're wondering why I've added ''less'' (and ''less-doc''), it's because ''man'' doesn't work correctly with ''more'' (the default pager). Don't fret too much about bloating up Alpine, though - adding man pages has a bigger footprint than less (''"less is more than man"???'')

== Operational hints ==

==== Shell @ commandline ====

Alpine comes with busybox by default. Busybox is an endpoint for numerous symlinks for various utilities. Though busybox is not that bad, the commands are impaired in functionality.

* Funny characters at the console
Edit the file at {{Path|/etc/rc.conf}} and change line 92 to:
unicode="YES"

* Bash
It is easy enough to have bash installed, but this does not mean the symlinks to busybox are gone.

Install bash with:
apk add bash bash-doc bash-completion

* Shell utilities (things like grep, [[awk]], ls are all busybox symlinks)
apk add util-linux pciutils usbutils coreutils binutils findutils grep

* /etc/{shadow,group} manipulation requires
apk add shadow

==== Disk Management ====

Disk management is so much easier with udisks or udisks2

Installation

apk add udisks2 udisks2-doc

See the mounted disks

udisksctl status

== Compiling : a few notes and a reminder ==

Compiling in Alpine may be more challenging because it uses [http://www.musl-libc.org/ musl-libc] instead of glibc. Please review [http://wiki.musl-libc.org/wiki/Functional_differences_from_glibc 'The functional differences with glibc' ] if you think of porting packages or just for the sake of knowing, of course.

Alpine offers the regular compiler stuff like gcc and cmake ... possible others

==== (unvalidated) apk packages to install so one can start building software ====
apk add build-base gcc abuild binutils binutils-doc gcc-doc

==== a complete install for cmake looks like ====

apk add cmake cmake-doc extra-cmake-modules extra-cmake-modules-doc

==== ccache is also available ====

apk add ccache ccache-doc

[[Category:Installation]]