ArchAudio

From ArchWiki

Jump to: navigation, search


Contents

Introduction

This page contains information related to a third-party initiative. You may be looking for Pro Audio and not even know it!

If you came here from another page, or were referred, you are probably interested in the ArchAudio repositories.

Read on if you are looking to contribute to the project, or are just plain bored.

Packaging

Prerequisite(s):

Getting Started

Take a look here.

Anyone and everyone keen on contributing source-based packages can start immediately, except for the unfortunate fact that we cannot automatically authenticate registered members to allow commits/check-ins. That is why we only request that you take the time to log on to our IRC channel, look for the user jonkristian, and send him a password hash. You can also PM the admin on the forums.

Password Hashing

As we talked about above, this is needed for anyone wanting to have some kind of write access to our subversion repository:

~$ htpasswd -cs $filename $username # you need to install apache for this tool

Or you can use the following web application: http://aspirine.org/htpasswd_en.html

Simply enter a username and password, change the algorithm to SHA-1, then click on "encrypt password". The output is what we want.

Buildscript Contributor

Since you would only have write access to the relevant parent directory, we recommended checking out with the full path:

~$ svn co https://svn.archaudio.org/trunk/buildscripts archaudio-sources --username=johndoe

Subversion Maintenance

It is always a good idea to make the following sanity checks a routine:

~$ svn stat
~$ svn merge --dry-run -r BASE:HEAD . # basically a more intuitive svn stat -u

And if you really cannot find out how to use SVN (man, wiki, google):

~$ svn add $somedir $somefile # to add to the repo (recursive)
~$ svn del $somedir $somefile # to delete

Warning: If you remove something without the svn command, Subversion will complain that it is missing since it is not aware of the removal.

~$ svn mv $oldname $newname # same warning applies; you cannot forget the svn before the mv!
~$ svn revert $somedir $somefile # well..revert your changes
~$ svn ci -m "$yourmessage" # to finally commit all changes

Binary Contributor

We suggest that you be well-acquainted with Arch Linux packaging. If you maintain packages in AUR you are on the right path.

You may want to checkout sparse directories so that you need not download all the uploaded binaries:

~$ svn co https://svn.archaudio.org/trunk/ ArchAudio --depth empty --username=johndoe

And then:

(
  cd ArchAudio
  svn up devel buildscripts
  svn up packages --depth immediates
  cd packages
  for i in experimental stable testing; do
    (cd $i && svn up i686 --depth empty) # or x86_64 depending on which you have permission to
  done
) # if you copy-pasted you have to press ENTER now

After that you can, at any time, view what is available:

cd ArchAudio/packages/testing/i686
svn ls

There is no need to checkout anything here at all, unless you want to do removal. In that case, simply download the file only:

svn ls | grep $unwantedpkg
svn up $unwantedpkgfullname
svn rm $unwantedpkgfullname
svn ci -m "Deleted obsolete package. Please make sure it doesn't exist in repo."
svn up --set-depth empty # in case there were multiple pkgs with the name eg. jack & jack2

