On Tue, 2006-04-18 at 13:19 -0400, Adrian Likins wrote:
On Mon, Apr 17, 2006 at 05:39:06PM -0700, Fernando Lopez-Lezcano
> I'm attaching my current unedited (ie: not edible by Fedora Extras :-)
> spec file for Jack... This is for CVS of the clock_fix branch, which
> fixes problems with low level timing on dual core Athlon processors (you
> also need a recent kernel that does not select the TSC for internal
> timing on those processors to make everything work correctly)
> Ah, I forgot - if you are using a proper "preempt" kernel then you also
> want Rui Nuno Capella's rtirq script (also part of Planet CCRMA) which
> optimizes the priority of irq processes to favor audio i/o - that's
> mentioned in the jack spec file, that's why I remembered.
Seems to build for me using mock to build it into a fc-devel build
No changes? That's a good start...
I don't think I build the right cvs branch though, since I just
the "jack-get-cvs" to build a tarball from cvs and built that with the spec
provided. So I just built HEAD so far.
The one I'm building is this:
cvs -d:pserver:firstname.lastname@example.org:/cvsroot/jackit login
cvs -z3 -d:pserver:email@example.com:/cvsroot/jackit co
The latest jack-get-cvs has this built in but the SRPM was not out for
that particular one because I was only doing internal testing, but I
just made it available:
This is not the latest jack but it is the latest with the clock fixes.
Jack used to use the TSC directly for internal high resolution timing
but that is impossible in the latest dual core Athlons where the TSC's
from the two processors can and do drift apart over time.
What are you using for your build system?
I'm using mach - still using apt for the build environment, I have to
switch to yum, the build root is in RAM (for speed) unpacked for each
build from a tar.gz snapshot. I have a set of scripts for handling
builds, snapshots, etc, they define "fcx" for each distribution so that
conditional things in the spec files work fine - I use one spec file to
build on different versions of rh/fc. They also define a release postfix
that becomes part of the release field (currently "rhfcx.ccrma") for
id'ing each rpm. I think the "bare" environment I use is too sparsely
populated so there will be more build dependencies in the spec file than
are probably needed for the redhat build system (I prefer to include as
few default packages as possible but that's just me).