Alpine Linux - User contributions [en]

Creating patches

2018-04-08T15:25:38Z

Pickfire: Fix new aport syntax

Patches should be created with git and submitted to [mailto:alpine-aports@lists.alpinelinux.org alpine-aports] mailing list with ''git send-email''.

== Only the last commit with 'git send-email' ==

To submit the last commit as a patch to [mailto:alpine-aports@lists.alpinelinux.org alpine-aports] mailing list:

{{Cmd|git send-email --to alpine-aports@lists.alpinelinux.org -1}}

{{Tip|You save the To-address (does not require '--to alpine-aports@lists.alpinelinux.org') in the git config with: {{Cmd|git config sendemail.to alpine-aports@lists.alpinelinux.org}}}}

The first line in commit message will be ''subject'' and the long description (separated with empty line) will be the body in the email. The example below shows

<pre>
testing/packagename: new aport <- header

https://example.com/packagename <- body
wonderful package
</pre>

{{Note|The git send-email command is provided by the '''git-email''' package ('''git-perl''' in v2.7 and older). }}

See [[Development using git#Email_configuration]] on how configure SMTP Auth.

== Multiple commits with 'git send-email' ==

If you have many commits you can create a directory with patches and send them with <tt>git send-email</tt>.

{{Cmd|<nowiki>rm -Rf patches
mkdir patches
git format-patch -o patches origin
git send-email patches --compose --no-chain-reply-to --to alpine-aports@lists.alpinelinux.org</nowiki>}}

You can also format patches for the last x number of commits with:
{{Cmd|<nowiki>git format-patch -x -o patches</nowiki>}}

This will produce the patches for each local commit in the directory "patches" and send them.
Use '''--no-chain-reply-to''' to avoid that each patch is sent as a ''reply'' to the previous patch.

Eg.
* [PATCH 0/m]
** [PATCH 1/m]
*** [PATCH 2/m]
**** ...

With the option '''--no-chain-reply-to''' the patches will be sent as a reply to the first email, the ''cover letter'' (the [PATCH 0/m]) and will make the email thread nicer.
Like this:
* [PATCH 0/m]
** [PATCH 1/m]
** [PATCH 2/m]
** ..

== Resend an updated patch ==
Sometimes patches are rejected due to minor issues in the patch. Do not send an incremental patch on top of your initial, bad, patch. Instead, recreate the patch and send a new, fixed version of your patch. (use ''git commit --amend'' to edit a local commit).

When you sending a second version of the patch use '''--subject-prefix "PATCH v2"''' to indicate that this is a new version of a previously sent patch. You may also use '''--in-reply-to <message-id>''' where <message-id> the the id of email requesting the resend.

You should also write a note on the what was changed. Use '''--annotate''' for this and write the comment under the three dashes "---" so the note is not included in the commit message. For example:
<pre>
...
Subject: [PATCH v2] testing/mypackage: new aport

https://example.com
Example package
---
Changes v1 -> v2:
- removed depends
- added zlib-dev to makedepends

testing/mypackage/APKBUILD | 41 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 41 insertions(+)
create mode 100644 testing/mypackage/APKBUILD
...
</pre>

Note that the notes that are below the "---" will not be included in the commit message.
[[Category:Development]]
[[Category:Git]]

== See also ==
* [[Patch Workflow]]

Creating an Alpine package

2018-04-08T15:20:30Z

Pickfire: Update git hook to show default content

== 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 Freenode's #alpine-devel on IRC.

== Creating an APKBUILD file ==

=== Use a template APKBUILD ===

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

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

{{:Include:Newapkbuild}}

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

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

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

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

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

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

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

"$pkgdir"/somedir

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

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

=== APKBUILD variables/functions ===

==== source ====

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

Here are few things to note:

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

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

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

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

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



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

==== depends & makedepends ====

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

No kidding, lots of important information can be found it the package INSTALL and README file (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. A good example is for instance "--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 the package builder but please try to follow Alpine's design concept as much as possible.

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

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

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

{{Cmd|scanelf -nR pkg}}

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

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

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

==== license ====

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

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

If a package has a special/custom license or is not listed as [https://opensource.org/licenses/alphabetical OSI approved] we need to provide it 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 license of the source code, please contact the author and ask him 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 (ie, 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 usefully 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 if you change something to 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 add the missing dependency. When there's an upstream version changes, 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 package is installed. Can be used to generate font cache and similar.

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

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

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

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

</dl>

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

...
</pre>

==== subpackages ====

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

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

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

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

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

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

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

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

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

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

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

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. Way's to create them are:

directory compare:

{{Cmd|diff -urp 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, we could create offset for the next patch. To make sure we always patch in a specified way we should number the patches as followed:

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

This way we are always sure patch 1 is first and if we want to add additional patches between them we can use 11,12,21,22...

Add names of the patch files to the ''source'' variable. If you haven't declared custom ''prepare'' function, then it's all what you need to do. Otherwise call ''default_prepare'' in your ''prepare'' function, for example:

prepare() {
default_prepare

# do your stuff
}

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

In Alpine >=3.4 you can define patch_args to supply the patch level. It 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 it and it is discussed below.

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

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

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

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

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

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

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

Just do something like:

<pre>
makedepends="patchutils"

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

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

==== Configure options ====

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

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

==== Make options ====

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

make

To disable parallel we use:

make -j1

We can use the same for make install.

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

make DESTDIR="$pkgdir" install

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

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

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

==== Additional files ====

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

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

== Build the package ==

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

{{Cmd|cd $pkgname
abuild checksum}}

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

{{Cmd|abuild -r}}

== Testing the package locally ==

When it completes, your package will be found in a subfolder of ''~/packages''. 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.

To install the package, you could:
{{Cmd|sudo apk add /home/<USER>/packages/testing/x86_64/$pkgname-$pkgver.apk}}

Or, modify your /etc/apk/repositories so that it points to your local ARCH/APKINDEX.tar.gz. Change USER to your login name.

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

== 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 (_).
# Remove unnecessary new lines.
# 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

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 you local git repo.

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

NOTE: when using our github repo, you can create PR's for each package. Please squash all commits into a single one per PR.

{{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 pull request to [https://github.com/alpinelinux/aports/ Alpine's mirror on GitHub] (read instructions [https://github.com/alpinelinux/aports/blob/master/.github/CONTRIBUTING.md here]).

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

To create a diff patch:

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

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

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

== Travis CI and automated testing ==

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

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

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

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

== Send a patch ==

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

== GitHub Tagging ==

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

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

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

[[Category:Development]]

Wayland

2017-03-16T06:53:40Z

Pickfire: /* XDG_RUNTIME_DIR */ Fix style

Wayland is a new display protocol that aims to replace X11.

== XDG_RUNTIME_DIR ==
Weston and other compositors require the XDG_RUNTIME_DIR variable to be set. Simply save the following script in /etc/profile.d/xdg_runtime_dir.sh and re-login to have it set up properly.

if test -z "${XDG_RUNTIME_DIR}"; then
export XDG_RUNTIME_DIR=/tmp/$(id -u)-runtime-dir
if ! test -d "${XDG_RUNTIME_DIR}"; then
mkdir "${XDG_RUNTIME_DIR}"
chmod 0700 "${XDG_RUNTIME_DIR}"
fi
fi

This code was taken from Weston's build instructions. Only ${UID} (not present on Alpine Linux) has been replaced with $(id -u).

Wayland

2017-03-16T06:53:01Z

Pickfire: Make reading flow better

Wayland

2017-03-16T06:52:10Z

Pickfire: /* XDG_RUNTIME_DIR */ Align script

Wayland is a new display protocol, that aims to replace X11.

== XDG_RUNTIME_DIR ==
Weston and other compositors require the XDG_RUNTIME_DIR variable to be set. Simply save the following script in /etc/profile.d/xdg_runtime_dir.sh and re-login to have it set up properly.

if test -z "${XDG_RUNTIME_DIR}"; then
export XDG_RUNTIME_DIR=/tmp/$(id -u)-runtime-dir
if ! test -d "${XDG_RUNTIME_DIR}"; then
mkdir "${XDG_RUNTIME_DIR}"
chmod 0700 "${XDG_RUNTIME_DIR}"
fi
fi

This code was taken from Weston's build instructions. Only ${UID} (not present on Alpine Linux) has been replaced with $(id -u).

Creating an Alpine package

2017-03-14T06:03:20Z

Pickfire: /* Commit your work */ Fix APKBUILD grep

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

== 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 create a daemon package which needs initd scripts you can add the -c making it:

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

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

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

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

"$pkgdir"/somedir

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

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

=== APKBUILD variables/functions ===

==== source ====

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

Here are few things to note:

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

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

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

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

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



* abuild currently supports the following archive types/archive file extensions:
** .tar.gz / .tgz
** .tar.bz2
** .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 it the package INSTALL and README file (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. A good example is for instance "--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 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).

* [http://www.gentoo-portage.com Search ebuilds]
* [http://sources.gentoo.org/viewcvs.py/gentoo-x86/ Gentoo CVS]
* [http://www.archlinux.org/packages/search/ Arch Linux packages] [https://aur.archlinux.org/ Arch Linux User Repository]

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

{{Cmd|scanelf -nR pkg}}

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

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

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

==== license ====

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

{| cellpadding="5" border="1" class="wikitable"
|-
! Short name
! Full name
|-
| GPL2
| GNU General Public License Version 2.0
|-
| LGPL2+
| GNU Lesser General Public License Version 2.1
|-
| ASL 2.0
| Apache License Version 2.0
|-
| BSD
| BSD License
|-
| MIT
| MIT license
|-
| MPL 2.0
| Mozilla Public License v2.0
|-
| ZPL 2.0
| Zope Public License v 2.0
|-
| PHP
| PHP License v3.0
|-
| zlib
| zlib/libpng License
|-
|}

For the GNU General Public License the '+' means ''or (at your option) any later version.'' which covers future releases of that license. We skip the ''v'' because it's obvious that the number shows the version. If you are unsure about the short name of a license, please check the resources below for additional information.

* [https://wiki.archlinux.org/index.php/Licenses ArchLinux and Licensing]
* [https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Good_Licenses Fedora and Licensing]

If a package has a special/custom license we need to provide it 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.

==== 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 (ie, 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 usefully 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 if you change something to your APKBUILD file without changing the actual $pkgver you can higer 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 add the missing dependency. When there's an upstream version changes, 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 package is installed. Can be used to generate font cache and similar.

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

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

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

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

</dl>

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

...
</pre>

==== subpackages ====

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

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

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

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

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

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

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

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

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

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

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

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. Way's to create them are:

directory compare:

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

file compare:

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

Because multiple patches can patch the same file, we could create offset for the next patch. To make sure we always patch in a specified way we should number the patches as followed:

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

This way we are always sure patch 1 is first and if we want to add additional patches between them we can use 11,12,21,22...

Add names of the patch files to the ''source'' variable. If you haven't declared custom ''prepare'' function, then it's all what you need to do. Otherwise call ''default_prepare'' in your ''prepare'' function, for example:

prepare() {
default_prepare || return 1

# do your stuff
}

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

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

{{Tip|Common steps for building package contain ''./configure'', ''make'' and ''make install''. Everyone of them should be enclosed by ''|| return 1'' to check exit status. Otherwise even if previous step fails e.g. ''./configure'', next will be launched e.g. ''make''. This complicates identifying the point where the build breaks. The same applies to installing additional files.}}

==== 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 || return 1

To disable parallel we use:

make -j1 || return 1

We can use the same for make install.

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

make DESTDIR="$pkgdir" install

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

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

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

==== Additional files ====

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

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

== Build the package ==

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

{{Cmd|cd $pkgname
abuild checksum}}

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

{{Cmd|abuild -r}}

== Commit your work ==

After you successfully build your package 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 you local git repo.

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

NOTE: when using our github repo, you can create PR's for each package. Please squash all commits into a single one per PR.

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

In the commit message, add the following (remove the comments in the last four lines):

{{Cmd| # Please enter the commit message for your changes
#[snip]
#
testing/$pkgname: new aport # this will be the subject line
# a blank line
$pkgurl # homepage of project
$pkgdesc # a one line description}}

Or you could add the following to your `aports/.git/hooks/prepare-commit-msg` to automatically generate the commit message:

#!/bin/sh
case "$2,$3" in
,|template,)
if git status --porcelain | grep -q '^A.*APKBUILD$'; then
meta() { git diff --staged | grep "^+$1" | sed 's/.*="\?//;s/"$//';}
cat > "$1" <<EOF
testing/$(meta pkgname): new aport

$(meta url)
$(meta pkgdesc)
EOF
else
git status --porcelain | sed -n 's/...$.*$\/APKBUILD/\1: /p;T;q' > "$1"
fi;;
esac

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 pull request to [https://github.com/alpinelinux/aports/ Alpine's mirror on GitHub] (read instructions [https://github.com/alpinelinux/aports/blob/master/.github/CONTRIBUTING.md here]).

Alternatively you can also create a diff (patch) of the changes you made and send this patch to the
[http://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]]

[[Category:Development]]

Raspberry Pi 3 - Configuring it as wireless access point -AP Mode

2017-03-07T07:39:31Z

Pickfire: style

=Copy the necessary firmware files=

Create a directory named /firmware/brcm on the root directory of your boot media as it will be automatically copied to /lib/firmware/brcm in the next boot.

Please make sure to include the following files namely brcmfmac43430-sdio.bin and brcmfmac43430-sdio.txt in /firmware/bcrm/ folder of your boot media

Download from https://github.com/RPi-Distro/firmware-nonfree/tree/master/brcm80211/brcm

=Install hostapd and dnsmasq=

apk add hostapd
apk add dnsmasq

=Configure /etc/hostapd/hostapd.conf=

interface=wlan0
driver=nl80211
ssid=Pi3-AP
hw_mode=g
channel=1
macaddr_acl=0
auth_algs=1
wpa=2
wpa_key_mgmt=WPA-PSK
wpa_passphrase=raspberry
rsn_pairwise=CCMP
wpa_pairwise=CCMP

=Configure your /etc/dnsmasq.conf=

interface=wlan0
dhcp-range=10.0.0.2,10.0.0.5,255.255.255.0,12h

=Configure Static ips for wlan0 in the file /etc/network/interfaces=

auto wlan0
iface wlan0 inet static
address 10.0.0.1
netmask 255.255.255.0

=Start the services=

service dnsmasq start
service hostapd start

=Enable the Services permanently on every bootup=

rc-update add dnsmasq
rc-update add hostapd

(to del)

rc-update del dnsmasq
rc-update del hostapd

(or)

rc-update add dnsmasq boot
rc-update add hostapd boot

(to del)

rc-update del dnsmasq boot
rc-update del hostapd boot

=Commit all changes to files=

Make sure you run the below command to commit all changes otherwise they will be lost on reboot

lbu ci

=References=
https://gist.github.com/atlury/fe0ea8b91a981c103df7

https://frillip.com/using-your-raspberry-pi-3-as-a-wifi-access-point-with-hostapd/

Thanks
oneinsect@gmail.com

Creating an Alpine package

2017-03-05T10:31:13Z

Pickfire: /* Commit your work */ Improve git hook to detect updates to aport

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

== 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 create a daemon package which needs initd scripts you can add the -c making it:

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

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

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

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

"$pkgdir"/somedir

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

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

=== APKBUILD variables/functions ===

==== source ====

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

Here are few things to note:

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

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

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

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

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



* abuild currently supports the following archive types/archive file extensions:
** .tar.gz / .tgz
** .tar.bz2
** .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 it the package INSTALL and README file (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. A good example is for instance "--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 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).

* [http://www.gentoo-portage.com Search ebuilds]
* [http://sources.gentoo.org/viewcvs.py/gentoo-x86/ Gentoo CVS]
* [http://www.archlinux.org/packages/search/ Arch Linux packages] [https://aur.archlinux.org/ Arch Linux User Repository]

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

{{Cmd|scanelf -nR pkg}}

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

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

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

==== license ====

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

{| cellpadding="5" border="1" class="wikitable"
|-
! Short name
! Full name
|-
| GPL2
| GNU General Public License Version 2.0
|-
| LGPL2+
| GNU Lesser General Public License Version 2.1
|-
| ASL 2.0
| Apache License Version 2.0
|-
| BSD
| BSD License
|-
| MIT
| MIT license
|-
| MPL 2.0
| Mozilla Public License v2.0
|-
| ZPL 2.0
| Zope Public License v 2.0
|-
| PHP
| PHP License v3.0
|-
| zlib
| zlib/libpng License
|-
|}

For the GNU General Public License the '+' means ''or (at your option) any later version.'' which covers future releases of that license. We skip the ''v'' because it's obvious that the number shows the version. If you are unsure about the short name of a license, please check the resources below for additional information.

* [https://wiki.archlinux.org/index.php/Licenses ArchLinux and Licensing]
* [https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Good_Licenses Fedora and Licensing]

If a package has a special/custom license we need to provide it 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.

==== 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 (ie, 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 usefully 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 if you change something to your APKBUILD file without changing the actual $pkgver you can higer 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 add the missing dependency. When there's an upstream version changes, 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 package is installed. Can be used to generate font cache and similar.

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

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

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

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

</dl>

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

...
</pre>

==== subpackages ====

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

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

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

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

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

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

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

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

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

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

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

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. Way's to create them are:

directory compare:

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

file compare:

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

Because multiple patches can patch the same file, we could create offset for the next patch. To make sure we always patch in a specified way we should number the patches as followed:

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

This way we are always sure patch 1 is first and if we want to add additional patches between them we can use 11,12,21,22...

Add names of the patch files to the ''source'' variable. If you haven't declared custom ''prepare'' function, then it's all what you need to do. Otherwise call ''default_prepare'' in your ''prepare'' function, for example:

prepare() {
default_prepare || return 1

# do your stuff
}

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

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

{{Tip|Common steps for building package contain ''./configure'', ''make'' and ''make install''. Everyone of them should be enclosed by ''|| return 1'' to check exit status. Otherwise even if previous step fails e.g. ''./configure'', next will be launched e.g. ''make''. This complicates identifying the point where the build breaks. The same applies to installing additional files.}}

==== 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 || return 1

To disable parallel we use:

make -j1 || return 1

We can use the same for make install.

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

make DESTDIR="$pkgdir" install

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

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

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

==== Additional files ====

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

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

== Build the package ==

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

{{Cmd|cd $pkgname
abuild checksum}}

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

{{Cmd|abuild -r}}

== Commit your work ==

After you successfully build your package 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 you local git repo.

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

NOTE: when using our github repo, you can create PR's for each package. Please squash all commits into a single one per PR.

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

In the commit message, add the following (remove the comments in the last four lines):

{{Cmd| # Please enter the commit message for your changes
#[snip]
#
testing/$pkgname: new aport # this will be the subject line
# a blank line
$pkgurl # homepage of project
$pkgdesc # a one line description}}

Or you could add the following to your `aports/.git/hooks/prepare-commit-msg` to automatically generate the commit message:

#!/bin/sh
case "$2,$3" in
,|template,)
if git status --porcelain | grep -q '^A. APKBUILD'; then
meta() { git diff --staged | grep "^+$1" | sed 's/.*="\?//;s/"$//';}
cat > "$1" <<EOF
testing/$(meta pkgname): new aport

$(meta url)
$(meta pkgdesc)
EOF
else
git status --porcelain | sed -n 's/...$.*$\/APKBUILD/\1: /p;T;q' > "$1"
fi;;
esac

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 pull request to [https://github.com/alpinelinux/aports/ Alpine's mirror on GitHub] (read instructions [https://github.com/alpinelinux/aports/blob/master/.github/CONTRIBUTING.md here]).

Alternatively you can also create a diff (patch) of the changes you made and send this patch to the
[http://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]]

[[Category:Development]]

Talk:LXC

2017-02-23T16:05:28Z

Pickfire: Add unpriviledged containers with shadow-uidmap

= Alternative Network Setup =

These are notes on macvlan on a box with real vlans. The goal here is to have the host on a management vlan, and several guests each on other vlans. There's no need for the host to talk to the guests. The host resides on the "OOB" network, and if the host needs to talk to a guest, it does so with lxc-console, like having a KVM. Each guest should get its address from the DHCP server on the appropriate vlan.Something like this:

Setup:
{| class="wikitable" border="1"
|-
| host
| dhcp on vlan 8
|-
| guest1
| dhcp on vlan 64
|-
| guest2
| dhcp on vlan 129
|-
| guest3
| dhcp on vlan64 (different address)
|}

* Host's /etc/network/interfaces file
auto lo
iface lo inet loopback

# MGMT vlan
auto eth0.8
iface eth0.8 inet dhcp
hostname lxchost

# USR vlan - we bring it up, but dont assign an address
auto eth0.65
iface eth0.65 inet manual
up ip link set $IFACE addr de:ad:be:ef:ca:fe
up ip link set $IFACE up
down ip link set $IFACE down

# VoIP vlan - we bring it up, but dont assign an address
auto eth0.129
iface eth0.129 inet manual
up ip link set $IFACE addr 0f:f1:ce:c0:ff:ee
up ip link set $IFACE up
down ip link set $IFACE down

* Here's /etc/lxc/lxc.conf
lxc.network.type = macvlan
# Allow guests on the same vlan to see each other
lxc.network.macvlan.mode = bridge
lxc.network.link = eth0.65
lxc.network.name = eth0
# lxc.network.hwaddr = de:ad:be:ef:c0:00 # macvlan will make one up, but possible if wanted
# lxc.network.flags = up # Do NOT bring up the interface, we will do so within the container
# lxc.network.ipv4 = 0.0.0.0 # Do NOT assign an address, we do so within the container

# Capabilities to drop (for instance, to stop the guest from mounting sys)
# Taken from http://sourceforge.net/mailarchive/message.php?msg_id=28285704
# sys_boot is not listed here, as it causes problems when the host tries to stop the guest

# If you trust the guest, then you can get by without dropping capabilities

lxc.cap.drop= sys_admin audit_control audit_write fsetid ipc_lock
lxc.cap.drop= ipc_owner lease linux_immutable mac_admin mac_override mknod setfcap
lxc.cap.drop= setpcap sys_module sys_nice sys_pacct sys_ptrace sys_rawio
lxc.cap.drop= sys_tty_config sys_time
* Create the guests
for a in `seq 1 3`; do
lxc-create -n guest${a} -f /etc/lxc/lxc.conf -t alpine
ln -s /etc/init.d/lxc /etc/init.d/lxc.guest${a}
done
* vi /var/lib/lxc/guest2/config
change lxc.network.link to eth0.129
* Start and enter the first guest (this is where the fun starts)
/etc/init.d/lxc.guest1 start
lxc-console -n guest1

=== Fun inside the guest ===

* /dev/null is currently created as a regular file
* /dev/zero doesn't exist

To create these, do the following from ''the host''

<pre>
rm -f /var/lib/lxc/[guest-name]/rootfs/dev/null
rm -f /var/lib/lxc/[guest-name]/rootfs/dev/zero
mknod /var/lib/lxc/[guest-name]/rootfs/dev/zero c 1 5
mknod /var/lib/lxc/[guest-name]/rootfs/dev/null c 1 3
</pre>

We do this in the host because our default config drops mknod capabilites in the guest.

=== What Works, What Doesnt ===
* Pro
** Each guest has its own mac address
** Network connectivity between each guest
** No communication allowed between host and guests (this is a plus in our case - managment vlan != user vlan)
** if iptables modules are loaded in the host, each guest can create its own iptables rules (awall for all! sweet)
* Con
** No communication allowed between host and guests because we are not using a bridge interface (this is a plus in our case - managment vlan != user vlan)

== About lxc-attach ==

I cannot conncect to any AL LXC build under AL... the response is always <pre>
infra:~# lxc-attach --name=git -- "ps ax"
lxc_container: attach.c: lxc_attach_to_ns: 196 Operation not permitted - failed to set namespace 'pid'
lxc_container: attach.c: lxc_attach: 844 failed to enter the namespace
</pre>
What did I possibly wrong? 
Or is it a bug in AL LXC?

=== Update about lxc-attach ===

'''LXC-host: lxc-attach fail with "lxc_attach_to_ns: 270 Operation not permitted - failed to set namespace 'pid'"'''

'''Issue:''' When you try to run lxc-attach, this fails. "use of CAP_SYS_ADMIN in chroot denied for /usr/bin/lxc-attach" appears in dmesg. 
'''Cause:''' This issue due to grsecurity restriction in the lxc host. 
'''Workaround:''' Add the following settings to your sysctl.conf file: 
<pre>
kernel.grsecurity.chroot_caps=0
kernel.grsecurity.chroot_deny_chmod=0
</pre>

Since those settings are read only at lxc host boot, and they have been applied in a second time, some of the lxc hosts might not have those settings loaded yet.
A simple workaround can be:

<pre>
echo 0 > /proc/sys/kernel/grsecurity/chroot_caps
echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_chroot
</pre>

or simply run:

<pre>sysctl -p</pre>

== Unprivileged containers ==

To use unprivileged containers, one needs to install shadow-uidmap and add 'name:100000:65536' to both /etc/subuid and /etc/subgid. Or they will get errors like:

unshare: Operation not permitted
read pipe: Permission denied
lxc-create: lxccontainer.c: do_create_container_dir: 985 Failed to chown container dir
lxc-create: tools/lxc_create.c: main: 318 Error creating container test

[[User:Pickfire|Pickfire]] ([[User talk:Pickfire|talk]]) 16:05, 23 February 2017 (UTC)

Creating an Alpine package

2017-02-22T07:32:14Z

Pickfire: /* Commit your work */ Add git hook to automatically generate commit message

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

== 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 create a daemon package which needs initd scripts you can add the -c making it:

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

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

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

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

"$pkgdir"/somedir

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

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

=== APKBUILD variables/functions ===

==== source ====

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

Here are few things to note:

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

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

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

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

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



* abuild currently supports the following archive types/archive file extensions:
** .tar.gz / .tgz
** .tar.bz2
** .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 it the package INSTALL and README file (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. A good example is for instance "--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 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).

* [http://www.gentoo-portage.com Search ebuilds]
* [http://sources.gentoo.org/viewcvs.py/gentoo-x86/ Gentoo CVS]
* [http://www.archlinux.org/packages/search/ Arch Linux packages] [https://aur.archlinux.org/ Arch Linux User Repository]

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

{{Cmd|scanelf -nR pkg}}

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

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

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

==== license ====

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

{| cellpadding="5" border="1" class="wikitable"
|-
! Short name
! Full name
|-
| GPL2
| GNU General Public License Version 2.0
|-
| LGPL2+
| GNU Lesser General Public License Version 2.1
|-
| ASL 2.0
| Apache License Version 2.0
|-
| BSD
| BSD License
|-
| MIT
| MIT license
|-
| MPL 2.0
| Mozilla Public License v2.0
|-
| ZPL 2.0
| Zope Public License v 2.0
|-
| PHP
| PHP License v3.0
|-
| zlib
| zlib/libpng License
|-
|}

For the GNU General Public License the '+' means ''or (at your option) any later version.'' which covers future releases of that license. We skip the ''v'' because it's obvious that the number shows the version. If you are unsure about the short name of a license, please check the resources below for additional information.

* [https://wiki.archlinux.org/index.php/Licenses ArchLinux and Licensing]
* [https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Good_Licenses Fedora and Licensing]

If a package has a special/custom license we need to provide it 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.

==== 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 (ie, 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 usefully 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 if you change something to your APKBUILD file without changing the actual $pkgver you can higer 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 add the missing dependency. When there's an upstream version changes, 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 package is installed. Can be used to generate font cache and similar.

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

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

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

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

</dl>

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

...
</pre>

==== subpackages ====

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

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

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

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

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

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

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

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

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

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

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

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. Way's to create them are:

directory compare:

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

file compare:

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

Because multiple patches can patch the same file, we could create offset for the next patch. To make sure we always patch in a specified way we should number the patches as followed:

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

This way we are always sure patch 1 is first and if we want to add additional patches between them we can use 11,12,21,22...

Add names of the patch files to the ''source'' variable. If you haven't declared custom ''prepare'' function, then it's all what you need to do. Otherwise call ''default_prepare'' in your ''prepare'' function, for example:

prepare() {
default_prepare || return 1

# do your stuff
}

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

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

{{Tip|Common steps for building package contain ''./configure'', ''make'' and ''make install''. Everyone of them should be enclosed by ''|| return 1'' to check exit status. Otherwise even if previous step fails e.g. ''./configure'', next will be launched e.g. ''make''. This complicates identifying the point where the build breaks. The same applies to installing additional files.}}

==== 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 || return 1

To disable parallel we use:

make -j1 || return 1

We can use the same for make install.

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

make DESTDIR="$pkgdir" install

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

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

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

==== Additional files ====

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

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

== Build the package ==

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

{{Cmd|cd $pkgname
abuild checksum}}

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

{{Cmd|abuild -r}}

== Commit your work ==

After you successfully build your package 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 you local git repo.

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

NOTE: when using our github repo, you can create PR's for each package. Please squash all commits into a single one per PR.

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

In the commit message, add the following (remove the comments in the last four lines):

{{Cmd| # Please enter the commit message for your changes
#[snip]
#
testing/$pkgname: new aport # this will be the subject line
# a blank line
$pkgurl # homepage of project
$pkgdesc # a one line description}}

Or you could add the following to your `aports/.git/hooks/prepare-commit-msg` to automatically generate the commit message:

#!/bin/sh
case "$2,$3" in
,|template,)
if git status --porcelain | grep -q '^A'; then
meta() { git diff --staged | grep "^+$1" | sed 's/.*="\?//;s/"$//';}
cat > "$1" <<EOF
testing/$(meta pkgname): new aport

$(meta url)
$(meta pkgdesc)
EOF
fi;;
esac

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 pull request to [https://github.com/alpinelinux/aports/ Alpine's mirror on GitHub] (read instructions [https://github.com/alpinelinux/aports/blob/master/.github/CONTRIBUTING.md here]).

Alternatively you can also create a diff (patch) of the changes you made and send this patch to the
[http://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]]

[[Category:Development]]

Raspberry Pi

2017-01-21T06:23:47Z

Pickfire: Show bind mount instead of automatically copy to boot partition

[[Category:Installation]]
This tutorial will help you install Alpine Linux on your Raspberry Pi.

== Preparation ==

This section will help you format and partition your SD card:

# [http://alpinelinux.org/downloads/ Download] Alpine for Raspberry Pi tarball which is named as <code>alpine-rpi-<version>-armhf.rpi.tar.gz</code>. You will need version 3.2.0 or greater if you have a Raspberry Pi 2.
# Mount your SD card to your workstation
# Use [https://en.wikipedia.org/wiki/GNOME_Disks gnome-disks] or [http://linux.die.net/man/8/fdisk fdisk] to create a FAT32 partition. If you are using fdisk, the FAT32 partition type is called ''W95 FAT32 (LBA)'' and its ID is 0xC.
# Mark the newly created partition as bootable and save
# Mount the previously created partition
# Extract the tarball contents to your FAT32 partition
# Unmount the SD Card.

== Installation ==

Alpine Linux will be installed as [[Installation#Installation_Handbook|diskless mode]], hence you need to use [[Alpine local backup|Alpine Local Backup (lbu)]] to save your modifications between reboots. Follow these steps to install Alpine Linux:

# Insert the SD Card into the Raspberry Pi and turn it on
# Login into the Alpine system as root. Leave the password empty.
# Type <code>setup-alpine</code>
# Once the installation is complete, commit the changes by typing <code>lbu commit</code>

Type <code>reboot</code> to verify that the installation was indeed successful.

== Post Installation ==

=== Update the System ===

Upon installation, make sure that your system is up-to-date:

{{cmd|apk update
apk upgrade}}

Don't forget to save the changes:

{{cmd|lbu commit}}

=== Clock-related error messages ===

During the booting time, you might notice errors related to the hardware clock. The Raspberry Pi does not have
a hardware clock and therefore you need to disable the hwclock daemon and enable swclock:

{{cmd|rc-update add swclock boot # enable the software clock
rc-update del hwclock boot # disable the hardware clock}}

Since Raspberry Pi does not have a clock, the Alpine Linux needs to know what the time is by using a
[https://en.wikipedia.org/wiki/Network_Time_Protocol Network Time Protocol (NTP)] daemon. Make sure that you a
NTP daemon installed and running. If you are not sure, then you can install NTP client by running the following
command:

{{cmd|setup-ntp}}

Busybox NTP client might be the most lightweight solution. Save the changes and reboot, once the NTP software is
installed and running:

{{cmd|lbu commit
reboot}}

After reboot, make sure that the <code>date</code> command outputs the correct date and time.

=== X11 Setup ===
Here are what you need if you want to try and run a single X11 application like a browser kiosk or maybe even a desktop: {{cmd|setup-xorg-base
apk add xf86-video-fbdev xf86-input-mouse xf86-input-keyboard dbus setxkbmap
rc-update add dbus}}

Also edit the default X11 module config: /etc/X11/xorg.conf.d/20-modules.conf
{{cmd|Section "Module"
Load "fbdevhw"
Load "fb"
Load "shadow"
Load "shadowfb"
Load "dbe"
Load "glx"
Disable "dri"
EndSection}}

Commit your changes:
{{cmd|lbu_commit}}

Now you should be able to run a browser or desktop. (Guides may follow)

If setup-xorg-base gives you an error regarding rc-update that fails to add mdev to sysinit just run:
{{cmd|rc-update mdev sysinit}}
to add it manually. If you skip this the next time you reboot your Raspberry Pi the screen maybe will not display anything on screen.

== Persistent storage ==

=== Loopback image with overlayfs ===

The install is in disk-less mode and forces everything into memory, if you want additional storage we need to create loop-back storage onto the SD mounted with overlayfs.

First make the sd-card writable again and change fstab to always do so:
{{cmd|mount /media/mmcblk0p1 -o rw,remount
sed -i 's/vfat\ ro,/vfat\ rw,' /etc/fstab}}

Create the loop-back file, this example is 1 GB:

{{cmd|dd if=/dev/zero of=/media/mmcblk0p1/persist.img bs=1024 count=0 seek=1048576}}

Install the ext utilities:

{{cmd|apk add e2fsprogs}}

Format the loop-back file:

{{cmd|mkfs.ext4 /media/mmcblk0p1/persist.img}}

Mount the storage:

{{cmd|echo "/media/mmcblk0p1/persist.img /media/persist ext4 rw,relatime,errors=remount-ro 0 0" >> /etc/fstab
mkdir /media/persist
mount -a}}

Make the overlay folders, we are doing /usr here, but you can do /home or anything else:

{{cmd|mkdir /media/persist/usr
mkdir /media/persist/.work
echo "overlay /usr overlay lowerdir=/usr,upperdir=/media/persist/usr,workdir=/media/persist/.work 0 0" >> /etc/fstab
mount -a}}

Your /etc/fstab should look something like this:
{{Cmd|/dev/cdrom /media/cdrom iso9660 noauto,ro 0 0
/dev/usbdisk /media/usb vfat noauto,ro 0 0
/dev/mmcblk0p1 /media/mmcblk0p1 vfat rw,relatime,fmask=0022,dmask=0022,errors=remount-ro 0 0
/media/mmcblk0p1/persist.img /media/persist ext4 rw,relatime,errors=remount-ro 0 0
overlay /usr overlay lowerdir=/usr,upperdir=/media/persist/usr,workdir=/media/persist/.work 0 0}}

Now commit the changes: (optionally remove the e2fsprogs, but it does contain repair tools)
{{cmd|lbu_commit}}

Remember with this setup, if you install things and you have done this overlay for /usr, you must not commit the 'apk add', otherwise while it boots it will try and install it to memory and not to the persist storage.

If you do want to install something small at boot you can use `apk add` and `lbu commit`.

If it is something a bit bigger then you can use `apk add` but then not commit it, it will be persistent (in /user), but do check everything you need is in that directory and not in folders you have not made persistent.

=== Traditional disk-based (sys) installation ===

{{Warning|This isn't yet supported by the Alpine setup scripts for Raspberry Pi. It requires manual intervention, and might break.}}

It is also possible to switch to a fully disk-based installation: this is not yet formally supported, but can be done somewhat manually. This frees all the memory otherwise needed for the root filesystem, allowing more installed packages.

Split your SD card into two partitions: the FAT32 boot partition described above (in this example it'll be <code>mmcblk0p1</code>) , and a second partition to hold the root filesystem (here it'll be <code>mmcblk0p2</code>). Boot and configure your diskless system as above, then create a root filesystem:

{{cmd|apk add e2fsprogs
mkfs.ext4 /dev/mmcblk0p2}}

Now do a disk install via a mountpoint. The <code>setup-disk</code> script will give some errors about syslinux/extlinux, but you can ignore these: the Raspberry Pi doesn't need this to boot anyway.

{{cmd|<nowiki>mkdir /stage
mount /dev/mmcblk0p2 /stage
setup-disk -o /media/mmcblk0p1/MYHOSTNAME.apkovl.tar.gz /stage
# (ignore errors about syslinux/extlinux)</nowiki>}}

Add a line to <code>/stage/etc/fstab</code> to mount the Pi's boot partition again:

{{cmd|/dev/mmcblk0p1 /media/mmcblk0p1 vfat defaults 0 0}}

Now add a <code>root=/dev/mmcblk0p2</code> parameter to the Pi's boot command line, either <code>cmdline-rpi2.txt</code> or <code>cmdline-rpi.txt</code> depending on model:

{{cmd|<nowiki>mount -o remount,rw /media/mmcblk0p1
sed -i '$ s/$/ root=\/dev\/mmcblk0p2/' /media/mmcblk0p1/cmdline-rpi2.txt</nowiki>}}

You might also consider <code>overlaytmpfs=yes</code> here, which will cause the underlying SD card root filesystem to be mounted read-only, with an overlayed tmpfs for modifications which will be discarded on shutdown.

Beware, though, that the contents of /boot will be ignored when the Pi boots: it will use the kernel, initramfs, and modloop images from the FAT32 boot partition. To update the kernel, initfs or modules, you will need to manually (generate and) copy these to the boot partition or you could use bind mount so that manually copy the files to boot partition is not needed.

{{cmd|<nowiki>echo /media/mmcblk0p1/boot /boot none defaults,bind 0 0 > /etc/fstab</nowiki>}}

== See Also ==

* [[Create a bootable SDHC from a Mac]]