[PlanetCCRMA] Advice on installing non-CCRMA sources (or I'm an Adult Now)

[Fernando Lopez-Lezcano]

On Wed, 2005-05-11 at 15:06, Shayne O'Connor wrote:
> i've gradually found myself installing/using/testing latest CVS versions
> of some of the CCRMA packages - stuff like Ardour, Muse, Hydrogen, Jack,
> Alsa, the kernel etc etc ... i know how to do most of them without
> running into conflicts with the CCRMA versions (most install over the
> top of the  CCRMA versions, or are able to be uninstalled without too
> many dramas).
> 
> however, the latest CVS of Ardour says this:
> 
>      * add compile-time check for jack_recompute_latencies()
>        * libardour: 0.891.4
> 
>     If you use an older version of JACK, you will be able to build Ardour,
>     but JACK port "total latencies" will not be updated in a timely
>     fashion, which can lead to some odd results some of the time.
> 
> so i got the cvs version of Jack, compiled (prefix=/usr) and installed
> it, did a "jackd --version" (jackd version 0.99.70 tmpdir /tmp protocol
> 15), compiled/installed Ardour ... but when building Ardour, it said:
> 
>     Checking for jack_client_open()...failed
>     >Checking for jack_recompute_total_latencies()...failed
> 
> Paul Davis said this:
> 
>     i suspect you have inadvertently done a dual install of JACK.
> 
> so, i went and searched for all the Jack files installed in /usr,
> deleted them, reinstalled Jack, tried compiling Ardour again, but the
> same failed check for jack_client_open and
> jack_recompute_total_latencies ...
> 
> so - what's the proper way for me to totally uninstall old Jack packages
> - can't really do it through Synaptic because it wants to remove about
> 50 other multi-media apps .... also - is there any special configuration
> options that Jack needs?

A way to uninstall a package is to do an "rpm -e --nodeps package_name",
but that of course leaves the rpm database in an inconsistent state (ie:
there are dependencies that are not met). 

Hmmmm... to get rid of all files you could do (with care) something like
this:
  rpm -q -l package_name > files
look at the files in the file "files" (;-) and then erase them. 

That will get rid of all the files in the package without erasing the
package itself from the rpm database. If you do an "rpm -V package_name"
you will see rpm complaining about the missing files :-)

> ***********************
> 
> 
> onto the kernel - i compiled/installed the latest kernel (2.6.12.rc4
> with rt-pre-empt patch and patched pam), which is something i just
> learned to do recently .... i don't usually build the RT-pre-empt patch,
> but i decided to give it a go last night. i built it with
> PRE-EMPT=DESKTOP, or whatever, and there were a few other options, but
> it ended up looking (through rtirq) a little bit different to what i
> remember the Planet's RT-preempt looked like:
> 
>     [mrmachine at localhost ~]$ /etc/init.d/rtirq status
> 
>       PID CLS RTPRIO  NI PRI %CPU STAT COMMAND
>      1218 FF      70   - 110  0.0 S<   IRQ 5        EMU10K1
>      1348 FF      60   - 100  0.0 S<   IRQ 3        ehci_hcd
>      1400 FF      60   - 100  0.0 S<   IRQ 4        ohci_hcd
>      1362 FF      59   -  99  0.1 S<   IRQ 11       ohci_hcd
>       288 FF      50   -  90  0.0 S<   IRQ 1        i8042
>         9 FF      49   -  89  0.0 S<   IRQ 9        acpi
>       234 FF      49   -  89  0.0 S<   IRQ 12       i8042
>       266 FF      47   -  87  0.0 S<   IRQ 14       ide0
>       268 FF      46   -  86  0.0 S<   IRQ 15       ide1
>      2114 FF      40   -  80  0.1 S<   IRQ 10       nvidia
>      2590 FF      39   -  79  0.0 S<   IRQ 7        parport0
> 
> 
> i'm sure that "RTC" is missing from the top of this list .... should I
> have said "Yes" to the option to pre-empt Real Big Clock (or something
> like that) that it gives when doing "make config"?

I think that options only applies when building with PREEMPT_RT but I
may be wrong. You could download the kernel .src.rpm, unpack it, and
compare the config file you are using with the one in the Planet CCRMA
kernel source package...

-- Fernando