We have “restructured” our repositories and have new names and serve new purposes. Where previously there were:

* stable  - tested builds (close to empty)
* testing - untested builds
* experimental - devel builds (almost always empty)

We now have:

* production - verified PKGBUILDs AND tested packages (hope to fill this up)
* preview - unverified PKGBUILDs AND/OR untested packages
* nightly - verified devel PKGBUILDs (automated nightly/daily builds soon)
* experimental - unverified devel PKGBUILDs  (automated nightly/daily builds soon)

Please check out the ‘packages’ page for further details and update your pacman configuration file:

# verified PKGBUILDs AND tested packages
[archaudio-production]
Server = http://repos.archaudio.org/$repo/$arch
 
# unverified PKGBUILDs AND/OR untested packages
[archaudio-preview]
Server = http://repos.archaudio.org/$repo/$arch
 
# verified devel PKGBUILDs
[archaudio-nightly]
Server = http://repos.archaudio.org/$repo/$arch
 
# unverified devel PKGBUILDs
[archaudio-experimental]
Server = http://repos.archaudio.org/$repo/$arch

There is a lot of room for improvement, but a one- or two-man show is not always enough. That is why we have created a separate forum for feedback and suggestions. For obvious issues or feature requests, please use the bugtracker.

Our long-term goal is to eventually have deep integration between the website and external databases, such as the VCS and package repositories. We have a standalone bugtracker in review currently, and we intend to replace our Flyspray installation with it. We also look forward to having an easier VCS contribution process (with regards to setting up permissions and the like).

On other news, there is work in progress currently to have an automated build system for a nightly repository of development builds. We will try to reflect all of our work in Subversion including that of
the website (under the “projects” directory) so that anyone may join in the fun.

That would be all for this announcement – til next time!

From now onwards, we will be posting any updates regarding audio packages that happen in the Arch Linux (semi-)official repositories.

Recent additions include:

* extra/slv2
* extra/libffado
* community/jack2
* community/jack2-dbus (split from jack2)
* community/ardourvst
* community/linuxsampler
* community/jsampler
* community/gigedit

That’s right, extra/ardour now has LV2 support and extra/jack is now built against libffado, needing it (optionally) to provide FireWire support. Without it, jackd will complain about the nonexistent library, but otherwise that’s not a problem for those without a FireWire device.

An interesting point to note is that jack2 is actually a build of both jackdbus and jackd, i.e it uses the “–classic” and “–dbus” flags together. This is due to the fact that a D-Bus-aware JACK can be useful for general-purpose multimedia (and of course for some niche audio tools that work with D-Bus), in particular PulseAudio. At the same time, the default binary is jackd, so the standard “professional” workflow is unaffected.

Unfortunately, D-Bus JACK control/monitor applications cannot be used with this combination, and so a dedicated D-Bus build is provided as jack2-dbus. Do note that a D-Bus-only JACK does not provide a jackd binary, but a jackdbus one instead. The standard workflow most users have become accustomed to will be broken in this case.

More information about this D-Bus business is on the JACK Wiki.

Another thing you might’ve noticed is that qsampler did not get a promotion like jsampler. This is simply because it fails to build.

Moving on, some not-so-recent additions that were previously housed here and you happen to be looking in the wrong place:

* community/patchage
* community/qtractor
* community/dssi-vst

Not really an addition, but extra/ecasound is now an improved package thanks to fellow Arch Linux pro-audio user Philipp “hollunder” Überbacher, informing us of more optional dependencies and subsequently the power of the program itself. Philipp has even begun writing a front-end in Lua (please do not ask; it’s unreleased).

We would also like to take this opportunity to let you know that our site is getting an overhaul soon (OK I know we are not that trustworthy when it comes to schedules but do expect it). Aside from that, our repositories will start to concentrate more on development/nightly/daily builds. We realise now that there is no need to worry about popular audio packages not being available for Arch Linux – anyone can nudge a Trusted User to take on a package from AUR. The situation is even better now as there’s been a number of new additions to the Arch Linux team in general.

Our internal repository management is going to be improved as well. Tools have been added and are being extended to make it easier for anyone to contribute. We are still lacking manpower, and we hope these tools will encourage potential contributors who are keen but afraid of a laborious workflow.

Til next time

Our repositories contain a good deal of packages of graphical software that may break due to this update, so we request that you hang tight and report such packages to the forums instead of the bugtracker (since we still do not have a proper list).

In the meantime, we will of course be hunting these packages down ourselves, but the rebuilds if necessary will take a little time.

Thank you for the patience!

It has been brought to our attention that FireWire users may be in for a nasty surprise, particularly, those who have yet to update their Arch Linux systems. Details are scarce as of this moment in writing, but a reporter [1] just came in with a story which should shed the most light [2].

OK, not really; it’s really simple. There are two kinds, or “stacks”, of FireWire subsystems in the kernel. One is old, and one is new. The old one is, well, an older stack, and is no longer provided. The new, well, is a more recent stack [3] with nicer module names which came with a recent kernel, which in turn was recently brought to us by Arch Linux [4]. FFADO was somewhat ready for this, but not completely (neither was Linux itself, maybe). Hence, this situation.