Now for the interesting part - committing new packages and maintaining the sparseness of the working copy. Say, for example, you have already built a few packages and have copied it here in [testing/i686] (either manually or by makepkg's $PKGDEST). You just need to add them to the server and then revert back to sparse mode:

svn add *
svn ci -m "Added foobar, foobox, toolbar, toolbox, xbox."
svn up --set-depth empty

Build Environment

It is essential that your environment remains sane throughout all builds. As such, we recommend chrooting. You may have to:

~# pacman -Sy devtools aufs2-util
~# modprobe aufs

If you find yourself building often (ArchAudio or not), add aufs to your list of startup daemons. You may also need to patch makechrootpkg to make use of aufs instead of unionfs:

--- /usr/sbin/makechrootpkg.old	2008-11-28 18:57:18.000000000 +0800
+++ /usr/sbin/makechrootpkg	2009-06-22 01:03:09.903654612 +0800
@@ -106,14 +106,14 @@

 uniondir="$chrootdir/union"
 echo "building union chroot"
-grep -Fq unionfs /proc/filesystems
+grep -Fq aufs /proc/filesystems
 if [ $? -ne 0 ]; then
-    modprobe -q unionfs
+    modprobe -q aufs
     if [ $? -ne 0 ]; then
-        echo "ERROR: No unionfs available. Abandon ship!" && exit 1
+        echo "ERROR: No aufs available. Abandon ship!" && exit 1
     fi
 fi
-mount -t unionfs none -o "dirs=$chrootdir/rw=rw:$chrootdir/root=ro" "$uniondir"
+mount -t aufs none -o "dirs=$chrootdir/rw=rw:$chrootdir/root=ro" "$uniondir"
 trap 'cleanup' 0 1 2 15
 
 if [ -n "$install_pkg" ]; then

Packaging Guidelines

We will try to have a proper outline in our subversion docs directory, but generally:

  • Use tools such as namcap and those from pacman-contrib as complementary solutions
  • Look out for other useful development utilities in the Arch Linux MLs or Forums
  • Most often you have to rely on yourself and "manual labour" to determine correct dependencies
  • Always ensure a binary installs and runs as expected
  • Try to keep in touch with upstream developers of packages you regularly update
  • Always check upstream for critical changes if an update does not go smoothly

Naming Conventions

Sometimes, software release names are more suited for developers and can be confusing for users. For instance, LV2 is the successor to LADSPA, but it is not really an "SDK" per se. Since all that is provided (and needed) is a core set of headers, the tarball is released as "lv2core". Often, such a naming can imply that there is more to the software than just those core specifications, like, perhaps an "lv2full".

As for "jack-audio-connection-kit", the fact that it is so long already qualifies it for renaming. We do not want to be expanding recursive acronyms, now, do we?

Currently, the following are upstream software (release tarballs) and their respective package names in our repository:

  • lv2core: lv2
  • jack-audio-connection-kit: jack
  • jack-1.9.2: jack2
  • jackdmp: jack2-svn

Realtime Kernel

Specific prerequisite(s):

As long as there is no user demand for another, we will roll just one kernel. This will be called kernel26rt, and will be indefinitely based on the stock Arch Linux kernel, kernel26.

In the event that you want to start from scratch, you can just:

~$ cp -r /var/abs/core/kernel26 .

Since the realtime patch can move really fast, and provided that Linux Audio itself is an experimental paradigm, the buildscripts should be as flexible as possible (contrast this to "portable") to allow for quick user updates. If you take a look at our PKGBUILD, you will notice a number of custom variables:

...
_realkernel=      # actual basekernel eg. for rc builds
_kernelpatch=
_rtpatch=
...

# If sources are rc, old rc, old rt, rc & old rt, old rc & old rt:
# rc, rc-old, rt-old, rc-rt-old, all-old or blank for default
_source=

...
[ "$_source" = "rc" ] && _rc=testing/
[ "$_source" = "rc-old" ] && _rc=testing/v$_realkernel/
[ "$_source" = "rt-old" ] && _rt=older/
...
...

Simply said, this amount of "tainting" is necessary to retain the simplicity; making the PKGBUILD flexible without compromising portability. On kernel updates, you have to compare the two PKGBUILDs for differences and reflect those needed onto ours. Remember - we want to maintain as much compatibility as possible. One of the final steps usually involves checking out what patches kernel26 includes (eg. AUFS, which is important):

~$ git clone http://projects.archlinux.org/git/linux-2.6-ARCH.git

Read PATCHCFG and reproduce the patching lines for our PKGBUILD. For example:

# add aufs2 support, in reference to:
# http://aufs.sourceforge.net
aufs2-20090611.patch%1

translates to:

source=(...
        ...
        aufs2-20090611.patch)

build() {
        ...
        patch -Np1 -i ../aufs2-20090611.patch
        ...

The files are available under the patches directory. But of course, if only life were so simple! The patches used in both packages will obviously be different if they are version-dependent, especially in this case where the aufs patch is for *30, whereas the version of kernel26rt is *29. Sometimes, you may even have to custom-roll your own patchset (grab upstream patch and diff on rt-patched kernel)! Anyway, for aufs you can take a look at their website:

o aufs2-standalone tree
$ git clone http://git.c3sl.ufpr.br/pub/scm/aufs/aufs2-standalone.git \
	 aufs2-standalone.git
$ cd aufs2-standalone.git
$ git checkout origin/aufs2-xx	# for instance, aufs2-27 for linux-2.6.27
			              # aufs2 (no -xx) for the latest -rc version.

And grab the kbuild patch, resulting in:

~$ patch -Np1 -i ../aufs2-kbuild.patch

Hopefully the order should not matter, but a general rule to follow is that you should apply the realtime patch last.

Personal tools