From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: A secure multimedia workstation Date: Tue, 10 Feb 2015 16:45:40 +0100 Message-ID: References: <87y4o9xqts.fsf@gnu.org> <20150209182303.GA24693@debian> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54720) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLD0c-0006Wh-70 for guix-devel@gnu.org; Tue, 10 Feb 2015 10:45:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YLD0X-0007Zf-A2 for guix-devel@gnu.org; Tue, 10 Feb 2015 10:45:54 -0500 Received: from pegasus.bbbm.mdc-berlin.de ([141.80.25.20]:57767) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLD0W-0007Yt-V7 for guix-devel@gnu.org; Tue, 10 Feb 2015 10:45:49 -0500 In-Reply-To: List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Dirk Scheuring Cc: guix-devel@gnu.org Dirk Scheuring writes: > This is interesting. You seem to make packaging much easier than I > thought it would be. I wonder why that is. It really *is* rather simple. I come from a background of packaging RPMs by writing spec files and I find packaging for Guix much less painful (to the point where it actually becomes fun). > running it. For example, Ricardo Wurmus (1) recently added Ardour (2), a > popular Digital Audio Workstation. Ardour depends on JACK Audio > Connection Kit (3), as do many applications in the Linux Audio > ecosystem. Multimedia distros like Ubuntu Studio and KXStudio include > JACK, plus a kernel version compiled with the -lowlatency flag, to > prevent dropouts/xruns when you're doing multichannel audio recording in > Ardour, which might also have other samplers, synthesizers and drum > machines feeding into it for playback, through JACK. So you want a > kernel that prioritizes audio throughput above all else. > > I wouldn't know whether such a kernel was available for Guix currently, > and if it wasn't, I wouldn't know how to compile one, and make it > available. I would have to learn these things first, before I could > start packaging something like Ardour. At least, so I thought. A realtime kernel is not currently available, but there have been discussions about simplifying the specification of custom kernel packages by providing a wrapper function that takes a kernel configuration file. Ardour works without a realtime kernel (and I have been using it in the past with stock kernels for many years). You can prevent xruns by increasing JACK buffers. This increases latency, but for recording where you don't need to listen to effects processing in realtime (i.e. if you use direct monitoring on your equipment) this is not an issue. Dependent on your workflow your requirements may differ. Still, the Ardour package itself does not need a realtime kernel as an explicit input, so from a packager's perspective this is a non-issue. > Moreover, there are production workflows which depend on Ardour being > connected to other programs (5) which in turn depend on JACK. So I > thought that I would have to track down all those interdependencies > between programs, and include knowledge about them, libraries, etc. in > the package receipt. I have to learn how to do that before I can > seriously contribute, don't I? When I packaged Ardour I looked at the immediate dependencies. If they were not yet available (like JACK or LV2) I packaged those first. Once all build dependencies were satisfied I could build Ardour successfully. Now, there are production workflows that require certain LV2 plugins, for example. But Ardour itself does not depend on them. Ardour, using LV2, looks up plugins in the LV2_PATH, a variable listing directories in which LV2 plugin bundles are to be found. At runtime you can modify this variable and make available to Ardour whatever plugin you have installed, long after Ardour was built. So you don't have to learn about these interdependencies because they don't really matter much to packaging. In some cases programmes are not as flexible as Ardour/LV2 and they look at hard-coded paths (e.g. CUPS with its filters). Only in these cases a little more effort is required. > Also, not all audio applications support JACK. PulseAudio tends to fight > with JACK, both trying to grab the audio hardware, but several other > popular apps use PulseAudio, rather than JACK, as their audio > server. The solution here is to configure PulseAudio to pipe its output > into JACK, and as I'm trying to find out how to do that (6), I stumble > across the remark > > "I performed the following changes to the files in /etc/pulse" > > when I realize that there is no /etc/pulse in Guix! Rather, the > configuration files are represented - as is everything else - by their > contribution to the hash values in /nix/store. Or that's how I currently > understand it. Guix (the package manager) and the Guix System Distribution (the GNU system based on Guix and other GNU software, or GNU GSD for short) are different things. While Guix only stores stuff in /gnu/store/, the system distribution may have "global" configuration files like any other system. I have not yet played with Pulseaudio on GNU GSD, but I'm confident that Pulseaudio does not insist on /etc/pulse for its configuration. AFAIR, Pulseaudio also supports per-user configuration. > So it seems like I have to learn how to map the relevant parts of the > LSB to /nix/store, and I will also have to find out which parts are > relevant for any program I have to include in my package, and I have to > learn how to express this information in my receipt, so that the build > process can use it successfully. And the deeper I crawl into this rabbit > hole, the longer my list of known unknowns grows, while unknown unknowns > remain unknown. I figured it might take me a while to work through all > this, given that I have other jobs, and a family. > > Or am I overcomplicating things here? Thanks for any advice, You probably are overcomplicating things :) Packaging up software is relatively straight-forward; configuring the system itself with good defaults out of the box less so. As a packager you don't have to worry much about system configuration. Most user software does not expect to run as a system-wide service and thus does not need any special configuration at build time. ~~ Ricardo