We do not think this warrants an update to our primary realtime kernel, since there is no such thing as 2.6.32-rt yet. However, you may like to know that the latest Linux comes with a new “make localmodconfig” which will definitely speed up your builds. If not, you may want to refrain from updating or roll back somehow.

On another note, you may have been expecting an update to the server-going-down article, so take this as one (although we brought things back up 2 weeks after that). The lack of an update can be attributed to the feeling of “incompleteness”, because we had a number of things in the TODO which we wanted to get done.

But never fear, we’re here – even when we’re not. So be good, be evil, and have a happy new year!

[1] http://forums.archaudio.org/topic/kernel-2632-firewire-and-jack-ffado-big-mess
[2] http://www.ffado.org/?q=node/1316
[3] http://ieee1394.wiki.kernel.org/index.php/Juju_Migration
[4] http://www.archlinux.org/news/477/

Within days, JACK 0.117.0 was superseded by 0.118.0, fixing a couple of urgent issues including that of a command line switch. Please read the release notes at the JACK website. Package-related differences from archlinux/extra are detailed in the changelog [pacman -Qc].

As for Ardour, the most significant change is that we do not build with syslibs. We are unsure why the Arch Linux package does, since aside from a library duplication “mess”, it does nothing but eliminate upstream support – and that should be against our KISS mantra (Tobias is still an awesome packager, so I think it is time for a bug report at the Arch tracker). Other than LV2, we have also enabled Wiimote support.

The nice thing is that our guidelines dictate that we thoroughly ensure dependencies are no more and no less, so cwiid is buildtime mandatory and runtime optional. We have dealt with jack* much the same way; ffado and celt. This is made possible because (a) we are rolling-release and (b) functionality is not lost – just the harmless missing library complaints if any. If you do not own a Wii Remote, a FireWire interface, or have no need for NetJACK, then this should be good news. The ardour* packages also come with a fixed dependency of liblrdf, since any update to that (or raptor) will most certainly break your guitar (we are not responsible).

As always, problems are to be reported at our bugtracker, before you run..swim upstream. On a side-note, Ardour 3 is ready for alpha-testing, but anyone interested should get it manually. This means no PKGBUILD for you, let alone a binary, and we do not encourage it even for AUR. That is, of course, until upstream says it is OK for testing on a bigger scale.

And one more thing, you do not “install” waf - it is an internal build utility

[1]

We (no wait..I?) finally decided that it’s time we moved something to stable, and none other than kernel26rt qualifies to be the first among the few. We’ve not forgotten to move the dependent packages either, and this so far only means nvidia-rt as we do not see how the binary ATI drivers or the virtualization stuff for example are going to fit in. So now you must add the repo to your list.

Reminder: x86_64 users, you have to WAIT =p

# /etc/pacman.conf
...
[archaudio-stable]
Server = http://repos.archaudio.org/stable/i686 # or x86_64
 
[archaudio-testing]
Server = http://repos.archaudio.org/testing/i686

[2]

So we got around to actually adding more useless things to our repos (no wait..I actually didn’t ask anyone for permission! *runs*), and this time they’re arrogantly called kernel26icedrt (in the spirit of Iced Tea)and kernel26daw. We plan to provide the PAE versions as well, and the latter will also get its Iced flavour in due time, preferably named kernel26icedaw. This is subject to change if and when another one of us decides differently.

So what’s the deal with these? Well, firstly, the icedrt is actually an “adaptation” of kernel26-ice from AUR. That is to say, we realised that a combination of realtime and some of those patches are in fact no cause for major disasters, and as such we rolled our own (we use different buildscripts).

Then we have this new daw thing. You guessed right, it’s our BFS-patched offering – for pro audio users. We couldn’t possibly name it kernel26bfs because there’s a possibility someone would like to have both installed, and for that there’s a kernel26-bfs in AUR. It does look like it needs a lot more love, though. So the current tentative list, which may be withdrawn at any time given our manpower to maintain these (well actually it’s just 2 different “branches”):

* kernel26rt
** kernel26rtpae
* kernel26icedrt
** kernel26icedrtpae

* kernel26daw
** kernel26dawpae
* kernel26icedaw
** kernel26icedawpae

Some clarification on the use or lack, of hyphens: They’re a hindrance. On the filesystem (eg. /usr/{lib,src}), it doesn’t matter, but for package names, we don’t want something which requires you to exercise “terminal stretching” when searching. In short, we like to keep things short.

This rounds up our absence from frontpage since the last update, and we hope you keep on rocking with Arch or whatever your poison is right now.

edit: Packages will still appear in testing until we replace them with bleeding builds.

For now, become Hercules:

# /etc/pacman.conf
...
[archaudio-testing]
Server = http://repos.archaudio.org/testing/i686 # or x86_64

Take a look at the “Packages” page for more details.